ICEpush
  1. ICEpush
  2. PUSH-173

ICEpush EE 3.0.0.GA - NPE on org.icepush.util.ExtensionRegistry.getBestExtension

          Details

          • Type: Bug Bug
          • Status: Closed
          • Priority: Major Major
          • Resolution: Won't Fix
          • Affects Version/s: 3.0.1, EE 3.0.0
          • Fix Version/s: EE-4.1.0.GA
          • Component/s: Push Library
          • Labels:
            None
          • Environment:
            Jboss 5.1G.A, WAS7, Chrome, FF, IE, ICEfaces EE 3.0.0G.A.
          • Assignee Priority:
            P2
          • Salesforce Case Reference:
          • Workaround Exists:
            Yes
          • Workaround Description:
            Hide
            A variety of workarounds are possible:
            add <listener> to web.xml for the various ICEfaces/ICEpush listeners
            add icepush.tld under WEB-INF

            However the best approach is to deploy the application as a zipped .war rather than an exploded directory.

            The same issue can occur when trying to include ICEfaces libs (e.g. icepush.jar) as shared libs in an .ear deployment. The solution is to simply include all libraries in the WEB-INF/lib directory of each war module.
            Show
            A variety of workarounds are possible: add <listener> to web.xml for the various ICEfaces/ICEpush listeners add icepush.tld under WEB-INF However the best approach is to deploy the application as a zipped .war rather than an exploded directory. The same issue can occur when trying to include ICEfaces libs (e.g. icepush.jar) as shared libs in an .ear deployment. The solution is to simply include all libraries in the WEB-INF/lib directory of each war module.

            Description

            The following exception is thrown when a sample application attached to this ticket is deployed and accessed on JBoss 5.1 server.

            at org.icepush.util.ExtensionRegistry.getBestExtension(ExtensionRegistry.java:69)
            at org.icefaces.impl.push.servlet.ICEpushResourceHandler$ICEpushResourceHandlerImpl.beforePhase(ICEpushResourceHandler.java:169)
            at org.icefaces.impl.push.servlet.ICEpushResourceHandler.beforePhase(ICEpushResourceHandler.java:109)
            at com.sun.faces.lifecycle.Phase.handleBeforePhase(Phase.java:228)
            at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:99)
            at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:111)
            at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
            at javax.faces.webapp.FacesServlet.service(FacesServlet.java:508)
            at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
            at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
            at com.cvty.coco.presentation.jsf.util.RequestWrapperFilter.doFilter(RequestWrapperFilter.java:45)
            at org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:237)
            at org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:167)
            at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
            at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
            at com.cvty.coco.presentation.jsf.util.AuthFilter.doFilter(AuthFilter.java:95)
            at org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:237)
            at org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:167)
            at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
            at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
            at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
            at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
            at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
            at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:235)
            at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
            at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:183)
            at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:95)
            at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126)
            at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70)
            at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
            at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
            at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
            at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
            at org.jboss.web.tomcat.service.request.ActiveRequestResponseCacheValve.internalProcess(ActiveRequestResponseCacheValve.java:74)
            at org.jboss.web.tomcat.service.request.ActiveRequestResponseCacheValve.invoke(ActiveRequestResponseCacheValve.java:47)
            at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
            at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829)
            at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:599)
            at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:451)
            at java.lang.Thread.run(Thread.java:619)

            Sample application is working fine when you remove icepush-ee.jar library.


            To reproduce:
            1. Place ICEFacesTestApp.war in <JBOSS location>/server/default/deploy location
            2. Start the server.
            3. Access application URL via browser.

            NOTE:
            Similar issue was reported for WAS7 application server

              Issue Links

              depends on

              Improvement - An improvement or enhancement to an existing feature or task. IPCK-401 Improve support for EAR deployments

              • Major - Major loss of function.
              • Open

                Activity

                Ascending order - Click to sort in descending order
                Evgheni Sadovoi created issue -
                Evgheni Sadovoi made changes -
                Field Original Value New Value
                Attachment ICEFacesTestApp.war.rar [ 14307 ]
                Evgheni Sadovoi made changes -
                Salesforce Case [5007000000LGK7K, 5007000000KHPQ1]
                Evgheni Sadovoi made changes -
                Assignee Ken Fyten [ ken.fyten ]
                Evgheni Sadovoi made changes -
                Salesforce Case [5007000000KHPQ1, 5007000000LGK7K] [5007000000KHPQ1, 5007000000LGK7K, 5007000000LFlwQ]
                Evgheni Sadovoi made changes -
                Environment Jboss 5.1G.A, Chrome, FF, IE, ICEfaces EE 3.0.0G.A. Jboss 5.1G.A, WAS7, Chrome, FF, IE, ICEfaces EE 3.0.0G.A.
                Description The following exception is thrown when a sample application attached to this ticket is deployed and accessed on JBoss 5.1 server.

                at org.icepush.util.ExtensionRegistry.getBestExtension(ExtensionRegistry.java:69)
                at org.icefaces.impl.push.servlet.ICEpushResourceHandler$ICEpushResourceHandlerImpl.beforePhase(ICEpushResourceHandler.java:169)
                at org.icefaces.impl.push.servlet.ICEpushResourceHandler.beforePhase(ICEpushResourceHandler.java:109)
                at com.sun.faces.lifecycle.Phase.handleBeforePhase(Phase.java:228)
                at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:99)
                at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:111)
                at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
                at javax.faces.webapp.FacesServlet.service(FacesServlet.java:508)
                at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
                at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
                at com.cvty.coco.presentation.jsf.util.RequestWrapperFilter.doFilter(RequestWrapperFilter.java:45)
                at org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:237)
                at org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:167)
                at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
                at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
                at com.cvty.coco.presentation.jsf.util.AuthFilter.doFilter(AuthFilter.java:95)
                at org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:237)
                at org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:167)
                at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
                at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
                at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
                at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
                at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
                at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:235)
                at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
                at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:183)
                at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:95)
                at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126)
                at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70)
                at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
                at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
                at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
                at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
                at org.jboss.web.tomcat.service.request.ActiveRequestResponseCacheValve.internalProcess(ActiveRequestResponseCacheValve.java:74)
                at org.jboss.web.tomcat.service.request.ActiveRequestResponseCacheValve.invoke(ActiveRequestResponseCacheValve.java:47)
                at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
                at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829)
                at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:599)
                at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:451)
                at java.lang.Thread.run(Thread.java:619)

                Sample application is working fine when you remove icepush-ee.jar library.


                To reproduce:
                1. Place ICEFacesTestApp.war in <JBOSS location>/server/default/deploy location
                2. Start the server.
                3. Access application URL via browser.                 		The following exception is thrown when a sample application attached to this ticket is deployed and accessed on JBoss 5.1 server.

                at org.icepush.util.ExtensionRegistry.getBestExtension(ExtensionRegistry.java:69)
                at org.icefaces.impl.push.servlet.ICEpushResourceHandler$ICEpushResourceHandlerImpl.beforePhase(ICEpushResourceHandler.java:169)
                at org.icefaces.impl.push.servlet.ICEpushResourceHandler.beforePhase(ICEpushResourceHandler.java:109)
                at com.sun.faces.lifecycle.Phase.handleBeforePhase(Phase.java:228)
                at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:99)
                at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:111)
                at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
                at javax.faces.webapp.FacesServlet.service(FacesServlet.java:508)
                at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
                at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
                at com.cvty.coco.presentation.jsf.util.RequestWrapperFilter.doFilter(RequestWrapperFilter.java:45)
                at org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:237)
                at org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:167)
                at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
                at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
                at com.cvty.coco.presentation.jsf.util.AuthFilter.doFilter(AuthFilter.java:95)
                at org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:237)
                at org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:167)
                at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
                at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
                at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
                at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
                at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
                at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:235)
                at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
                at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:183)
                at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:95)
                at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126)
                at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70)
                at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
                at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
                at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
                at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
                at org.jboss.web.tomcat.service.request.ActiveRequestResponseCacheValve.internalProcess(ActiveRequestResponseCacheValve.java:74)
                at org.jboss.web.tomcat.service.request.ActiveRequestResponseCacheValve.invoke(ActiveRequestResponseCacheValve.java:47)
                at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
                at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829)
                at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:599)
                at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:451)
                at java.lang.Thread.run(Thread.java:619)

                Sample application is working fine when you remove icepush-ee.jar library.


                To reproduce:
                1. Place ICEFacesTestApp.war in <JBOSS location>/server/default/deploy location
                2. Start the server.
                3. Access application URL via browser.

                NOTE:
                Similar issue was reported for WAS7 application server
                Ken Fyten made changes -
                Fix Version/s EE-3.0.0.GA_P01 [ 10329 ]
                Fix Version/s 3.1 [ 10310 ]
                Assignee Priority P2
                Assignee Ken Fyten [ ken.fyten ] Ted Goddard [ ted.goddard ]
                Ken Fyten made changes -
                Assignee Priority P2 P1
                Affects Version/s 3.0.1 [ 10311 ]
                Hide
                Permalink
                Ted Goddard added a comment -

                Adding the following listeners allows ICEpush to startup, but is still not sufficient for all ICEpush-EE features since they also rely on ServletContextListener initialization:

                <listener>
                <listener-class>com.sun.faces.config.ConfigureListener</listener-class>
                </listener>
                <listener>
                <listener-class>org.icepush.util.ExtensionRegistry</listener-class>
                </listener>
                <listener>
                <listener-class>org.icepush.servlet.MainServlet$ExtensionRegistration</listener-class>
                </listener>
                <listener>
                <listener-class>org.icepush.EmailNotificationProvider$AutoRegister</listener-class>
                </listener>

                Show
                Ted Goddard added a comment - Adding the following listeners allows ICEpush to startup, but is still not sufficient for all ICEpush-EE features since they also rely on ServletContextListener initialization: <listener> <listener-class>com.sun.faces.config.ConfigureListener</listener-class> </listener> <listener> <listener-class>org.icepush.util.ExtensionRegistry</listener-class> </listener> <listener> <listener-class>org.icepush.servlet.MainServlet$ExtensionRegistration</listener-class> </listener> <listener> <listener-class>org.icepush.EmailNotificationProvider$AutoRegister</listener-class> </listener>
                Hide
                Permalink
                Ted Goddard added a comment -

                If the supplied test application is deployed to JBoss as a single (zipped) .war rather than an exploded .war, the listeners are called as required and ICEpush is initialized without exceptions.

                Show
                Ted Goddard added a comment - If the supplied test application is deployed to JBoss as a single (zipped) .war rather than an exploded .war, the listeners are called as required and ICEpush is initialized without exceptions.
                Ted Goddard made changes -
                Workaround Description A variety of workarounds are possible:
                add <listener> to web.xml for the various ICEfaces/ICEpush listeners
                add icepush.tld under WEB-IN

                However the best approach is to deploy the application as a zipped .war rather than an exploded directory.
                Workaround Exists [Yes]
                Hide
                Permalink
                Ted Goddard added a comment -

                Failure on JBoss was due to deployment as exploded .war with apparent bug in JBoss to not scan TLDs under these conditions.

                Show
                Ted Goddard added a comment - Failure on JBoss was due to deployment as exploded .war with apparent bug in JBoss to not scan TLDs under these conditions.
                Ted Goddard made changes -
                Status Open [ 1 ] Resolved [ 5 ]
                Resolution Fixed [ 1 ]
                Ted Goddard made changes -
                Workaround Description A variety of workarounds are possible:
                add <listener> to web.xml for the various ICEfaces/ICEpush listeners
                add icepush.tld under WEB-IN

                However the best approach is to deploy the application as a zipped .war rather than an exploded directory.
                		 A variety of workarounds are possible:
                add <listener> to web.xml for the various ICEfaces/ICEpush listeners
                add icepush.tld under WEB-INF

                However the best approach is to deploy the application as a zipped .war rather than an exploded directory.
                Ken Fyten made changes -
                Fix Version/s EE 3.1.0 [ 10323 ]
                Fix Version/s 3.1 [ 10310 ]
                Affects Version/s 3.0.1 [ 10311 ]
                Ken Fyten made changes -
                Summary ICEFaces 3.0 - NPE on org.icepush.util.ExtensionRegistry.getBestExtension ICEpush EE 3.0.0.GA - NPE on org.icepush.util.ExtensionRegistry.getBestExtension
                Ken Fyten made changes -
                Resolution Fixed [ 1 ]
                Status Resolved [ 5 ] Reopened [ 4 ]
                Assignee Priority P1 P2
                Ken Fyten made changes -
                Fix Version/s 3.1 [ 10310 ]
                Fix Version/s EE 3.1.0 [ 10323 ]
                Affects Version/s 3.0.1 [ 10311 ]
                Ken Fyten made changes -
                Assignee Priority P2 P1
                Assignee Ted Goddard [ ted.goddard ] Carmen Cristurean [ ccristurean ]
                Arran Mccullough made changes -
                Salesforce Case [5007000000LFlwQ, 5007000000LGK7K, 5007000000KHPQ1] [5007000000LFlwQ, 5007000000LGK7K, 5007000000KHPQ1, 5007000000LI9Rq]
                Hide
                Permalink
                Carmen Cristurean added a comment -

                The .war file has been deployed to WAS7 (class loader order has been selected as 'Classes loaded with local class loader first (parent last)', similarly to the deployment of ICEfaces3 sample applications).
                The WAS admin console indicated successful installation of the .war file:

                Installing...
                If there are enterprise beans in the application, the EJB deployment process can take several minutes. Do not save the configuration until the process completes.

                Check the SystemOut.log on the deployment manager or server where the application is deployed for specific information about the EJB deployment process as it occurs.

                ADMA5016I: Installation of ICEfacesTestApp_war started.

                ADMA5067I: Resource validation for application ICEfacesTestApp_war completed successfully.

                ADMA5058I: Application and module versions are validated with versions of deployment targets.

                ADMA5005I: The application ICEfacesTestApp_war is configured in the WebSphere Application Server repository.

                ADMA5053I: The library references for the installed optional package are created.

                ADMA5005I: The application ICEfacesTestApp_war is configured in the WebSphere Application Server repository.

                ADMA5001I: The application binaries are saved in /opt/IBM/v7.0/WebSphere/AppServer/profiles/AppSrv01/wstemp/0/workspace/cells/centurionNode02Cell/applications/ICEfacesTestApp_war.ear/ICEfacesTestApp_war.ear

                ADMA5005I: The application ICEfacesTestApp_war is configured in the WebSphere Application Server repository.

                SECJ0400I: Successfully updated the application ICEfacesTestApp_war with the appContextIDForSecurity information.

                ADMA5005I: The application ICEfacesTestApp_war is configured in the WebSphere Application Server repository.

                ADMA5113I: Activation plan created successfully.

                ADMA5011I: The cleanup of the temp directory for application ICEfacesTestApp_war is complete.

                ADMA5013I: Application ICEfacesTestApp_war installed successfully.

                Application ICEfacesTestApp_war installed successfully.

                Show
                Carmen Cristurean added a comment - The .war file has been deployed to WAS7 (class loader order has been selected as 'Classes loaded with local class loader first (parent last)', similarly to the deployment of ICEfaces3 sample applications). The WAS admin console indicated successful installation of the .war file: Installing... If there are enterprise beans in the application, the EJB deployment process can take several minutes. Do not save the configuration until the process completes. Check the SystemOut.log on the deployment manager or server where the application is deployed for specific information about the EJB deployment process as it occurs. ADMA5016I: Installation of ICEfacesTestApp_war started. ADMA5067I: Resource validation for application ICEfacesTestApp_war completed successfully. ADMA5058I: Application and module versions are validated with versions of deployment targets. ADMA5005I: The application ICEfacesTestApp_war is configured in the WebSphere Application Server repository. ADMA5053I: The library references for the installed optional package are created. ADMA5005I: The application ICEfacesTestApp_war is configured in the WebSphere Application Server repository. ADMA5001I: The application binaries are saved in /opt/IBM/v7.0/WebSphere/AppServer/profiles/AppSrv01/wstemp/0/workspace/cells/centurionNode02Cell/applications/ICEfacesTestApp_war.ear/ICEfacesTestApp_war.ear ADMA5005I: The application ICEfacesTestApp_war is configured in the WebSphere Application Server repository. SECJ0400I: Successfully updated the application ICEfacesTestApp_war with the appContextIDForSecurity information. ADMA5005I: The application ICEfacesTestApp_war is configured in the WebSphere Application Server repository. ADMA5113I: Activation plan created successfully. ADMA5011I: The cleanup of the temp directory for application ICEfacesTestApp_war is complete. ADMA5013I: Application ICEfacesTestApp_war installed successfully. Application ICEfacesTestApp_war installed successfully.
                Hide
                Permalink
                Carmen Cristurean added a comment -

                Although the WAS admin console indicated successful installation of the .war file, I found the following errors in the SystemOut.log:

                [4/25/12 1:50:25:677 MDT] 00000027 ApplicationMg A WSVR0200I: Starting application: ICEfacesTestApp_war
                [4/25/12 1:50:25:678 MDT] 00000027 ApplicationMg A WSVR0204I: Application: ICEfacesTestApp_war Application build level: Unknown
                [4/25/12 1:50:25:791 MDT] 00000027 webapp I com.ibm.ws.webcontainer.webapp.WebGroupImpl WebGroup SRVE0169I: Loading Web Module: ICEfacesTestApp.war.
                [4/25/12 1:50:25:893 MDT] 00000027 WASSessionCor I SessionContextRegistry getSessionContext SESN0176I: Will create a new session context for application key default_host/ICEfacesTestApp
                [4/25/12 1:50:26:247 MDT] 00000027 config I Initializing Mojarra 2.1.3 (FCS 20110908) for context '/ICEfacesTestApp'
                [4/25/12 1:50:29:161 MDT] 00000027 config E Critical error during deployment:
                java.lang.NoClassDefFoundError: org.jboss.logging.Logger
                at org.jboss.web.jsf.integration.injection.JBossInjectionProvider.<clinit>(JBossInjectionProvider.java:56)
                at java.lang.J9VMInternals.initializeImpl(Native Method)
                at java.lang.J9VMInternals.initialize(J9VMInternals.java:200)
                at java.lang.J9VMInternals.newInstanceImpl(Native Method)
                at java.lang.Class.newInstance(Class.java:1325)
                at com.sun.faces.spi.InjectionProviderFactory.getProviderInstance(InjectionProviderFactory.java:156)
                at com.sun.faces.spi.InjectionProviderFactory.createInstance(InjectionProviderFactory.java:117)
                at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:334)
                at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:225)
                at com.ibm.ws.webcontainer.webapp.WebApp.notifyServletContextCreated(WebApp.java:1663)
                at com.ibm.ws.webcontainer.webapp.WebApp.commonInitializationFinish(WebApp.java:364)
                at com.ibm.ws.webcontainer.webapp.WebAppImpl.initialize(WebAppImpl.java:294)
                ...
                at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1550)
                Caused by: java.lang.ClassNotFoundException: org.jboss.logging.Logger
                at java.lang.ClassNotFoundException.<init>(ClassNotFoundException.java:76)
                at java.net.URLClassLoader.findClass(URLClassLoader.java:419)
                at com.ibm.ws.bootstrap.ExtClassLoader.findClass(ExtClassLoader.java:150)
                at java.lang.ClassLoader.loadClass(ClassLoader.java:643)
                at com.ibm.ws.bootstrap.ExtClassLoader.loadClass(ExtClassLoader.java:90)
                at java.lang.ClassLoader.loadClass(ClassLoader.java:609)
                at com.ibm.ws.classloader.ProtectionClassLoader.loadClass(ProtectionClassLoader.java:62)
                at com.ibm.ws.classloader.ProtectionClassLoader.loadClass(ProtectionClassLoader.java:58)
                at com.ibm.ws.classloader.CompoundClassLoader.loadClass(CompoundClassLoader.java:474)
                at java.lang.ClassLoader.loadClass(ClassLoader.java:609)
                at com.ibm.ws.classloader.CompoundClassLoader.loadClass(CompoundClassLoader.java:506)
                at java.lang.ClassLoader.loadClass(ClassLoader.java:609)
                ... 107 more

                Show
                Carmen Cristurean added a comment - Although the WAS admin console indicated successful installation of the .war file, I found the following errors in the SystemOut.log: [4/25/12 1:50:25:677 MDT] 00000027 ApplicationMg A WSVR0200I: Starting application: ICEfacesTestApp_war [4/25/12 1:50:25:678 MDT] 00000027 ApplicationMg A WSVR0204I: Application: ICEfacesTestApp_war Application build level: Unknown [4/25/12 1:50:25:791 MDT] 00000027 webapp I com.ibm.ws.webcontainer.webapp.WebGroupImpl WebGroup SRVE0169I: Loading Web Module: ICEfacesTestApp.war. [4/25/12 1:50:25:893 MDT] 00000027 WASSessionCor I SessionContextRegistry getSessionContext SESN0176I: Will create a new session context for application key default_host/ICEfacesTestApp [4/25/12 1:50:26:247 MDT] 00000027 config I Initializing Mojarra 2.1.3 (FCS 20110908) for context '/ICEfacesTestApp' [4/25/12 1:50:29:161 MDT] 00000027 config E Critical error during deployment: java.lang.NoClassDefFoundError: org.jboss.logging.Logger at org.jboss.web.jsf.integration.injection.JBossInjectionProvider.<clinit>(JBossInjectionProvider.java:56) at java.lang.J9VMInternals.initializeImpl(Native Method) at java.lang.J9VMInternals.initialize(J9VMInternals.java:200) at java.lang.J9VMInternals.newInstanceImpl(Native Method) at java.lang.Class.newInstance(Class.java:1325) at com.sun.faces.spi.InjectionProviderFactory.getProviderInstance(InjectionProviderFactory.java:156) at com.sun.faces.spi.InjectionProviderFactory.createInstance(InjectionProviderFactory.java:117) at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:334) at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:225) at com.ibm.ws.webcontainer.webapp.WebApp.notifyServletContextCreated(WebApp.java:1663) at com.ibm.ws.webcontainer.webapp.WebApp.commonInitializationFinish(WebApp.java:364) at com.ibm.ws.webcontainer.webapp.WebAppImpl.initialize(WebAppImpl.java:294) ... at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1550) Caused by: java.lang.ClassNotFoundException: org.jboss.logging.Logger at java.lang.ClassNotFoundException.<init>(ClassNotFoundException.java:76) at java.net.URLClassLoader.findClass(URLClassLoader.java:419) at com.ibm.ws.bootstrap.ExtClassLoader.findClass(ExtClassLoader.java:150) at java.lang.ClassLoader.loadClass(ClassLoader.java:643) at com.ibm.ws.bootstrap.ExtClassLoader.loadClass(ExtClassLoader.java:90) at java.lang.ClassLoader.loadClass(ClassLoader.java:609) at com.ibm.ws.classloader.ProtectionClassLoader.loadClass(ProtectionClassLoader.java:62) at com.ibm.ws.classloader.ProtectionClassLoader.loadClass(ProtectionClassLoader.java:58) at com.ibm.ws.classloader.CompoundClassLoader.loadClass(CompoundClassLoader.java:474) at java.lang.ClassLoader.loadClass(ClassLoader.java:609) at com.ibm.ws.classloader.CompoundClassLoader.loadClass(CompoundClassLoader.java:506) at java.lang.ClassLoader.loadClass(ClassLoader.java:609) ... 107 more
                Carmen Cristurean made changes -
                Assignee Carmen Cristurean [ ccristurean ] Deryk Sinotte [ deryk.sinotte ]
                Hide
                Permalink
                Deryk Sinotte added a comment -

                The test application looks like it has a dependency on some JBoss libraries so probably won't run on non-JBoss servers unless we try and tweak it.

                I created an ICEfaces EAR called push-apps-sp.ear which included 2 war files (core/chat and core/auction) both of which use ICEpush. I created the EAR so that the .war files did NOT include icepush.jar. Instead, icepush.jar was included at the application level. When deployed, I got the same problem as originally described:

                java.lang.NullPointerException
                at org.icepush.util.ExtensionRegistry.getBestExtension(ExtensionRegistry.java:69)
                at org.icefaces.impl.push.servlet.ICEpushResourceHandler$ICEpushResourceHandlerImpl.beforePhase(ICEpushResourceHandler.java:169)
                at org.icefaces.impl.push.servlet.ICEpushResourceHandler.beforePhase(ICEpushResourceHandler.java:109)
                at com.sun.faces.lifecycle.Phase.handleBeforePhase(Phase.java:228)
                at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:99)
                at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:116)
                at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
                at javax.faces.webapp.FacesServlet.service(FacesServlet.java:593)
                at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:227)
                at weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:125)
                at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:300)
                at weblogic.servlet.internal.TailFilter.doFilter(TailFilter.java:26)
                at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56)
                at weblogic.servlet.internal.RequestEventsFilter.doFilter(RequestEventsFilter.java:27)
                at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56)
                at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.doIt(WebAppServletContext.java:3684)
                at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:3650)
                at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
                at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:121)
                at weblogic.servlet.internal.WebAppServletContext.securedExecute(WebAppServletContext.java:2268)
                at weblogic.servlet.internal.WebAppServletContext.execute(WebAppServletContext.java:2174)
                at weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1446)
                at weblogic.work.ExecuteThread.execute(ExecuteThread.java:201)
                at weblogic.work.ExecuteThread.run(ExecuteThread.java:173)

                This adds credence to the theory that the required listeners are not being called.

                Show
                Deryk Sinotte added a comment - The test application looks like it has a dependency on some JBoss libraries so probably won't run on non-JBoss servers unless we try and tweak it. I created an ICEfaces EAR called push-apps-sp.ear which included 2 war files (core/chat and core/auction) both of which use ICEpush. I created the EAR so that the .war files did NOT include icepush.jar. Instead, icepush.jar was included at the application level. When deployed, I got the same problem as originally described: java.lang.NullPointerException at org.icepush.util.ExtensionRegistry.getBestExtension(ExtensionRegistry.java:69) at org.icefaces.impl.push.servlet.ICEpushResourceHandler$ICEpushResourceHandlerImpl.beforePhase(ICEpushResourceHandler.java:169) at org.icefaces.impl.push.servlet.ICEpushResourceHandler.beforePhase(ICEpushResourceHandler.java:109) at com.sun.faces.lifecycle.Phase.handleBeforePhase(Phase.java:228) at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:99) at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:116) at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:593) at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:227) at weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:125) at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:300) at weblogic.servlet.internal.TailFilter.doFilter(TailFilter.java:26) at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56) at weblogic.servlet.internal.RequestEventsFilter.doFilter(RequestEventsFilter.java:27) at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56) at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.doIt(WebAppServletContext.java:3684) at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:3650) at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321) at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:121) at weblogic.servlet.internal.WebAppServletContext.securedExecute(WebAppServletContext.java:2268) at weblogic.servlet.internal.WebAppServletContext.execute(WebAppServletContext.java:2174) at weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1446) at weblogic.work.ExecuteThread.execute(ExecuteThread.java:201) at weblogic.work.ExecuteThread.run(ExecuteThread.java:173) This adds credence to the theory that the required listeners are not being called.
                Hide
                Permalink
                Deryk Sinotte added a comment -

                After some futzing around with WebSphere 7, I was basically able to confirm the same behaviour there as well. If I was forced to guess, I'd say that, because the libraries themselves aren't in the .war file, they aren't scanned by the servlet container which therefore means that the relevant servlet context listeners are not fired. Since icepush relies on them to be fired, it looks like icepush.jar needs to be in the .war file for the time being.

                [4/26/12 16:09:30:968 PDT] 0000001e webapp E com.ibm.ws.webcontainer.webapp.WebApp logServletError SRVE0293E: [Servlet Error]-[Faces Servlet]: java.lang.NullPointerException
                at org.icepush.util.ExtensionRegistry.getBestExtension(ExtensionRegistry.java:69)
                at org.icefaces.impl.push.servlet.ICEpushResourceHandler$ICEpushResourceHandlerImpl.beforePhase(ICEpushResourceHandler.java:169)
                at org.icefaces.impl.push.servlet.ICEpushResourceHandler.beforePhase(ICEpushResourceHandler.java:109)
                at com.sun.faces.lifecycle.Phase.handleBeforePhase(Phase.java:228)
                at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:99)
                at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:116)
                at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
                at javax.faces.webapp.FacesServlet.service(FacesServlet.java:593)
                at com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:1655)
                at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:937)
                at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:500)
                at com.ibm.ws.webcontainer.servlet.ServletWrapperImpl.handleRequest(ServletWrapperImpl.java:178)
                at com.ibm.ws.webcontainer.webapp.WebApp.handleRequest(WebApp.java:3826)
                at com.ibm.ws.webcontainer.webapp.WebGroup.handleRequest(WebGroup.java:276)
                at com.ibm.ws.webcontainer.WebContainer.handleRequest(WebContainer.java:931)
                at com.ibm.ws.webcontainer.WSWebContainer.handleRequest(WSWebContainer.java:1583)
                at com.ibm.ws.webcontainer.channel.WCChannelLink.ready(WCChannelLink.java:186)
                at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleDiscrimination(HttpInboundLink.java:455)
                at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleNewInformation(HttpInboundLink.java:384)
                at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.ready(HttpInboundLink.java:272)
                at com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.sendToDiscriminators(NewConnectionInitialReadCallback.java:214)
                at com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.complete(NewConnectionInitialReadCallback.java:113)
                at com.ibm.ws.tcp.channel.impl.AioReadCompletionListener.futureCompleted(AioReadCompletionListener.java:165)
                at com.ibm.io.async.AbstractAsyncFuture.invokeCallback(AbstractAsyncFuture.java:217)
                at com.ibm.io.async.AsyncChannelFuture.fireCompletionActions(AsyncChannelFuture.java:161)
                at com.ibm.io.async.AsyncFuture.completed(AsyncFuture.java:138)
                at com.ibm.io.async.ResultHandler.complete(ResultHandler.java:204)
                at com.ibm.io.async.ResultHandler.runEventProcessingLoop(ResultHandler.java:775)
                at com.ibm.io.async.ResultHandler$2.run(ResultHandler.java:905)
                at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1550)

                Show
                Deryk Sinotte added a comment - After some futzing around with WebSphere 7, I was basically able to confirm the same behaviour there as well. If I was forced to guess, I'd say that, because the libraries themselves aren't in the .war file, they aren't scanned by the servlet container which therefore means that the relevant servlet context listeners are not fired. Since icepush relies on them to be fired, it looks like icepush.jar needs to be in the .war file for the time being. [4/26/12 16:09:30:968 PDT] 0000001e webapp E com.ibm.ws.webcontainer.webapp.WebApp logServletError SRVE0293E: [Servlet Error] - [Faces Servlet] : java.lang.NullPointerException at org.icepush.util.ExtensionRegistry.getBestExtension(ExtensionRegistry.java:69) at org.icefaces.impl.push.servlet.ICEpushResourceHandler$ICEpushResourceHandlerImpl.beforePhase(ICEpushResourceHandler.java:169) at org.icefaces.impl.push.servlet.ICEpushResourceHandler.beforePhase(ICEpushResourceHandler.java:109) at com.sun.faces.lifecycle.Phase.handleBeforePhase(Phase.java:228) at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:99) at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:116) at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:593) at com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:1655) at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:937) at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:500) at com.ibm.ws.webcontainer.servlet.ServletWrapperImpl.handleRequest(ServletWrapperImpl.java:178) at com.ibm.ws.webcontainer.webapp.WebApp.handleRequest(WebApp.java:3826) at com.ibm.ws.webcontainer.webapp.WebGroup.handleRequest(WebGroup.java:276) at com.ibm.ws.webcontainer.WebContainer.handleRequest(WebContainer.java:931) at com.ibm.ws.webcontainer.WSWebContainer.handleRequest(WSWebContainer.java:1583) at com.ibm.ws.webcontainer.channel.WCChannelLink.ready(WCChannelLink.java:186) at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleDiscrimination(HttpInboundLink.java:455) at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleNewInformation(HttpInboundLink.java:384) at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.ready(HttpInboundLink.java:272) at com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.sendToDiscriminators(NewConnectionInitialReadCallback.java:214) at com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.complete(NewConnectionInitialReadCallback.java:113) at com.ibm.ws.tcp.channel.impl.AioReadCompletionListener.futureCompleted(AioReadCompletionListener.java:165) at com.ibm.io.async.AbstractAsyncFuture.invokeCallback(AbstractAsyncFuture.java:217) at com.ibm.io.async.AsyncChannelFuture.fireCompletionActions(AsyncChannelFuture.java:161) at com.ibm.io.async.AsyncFuture.completed(AsyncFuture.java:138) at com.ibm.io.async.ResultHandler.complete(ResultHandler.java:204) at com.ibm.io.async.ResultHandler.runEventProcessingLoop(ResultHandler.java:775) at com.ibm.io.async.ResultHandler$2.run(ResultHandler.java:905) at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1550)
                Deryk Sinotte made changes -
                Workaround Description A variety of workarounds are possible:
                add <listener> to web.xml for the various ICEfaces/ICEpush listeners
                add icepush.tld under WEB-INF

                However the best approach is to deploy the application as a zipped .war rather than an exploded directory.
                		 A variety of workarounds are possible:
                add <listener> to web.xml for the various ICEfaces/ICEpush listeners
                add icepush.tld under WEB-INF

                However the best approach is to deploy the application as a zipped .war rather than an exploded directory.

                The same issue can occur when trying to include ICEfaces libs (e.g. icepush.jar) as shared libs in an .ear deployment. The solution is to simply include all libraries in the WEB-INF/lib directory of each war module.
                Deryk Sinotte made changes -
                Link This issue depends on IPCK-401 [ IPCK-401 ]
                Deryk Sinotte made changes -
                Fix Version/s 3.2 [ 10340 ]
                Fix Version/s EE 3.2.0 [ 10323 ]
                Fix Version/s EE-3.0.0.GA_P01 [ 10329 ]
                Fix Version/s 3.1 [ 10310 ]
                Migration made changes -
                Assignee Deryk Sinotte [ deryk.sinotte ] Jack Van Ooststroom [ jack.van.ooststroom ]
                Fix Version/s 3.3 [ 10374 ]
                Fix Version/s EE-3.2.0.GA [ 10323 ]
                Fix Version/s 3.2 [ 10340 ]
                Jack Van Ooststroom made changes -
                Fix Version/s EE-3.3.0.GA [ 10575 ]
                Fix Version/s 3.3 [ 10374 ]
                Hide
                Permalink
                Jack Van Ooststroom added a comment -

                I changed the target to EE-3.3.0.GA as this is more likely to be an EE fix. For 3.3.0 we can suggest the mentioned workarounds for the time being. Other servers seem to suffer from this as well. A potential fix would probably have to be tested on our matrix of supported servers.

                Show
                Jack Van Ooststroom added a comment - I changed the target to EE-3.3.0.GA as this is more likely to be an EE fix. For 3.3.0 we can suggest the mentioned workarounds for the time being. Other servers seem to suffer from this as well. A potential fix would probably have to be tested on our matrix of supported servers.
                Ken Fyten made changes -
                Assignee Priority P1 [ 10010 ] P2 [ 10011 ]
                Ken Fyten made changes -
                Fix Version/s EE-3.4.0.GA [ 11170 ]
                Fix Version/s EE-3.3.0.GA [ 10575 ]
                Tyler Johnson made changes -
                Salesforce Case Reference 5007000000LFlwQAAT
                Ken Fyten made changes -
                Fix Version/s EE-3.3.0.GA_P01 [ 11175 ]
                Fix Version/s EE-3.4.0.GA [ 11170 ]
                Ken Fyten made changes -
                Fix Version/s EE-3.4.0.GA [ 11170 ]
                Fix Version/s EE-3.3.0.GA_P01 [ 11175 ]
                Hide
                Permalink
                Jack Van Ooststroom added a comment -

                After discussing this with Deryk, here is the summary for this JIRA:

                1. The issue here is that the listeners registered in the .tld-file(s) aren't getting called when using an .ear-file with multiple .war-files but having the icepush.jar at the .ear-level, and not at the .war-level.

                2. There is a workaround for this issue when using an .ear-file with multiple .war-files using ICEfaces/ICEpush, which is to include the already existing .jar-files in each .war-file. This can be considered a overhead.

                3. On the short term, get rid off the NPE by adding a null check and log a warning message explaining the problem. This is not a solution, but nicer then throwing the NPE.

                4. Eventually we should look into the potential solution as mentioned in IPCK-401 and have a separate .jar-file that includes all our .tld-files and have that at the .war-level, and have the icepush.jar still at the .ear-level.

                Show
                Jack Van Ooststroom added a comment - After discussing this with Deryk, here is the summary for this JIRA: 1. The issue here is that the listeners registered in the .tld-file(s) aren't getting called when using an .ear-file with multiple .war-files but having the icepush.jar at the .ear-level, and not at the .war-level. 2. There is a workaround for this issue when using an .ear-file with multiple .war-files using ICEfaces/ICEpush, which is to include the already existing .jar-files in each .war-file. This can be considered a overhead. 3. On the short term, get rid off the NPE by adding a null check and log a warning message explaining the problem. This is not a solution, but nicer then throwing the NPE. 4. Eventually we should look into the potential solution as mentioned in IPCK-401 and have a separate .jar-file that includes all our .tld-files and have that at the .war-level, and have the icepush.jar still at the .ear-level.
                Jack Van Ooststroom made changes -
                Fix Version/s EE-4.1.0.GA [ 12172 ]
                Fix Version/s EE-4.0.0.GA [ 11170 ]
                Hide
                Permalink
                Jack Van Ooststroom added a comment -

                Re-targeting for EE-4.1.0.GA

                Show
                Jack Van Ooststroom added a comment - Re-targeting for EE-4.1.0.GA
                Hide
                Permalink
                Ken Fyten added a comment -

                Closing this as Won't Fix.

                Multiple acceptable workarounds exist.

                Show
                Ken Fyten added a comment - Closing this as Won't Fix. Multiple acceptable workarounds exist.
                Ken Fyten made changes -
                Status Reopened [ 4 ] Closed [ 6 ]
                Resolution Won't Fix [ 2 ]

                  People

                  • Assignee:
                    Jack Van Ooststroom
                    Reporter:
                    Evgheni Sadovoi
                  • Votes:
                    0 Vote for this issue
                    Watchers:
                    3 Start watching this issue

                    Dates

                    • Created:
                      Updated:
                      Resolved: