1 2 Previous Next 15 Replies Latest reply on Oct 16, 2010 1:27 PM by Justin Bertram

    Does JBoss ESB violate the JEE 5 Specification?

    Peer Bech Hansen Newbie
      Does JBoss ESB violate the JEE 5 Specification?
      For the project I’m currently working on, I’m trying to get the JBoss ESB to use IBM WebSphere MQ queues as both incoming data providers and outgoing data consumers.
      I’m using IBM’s “WebSphere MQ resource adapter” and JCA administered objects to bind remote WMQ queues to my local JNDI.
      The guides I have followed, to configure the resource adaptor and to define my queues is found here:
      It seems to work beautifully; I have developed a proof-of-concept EJB3 Webservice that looks up WMQ queues and uses the WMQ ConnectionFactory implementation to put messages on the queue.
      The following is the Webservice I have successfully used to put messages on a WebSphere queue from a JBoss AS, hence I conclude that my queue and resource adapter configuration is correct.
      [Example]
      My problem occurs, when I’m trying to use the JBoss ESB JMSRouter class to write to  a queue:
      When sending messages I get the following error:
      The “WebSphere MQ resource adapter” fails; telling me that an illegal method has been called.
      After a little investigation I think I have found out why:
      For sending messages to the queues I’m using the
      org.jboss.soa.esb.actions.routing.JMSRouter action class and for reading messages I’m using the
      Both these two classes internally use the class           org.jboss.internal.soa.esb.rosetta.pooling.JmsConnectionPool.
      On line 778, the JmsConnectionPool class is calling the method setExceptionListener() on the ConnectionFactory.
      On page 133 - 134 of the Java™ Platform, Enterprise Edition (Java EE) Specification, v5 (http://jcp.org/aboutJava/communityprocess/final/jsr244/index.html) it is clearly stated that call to this method (and other methods), from web or EJB containers is prohibited.
      The “WebSphere MQ resource adapter” has implemented this restriction and throws an Exception if the method is call on their ConnectionFactory implementation.
      So the questions is?
      Isn’t JBoss ESB violation the JEE5 specification, and how do I create a workaround for the problem?
      Hi all

      Hi JBoss people

       

      For the project I’m currently working on, I’m trying to get the JBoss ESB to use IBM WebSphere MQ queues as both incoming data providers and outgoing data consumers.

       

      I’m using IBM’s “WebSphere MQ resource adapter” and JCA administered objects to bind remote WMQ queues to my local JNDI.

       

      The guides I have followed, to configure the resource adaptor and to define my queues is found here:

      http://www.ibm.com/developerworks/websphere/library/techarticles/0710_ritchie/0710_ritchie.html

      http://community.jboss.org/wiki/UsingWebSphereMQSeriesWithJBossASPart4

       

      It seems to work beautifully; I have developed a proof-of-concept EJB3 Webservice that looks up WMQ queues and uses the WMQ ConnectionFactory implementation to put messages on the queue.

       

      The following is the Webservice I have successfully used to put messages on a WebSphere queue from a JBoss AS, hence I conclude that my queue and resource adapter configuration is correct.

       

       

      package com.test.ws;
      
      import java.util.Properties;
      
      import javax.ejb.Stateless;
      import javax.jms.Connection;
      import javax.jms.ConnectionFactory;
      import javax.jms.MessageProducer;
      import javax.jms.Queue;
      import javax.jms.QueueSession;
      import javax.jms.Session;
      import javax.jms.TextMessage;
      import javax.jws.WebMethod;
      import javax.jws.WebService;
      import javax.naming.Context;
      import javax.naming.InitialContext;
      
      import org.jboss.wsf.spi.annotation.WebContext;
      
      @Stateless
      @WebService(serviceName = "TestWMQService", targetNamespace = "http://TestWMQService")
      @WebContext(contextRoot = "/ws", urlPattern = "/TestWMQService")
      public class TestWMQService {
      
           private static final Logger logger = Logger.getLogger(TestWMQService.class.getName());
      
           @WebMethod
           public void testing() throws Exception {
                try {
      
                     Properties properties = new Properties();
                     properties.put(Context.INITIAL_CONTEXT_FACTORY, "org.jnp.interfaces.NamingContextFactory");
                     properties.put(Context.URL_PKG_PREFIXES, "org.jboss.naming:org.jnp.interfaces");
                     properties.put(Context.PROVIDER_URL, "jnp://127.0.0.1:9199");
                     InitialContext iniCtx = new InitialContext();
      
                     ConnectionFactory qcf = (ConnectionFactory) iniCtx.lookup("java:WMQConnectionFactory");
                     Connection conn = qcf.createConnection();
                     Queue queue = (Queue) iniCtx.lookup("queue/WMQTest");
      
                     Session session = conn.createSession(false, QueueSession.AUTO_ACKNOWLEDGE);
                     conn.start();
      
                     MessageProducer send = session.createProducer(queue);
                     TextMessage tm = session.createTextMessage();
                     tm.setText("WMQ Testing");
      
                     send.send(tm);
                     send.close();
                     session.close();
                     conn.close();
      
                } catch (Exception e) {
                     e.printStackTrace();
                     throw e;
                }
           }
      }
      
       
      

       

       

       

      My problem occurs, when I’m trying to use the JBoss ESB JMSRouter class to write to  a queue:

       

      When the ESB project is initialized i get the following error:

       

      Caused by: org.jboss.soa.esb.ConfigurationException: Failed to configure JMS Destination for routing.
              at com.testproject.esbpoc.JMSRouter.createQueueSetup(JMSRouter.java:509)
              at com.testproject.esbpoc.JMSRouter.<init>(JMSRouter.java:291)
              ... 93 more
      Caused by: com.ibm.msg.client.jms.DetailedIllegalStateException: MQJCA1031: The method can only be called in the application client container. The application was not running in the application client container when this method was called.  Ensure that the application runs in the application client container, or modify the application to avoid this method call.
              at com.ibm.mq.connector.services.JCAExceptionBuilder.buildException(JCAExceptionBuilder.java:149)
              at com.ibm.mq.connector.services.JCAExceptionBuilder.buildException(JCAExceptionBuilder.java:86)
              at com.ibm.mq.connector.outbound.ConnectionWrapper.setExceptionListener(ConnectionWrapper.java:183)
              at org.jboss.internal.soa.esb.rosetta.pooling.JmsConnectionPool$JmsSessionPool.initConnection(JmsConnectionPool.java:778)
              at org.jboss.internal.soa.esb.rosetta.pooling.JmsConnectionPool$JmsSessionPool.getSession(JmsConnectionPool.java:704)
              at org.jboss.internal.soa.esb.rosetta.pooling.JmsConnectionPool.internalGetSession(JmsConnectionPool.java:260)
              at org.jboss.internal.soa.esb.rosetta.pooling.JmsConnectionPool.getSession(JmsConnectionPool.java:198)
              at org.jboss.internal.soa.esb.rosetta.pooling.JmsConnectionPool.getSession(JmsConnectionPool.java:353)
              at com.testproject.esbpoc.JMSRouter.createQueueSetup(JMSRouter.java:488)
              ... 94 more
      

       

       

      The “WebSphere MQ resource adapter” fails; telling me that an illegal method has been called.

       

      After a little investigation I think I have found out why:

       

      For sending messages to the queues I’m using the action class:

      org.jboss.soa.esb.actions.routing.JMSRouter

       

       

      The class internally use the class:

      org.jboss.internal.soa.esb.rosetta.pooling.JmsConnectionPool.

       

       

       

      On line 778, the JmsConnectionPool class is calling the method setExceptionListener() on the ConnectionFactory.

       

      On page 133 - 134 of the Java™ Platform, Enterprise Edition (Java EE) Specification, v5 (http://jcp.org/aboutJava/communityprocess/final/jsr244/index.html) it is clearly stated that call to this method (and other methods), from web or EJB containers is prohibited.

       

      The “WebSphere MQ resource adapter” has implemented this restriction and throws an Exception if the method is call on their ConnectionFactory implementation.

       

      So the questions is:

       

      Isn’t JBoss ESB violating the JEE5 specification, and how do I create a workaround for the problem?

       

      Looking forward to hear your opinions.

       

      Kind regards

       

      Peer Bech Hansen

      Logica Denmark

       

       

      Environment used:

      Microsoft Windows XP SP3

      JBoss AS 5.1.0 GA

      JBoss Messaging 1.4.3 GA

      JBoss ESB 4.9

        • 1. Re: Does JBoss ESB violate the JEE 5 Specification?
          Peer Bech Hansen Newbie

          I have now experienced the exact same type of error in JBoss Messaging 1.4.3 GA. (Bundled with JBossAS 5.1.0 GA)

          The Bridge service calls the same restricted method, leading to error.

           

          http://community.jboss.org/message/562832

          • 2. Re: Does JBoss ESB violate the JEE 5 Specification?
            Kevin Conner Master

            I would guess that you have configured the bridge and ESB to use a JCA wrapped JMS provider rather than the real JMS client.

             

            Kev

            • 3. Re: Does JBoss ESB violate the JEE 5 Specification?
              Peer Bech Hansen Newbie

              Hi Kevin

               

              Yes I have configured both the Bridge and the ESB to use the WebSphere MQ resource adapter provided by IBM (Se the initial question for configuration details)

               

              I’m afraid I don’t really understand your answer. Why shouldn't I use JCA to connect to the WMQ resource? Isn’t that exactly what its for?

               

              What do you mean by “The real JMS client”? I use the client provided by IBM.

               

              I want to use “AdminObject”s to bind the WMQ Queues to my local JNDI, to make the solution be unaware about the fact, that the Queues are WMQ implementations.

               

              Peer

              • 4. Re: Does JBoss ESB violate the JEE 5 Specification?
                Kevin Conner Master

                I believe the bridge assumes a remote JMS provider rather than a colocated one and the ESB JMS courier code handles pooling, transaction enlistment by itself.

                 

                The JMS client should be the one that a standalone client would use from outside the app server.

                • 5. Re: Does JBoss ESB violate the JEE 5 Specification?
                  Peer Bech Hansen Newbie

                  Kevin Conner wrote:

                   

                  I believe the bridge assumes a remote JMS provider rather than a colocated one and the ESB JMS courier code handles pooling, transaction enlistment by itself.

                   

                  I have been studying the code for the org.jboss.jms.server.bridge.Bridge and I don’t believe it assumes anything at all about the nature of the JMS provider. I can’t find anything in the documentation that substantiates that argument either.

                   

                  I have also been studying the code for the ESB org.jboss.soa.esb.actions.routing.JMSRouter, and as far as I can tell, they both simply lookup an implementation of javax.jms.ConnectionFactory from the JNDI. (The JNDI could be local or remote; it doesn’t matter in this case)

                   

                  The implementation of javax.jms.ConnectionFactory is then used to create an implementation of javax.jms.Connection.

                  On this connection, org.jboss.soa.esb.actions.routing.JMSRouter and org.jboss.jms.server.bridge.Bridge both causes a call to the connections setException() method. A call that is performed from within the ApplicationServer, thus prohibited according to the J2EE specification.

                   

                   

                  Kevin Conner wrote:

                   

                  The JMS client should be the one that a standalone client would use from outside the app server.

                   

                  I can’t see why it matters if I use the JCA resource adaptor or the standalone client?

                  org.jboss.soa.esb.actions.routing.JMSRouter and org.jboss.jms.server.bridge.Bridge will still uses implementations of javax.jms.ConnectionFactory and javax.jms.Connection, and there will still be invoked illegal calls to the implementations setException() method from within the ApplicationServer.

                  • 6. Re: Does JBoss ESB violate the JEE 5 Specification?
                    Kevin Conner Master

                    It matters because there are implications in using the JCA provided wrapped objects, specifically the pooling and enlistment of the XAResources within the transaction.  In addition the JCA provided objects restrict the JMS API which is why you are seeing that exception.

                     

                    Kev

                    • 7. Re: Does JBoss ESB violate the JEE 5 Specification?
                      Tom Fennelly Master

                      Peer, configure the JMSRouter to connect directly to the remote WMQ provider.  Do not configure it to connect to the local JCA wrapped objects.

                      • 8. Re: Does JBoss ESB violate the JEE 5 Specification?
                        Peer Bech Hansen Newbie

                        Tom:

                         

                        Why?

                         

                        If I can't use the WebSphere resource adaptor like this, what is it for then?

                         

                        Either way I do this, does not change the fact that JBoss (ESB Action and Messaging MBean) server-code call the setException() on the javax.jms.Connection implementation.

                        And this is NOT legal according to the J2EE spec. I'm i wrong?

                         

                        For me this is not so much a discussion about how I do this, than it is a discussion about JBoss is calling a method where it is not allowed to, according to the J2EE specification.

                        If JBoss met the requirements from the specification, I would have no problems and my solution would work perfectly.

                        • 9. Re: Does JBoss ESB violate the JEE 5 Specification?
                          Kevin Conner Master

                          But it is legal with the JMS spec and the standalone client (rather than the JCA one).

                           

                          Kev

                          • 10. Re: Does JBoss ESB violate the JEE 5 Specification?
                            Kevin Conner Master

                            You should also note that an ESB deployment is neither a WEB nor EJB deployment.

                             

                            Kev

                            • 11. Re: Does JBoss ESB violate the JEE 5 Specification?
                              Tom Fennelly Master

                              Peer... with respect to JCA (and especially WMQ) you are correct.... this is an issue and it needs to be addressed.  So, I think we can park that part of the discussion now.

                               

                              As far as getting a solution for your app now... the only possibilities you have (at the moment) are to:

                              1. Use the JMSRouter as outlined above i.e. connect directly to the WMQ provider (not via JCA).
                              2. Implement a shortterm workaround ESB Action that does the routing to the JCA wrapped endpoing i.e. does not use the ESBs JMS Connection pooling (as with JMSRouter).  This would be implemented similarly to your webservice, so you could reuse that code.

                               

                              Hope that helps.

                              • 12. Re: Does JBoss ESB violate the JEE 5 Specification?
                                Kevin Conner Master

                                The only issue wrt ESB and the bridge would be to clarify the documentation describing how to configure this.

                                 

                                Kev

                                • 13. Re: Does JBoss ESB violate the JEE 5 Specification?
                                  Peer Bech Hansen Newbie

                                  Thanks a lot for all your input.

                                   

                                  Beside this thread, I have also been communication, via mail, with a guy from IBM. He says that the resource adaptor is the only supported approach for using WMQ within the JBoss environment.

                                   

                                  I guess the problem is that JBoss and IBM have different opinion about what qualifies as an Application client container.

                                   

                                  JBoss is of the perception that ESB and MBeans runs in the “Application client container” as they are really not running in EJB or WEB containers.

                                   

                                  IBM (and in my opinion maybe also the J2EE specification) is of the perception that applications running inside an Application Server, cannot be treated as running in the “Application client container”.

                                   

                                  The J2EE definition of  “Application clients”:

                                  “Application clients are Java programming language programs that are typically GUI programs that execute on a desktop computer. Application clients offer a user experience similar to that of native applications, and have access to all of the facilities of the Java EE middle tier.”

                                   

                                  The J2EE limitation:

                                  The following methods may only be used by application components executing in the application client container:JAVA™ TRANSACTION API (JTA) 1.1 REQUIREMENTS 133

                                  ...

                                  javax.jms.Connection method setExceptionListener

                                  ...

                                   

                                  My solution

                                  I have developed a fix for the JMSRouter class and one for the Bridge class.

                                  Both fixes is a copy of the exact original implementation of the classes, but where setException() is call, I catch and log the Exception thrown by the WMQ resource adaptor.

                                   

                                  My overriding classes is packed in JAR files an added to the classpath before the original JBoss JAR files. Because I keep the original class- and packagename my implementation is the one being classloaded.

                                   

                                   

                                  The future

                                  Tom, as you mentioned, we might have an issue here and it needs to be addressed. How do we make sure it will be addressed. Are you guys in a position at JBoss where you can follow up on future versions and specifications?

                                  • 14. Re: Does JBoss ESB violate the JEE 5 Specification?
                                    Kevin Conner Master

                                    Hiya Peer.

                                     

                                    I have already created an issue to revisit the documentation covering the integration of WSMQ, part of this task will also look at whether we can use the JCA in specific circumstances.

                                     

                                    Kev

                                    1 2 Previous Next