11 Replies Latest reply on Feb 28, 2007 2:03 PM by jon_scott

    IPC WindowActionEvent getParameters()

    jon_scott

      Hi,

      I'm using jboss 4.0.3SP1
      with jboss portal 2.2.1-GA
      and jdk 1.5.0_05.

      I've got the InterPortlet Communication example working, but when I do a call to WindowActionEvent getParameters() I get the following error:

      2007-02-21 10:53:33,650 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/portal].[PortalServletWithPathMapping]] Servlet.service() for servlet PortalServletWithPathMapping threw exception
      java.lang.NoSuchMethodError: org.jboss.portlet.event.node.WindowActionEvent.getParameters()Lorg/jboss/portal/server/util/Parameters;

      Any help would be appreciated.

        • 1. Re: IPC WindowActionEvent getParameters()
          jon_scott

          Oh, my jboss-service for this is:

           <mbean
           code="org.jboss.portal.core.event.PortalEventListenerServiceImpl"
           name="portal:service=ListenerService,type=jon"
           xmbean-dd="org/jboss/portal/core/event/PortalEventListenerServiceImpl.xml">
           <xmbean/>
           <depends
           optional-attribute-name="Registry"
           proxy-type="attribute">portal:service=ListenerRegistry</depends>
           <attribute name="RegistryId">jon</attribute>
           <attribute name="ListenerClassName">rsb6.portlet.USAFComponentPortlet$Listener</attribute>
           </mbean>
          


          • 2. Re: IPC WindowActionEvent getParameters()
            jon_scott

            If I use seperate classloaders for the sar I get the following:

            Caused by: javax.management.InvalidAttributeValueException: Set attribute has class class $Proxy141 loaded from org.jboss.mx.util.MBeanProxyExt$2@fc9074 that is not assignable to attribute class interface org.jboss.portal.core.event.PortalEventListenerRegistry loaded from org.jboss.mx.loading.UnifiedClassLoader3@fac2be{ url=file:/home/jboss/jbossas/jboss-4.0.3SP1/server/uat/tmp/deploy/tmp60673RSBArea6.sar ,addedOrder=95}
             at org.jboss.mx.interceptor.ModelMBeanAttributeInterceptor.checkAssignable(ModelMBeanAttributeInterceptor.java:214)
             at org.jboss.mx.interceptor.ModelMBeanAttributeInterceptor.invoke(ModelMBeanAttributeInterceptor.java:73)
             at org.jboss.mx.interceptor.PersistenceInterceptor.invoke(PersistenceInterceptor.java:61)
             at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
             at org.jboss.mx.server.AbstractMBeanInvoker.setAttribute(AbstractMBeanInvoker.java:442)
             at org.jboss.mx.server.MBeanServerImpl.setAttribute(MBeanServerImpl.java:593)
             at org.jboss.system.ServiceConfigurator.setAttribute(ServiceConfigurator.java:665)


            • 3. Re: IPC WindowActionEvent getParameters()
              jon_scott

              All I can think is that this is a compatiblity issue between the jboss server
              and portal that we're using, in terms of IPC. Either that or I'm doing something really stupid, which is not unheard of. Please help if you can.
              Just tell me I'm stupid so I can give up and go to sleep.

              • 4. Re: IPC WindowActionEvent getParameters()
                jon_scott

                btw - I'm not doing this out of stubborness. The reason I'm doing it is because we have an app in the portal with a menu on the left that determines what gets displayed in the centre. But when it comes to
                people clicking on reports I want the centre portlet in a maximized window state - and it's not possible, from my understanding, to do that once
                the render request is fired - it's only possible through an action request.
                Well - maybe I am stubborn and we should just have everything in the centre.

                • 5. Re: IPC WindowActionEvent getParameters()
                  jon_scott

                  Not that I've gone mad and am talking to myself or anything.

                  • 6. Re: IPC WindowActionEvent getParameters()
                    theute

                    Sorry i don't know the status of our IPC solution, it will change once the portlet 2.0 spec that implements it is done.



                    You should get some sleep anyway ;) me too actually :)

                    • 7. Re: IPC WindowActionEvent getParameters()
                      jon_scott

                      Yeah - I understand I'm flogging a dead horse - but we have a heavily used production server and the idea of upgrading is scary - so many things could go wrong. Any chance you could have a word with Roy? Just want an interim - for the next month or two. Till we get our stupid arses together. Help.

                      • 8. Re: IPC WindowActionEvent getParameters()
                        jon_scott

                        omg - forget it. I am stubborn and willful. No wonder people get nervous when they offer me projects. ;-)

                        • 9. Re: IPC WindowActionEvent getParameters()
                          jon_scott

                          OK - going to sleep
                          ;_-)

                          Broken

                          • 10. Re: IPC WindowActionEvent getParameters()
                            jon_scott

                            Thanks for your response Thomas. I give up! But better things will follow - I'm sure!

                            • 11. Re: IPC WindowActionEvent getParameters()
                              jon_scott

                              For anyone interested, I got it working.
                              If you're using the portal 2.2 example, don't - the packaging is misleading. I found it worked if I packaged the listener in a sar in an ear on it's own - this gets rid of so many problems. You don't need to include the portal lib jars - which can cause conflicts. Packaging it an ear gets rid of the startup problems.
                              Then, as per the documentation, you add the listener to the *-object.xml and just package your portlet normally, which happens to get rid of hot redeploy errors if you were packaging the whole lot in an ear in the first place. I think having the listener as an inner class causes so many problems. But maybe I'm missing a piece of the bigger picture.