MyFaces Core
  1. MyFaces Core
  2. MYFACES-3575

Disable relative location caching in DefaultFaceletFactory

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Later
    • Affects Version/s: 2.0.14, 2.1.8
    • Fix Version/s: None
    • Component/s: Extension Feature
    • Labels:
      None
    • Environment:
      Linux

      Description

      In some circumstances the caching of the relative location in the public Facelet getFacelet(String uri) in DefaultFaceletFactory is not desirable: e.g. return the mobile and full content version for the same URI, if the user changes the content type on the fly. Now this caching always causes the same content to be returned.
      Should it be possible to switch it off like it is done for other caches in this class with needsToBeRefreshed check and NO_CACHE_DELAY configuration parameter?

        Activity

        Hide
        Leonardo Uribe added a comment -

        In JSF 2.1 you can provide your custom FaceletCacheFactory and override that part. Since JSF 2.0 and 2.1 has few changes, there is no need to do something in JSF 2.0 branch, just try with 2.1 jars.

        Show
        Leonardo Uribe added a comment - In JSF 2.1 you can provide your custom FaceletCacheFactory and override that part. Since JSF 2.0 and 2.1 has few changes, there is no need to do something in JSF 2.0 branch, just try with 2.1 jars.
        Hide
        Leonardo Uribe added a comment -

        Implemented in JSF 2.1

        Show
        Leonardo Uribe added a comment - Implemented in JSF 2.1
        Hide
        Dmitry Kukushkin added a comment -

        Still no good, using 2.1.8. My problem is that in public Facelet getFacelet(String uri) relative location is unconditionally cached, while in my case _resolver.resolveUrl(path) can return different URLs for the same path, depending on the application's internal state. The caching of the outcome of _resolver.resolveUrl(path) breaks this.

        Show
        Dmitry Kukushkin added a comment - Still no good, using 2.1.8. My problem is that in public Facelet getFacelet(String uri) relative location is unconditionally cached, while in my case _resolver.resolveUrl(path) can return different URLs for the same path, depending on the application's internal state. The caching of the outcome of _resolver.resolveUrl(path) breaks this.
        Hide
        Dmitry Kukushkin added a comment -

        Still no good, using 2.1.8. My problem is that in public Facelet getFacelet(String uri) relative location is unconditionally cached, while in my case _resolver.resolveUrl(path) can return different URLs for the same path, depending on the application's internal state. The caching of the outcome of _resolver.resolveUrl(path) breaks this.

        Show
        Dmitry Kukushkin added a comment - Still no good, using 2.1.8. My problem is that in public Facelet getFacelet(String uri) relative location is unconditionally cached, while in my case _resolver.resolveUrl(path) can return different URLs for the same path, depending on the application's internal state. The caching of the outcome of _resolver.resolveUrl(path) breaks this.
        Hide
        Leonardo Uribe added a comment -

        Now I get it what you want. I don't think it could be possible, because this quickly leads to inconsistencies. Maybe what you are looking for is PrettyFaces, which allows to rewrite the url based on different conditions. No need to do anything here.

        Show
        Leonardo Uribe added a comment - Now I get it what you want. I don't think it could be possible, because this quickly leads to inconsistencies. Maybe what you are looking for is PrettyFaces, which allows to rewrite the url based on different conditions. No need to do anything here.
        Hide
        Dmitry Kukushkin added a comment -

        Is it not just making this _relativeLocations expiring, as it is done for _compositeComponentMetadataFacelets in the DefaultFaceletFactory class? This IMO will be more consistent instead.

        Show
        Dmitry Kukushkin added a comment - Is it not just making this _relativeLocations expiring, as it is done for _compositeComponentMetadataFacelets in the DefaultFaceletFactory class? This IMO will be more consistent instead.
        Hide
        Leonardo Uribe added a comment -

        _relativeLocations do not expire. Look again the code, and you'll see the code for compositeComponentMetadataFacelets is just a copy of the default one.

        Show
        Leonardo Uribe added a comment - _relativeLocations do not expire. Look again the code, and you'll see the code for compositeComponentMetadataFacelets is just a copy of the default one.
        Hide
        Dmitry Kukushkin added a comment -

        This is what I meant, why not to make _relativeLocations cache also expiring, like it is done for _compositeComponentMetadataFacelets?

        Show
        Dmitry Kukushkin added a comment - This is what I meant, why not to make _relativeLocations cache also expiring, like it is done for _compositeComponentMetadataFacelets?
        Hide
        Leonardo Uribe added a comment -

        They are two different things. I finally can see the problem, it could be good to have a logic here, but it should be solved at spec level.

        Show
        Leonardo Uribe added a comment - They are two different things. I finally can see the problem, it could be good to have a logic here, but it should be solved at spec level.
        Hide
        Leonardo Uribe added a comment -

        I have been thinking about this problem and the intention of _relativeLocations is prevent unnecessary calls to ExternalContext.getResource(). In theory a cache like this one should be inside ResourceResolver implementation, because that's the right location to do that caching. Also, that part is done there to prevent unnecessary URL parsing.

        The real problem is the whole hack proposed violates Partial State Saving (PSS) requeriments, because it allows to change the location of the templates for a given string pointing to a template. So, if there is a postback and something has changed the algorithm will fail.

        Show
        Leonardo Uribe added a comment - I have been thinking about this problem and the intention of _relativeLocations is prevent unnecessary calls to ExternalContext.getResource(). In theory a cache like this one should be inside ResourceResolver implementation, because that's the right location to do that caching. Also, that part is done there to prevent unnecessary URL parsing. The real problem is the whole hack proposed violates Partial State Saving (PSS) requeriments, because it allows to change the location of the templates for a given string pointing to a template. So, if there is a postback and something has changed the algorithm will fail.
        Hide
        Leonardo Uribe added a comment -

        I have been thinking about it and the problem should be solved at spec level, maybe in JSF 2.2 with multi-templating feature. For now, we cannot do anything in 2.0 / 2.1 without introduce other side effects. I'll close this one as later, because it will be discussed under JSF 2.2 topics.

        Show
        Leonardo Uribe added a comment - I have been thinking about it and the problem should be solved at spec level, maybe in JSF 2.2 with multi-templating feature. For now, we cannot do anything in 2.0 / 2.1 without introduce other side effects. I'll close this one as later, because it will be discussed under JSF 2.2 topics.

          People

          • Assignee:
            Leonardo Uribe
            Reporter:
            Dmitry Kukushkin
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development