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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
