Jetspeed 2
  1. Jetspeed 2
  2. JS2-734

Drop jetspeed- prefix support for local PA deployment

    Details

    • Type: Task Task
    • Status: Closed
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: 2.1
    • Fix Version/s: 2.2.0
    • Component/s: Container
    • Labels:
      None

      Description

      It's fairly easy to demonstrate the issue. In the init() method of a simple Portlet, if I attempt to get the PortletContext and then call getResource on it like so:

      PortletContext context = portletConfig.getPortletContext();
      try

      { URL resource = context.getResource("/"); }

      catch (MalformedURLException e)

      { e.printStackTrace(); }

      I'll get the following:

      2007-06-14 15:13:31,125 [http-8080-Processor25] ERROR org.apache.jetspeed.factory.JetspeedPortletFactory - PortletFactory: Failed to load portlet foo.test.MyPortlet
      java.lang.NullPointerException
      at org.apache.jetspeed.container.JetspeedPortletContext.getResource(JetspeedPortletContext.java:193)
      at foo.test.MyPortlet.init(Unknown Source)
      at org.apache.jetspeed.factory.JetspeedPortletInstance.init(JetspeedPortletInstance.java:84)
      at org.apache.jetspeed.factory.JetspeedPortletFactory.getPortletInstance(JetspeedPortletFactory.java:229)
      at org.apache.jetspeed.aggregator.impl.HeaderAggregatorImpl.renderHeaderFragment(HeaderAggregatorImpl.java:1056)
      at org.apache.jetspeed.aggregator.impl.HeaderAggregatorImpl.aggregateAndRender(HeaderAggregatorImpl.java:1037)
      at org.apache.jetspeed.aggregator.impl.HeaderAggregatorImpl.aggregateAndRender(HeaderAggregatorImpl.java:1029)
      at org.apache.jetspeed.aggregator.impl.HeaderAggregatorImpl.aggregateAndRender(HeaderAggregatorImpl.java:1029)
      at org.apache.jetspeed.aggregator.impl.HeaderAggregatorImpl.build(HeaderAggregatorImpl.java:1007)
      at org.apache.jetspeed.aggregator.HeaderAggregatorValve.invoke(HeaderAggregatorValve.java:48)
      at org.apache.jetspeed.pipeline.JetspeedPipeline$Invocation.invokeNext(JetspeedPipeline.java:166)
      at org.apache.jetspeed.decoration.DecorationValve.invoke(DecorationValve.java:97)
      at org.apache.jetspeed.pipeline.JetspeedPipeline$Invocation.invokeNext(JetspeedPipeline.java:166)
      at org.apache.jetspeed.pipeline.valve.impl.ActionValveImpl.invoke(ActionValveImpl.java:182)
      at org.apache.jetspeed.pipeline.JetspeedPipeline$Invocation.invokeNext(JetspeedPipeline.java:166)
      at org.apache.jetspeed.container.ContainerValve.invoke(ContainerValve.java:76)
      at org.apache.jetspeed.pipeline.JetspeedPipeline$Invocation.invokeNext(JetspeedPipeline.java:166)
      at org.apache.jetspeed.profiler.impl.ProfilerValveImpl.invoke(ProfilerValveImpl.java:255)
      at org.apache.jetspeed.pipeline.JetspeedPipeline$Invocation.invokeNext(JetspeedPipeline.java:166)
      at org.apache.jetspeed.security.impl.LoginValidationValveImpl.invoke(LoginValidationValveImpl.java:159)
      at org.apache.jetspeed.pipeline.JetspeedPipeline$Invocation.invokeNext(JetspeedPipeline.java:166)
      at org.apache.jetspeed.security.impl.PasswordCredentialValveImpl.invoke(PasswordCredentialValveImpl.java:149)
      at org.apache.jetspeed.pipeline.JetspeedPipeline$Invocation.invokeNext(JetspeedPipeline.java:166)
      at org.apache.jetspeed.localization.impl.LocalizationValveImpl.invoke(LocalizationValveImpl.java:169)
      at org.apache.jetspeed.pipeline.JetspeedPipeline$Invocation.invokeNext(JetspeedPipeline.java:166)
      at org.apache.jetspeed.security.impl.AbstractSecurityValve$1.run(AbstractSecurityValve.java:118)
      at java.security.AccessController.doPrivileged(Native Method)
      at javax.security.auth.Subject.doAsPrivileged(Subject.java:454)
      at org.apache.jetspeed.security.JSSubject.doAsPrivileged(JSSubject.java:195)
      at org.apache.jetspeed.security.impl.AbstractSecurityValve.invoke(AbstractSecurityValve.java:112)
      at org.apache.jetspeed.pipeline.JetspeedPipeline$Invocation.invokeNext(JetspeedPipeline.java:166)
      at org.apache.jetspeed.container.url.impl.PortalURLValveImpl.invoke(PortalURLValveImpl.java:67)
      at org.apache.jetspeed.pipeline.JetspeedPipeline$Invocation.invokeNext(JetspeedPipeline.java:166)
      at org.apache.jetspeed.capabilities.impl.CapabilityValveImpl.invoke(CapabilityValveImpl.java:128)
      at org.apache.jetspeed.pipeline.JetspeedPipeline$Invocation.invokeNext(JetspeedPipeline.java:166)
      at org.apache.jetspeed.pipeline.JetspeedPipeline.invoke(JetspeedPipeline.java:145)
      at org.apache.jetspeed.engine.JetspeedEngine.service(JetspeedEngine.java:214)
      at org.apache.jetspeed.engine.JetspeedServlet.doGet(JetspeedServlet.java:242)
      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:252)
      at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
      at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:672)
      at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:463)
      at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:398)
      at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:301)
      at org.apache.jasper.runtime.PageContextImpl.doForward(PageContextImpl.java:688)
      at org.apache.jasper.runtime.PageContextImpl.forward(PageContextImpl.java:658)
      at org.apache.jsp.index_jsp._jspService(index_jsp.java:44)
      at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97)
      at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
      at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:334)
      at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:314)
      at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264)
      at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
      at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
      at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
      at org.apache.jetspeed.engine.servlet.XXSUrlAttackFilter.doFilter(XXSUrlAttackFilter.java:51)
      at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
      at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
      at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
      at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
      at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:432)
      at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
      at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
      at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
      at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
      at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
      at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
      at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
      at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80)
      at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
      at java.lang.Thread.run(Thread.java:613)

      It appears the PortletContext gets created but the wrapped servlet context that it uses is null.

      1. getResource.zip
        5 kB
        Deryk Sinotte
      2. local-deploy-diff.txt
        1.0 kB
        Woonsan Ko

        Activity

        Hide
        David Sean Taylor added a comment -

        What is the base class of your portlet?
        Do you call super.init() first?

        super.init(config);
        PortletContext context = getPortletContext();

        Show
        David Sean Taylor added a comment - What is the base class of your portlet? Do you call super.init() first? super.init(config); PortletContext context = getPortletContext();
        Hide
        Deryk Sinotte added a comment -

        I'm not extending GenericPortlet (or any other concrete Portlet implementation), simply implementing the Portlet interface.

        Show
        Deryk Sinotte added a comment - I'm not extending GenericPortlet (or any other concrete Portlet implementation), simply implementing the Portlet interface.
        Hide
        David Sean Taylor added a comment -

        Can you try implementing the method below on your portlet:

        private transient PortletConfig config;

        public void init (PortletConfig config) throws PortletException

        { this.config = config; this.init(); }
        Show
        David Sean Taylor added a comment - Can you try implementing the method below on your portlet: private transient PortletConfig config; public void init (PortletConfig config) throws PortletException { this.config = config; this.init(); }
        Hide
        Deryk Sinotte added a comment -

        Now I'm feeling a bit dense.

        The Portlet.init( PortletConfig portletConfig) method takes a PortletConfig parameter. Which init() method am I calling inside of that? Are you saying that I should create a separate init() method that doesn't take a PortletConfig but does the other logic that I need? And if so, how exactly should this address the issue? Wouldn't the resulting behaviour really be the same?

        I did notice that the Portlet.init( PortletConfig portletConfig) method does seem to be called twice for some reason even though the portlet only appears once (which I believe violates the spec). Is this related?

        In any event, I implemented what you recommended and this is what it looks like:

        package foo.test;

        import javax.portlet.ActionRequest;
        import javax.portlet.ActionResponse;
        import javax.portlet.Portlet;
        import javax.portlet.PortletConfig;
        import javax.portlet.PortletContext;
        import javax.portlet.PortletException;
        import javax.portlet.RenderRequest;
        import javax.portlet.RenderResponse;
        import java.io.IOException;
        import java.io.PrintWriter;
        import java.net.MalformedURLException;
        import java.net.URL;

        public class MyPortlet implements Portlet {

        private transient PortletConfig portletConfig;

        public void init(PortletConfig portletConfig) throws PortletException

        { System.out.println("MyPortlet.init: called"); this.portletConfig = portletConfig; this.initialize(); }

        private void initialize(){
        PortletContext context = portletConfig.getPortletContext();
        try

        { URL resource = context.getResource("/"); System.out.println("MyPortlet.initialize: resource = " + resource); }

        catch (MalformedURLException e)

        { e.printStackTrace(); System.out.println("MyPortlet.initialize: problem getting resource\n" + e); }

        }

        public void processAction(ActionRequest actionRequest,
        ActionResponse actionResponse)
        throws PortletException, IOException

        { System.out.println("MyPortlet.processAction: called"); }

        public void render(RenderRequest renderRequest,
        RenderResponse renderResponse)
        throws PortletException, IOException {
        System.out.println("MyPortlet.render: called");

        PortletContext context = portletConfig.getPortletContext();
        try

        { URL resource = context.getResource("/"); System.out.println("MyPortlet.render: resource = " + resource); }

        catch (MalformedURLException e)

        { System.out.println("MyPortlet.render: problem getting resource\n" + e); }

        renderResponse.setContentType("text/html");
        PrintWriter writer = renderResponse.getWriter();
        writer.print("rendered");
        writer.flush();
        }

        public void destroy()

        { System.out.println("MyPortlet.destroy: called"); }

        }

        Then I added a single instance to the default-page.psml. When loading the page, I see the same error:

        2007-06-18 10:47:11,173 [http-8080-Processor25] ERROR org.apache.jetspeed.factory.JetspeedPortletFactory - PortletFactory: Failed to load portlet foo.test.MyPortlet
        java.lang.NullPointerException
        at org.apache.jetspeed.container.JetspeedPortletContext.getResource(JetspeedPortletContext.java:193)
        at foo.test.MyPortlet.initialize(Unknown Source)
        at foo.test.MyPortlet.init(Unknown Source)
        at org.apache.jetspeed.factory.JetspeedPortletInstance.init(JetspeedPortletInstance.java:84)
        at org.apache.jetspeed.factory.JetspeedPortletFactory.getPortletInstance(JetspeedPortletFactory.java:229)
        ...

        I also see the following System.out calls:

        MyPortlet.init: called
        MyPortlet.init: called
        MyPortlet.initialize: resource = jndi:/localhost/jetspeed/
        MyPortlet.render: called
        MyPortlet.render: resource = jndi:/localhost/jetspeed/

        Show
        Deryk Sinotte added a comment - Now I'm feeling a bit dense. The Portlet.init( PortletConfig portletConfig) method takes a PortletConfig parameter. Which init() method am I calling inside of that? Are you saying that I should create a separate init() method that doesn't take a PortletConfig but does the other logic that I need? And if so, how exactly should this address the issue? Wouldn't the resulting behaviour really be the same? I did notice that the Portlet.init( PortletConfig portletConfig) method does seem to be called twice for some reason even though the portlet only appears once (which I believe violates the spec). Is this related? In any event, I implemented what you recommended and this is what it looks like: package foo.test; import javax.portlet.ActionRequest; import javax.portlet.ActionResponse; import javax.portlet.Portlet; import javax.portlet.PortletConfig; import javax.portlet.PortletContext; import javax.portlet.PortletException; import javax.portlet.RenderRequest; import javax.portlet.RenderResponse; import java.io.IOException; import java.io.PrintWriter; import java.net.MalformedURLException; import java.net.URL; public class MyPortlet implements Portlet { private transient PortletConfig portletConfig; public void init(PortletConfig portletConfig) throws PortletException { System.out.println("MyPortlet.init: called"); this.portletConfig = portletConfig; this.initialize(); } private void initialize(){ PortletContext context = portletConfig.getPortletContext(); try { URL resource = context.getResource("/"); System.out.println("MyPortlet.initialize: resource = " + resource); } catch (MalformedURLException e) { e.printStackTrace(); System.out.println("MyPortlet.initialize: problem getting resource\n" + e); } } public void processAction(ActionRequest actionRequest, ActionResponse actionResponse) throws PortletException, IOException { System.out.println("MyPortlet.processAction: called"); } public void render(RenderRequest renderRequest, RenderResponse renderResponse) throws PortletException, IOException { System.out.println("MyPortlet.render: called"); PortletContext context = portletConfig.getPortletContext(); try { URL resource = context.getResource("/"); System.out.println("MyPortlet.render: resource = " + resource); } catch (MalformedURLException e) { System.out.println("MyPortlet.render: problem getting resource\n" + e); } renderResponse.setContentType("text/html"); PrintWriter writer = renderResponse.getWriter(); writer.print("rendered"); writer.flush(); } public void destroy() { System.out.println("MyPortlet.destroy: called"); } } Then I added a single instance to the default-page.psml. When loading the page, I see the same error: 2007-06-18 10:47:11,173 [http-8080-Processor25] ERROR org.apache.jetspeed.factory.JetspeedPortletFactory - PortletFactory: Failed to load portlet foo.test.MyPortlet java.lang.NullPointerException at org.apache.jetspeed.container.JetspeedPortletContext.getResource(JetspeedPortletContext.java:193) at foo.test.MyPortlet.initialize(Unknown Source) at foo.test.MyPortlet.init(Unknown Source) at org.apache.jetspeed.factory.JetspeedPortletInstance.init(JetspeedPortletInstance.java:84) at org.apache.jetspeed.factory.JetspeedPortletFactory.getPortletInstance(JetspeedPortletFactory.java:229) ... I also see the following System.out calls: MyPortlet.init: called MyPortlet.init: called MyPortlet.initialize: resource = jndi:/localhost/jetspeed/ MyPortlet.render: called MyPortlet.render: resource = jndi:/localhost/jetspeed/
        Hide
        Woonsan Ko added a comment -

        It does not seem that the wrapped servlet context is null because of the following reasons:

        • The getResource() method returns correctly as you see. 'jndi:/localhost/jetspeed/' string is returned by Catalina's application context.
        • The error message, 'PortletFactory: Failed to load...' is logged by JetspeedPortletFactory class, and the #229 line of the class is like the following:

        Thread.currentThread().setContextClassLoader(paCl);

        So, the exception is originated from JetspeedPortletFactory, not JetspeedPortletContext.
        By the way, is it possible that currentThread() is null? I don't have any clue on this.
        Anyway, the above line looks necessary for initializing portlet with its proper classloader.

        By the way, I've tested your portlet on Tomcat 5.5 and Sun's JVM 1.5 on Windows XP, but I could not reproduce the exception. Is there any special thing in your environment?

        Show
        Woonsan Ko added a comment - It does not seem that the wrapped servlet context is null because of the following reasons: The getResource() method returns correctly as you see. 'jndi:/localhost/jetspeed/' string is returned by Catalina's application context. The error message, 'PortletFactory: Failed to load...' is logged by JetspeedPortletFactory class, and the #229 line of the class is like the following: Thread.currentThread().setContextClassLoader(paCl); So, the exception is originated from JetspeedPortletFactory, not JetspeedPortletContext. By the way, is it possible that currentThread() is null? I don't have any clue on this. Anyway, the above line looks necessary for initializing portlet with its proper classloader. By the way, I've tested your portlet on Tomcat 5.5 and Sun's JVM 1.5 on Windows XP, but I could not reproduce the exception. Is there any special thing in your environment?
        Hide
        Deryk Sinotte added a comment -

        I must have some simple, fundamental thing wrong.

        I tried a couple of different things. I downloaded a clean Jetspeed 2.1 binary and I simplified my portlet application down to the bare metal. I also implemented a second portlet the extends GenericPortlet rather than implement the Portlet interface. I've attached a zip file with a simple get-resource.psml page and the war file.

        If I copy this war file to Jetspeed-Demo-2.1/webapps/jetspeed/WEB-INF/deploy and then go to:

        http://localhost:8080/jetspeed/portal/get-resource.psml

        I get the same problem with NullPointerExceptions.

        I'm running Mac OS X 10.4.9, Apple JVM 1.5.0_07. I guess I'll wander over to another cubicle and see if I can get someone to run this on Windows for me to double-check. If someone could peek at my war file and see if I'm missing something obvious, I would appreciate it.

        At a minimum, I think I'm doing everything summarized in the documentation for building and deploying the simplest portlet (http://portals.apache.org/jetspeed-2/guides/guide-simple-portlet.html).

        Show
        Deryk Sinotte added a comment - I must have some simple, fundamental thing wrong. I tried a couple of different things. I downloaded a clean Jetspeed 2.1 binary and I simplified my portlet application down to the bare metal. I also implemented a second portlet the extends GenericPortlet rather than implement the Portlet interface. I've attached a zip file with a simple get-resource.psml page and the war file. If I copy this war file to Jetspeed-Demo-2.1/webapps/jetspeed/WEB-INF/deploy and then go to: http://localhost:8080/jetspeed/portal/get-resource.psml I get the same problem with NullPointerExceptions. I'm running Mac OS X 10.4.9, Apple JVM 1.5.0_07. I guess I'll wander over to another cubicle and see if I can get someone to run this on Windows for me to double-check. If someone could peek at my war file and see if I'm missing something obvious, I would appreciate it. At a minimum, I think I'm doing everything summarized in the documentation for building and deploying the simplest portlet ( http://portals.apache.org/jetspeed-2/guides/guide-simple-portlet.html ).
        Hide
        Deryk Sinotte added a comment -

        I forgot to add that I added a very simple listener to the web.xml:

        <listener>
        <listener-class>
        foo.test.TestListener
        </listener-class>
        </listener>

        and it doesn't appear to be constructed and/or called so I'm sure there's something basic I'm overlooking.

        Show
        Deryk Sinotte added a comment - I forgot to add that I added a very simple listener to the web.xml: <listener> <listener-class> foo.test.TestListener </listener-class> </listener> and it doesn't appear to be constructed and/or called so I'm sure there's something basic I'm overlooking.
        Hide
        Woonsan Ko added a comment -

        I got the same problem on my machine.
        A strange thing is that the jetspeed-bug.war file is deployed to /webapps/jetspeed/WEB-INF/apps/ directory, not /webapps/ directory.
        Probably, because the app is deployed to local app directory, it can't use portlet context correctly.
        Anyway, if the app is correctly deployed, this problem will not occur.
        I looked into web.xml and portlet.xml, but I could not find anything that made wrong deployment.
        In contrast to this, demo.war is correctly deployed.

        Show
        Woonsan Ko added a comment - I got the same problem on my machine. A strange thing is that the jetspeed-bug.war file is deployed to /webapps/jetspeed/WEB-INF/apps/ directory, not /webapps/ directory. Probably, because the app is deployed to local app directory, it can't use portlet context correctly. Anyway, if the app is correctly deployed, this problem will not occur. I looked into web.xml and portlet.xml, but I could not find anything that made wrong deployment. In contrast to this, demo.war is correctly deployed.
        Hide
        Woonsan Ko added a comment -

        I guess I found the cause.
        Two problems:
        (1) Your portlet application war file name should not be prefixed by 'jetspeed-'.
        If the war file name is like that, org.apache.jetspeed.deployment.impl.DeployPortletAppEventListener class will treat it as a local portlet application.
        (2) In your war file, there should not be any duplicate entry. In your war file, there's a duplicate entry, test.jsp. Duplicate entry makes java.util.zip.ZipException, which stops auto deployment of Jetspeed-2.

        I created war file named 'myjetspeed-bug.war' with no duplicate entry like the following:
        > jar cvf ../myjetspeed-bug.war *

        And, I modified the psml like this to adjust the unique fragment IDs:

        <fragment id="getresource" type="layout" name="jetspeed-layouts::VelocityTwoColumns">
        <fragment id="getresource-00" type="portlet" name="myjetspeed-bug::jetspeed-bug-interface">
        <!-- ... -->
        </fragment>
        <fragment id="getresource-01" type="portlet" name="myjetspeed-bug::jetspeed-bug-superclass">
        <!-- ... -->
        </fragment>
        </fragment>

        After deploying this war file, I succeeded in seeing 'Resource: jndi:/localhost/myjetspeed-bug/' in the page.
        And, I could see the following in the Tomcat console without any exception:

        MyPortlet.init: called
        MyPortlet.getResource: resource = /
        MyPortlet.initialize: resource = jndi:/localhost/myjetspeed-bug/
        MyPortlet.getResource: resource = /WEB-INF/web.xml
        MyPortlet.initialize: resource = jndi:/localhost/myjetspeed-bug/WEB-INF/web.xml
        MyGenericPortlet.init
        MyGenericPortlet.getResource: resource = /
        MyGenericPortlet.initialize: resource = jndi:/localhost/myjetspeed-bug/
        MyGenericPortlet.getResource: resource = /WEB-INF/web.xml
        MyGenericPortlet.initialize: resource = jndi:/localhost/myjetspeed-bug/WEB-INF/web.xml
        MyPortlet.render: called
        MyPortlet.getResource: resource = /
        MyPortlet.initialize: resource = jndi:/localhost/myjetspeed-bug/
        MyGenericPortlet.render: called
        MyGenericPortlet.getResource: resource = /
        MyGenericPortlet.initialize: resource = jndi:/localhost/myjetspeed-bug/

        If this solves your problem, we can get a good lesson: Don't prefix by 'jetspeed-'.

        Show
        Woonsan Ko added a comment - I guess I found the cause. Two problems: (1) Your portlet application war file name should not be prefixed by 'jetspeed-'. If the war file name is like that, org.apache.jetspeed.deployment.impl.DeployPortletAppEventListener class will treat it as a local portlet application. (2) In your war file, there should not be any duplicate entry. In your war file, there's a duplicate entry, test.jsp. Duplicate entry makes java.util.zip.ZipException, which stops auto deployment of Jetspeed-2. I created war file named 'myjetspeed-bug.war' with no duplicate entry like the following: > jar cvf ../myjetspeed-bug.war * And, I modified the psml like this to adjust the unique fragment IDs: <fragment id="getresource" type="layout" name="jetspeed-layouts::VelocityTwoColumns"> <fragment id="getresource-00" type="portlet" name="myjetspeed-bug::jetspeed-bug-interface"> <!-- ... --> </fragment> <fragment id="getresource-01" type="portlet" name="myjetspeed-bug::jetspeed-bug-superclass"> <!-- ... --> </fragment> </fragment> After deploying this war file, I succeeded in seeing 'Resource: jndi:/localhost/myjetspeed-bug/' in the page. And, I could see the following in the Tomcat console without any exception: MyPortlet.init: called MyPortlet.getResource: resource = / MyPortlet.initialize: resource = jndi:/localhost/myjetspeed-bug/ MyPortlet.getResource: resource = /WEB-INF/web.xml MyPortlet.initialize: resource = jndi:/localhost/myjetspeed-bug/WEB-INF/web.xml MyGenericPortlet.init MyGenericPortlet.getResource: resource = / MyGenericPortlet.initialize: resource = jndi:/localhost/myjetspeed-bug/ MyGenericPortlet.getResource: resource = /WEB-INF/web.xml MyGenericPortlet.initialize: resource = jndi:/localhost/myjetspeed-bug/WEB-INF/web.xml MyPortlet.render: called MyPortlet.getResource: resource = / MyPortlet.initialize: resource = jndi:/localhost/myjetspeed-bug/ MyGenericPortlet.render: called MyGenericPortlet.getResource: resource = / MyGenericPortlet.initialize: resource = jndi:/localhost/myjetspeed-bug/ If this solves your problem, we can get a good lesson: Don't prefix by 'jetspeed-'.
        Hide
        Deryk Sinotte added a comment -

        Right on both counts. Thanks for your help.

        The duplicate entries in the jar file was caused by a typo in one of our common build files so I apologize for that. As for the "jetspeed-" prefix, changing the name made everything work as expected - including the listener. My opinion is that relying on a prefix for the war name to hot deploy stuff is not a great idea. There should be something more explicit/declarative to achieve the same thing - potentially something in the jetspeed-portlet.xml or perhaps a completely separate deploy folder.

        Anyway, again, thanks. Onward we go. You can close this case and consider opening a different one recommending an enhancement to the "jetspeed" thing.

        Deryk

        Show
        Deryk Sinotte added a comment - Right on both counts. Thanks for your help. The duplicate entries in the jar file was caused by a typo in one of our common build files so I apologize for that. As for the "jetspeed-" prefix, changing the name made everything work as expected - including the listener. My opinion is that relying on a prefix for the war name to hot deploy stuff is not a great idea. There should be something more explicit/declarative to achieve the same thing - potentially something in the jetspeed-portlet.xml or perhaps a completely separate deploy folder. Anyway, again, thanks. Onward we go. You can close this case and consider opening a different one recommending an enhancement to the "jetspeed" thing. Deryk
        Hide
        Woonsan Ko added a comment -

        I agree with Deryk. I think the 'jetspeed-' prefix for local PA could be out-of-date after Jetspeed-2 2.1 release, which added a new local PA deploy folder. (http://issues.apache.org/jira/browse/JS2-606)
        So I attached a patch to remove prefix checking after my basic tests.

        Show
        Woonsan Ko added a comment - I agree with Deryk. I think the 'jetspeed-' prefix for local PA could be out-of-date after Jetspeed-2 2.1 release, which added a new local PA deploy folder. ( http://issues.apache.org/jira/browse/JS2-606 ) So I attached a patch to remove prefix checking after my basic tests.
        Hide
        David Sean Taylor added a comment -

        I think we can get this in for 2.1.1, as I am working with Mohan on deprecating the layout portlets jar and moving it all into Jetspeed core as a new kind of PA (internal)

        Show
        David Sean Taylor added a comment - I think we can get this in for 2.1.1, as I am working with Mohan on deprecating the layout portlets jar and moving it all into Jetspeed core as a new kind of PA (internal)
        Hide
        Ate Douma added a comment -

        Set fix version to 2.2

        I agree to dropping the jetspeed- prefix as we have the deploy/local folder solution since 2.1 already.
        But replacing local deployment with a new internal PA solution isn't going to be ready before 2.2.
        And I don't want to "break" 2.1.x functionality people might still depend on, so dropping the jetspeed- prefix has to be postponed until 2.2 as well.

        Show
        Ate Douma added a comment - Set fix version to 2.2 I agree to dropping the jetspeed- prefix as we have the deploy/local folder solution since 2.1 already. But replacing local deployment with a new internal PA solution isn't going to be ready before 2.2. And I don't want to "break" 2.1.x functionality people might still depend on, so dropping the jetspeed- prefix has to be postponed until 2.2 as well.
        Hide
        Ate Douma added a comment -

        I think its now time to drop the support for the jetspeed- prefix handling: the local deployment folder solution has been in place long enough.

        Show
        Ate Douma added a comment - I think its now time to drop the support for the jetspeed- prefix handling: the local deployment folder solution has been in place long enough.
        Hide
        Ate Douma added a comment -

        Renaming the issue to better reflect the task at hand

        Show
        Ate Douma added a comment - Renaming the issue to better reflect the task at hand
        Hide
        Vivek Kumar added a comment -

        Removing the "jetspeed-" prefix condtion for local PA deployment, solution for local PA deployment has already provided by
        placing local PA in local folder under deploy folder

        Show
        Vivek Kumar added a comment - Removing the "jetspeed-" prefix condtion for local PA deployment, solution for local PA deployment has already provided by placing local PA in local folder under deploy folder

          People

          • Assignee:
            Vivek Kumar
            Reporter:
            Deryk Sinotte
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development