javaserverfaces-spec-public
  1. javaserverfaces-spec-public
  2. JAVASERVERFACES_SPEC_PUBLIC-1121

FaceletCache: some caching is incorrectly done in DefaultFaceletFactory

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: 2.2 Sprint 13
    • Fix Version/s: None
    • Component/s: Facelets/VDL
    • Labels:
      None

      Description

      LU> I realized the FaceletCache API has a flaw.

      LU> The original code from facelets 1.1.x has logic to cache the
      LU> "conversion" between logical identifiers to find a specific facelet and
      LU> its related URL.

      LU> So inside DefaultFaceletFactory there is a map like this:

      LU> private Map<String, URL> _relativeLocations;

      LU> Checking the code deeper, I notice this cache store also the values
      LU> returned by the ResourceResolver.

      LU> Now suppose a scenario where you have a custom FaceletCache
      LU> implementation, and by some coincidence there is some mechanism to load/
      LU> unload some facelets in some way. Once a facelet is called,
      LU> relativeLocations will hold the same key/value pair, so if a facelet is
      LU> unloaded and then another one is loaded and it has the same association,
      LU> it will fail to find the new one.

      LU> A realistic scenario that will be part of JSF 2.2 spec is if you have
      LU> a jar with some composite components and facelet files. For two
      LU> different skins, there will be facelets with the same "logical
      LU> identifiers", but with different URL. This issue prevents change the
      LU> skins on the fly, because you can't clean that map.

      LU> Who should hold that map? It should be hold by FaceletCache, not by
      LU> FaceletFactory, because FaceletCache is the responsible to load/unload
      LU> and hold facelets into memory.

        Issue Links

          Activity

          Ed Burns created issue -
          Ed Burns made changes -
          Field Original Value New Value
          Link This issue depends on JAVASERVERFACES_SPEC_PUBLIC-777 [ JAVASERVERFACES_SPEC_PUBLIC-777 ]
          Ed Burns made changes -
          Assignee Ed Burns [ edburns ]
          Hide
          Ed Burns added a comment -

          Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.

          Show
          Ed Burns added a comment - Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.
          Ed Burns made changes -
          Priority Minor [ 4 ] Trivial [ 5 ]
          Manfred Riem made changes -
          Priority Trivial [ 5 ] Minor [ 4 ]
          Hide
          Manfred Riem added a comment -

          Set priority to Minor

          Show
          Manfred Riem added a comment - Set priority to Minor

            People

            • Assignee:
              Unassigned
              Reporter:
              Ed Burns
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:

                Time Tracking

                Estimated:
                Original Estimate - 1 day
                1d
                Remaining:
                Remaining Estimate - 1 day
                1d
                Logged:
                Time Spent - Not Specified
                Not Specified