[ 
https://issues.apache.org/jira/browse/CXF-7975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Milko Schuurman updated CXF-7975:
---------------------------------
    Summary: jms.util.MessageListenerContainer is incompatible with JEE web and 
EJB applications  (was: jms.util.MessageListenerContainer is incompatible with 
JEE WAR and EJB applications)

> jms.util.MessageListenerContainer is incompatible with JEE web and EJB 
> applications
> -----------------------------------------------------------------------------------
>
>                 Key: CXF-7975
>                 URL: https://issues.apache.org/jira/browse/CXF-7975
>             Project: CXF
>          Issue Type: Bug
>          Components: JMS
>    Affects Versions: 3.2.7
>         Environment: WebSphere Application Server 8.5.5.11
> OpenJDK 1.8.0_181
>            Reporter: Milko Schuurman
>            Priority: Major
>
> Invoking a for JMS configured JAX WS client with a ConnectionFactory managed 
> by an application server results in the following stacktrace:
> {code:java}
> org.apache.cxf.phase.PhaseInterceptorChain doDefaultLogging Interceptor for 
> [...] has thrown exception, unwinding now
>                                  java.lang.RuntimeException: Method 
> setMessageListener not permitted
>         at 
> org.apache.cxf.transport.jms.util.JMSUtil.convertJmsException(JMSUtil.java:92)
>         at 
> org.apache.cxf.transport.jms.util.MessageListenerContainer.start(MessageListenerContainer.java:66)
>         at 
> org.apache.cxf.transport.jms.JMSConduit.setupReplyDestination(JMSConduit.java:236)
>         at 
> org.apache.cxf.transport.jms.JMSConduit.sendAndReceiveMessage(JMSConduit.java:248)
>         at 
> org.apache.cxf.transport.jms.JMSConduit.sendExchange(JMSConduit.java:177)
>         at 
> org.apache.cxf.transport.jms.MessageStreamUtil$SendingWriter.close(MessageStreamUtil.java:66)
>         at 
> org.apache.cxf.transport.jms.MessageStreamUtil.closeStreams(MessageStreamUtil.java:89)
>         at org.apache.cxf.transport.jms.JMSConduit.close(JMSConduit.java:103)
>         at 
> org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:63)
>         at 
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
>         at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:531)
>         at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:440)
>         at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:355)
>         at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:313)
>         at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:96)
>         at 
> org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:140)
> [...]
> {code}
> The exception is thrown by WebSphere's impl of javax.jms.MessageConsumer 
> (com.ibm.ejs.jms.JMSMessageConsumerHandle) that wraps the MessageConsumer 
> impl of our JMS provider:
> {code:java}
> Caused by: javax.jms.IllegalStateException: Method setMessageListener not 
> permitted
>         at 
> com.ibm.ejs.jms.JMSCMUtils.methodNotPermittedException(JMSCMUtils.java:244)
>         at 
> com.ibm.ejs.jms.JMSMessageConsumerHandle.setMessageListener(JMSMessageConsumerHandle.java:397)
>         at 
> org.apache.cxf.transport.jms.util.MessageListenerContainer.start(MessageListenerContainer.java:62)
>         ... 100 more
> {code}
> According to the JMS 2.0 docs on MessageConsumer.setMessageListener this kind 
> of behavior can be expected (though from what i can find only WebSphere chose 
> this route):
> {code:java}
> [...]
> This method must not be used in a Java EE web or EJB application. Doing so 
> may cause a JMSException to be thrown though this is not guaranteed.
> {code}
> Source: 
> [https://docs.oracle.com/javaee/7/api/javax/jms/MessageConsumer.html#setMessageListener-javax.jms.MessageListener-]
> Line where setMessageListener is called: MessageListenerContainer:62 (after 
> creation of the container on JMSConduit:224).
>  
> Is there currently any way to work around this (besides not using a managed 
> connection factory)?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to