ServletContextUriLocator fails to use requestDispatcher

[GoogleCodeExporter]

Hi!

ServletContextUriLocator fails to use the requestDispatcher. Using the private 
(injected) variable 'dispatcherLocator' returns a nullpointerexception on line 
217 (in version 1.7.3). Looking through the code I can't find any place where 
the locator is being injected with the correct objects, which would explain the 
issue.

As I'm not familiar with the code I can't really judge what the appropriate 
solution would be, so hence the error report instead of a pull request ;)

Used version: 1.7.3
Error occurs when trying to include a JSP file from a LESS stylesheet, but 
doesn't throw an exception as the Locator gracefully falls back to using the 
ServletContext.

Original issue reported on code.google.com by martijn....@gmail.com on 28 Feb 2014 at 2:44

[GoogleCodeExporter]

Could you provide more details (ideally a quick-start project)?
The dispatcherLocator is annotated with @Inject and is being injected during 
instantiation of the ServletContextUriLocator. If it is null, there is probably 
a test-case I'm not aware of.

Original comment by alex.obj...@gmail.com on 28 Feb 2014 at 2:50

• Changed state: Accepted

[GoogleCodeExporter]

I'll see if I can make something up.

The use case is a JSP include inside a CSS file (cssImport preprocessor). 
Perhaps that triggers something.

Original comment by martijn....@gmail.com on 28 Feb 2014 at 3:07

[GoogleCodeExporter]

I hacked up a test in my forked repository. You can find it here: 
https://github.com/baaym/wro4j/commit/47c339d718a07ba192882013780ab898d78dc074

The test is kind of dirty, as it starts a real jetty context, and I had to 
disable jsp/servlet dependencies to avoid conflicts with the jetty dependencies 
(*sigh*). Anyway, it should give you an opportunity to see the problem. I'll 
give it a shot to fix it too.

Original comment by martijn....@gmail.com on 2 Mar 2014 at 3:19

[GoogleCodeExporter]

Alright, so I did another hack 
(https://github.com/baaym/wro4j/commit/8444e373969a68c5a7c705b4c0a347b433f8822b)
. I forced the injection of locators, which fixes the problem.

In my case, the locators come from the DefaultUriLocatorFactory, which in turn 
loads all locators from DefaultConfigurableProvider, which holds an instance of 
DefaultLocatorProvider;

Now I don't know where to 'neatly' fix this issue, as I'm not familiar with the 
codebase. Hopefully someone can point that out to me?

Original comment by martijn....@gmail.com on 2 Mar 2014 at 4:05

[GoogleCodeExporter]

The fix is merged in branch 1.7.x.

Though I like the integration tests using jetty approach, I didn't integrate 
your changes because these would require using a different version of 
servlet-api which I would like to avoid for now. But I will try to find a 
similar approach (using arquillian probably or something else) to use for 
integration testing. 

Thanks.

Original comment by alex.obj...@gmail.com on 7 Mar 2014 at 11:24

• Changed state: Fixed
• Added labels: Milestone-Release-1.7.4

[GoogleCodeExporter]

Thanks for fixing! I didn't have the intention for the jetty tests to make it 
back into the main code anyway, as they were quite hacked up just to give you a 
use case of the bug. So I'm cool with that ;)

Original comment by martijn....@gmail.com on 8 Mar 2014 at 8:06