portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Scott Heaberlin <heabd...@gmail.com>
Subject Garbage Collection of threadlocal variables (was Re: J2 Struts Bridge NullPointer when portal page viewed)
Date Thu, 03 Feb 2005 03:56:44 GMT
Follow up:  

Having not reached any breakpoints set in the J2 Struts Bridge code
during my debugging sessions, I felt it a necessary formality to
change the portlet-class from StrutsPortlet to something that would
make no use of the Struts Bridge.  I replaced the struts portlet with
a simple portlet that printed out its classname to the response.

Same result with the redeployed app - NullPointer before it even
reaches the portlet.

Is there any way possible that the threadlocal data
(org.apache.pluto.om.portlet.PortletDefinition) stored in
JetspeedPortletFactoryProxy can be lost due to something such as
garbage collection?  I cannot otherwise explain its disappearance
during the lifecycle of a request for this particular deployed portlet
application.  It is obviously not struts-bridge related, nor is is it
systemic in my J2 environment (nearly cvs-head at this point - it
should be the state of cvs just after Ate's latest bridge commits) as
I have other custom portlet webapps deployed and running with no
problem.  Yet it is a chronic problem for this particular deployed
webapp for some reason.

Any thoughts?


On Tue, 1 Feb 2005 02:06:00 -0500, Scott Heaberlin <heabdogg@gmail.com> wrote:
> Hello all -
> 
> I can configure and deploy an existing tiles app within J2
> (/jetspeed/WEB-INF/deploy) and view / use the application in tomcat at
> its non-portlet context (eg, /webapp). However, whenever I request a
> .psml with a fragment that contains the struts portlet configured for
> the app, I get a NullPointerException at line 217 (latest cvs head) of
>  JetspeedContainerServlet.
> 
> For the longest time I was unable to get the app to work in either
> context (portal vs webapp), but I was *finally* able to at least run
> the app deployed by J2 but requested at the web context root. To do
> so, I had to remove my <request-processor> elements in the
> struts-config-module.xml files and just letting StrutsPortlet notice
> the TilesPlugin usage and configure TilesPortletRequestProcessor on
> its own.  The only thing I gain from this is the ability to run the
> app at the direct webapp context.  When viewing the app via
> strutsportlet, I get the following stack trace that has hounded me
> since day one with this Tiles-app-in-J2 quest.
> 
> web.xml snippets:
> 
>     <servlet-name>action</servlet-name>
>     <!--<servlet-class>org.apache.struts.action.ActionServlet</servlet-class>-->
>     <servlet-class>org.apache.portals.bridges.struts.PortletServlet</servlet-class>
>     <init-param>
>         <!-- jgossip module-->
>       <param-name>config/jgossip</param-name>
>       <param-value>/WEB-INF/struts-config-jgossip.xml</param-value>
>     </init-param>
> ...
>   <taglib>
>     <taglib-uri>/tags/struts-html</taglib-uri>
>     <taglib-location>/WEB-INF/struts-1.2.4-portlet-html-0.2.tld</taglib-location>
>   </taglib>
> 
> struts-config-jgossip.xml snippet:
>      <!-- let StrutsPortlet figure out the req processor -->
>      <!--
>      <controller pagePattern="$M$P"
>                  inputForward="true"
> 
> processorClass="org.apache.portals.bridges.struts.PortletTilesRequestProcessor"/>
>      -->
> ...
>         <plug-in className="org.apache.struts.tiles.TilesPlugin">
>                 <set-property property="definitions-config"
> value="/WEB-INF/tiles-defs-jgossip.xml"/>
>                 <set-property property="moduleAware" value="true"/>
>                 <set-property property="definitions-parser-validate" value="true"/>
>         </plug-in>
> 
> portlet.xml snippet:
> <portlet-app id="jgossip" version="1.0">
>   <portlet id="JGossipPortlet">
>     <init-param>
>       <name>ServletContextProvider</name>
>       <value>org.apache.jetspeed.portlet.ServletContextProviderImpl</value>
>     </init-param>
>     <init-param>
>       <name>ViewPage</name>
>       <value>/jgossip/jgossip</value>
>     </init-param>
>     <portlet-name>JGossipPortlet</portlet-name>
>     <display-name>JGossip Forum Portlet</display-name>
>     <description>This is the JGossip forum portlet</description>
>     <portlet-class>org.apache.portals.bridges.struts.StrutsPortlet</portlet-class>
>     <expiration-cache>-1</expiration-cache>
>       <mime-type>text/html</mime-type>
>       <portlet-mode>VIEW</portlet-mode>
>     </supports>
> 
> struts-portlet-config.xml:
> Note: All I am wanting to do at this point is to view the first URL,
> which performs a login action and redirects, which seems to fit in
> with Ate's Struts Bridge doc recommendations.  I have tried changing
> the portlet-url-type default attrib from 'render' to 'action' and have
> the same result with both.
> <config>
>   <render-context>
>     <attribute name="errors"/>
>     <attribute name="message"/>
>   </render-context>
>   <portlet-url-type default="action">
>   </portlet-url-type>
> 
> Again, viewing in the deployed web root works - the app runs as normal.
> Viewing within J2 yields the following *every* time:
> 
> 2005-02-01 01:58:17 StandardContext[/jgossip]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)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:324)
>         at org.springframework.aop.framework.AopProxyUtils.invokeJoinpointUsingReflection(AopProxyUtils.java:61)
>         at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:142)
>         at $Proxy10.render(Unknown Source)
>         at org.apache.pluto.PortletContainerImpl.renderPortlet(PortletContainerImpl.java:103)
>         at org.apache.jetspeed.container.JetspeedPortletContainerWrapper.renderPortlet(JetspeedPortletContainerWrapper.java:88)
>         at org.apache.jetspeed.aggregator.impl.RenderingJob.execute(RenderingJob.java:108)
>         at org.apache.jetspeed.aggregator.impl.PortletRendererImpl.renderNow(PortletRendererImpl.java:103)
>         at org.apache.jetspeed.aggregator.impl.PageAggregatorImpl.aggregateAndRender(PageAggregatorImpl.java:261)
>         at org.apache.jetspeed.aggregator.impl.PageAggregatorImpl.aggregateAndRender(PageAggregatorImpl.java:244)
>         at org.apache.jetspeed.aggregator.impl.PageAggregatorImpl.build(PageAggregatorImpl.java:148)
> ...
> many more lines here
> 
> Any thoughts?  I'd appreciate any further insight.  I'm really getting
> frustrated with this - especially since I'm now able to reap the
> advantages of the latest Struts Bridge (eg running as normal within
> the normal deployment context).
> 
> Thanks,
> 
> --
> 
> -Scott
> 
> 
> Scott Heaberlin
> 


-- 


-Scott


Scott Heaberlin

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


Mime
View raw message