On 13-10-27 9:08 PM, Eric B wrote:
On 13-10-27 3:50 PM, Mick Semb Wever wrote:
basicTilesContainer.getAttributeContext(request)
should be returning a working AttributeContext for you.
It should not be null (or an empty deque) and should not be creating a
new one for you.
As AttributeContexts are pushed onto the stack, via
startContext(request), cascading attributes are copied over.
But you haven't configured any of your attributes to be cascading.
Can you try adding cascading="true" to your defaults list-attribute.
For example like
<put-list-attribute name="defaults" cascading="true">
<add-attribute value="{1}"/>
<add-attribute value="common"/>
</put-list-attribute>
I've tried with both cascade="true" and inherit="true", but neither seem to have any
effect. What I have noticed is that the only time the "correct"
context is pushed onto the stack is in BasicTilesContainer.render() (line 235)
when it is pushing the subContext onto the stack. Likely due to the
previous line: subcontext.inherit(definition), where definition seems to be the
attributes as listed in the tiles.xml file.
Otherwise, I don't really see anywhere that the "inherit" or "cascade" settings
make a difference. Do you know where in the code the cascade/inherit
settings are examined and where the necessary actions are supposed to take
place? B/c the code which retrieves the context from the stack is fairly
simple - if the context is on the stack, use it, otherwise create a new empty
one and push onto the stack
(BasicTilesContainer.getAttributeContext(request) - line 142).
Apparently, I was too hasty in my last message. Tiles.xml changes are usually picked up automatically, but for some reason, they weren't this time.
I restarted the server, and sure enough, with cascade="true", the list-attributes are pushed forward into the new context (still not sure where this
happens in the code). Consequently, they are properly retrieved.
So, am making some progress. However, am hitting more stumbling blocks. When OptionsRenderer is searching for the templates, I get the following
exceptions thrown:
java.lang.IllegalArgumentException: no URL for ServletContext resource
[/WEB-INF/views/tiles/secure/login/footer.jsp]
at
org.springframework.web.servlet.view.tiles3.SpringWildcardServletTilesApplicationContext.getResources(SpringWildcardServletTilesApplicationContext.java:94)
at
org.springframework.web.servlet.view.tiles3.SpringWildcardServletTilesApplicationContext.getResource(SpringWildcardServletTilesApplicationContext.java:60)
at
org.apache.tiles.extras.renderer.OptionsRenderer.renderAttempt(OptionsRenderer.java:124)
at
org.apache.tiles.extras.renderer.OptionsRenderer.render(OptionsRenderer.java:109)
at
org.apache.tiles.request.render.ChainedDelegateRenderer.render(ChainedDelegateRenderer.java:68)
at
org.apache.tiles.impl.BasicTilesContainer.render(BasicTilesContainer.java:259)
at
org.apache.tiles.template.InsertAttributeModel.renderAttribute(InsertAttributeModel.java:188)
at
org.apache.tiles.template.InsertAttributeModel.execute(InsertAttributeModel.java:132)
at
org.apache.tiles.jsp.taglib.InsertAttributeTag.doTag(InsertAttributeTag.java:300)
at
org.apache.jsp.WEB_002dINF.views.tiles.layouts.default_jsp._jspx_meth_tiles_005finsertAttribute_005f5(default_jsp.java:319)
at
org.apache.jsp.WEB_002dINF.views.tiles.layouts.default_jsp._jspService(default_jsp.java:131)
...
...
at java.lang.Thread.run(Thread.java:724)
Caused by: java.io.FileNotFoundException: ServletContext resource [/WEB-INF/views/tiles/secure/login/footer.jsp] cannot be resolved to URL because it
does not exist
at
org.springframework.web.context.support.ServletContextResource.getURL(ServletContextResource.java:154)
at
org.springframework.web.servlet.view.tiles3.SpringWildcardServletTilesApplicationContext.getResources(SpringWildcardServletTilesApplicationContext.java:90)
... 102 more
I've traced this back to the org.springframework.web.servlet.view.tiles3.SpringWildcardServletTilesApplicationContext.getResources(String) method -
line 94 (as indicated in the stacktrace), which ends up wrapping the IO exception in an IllegalArgumentException. OptionsRenderer does not catch the
IllegalArgumentException (only catches FileNotFound and IOExceptions), so it never checks subsequent options in the list, and lets the exception
bubble up the stack and consequently, the options are never actually checked.
So at this point, it would appear that either something changed in SpringWildcardServletTilesApplicationContext that never previously wrapped the
exception, or there is a bug in OptionsRenderer that doesn't properly handle the IllegalArgumentException.
Thanks,
Eric
