Sorry about this delayed response (I intended to reply to your earlier request but forgot).
A TilesPortletRequestProcessor is planned! I got a report from one user who created a new TilesPortletRequestProcessor by extending the TilesRequestProcessor and merged in the PortletRequestProcessor behavior. This, to his report, seems to be working flawlessly! Note: this is a different solution to the one you describe below.
I intend to supply a TilesPortletRequestProcessor with the Struts Bridge once I have found the time and an example Tiles Struts application I can test this out with. I don't use Tiles myself, so it'll take some time for me to validate the solution (which is a requirement before I commit it).
If anyone could supply me with a good test application which uses Tiles extensively and is/should be behaving correctly within a Portlet (JSR-168) environment I would appreciate it. It will certainly speed things up as I don't have time to look for one myself right now.
Regards, Ate
Scott Heaberlin wrote:
Resending this question with much more info:
Any support yet for a TilesPortletRequestProcessor? Is there any reason why PortletRequestProcessor couldn't extend TilesRequestProcessor instead of the base Struts RequestProcessor? I ran into difficulties using the first Struts Bridge version with Tiles based apps because Tiles apps use TilesRequestProcessor instead of the default. Using the old PortletRequestProcessor in struts-config.xml for Tiles apps yielded exceptions.
I attempted to write a derivative of TilesRequestProcessor similar to
PortletRequestProcessor but I must have missed something and couldn't
get it to work. What I tried was to extend the bridge's
PortletRequestProcessor, adding a private TilesRequestProcessor
instance and overriding in my PortletTilesRequestProcessor class the
methods that org.apache.struts.tiles.TilesRequestProcessor overrides. My goal was to essentially perform the same operations as
PortletRequetProcessor but also allow the processor to check URIs for
requested tile defs.
From the TilesRequestProcessor javadocs:<quote> catching is done by overloading the following methods: * processForwardConfig * internalModuleRelativeForward * internalModuleRelativeInclude </quote>
So, I did the same thing in my extention of PortletRequestProcessor, and simply delegated the above overridden methods to my private TilesRequestProcessor instance.
Unfortunately, no matter what I tried, I always had NullPointerExceptions thrown from JetspeedContainerServlet. From what I can tell, something just isn't right (I believe somehow some expected javax.portlet attribute(s) are missing in the request object passed to the container servlet... but as I'm neither a J2 internals expert nor a Struts/Tiles expert, I'm not quite sure how this happened.
Any thoughts? Below is the top lines from the stack trace in my tomcat log. Note I only accessed the context from a .psml page within J2 (the tilestest.war was deployed within J2).
Thanks in advance,
-Scott Heaberlin
log snippet:
2005-01-21 01:13:38 StandardContext[/tilestest]JetspeedContainerServlet: Error rendering JetspeedContainerServlet error page: java.lang.NullPointerException java.lang.NullPointerException at org.apache.jetspeed.container.JetspeedContainerServlet.doGet(JetspeedContainerServlet.java:217) at javax.servlet.http.HttpServlet.service(HttpServlet.java:689) at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:237) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:704) at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:590) at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:510) at org.apache.jetspeed.container.invoker.ServletPortletInvoker.invoke(ServletPortletInvoker.java:213) at org.apache.jetspeed.container.invoker.ServletPortletInvoker.render(ServletPortletInvoker.java:124)
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
