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 Tue, 25 Jan 2005 21:27:48 GMT

Scott Heaberlin wrote:
> See comments inline.
>>A TilesPortletRequestProcessor is planned!
> Excellent news!
>>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!
> Could you perhaps be a little more specific?  I have tried an OO
> approach as well as in desperation cloning the process() and
> processRoles() methods in a TilesRequestProcessor subclass.
I haven't seen the code yet so I'm only passing on what I've been told, but
as far I know they modified the PortletRequestProcessor to extend TilesRequestProcessor
instead of wrapping one.

Colin: could you confirm this?

>>Note: this is a different solution to the one you describe below.
> Again, perhaps I am not following you when you say "merged in the
> PortletRequestProcessor behavior" - I feel like I have done this too
> from what I can tell.  In fact, to be honest, I don't even think my
> request processor is even being invoked (it doesn't appear in the
> stack trace - see original thread)
> I attached a debugger and stepped through one request. My assumptions
> were confirmed - the request never makes it to any code I have
> authored.  In fact, it dies within 5 lines of actually invoking the
> portlet itself (I am using StrutsPortlet).
> In an effort to learn and perhaps to contribute what I find, (not to
> mention to conquer this beast with whom I've been wrestling - I'm sure
> you can relate) I want to at least continue to try to get this to
> work.  That in mind, I have one outstanding question based on the
> stack trace I originally posted (I will repost at the end of this
> message) combined with what I saw stepping through one request with
> the debugger.
> Somewhere between where ServletPortletInvoker::invoke() runs and
> JetspeedContainerServlet::doGet(), the ThreadLocal data within the
> JetspeedPortletFactoryProxy class seems to disappear.  I have verified
> that within ServletPortletInvoker,
> JetspeedPortletFactoryProxy::setCurrentPortletDefinition(PortletDefinition)
> is indeed called with a non-null PortletDefinition.
> The next 7 calls in the stack are from javax.servlet, for which I do
> not have the source.  By the time we reach
> JetspeedContainerServlet::doGet() -
> JetspeedPortletFactoryProxy::getCurrentPortletDefinition() returns
> null.  2 lines of code later, the container servlet attempts to get
> the name of the pluto PortletDefinition which is presumed to exist as
> a ThreadLocal variable - resulting in my NPE.
> Note, I am indeed using the latest cvs head, not an M build.
> I appreciate  any insight you may have into this.  If I can get this
> working, I'd be happy to contribute documentation and/or patches
> related to Tiles-in-J2 effort!
> Thanks in advance,
> -Scott
> Scott Heaberlin
> 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