ServletContextUriLocator does not work on WebSphere 6.1

[GoogleCodeExporter]

What steps will reproduce the problem?
1. create a resource bundle using static resources
2. run it on WebSphere
3. First request for the CSS-bundle will fail. If the model and cache is 
reloaded the next request will also fail. 

What is the expected output? What do you see instead?
Should return the bundles CSS. Returns the CSS gziped, but because all the 
individual request for each CSS to be bundled fails (response already 
committed) wro4j is not able to update the header for the final bundled 
response. Thus the client does not get the Content-Encoding ("gzip") and etag 
header. Following requests will get the correct CSS bundle. 

What version of the product are you using? On what operating system?
1.4.4

Please provide any additional information below.
I have implemented a simplified solution which works well not using the 
requestDispather to locate the other resources. It only relies on the 
servletContext (as I would expect). 

Original issue reported on code.google.com by ivarc...@gmail.com on 29 Feb 2012 at 10:12

Attachments:

• StaticWebResourceLocator.java

[GoogleCodeExporter]

Original comment by alex.obj...@gmail.com on 29 Feb 2012 at 11:26

• Changed state: Accepted

[GoogleCodeExporter]

As commented in ServletContextUriLocator, the dispatcherStreamLocator is used 
first for a reason. Your implementation serves the stream from servletContext 
only. 

Probably a good idea would be to make the order configurable. 

You would use it this way:

new ServletContextUriLocator().setUseDispatcherFirst(false). 

The name of the method should be different (have to think more about a good 
name example). 

This way, no new UriLocator implementation is required and it can be easily 
plugged in into the UriLocatorFactory.

What do you think?

Original comment by alex.obj...@gmail.com on 29 Feb 2012 at 3:17

[GoogleCodeExporter]

I guess the dispatherStreamLocator is used to allow bundling of dynamic 
resources (produced by a servlet or jsp)?? But why should 
ServletConextUriLocator support bundling of dynamic resources as part of the 
normal behavior? To me it seems more natural to have this achieved with a 
specialized UriLocator. 

I think at least the ServletConextUriLocator should be configurable to drop the 
dispather-based-resolving. A name for this could be: 
new ServletContextUriLocator().disableDispatcherBasedLocator(true)

Original comment by ivarc...@gmail.com on 29 Feb 2012 at 6:13

[GoogleCodeExporter]

You can't have a different locator, since you use the same uri to describe 
servletContext relative resource.

Dynamic resource bundling does make sense for some use-cases. A good example is 
javascripts generated by DWR, which are available only at runtime. 

Disabling dispatcher based locator would work, but I think it would have the 
same effect as changing the order of locators (servletContext first, then 
dispatcher) based on configuration.. 

Considering that, would you still want to be able to disable the dispatcher 
based locator? After all, it is possible to make this locator configurable and 
it would be possible to override this behavior.

Original comment by alex.obj...@gmail.com on 29 Feb 2012 at 6:26

[GoogleCodeExporter]

I buy your DWR argument. The order should be configurable and users with other 
needs should override which locators they use (and create their own custom 
one). 

Original comment by ivarc...@gmail.com on 29 Feb 2012 at 6:31

[GoogleCodeExporter]

I agree that behavior should be configurable. 
Would you like to update the current implementation this way? 

Since it is easy to create a new uriLocator, I think that any custom behavior 
can be achieved by creating a new locator implementation (from scratch). The 
only advantage of making the ServletContextUriLocator configurable, is that the 
client can reuse a lot of existing code..

Original comment by alex.obj...@gmail.com on 29 Feb 2012 at 6:39

[GoogleCodeExporter]

Yes I would be happy to. 

Original comment by ivarc...@gmail.com on 29 Feb 2012 at 6:42

[GoogleCodeExporter]

Any contribution is welcome. You can fork the project from github and fix this 
issue in a separate branch. (Start from 1.4.x branch - main development branch).

Original comment by alex.obj...@gmail.com on 29 Feb 2012 at 6:44

[GoogleCodeExporter]

Original comment by alex.obj...@gmail.com on 1 Mar 2012 at 10:52

• Added labels: Milestone-Release-1.4.5

[GoogleCodeExporter]

Original comment by alex.obj...@gmail.com on 2 Mar 2012 at 10:00

• Changed state: Fixed

[GoogleCodeExporter]

The solution for this task is setting a custom locator strategy for UriLocator, 
example:
new 
ServletContextUriLocator().setLocatorStrategy(LocatorStrategy.SERVLET_CONTEXT_FI
RST).

Setting LocatorStrategy.SERVLET_CONTEXT_FIRST strategy solves the websphere 
related problem. 

Note that by default, another strategy is used: 
LocatorStrategy.DISPATCHER_FIRST (which preserves current behavior).

Original comment by alex.obj...@gmail.com on 3 Mar 2012 at 8:18