[PUSH-173] ICEpush EE 3.0.0.GA - NPE on org.icepush.util.ExtensionRegistry.getBestExtension - ICEsoft JIRA Issue Tracker

Details

Type: Bug
Status: Closed
Priority: 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

Options
- Sort By Name
- Sort By Date
- Ascending
- Descending
- Download All

Attachments

ICEFacesTestApp.war.rar

16/Apr/12 3:25 PM

9.27 MB

Evgheni Sadovoi

Issue Links

depends on

IPCK-401 Improve support for EAR deployments

Open

Activity

Ascending order - Click to sort in descending order

Hide

Permalink

Ted Goddard added a comment - 18/Apr/12 12:37 PM

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 - 18/Apr/12 12:37 PM 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>

5 older comments

Hide

Permalink

Deryk Sinotte added a comment - 26/Apr/12 6:13 PM

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 - 26/Apr/12 6:13 PM 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)

Hide

Permalink

Jack Van Ooststroom added a comment - 19/Mar/13 4:07 PM

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 - 19/Mar/13 4:07 PM 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.

Hide

Permalink

Jack Van Ooststroom added a comment - 29/Aug/13 5:07 PM

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 - 29/Aug/13 5:07 PM 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.

Hide

Permalink

Jack Van Ooststroom added a comment - 27/Jan/15 3:01 PM

Re-targeting for EE-4.1.0.GA

Show

Jack Van Ooststroom added a comment - 27/Jan/15 3:01 PM Re-targeting for EE-4.1.0.GA

Hide

Permalink

Ken Fyten added a comment - 02/Mar/16 2:56 PM

Closing this as Won't Fix.

Multiple acceptable workarounds exist.

Show

Ken Fyten added a comment - 02/Mar/16 2:56 PM Closing this as Won't Fix. Multiple acceptable workarounds exist.

People

Assignee:

Jack Van Ooststroom

Reporter:

Evgheni Sadovoi

Votes:

0 Vote for this issue

Watchers:

3 Start watching this issue

Dates

Created:

16/Apr/12 3:23 PM

Updated:

02/Mar/16 2:56 PM

Resolved:

02/Mar/16 2:56 PM