portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ate Douma <...@douma.nu>
Subject Re: J2: Tiles support in Struts Bridge
Date Mon, 24 Jan 2005 08:42:45 GMT
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: jetspeed-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org

To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org

View raw message