tiles-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric B <ebe...@hotmail.com>
Subject Re: OptionsRenderer not working
Date Mon, 28 Oct 2013 01:43:57 GMT
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.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)
	... 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.



View raw message