You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jetspeed-dev@portals.apache.org by Scott Heaberlin <he...@gmail.com> on 2005/02/01 08:06:00 UTC
J2 Struts Bridge NullPointer when portal page viewed
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
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: Garbage Collection of threadlocal variables (was Re: J2 Struts
Bridge NullPointer when portal page viewed)
Posted by Ate Douma <at...@douma.nu>.
Scott,
I can't say I understand what's going wrong but I think it's very
unlikely the Garbage Collection is causing this.
As I understand it you have now created a stripped down version of
your portlet which still doesn't run. Somehow, there must be an error
in the configuration I think.
Maybe its possible for you to send me the stripped down version and
I can have a look. If you do, then please including the build scripts!
Ate
Scott Heaberlin wrote:
> 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 <he...@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
>>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Garbage Collection of threadlocal variables (was Re: J2 Struts Bridge NullPointer when portal page viewed)
Posted by Scott Heaberlin <he...@gmail.com>.
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 <he...@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