ICEfaces
  1. ICEfaces
  2. ICE-4989

ResourceRegistry should document or change session-bound constraint

          Details

          • Type: Bug Bug
          • Status: Closed
          • Priority: Major Major
          • Resolution: Fixed
          • Affects Version/s: 1.8.2, 1.8.2-EE-GA
          • Fix Version/s: 1.8.2-EE-GA_P01, 1.8.3
          • Component/s: Framework
          • Labels:
            None
          • Environment:
            n/a

            Description

            The ResourceRegistry registers resources for the ResourceDispatcher to serve. As the ResourceDispatcher is tied to the MainSessionServlet, this constrains the ResourceRegistry to only be able to successfully register request or session-scoped resources, and prevents it from being able to use application-scoped resources. This is a large constraint for a registry designed "to be used by the component renderers to load Javascript code, CSS rules, and also register any kind of resource the component renderer needs". The limitation should be documented in the ResourceRegistry or the ResourceRegistry should not be tied to a session-bound servlet.

              Activity

              Ascending order - Click to sort in descending order
              Hide
              Permalink
              Deryk Sinotte added a comment -

              Mircea, we need to comment on this request during work on the next 1.8.x cycle.

              Show
              Deryk Sinotte added a comment - Mircea, we need to comment on this request during work on the next 1.8.x cycle.
              Hide
              Permalink
              Ted Goddard added a comment -

              Resources can point to objects shared in application scope and be shared that way. Philip, can you provide some sample code that shows the problem? Is it memory use that is the concern?

              Show
              Ted Goddard added a comment - Resources can point to objects shared in application scope and be shared that way. Philip, can you provide some sample code that shows the problem? Is it memory use that is the concern?
              Hide
              Permalink
              Philip Breau added a comment -

              Not really, if you use an application-scoped bean to register a resource, and then try to expose a registered URI that the API provides for that resource to the page, that URI is bound to the current session, not to the entire application. The resource has to be re-registered for all sessions. We ran into this with the composite components where we were registering images and icons through the Resource API to be used in the components. This was originally done in application-scoped beans. We found that only the first session (where the app scoped beans are first created) would be able to access the resources through the generated URI provided by the Resource API. If another session tried to access the same URI, they would receive a 404 as the API would only look into the current session. This stems from the fact that the SessionBoundServlet is used to store the pool of registered resources, and that is, by definition, bound to the current session.

              Show
              Philip Breau added a comment - Not really, if you use an application-scoped bean to register a resource, and then try to expose a registered URI that the API provides for that resource to the page, that URI is bound to the current session, not to the entire application. The resource has to be re-registered for all sessions. We ran into this with the composite components where we were registering images and icons through the Resource API to be used in the components. This was originally done in application-scoped beans. We found that only the first session (where the app scoped beans are first created) would be able to access the resources through the generated URI provided by the Resource API. If another session tried to access the same URI, they would receive a 404 as the API would only look into the current session. This stems from the fact that the SessionBoundServlet is used to store the pool of registered resources, and that is, by definition, bound to the current session.
              Hide
              Permalink
              Mircea Toma added a comment - - edited

              The current API and its implementation might not be the most efficient one but it covers more that 80% of the use cases. The rest of 20% where application wide dynamic resources need to be registered it's perfectly acceptable to register the application wide resource for each user session. Normally resource's data won't be copied for each user session, the registered resources will just act as pointers to the application wide data.
              The current behavior also manages to free the user from resource cleanup since the application developer does not have to track resource usage by the different active sessions and discard resources when not in use.

              Show
              Mircea Toma added a comment - - edited The current API and its implementation might not be the most efficient one but it covers more that 80% of the use cases. The rest of 20% where application wide dynamic resources need to be registered it's perfectly acceptable to register the application wide resource for each user session. Normally resource's data won't be copied for each user session, the registered resources will just act as pointers to the application wide data. The current behavior also manages to free the user from resource cleanup since the application developer does not have to track resource usage by the different active sessions and discard resources when not in use.
              Hide
              Permalink
              Mircea Toma added a comment -

              Updated ResourceRegistry javadocs to better describe current behavior.

              Show
              Mircea Toma added a comment - Updated ResourceRegistry javadocs to better describe current behavior.
              Hide
              Permalink
              Ken Fyten added a comment -

              Doesn't seem to be a commit for this on the icefaces-ee/branches/icefaces-ee-1.8.2_P01 branch.

              Show
              Ken Fyten added a comment - Doesn't seem to be a commit for this on the icefaces-ee/branches/icefaces-ee-1.8.2_P01 branch.
              Hide
              Permalink
              Mircea Toma added a comment -

              Updated Javadocs in EE branch as well.

              Show
              Mircea Toma added a comment - Updated Javadocs in EE branch as well.

                People

                • Assignee:
                  Unassigned
                  Reporter:
                  Philip Breau
                • Votes:
                  0 Vote for this issue
                  Watchers:
                  0 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved: