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>

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

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.

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

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.

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)

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.

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.

Re-targeting for EE-4.1.0.GA

Closing this as Won't Fix.

Multiple acceptable workarounds exist.