9 Replies Latest reply: Sep 23, 2013 6:21 AM by senthil kumar RSS

Using JNDI to connect to Websphere MQ, without hardcoded info

zecas zecas Newbie

Hi,

 

I'm struggling with JBoss to properly use a JNDI connection to completly make a connection to Websphere MQ Series, to feed an MDB.

 

I need some help, I'm trying to "sell" the idea of JBoss for this specific client I'm working for, and I would like to pass this difficulty, but I need some help from the community.

 

Versions:

JBoss 5.1.0 GA

Java JDK 1.6.0

WebSphere MQ 7.0.1 (on remote machine, 192.168.1.30:1414)

 

I've copied the "wmq.jmsra.rar" file into c:\...\jboss-5.1.0.GA\server\default\deploy folder. In that same location, I've created the file "wmq.jmsra-ds.xml", for the queue settings.

 

File "wmq.jmsra-ds.xml" contents:

 

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<connection-factories>
    <mbean code="org.jboss.resource.deployment.AdminObject" name="jboss.jca:service=WASDestination,name=TestQ">
    <!--<mbean code="org.jboss.resource.deployment.AdminObject" name="jca.wmq:name=TestQ">-->
        <depends optional-attribute-name="RARName">jboss.jca:service=RARDeployment,name='wmq.jmsra.rar'</depends>
        <attribute name="JNDIName">queue/TestQ</attribute>
        <attribute name="Type">javax.jms.Queue</attribute>
        <attribute name="Properties">
            baseQueueManagerName=QM_server01
            baseQueueName=TestQ
        </attribute>
    </mbean>
    <tx-connection-factory>
        <jndi-name>conn/TestQ</jndi-name>
        <xa-transaction></xa-transaction>
        <rar-name>wmq.jmsra.rar</rar-name>
        <connection-definition>javax.jms.ConnectionFactory</connection-definition>
        <config-property name="channel" type="java.lang.String">SYSTEM.DEF.SVRCONN</config-property>
        <config-property name="hostName" type="java.lang.String">192.168.1.30</config-property>
        <config-property name="port" type="java.lang.String">1414</config-property>
        <config-property name="queueManager" type="java.lang.String">QM_server01</config-property>
        <config-property name="transportType" type="java.lang.String">CLIENT</config-property>
        <!--<max-pool-size>20</max-pool-size>-->
        <security-domain-and-application>JmsXARealm</security-domain-and-application>
    </tx-connection-factory>
</connection-factories>

 

In WebSphere MQ server, I have the queue manager instance named "QM_server01" and I've created a queue "TestQ" with default values applied. It was a fresh MQ install, I've just entered "IBM MQ Explorer" and created the "TestQ" queue.

 

Now from my project, I have the following Message Driven Bean:

 

@MessageDriven(
        activationConfig = {
                @ActivationConfigProperty(propertyName="destinationType", propertyValue="javax.jms.Queue"),
                @ActivationConfigProperty(propertyName="destination", propertyValue="queue/TestQ"),
                @ActivationConfigProperty(propertyName="useJNDI", propertyValue="true"),
                @ActivationConfigProperty(propertyName="hostName", propertyValue="192.168.1.30"),
                @ActivationConfigProperty(propertyName="port", propertyValue="1414"),
                @ActivationConfigProperty(propertyName="queueManager", propertyValue="QM_server01")
        })
@ResourceAdapter("wmq.jmsra.rar")
@TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED)
public class TestMQ implements MessageListener {

    public void onMessage(Message message) {
        System.out.println(message.toString());
    }

}

 

Now this works fine. If I insert a message in the Websphere MQ, my MDB will pick it up with no problem.

 

My real problem is that, although I have defined the "mbean" in my "wmq.jmsra-ds.xml" JBoss deploy file, I cannot find a way to use it to get the MQ info. Although I have info defined in jboss deploy xml file, I need to put IP, PORT, etc. in the MDB in order to make it work.

 

Looking at my MDB code, I have the IP, PORT, QueManager name all hardcoded. And also I have a reference to "@ResourceAdapter" JBoss specific annotation.

 

I was hoping to configure this info in some server specific file, like the "wmq.jmsra-ds.xml", and eventually in the "jboss.xml" or some binding file that I could provide in my EJB jar file (which is part of an EAR).

 

I need to make the project work on JBoss and WebSphere Application Servers, and also (and specially) to not relly on remote MQ location hardcoded in my MDB's.

 

My project will go through several environments until reaching the final production environment, and I don't want to make builds for each of them.

 

So any way of just pointing to the JNDI and JBoss pick it up? Do I need to provide a jboss-specific xml binding file in my project?

 

It this a limitation of JBoss 5.1.0 GA? If so, will JBoss 6 provide the solution I'm looking for?

 

 

Again, I'm hopping the community to help me solve this situation. As I have it now, I will have a hard time moving on with the project in JBoss.

 

 

Thanks

  • 1. Re: Using JNDI to connect to Websphere MQ, without hardcoded info
    Stuart Clayton Newbie

    I just had exactly the same problem with incoming MDBs (receiving messages from MQ), with the same versions of JBoss and MQ. I solved it after literally days of investigation, by following the http://community.jboss.org/wiki/HowToConfigureEJB3MDBsForIBMWebsphereMQ hint for creating an "aop domain", with an important correction.

     

    This "domain" contains all the context (host, port etc) that we currently have either in the annotations, the ejb-jar.xml or the jboss.xml (there seems to be no difference between the last two files, as far as where the activationSpecs are for queue MDBs). This "domain" arranges for yet another ( ! ) set of "activationSpec annotations" to be injected into the MDB class code, but indirectly instead of having to put annotations explicitly in the class source.

     

    Here is what the additional code in the JBoss deploy/ejb3-interceptors-aop.xml file looks like (note that the @org.jboss.ejb3.annotation.DefaultActivationSpecs ({ ...  stuff has to be on one line, without CRLFs ):

     

    <domain name="IBMMQ Message Driven Bean" extends="Intercepted Bean" inheritBindings="true">
          <bind pointcut="execution(public * *->*(..))">
             <interceptor-ref name="org.jboss.ejb3.security.AuthenticationInterceptorFactory"/>
             <interceptor-ref name="org.jboss.ejb3.security.RunAsSecurityInterceptorFactory"/>
          </bind>
          <!-- TODO: Authorization? -->
          <bind pointcut="execution(public * *->*(..))">
             <interceptor-ref name="org.jboss.ejb3.tx.CMTTxInterceptorFactory"/>
             <interceptor-ref name="org.jboss.ejb3.stateless.StatelessInstanceInterceptor"/>
             <interceptor-ref name="org.jboss.ejb3.tx.BMTTxInterceptorFactory"/>
             <interceptor-ref name="org.jboss.ejb3.AllowedOperationsInterceptor"/>
             <interceptor-ref name="org.jboss.ejb3.entity.TransactionScopedEntityManagerInterceptor"/>
             <!-- interceptor-ref name="org.jboss.ejb3.interceptor.EJB3InterceptorsFactory"/ -->
             <stack-ref name="EJBInterceptors"/>
          </bind>
    
          <annotation expr="class(*) AND !class(@org.jboss.ejb3.annotation.Pool)">
             @org.jboss.ejb3.annotation.Pool (value="StrictMaxPool", maxSize=15, timeout=10000)
          </annotation>
          <annotation expr="!class(@org.jboss.ejb3.annotation.DefaultActivationSpecs)">
             @org.jboss.ejb3.annotation.DefaultActivationSpecs ({@javax.ejb.ActivationConfigProperty(propertyName = "channel", propertyValue = "SYSTEM.DEF.SVRCONN"), @javax.ejb.ActivationConfigProperty(propertyName = "hostName", propertyValue = "127.0.0.1"), @javax.ejb.ActivationConfigProperty(propertyName = "queueManager", propertyValue = "QM_APPLE"), @javax.ejb.ActivationConfigProperty(propertyName = "port", propertyValue = "1415"), @javax.ejb.ActivationConfigProperty(propertyName = "transportType", propertyValue = "CLIENT")})
          </annotation>  
    

     

     

    The MDB declaration now looks like this:

     

    @MessageDriven(activationConfig = { @ActivationConfigProperty(propertyName = "messagingType", propertyValue = "javax.jms.MessageListener"),
            @ActivationConfigProperty(propertyName = "destinationType", propertyValue = "javax.jms.Queue") })
    @TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED)
    @ResourceAdapter(value = "wmq.jmsra.rar")
    @AspectDomain("IBMMQ Message Driven Bean")
    public class ReadMQAgent implements MessageListener {
    

     

     

    The ejb-jar.xml now looks like this:

     

    <ejb-jar xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:ejb="http://java.sun.com/xml/ns/javaee/ejb-jar_3_0.xsd" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-jar_3_0.xsd" version="3.0">
      <enterprise-beans>
        <message-driven>
          <ejb-name>ReadMQAgent</ejb-name>
          <ejb-class>com.fleetboard.agw.calculator.msgproc.impl.ReadMQAgent</ejb-class>        
          <activation-config>
            <activation-config-property>
              <activation-config-property-name>useJNDI</activation-config-property-name>
              <activation-config-property-value>false</activation-config-property-value>
            </activation-config-property>   
            <activation-config-property>
              <activation-config-property-name>destination</activation-config-property-name>
              <activation-config-property-value>Q1</activation-config-property-value>
            </activation-config-property>  
           </activation-config>
        </message-driven>
      </enterprise-beans>
    </ejb-jar>
    

     

     

    In the AOP "domain" declaration from the link given above, the annotation class was specified as @org.jboss.annotation.ejb.DefaultActivationSpecs. Somewhere (can't find it now) there was a user comment on this example, pointing out that the class should be @org.jboss.ejb3.annotation.DefaultActivationSpecs. After I changed this accordingly, the whole business finally worked as expected. Before this last change, I was getting an MQ error about "Q1" not being defined.

     

    Of course there is never an upside without a downside. Now the eclipse console favors me with a extra splodge of JBoss startup warnings that don't amount to a hill of beans, apparently, because everything works fine: 165 consecutive repetitions of the line

     

    09:25:49,006 WARN  [AnnotationCreator] No ClassLoader provided, using TCCL: javax.ejb.ActivationConfigProperty
    

     

  • 2. Re: Using JNDI to connect to Websphere MQ, without hardcoded info
    Stuart Clayton Newbie

    You write that your goal is "to feed an MDB", which I assume means that you want *incoming* messages from MQ to arrive there: your MDB is consuming messages, not producing them.

     

    According to the MQ documentation Version 6.0 ("MQ Using Java", Appendix F), the AdminObject that you have defined in wmq.jmsra-ds.xml is needed only for outbound messages, i.e. those originating in a class using JMS through a connection factory and going through the resource adapter outwards in the direction of MQ:

    The properties of an administered object, which the application server uses to create a JMS Queue object or JMS Topic object for outbound communication. These properties are also described in “Configuration for outbound communication” on page 661.

    That is not true. One way (the only way ??) to create a JNDI name for a queue whose messages the application wants to consume - "inbound messages" in resource adapter parlance - is to declare an mbean "AdminObject" in the wmq.jmsra-ds.xml, just as in the outbound message case. You actually do this in your example. I initially didn't see the "useJNDI=true" in your class annotation.

     

    For outbound messages, you need to declare a connection factory in the MQ datasource descriptor wmq.jmsra-ds.xml:

     

    <?xml version="1.0" encoding="UTF-8" standalone="yes"?>

    <connection-factories>

        <mbean code="org.jboss.resource.deployment.AdminObject" name="jboss.jca:service=WASDestination,name=TestQ">

        <!--<mbean code="org.jboss.resource.deployment.AdminObject" name="jca.wmq:name=TestQ">-->

            <depends optional-attribute-name="RARName">jboss.jca:service=RARDeployment,name='wmq.jmsra.rar'</depends>

            <attribute name="JNDIName">queue/TestQ</attribute>

            <attribute name="Type">javax.jms.Queue</attribute>

            <attribute name="Properties">

                baseQueueManagerName=QM_server01

                baseQueueName=TestQ

            </attribute>

        </mbean>

    </connection-factories>

    For inbound messages, you don't need to declare a connection factory, but you do need to declare "what queue I mean": either by means of explicit class annotations, or by using the AOP domain descriptor. When you use the AOP domain descriptor, JBoss inserts "behind the scenes", into the bytecode of the receiving MDB, all the connection info that would  otherwise have to be provided by explicit class annotations.

     

    For inbound messages you also need an ejb-jar.xml, but it contains only the JNDI name of the queue declared in the AOP domain descriptor, and the class name. The ejb-jar.xml ties together the queue and the class that will consume from the queue. In your case the ejb-jar.xml would look like this:

    <ejb-jar xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:ejb="http://java.sun.com/xml/ns/javaee/ejb-jar_3_0.xsd" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-jar_3_0.xsd" version="3.0">
      <enterprise-beans>
        <message-driven>
          <ejb-name>[some string]</ejb-name>
          <ejb-class>[x.y.z.classname]</ejb-class>        
          <activation-config>
            <activation-config-property>
              <activation-config-property-name>useJNDI</activation-config-property-name>
              <activation-config-property-value>true</activation-config-property-value>
            </activation-config-property>   
            <activation-config-property>
              <activation-config-property-name>destination</activation-config-property-name>
              <activation-config-property-value>TestQ</activation-config-property-value>
            </activation-config-property>  
           </activation-config>
        </message-driven>
      </enterprise-beans>
    </ejb-jar>

     

     

    In this way, every specification has been moved out of the class annotations, and moved into AOP and datasource descriptors, and an ejb-jar.xml file.

     

    For incoming messages, you can change the host, channel, port etc. in the AOP domain descriptor, without changing code. For outgoing messages, you can change the queue name and its queue manager in the MQ datasource descriptor, without changing code.

     

    Readers should note that my example and that of zecas contain different queue names, class name etc. This is a little confusing, but I think it's easy enough to figure out what's going on.

     

    The JCA specification provides different programmatic constructs for incoming and outgoing communication. The reasons for this asymmetry are not quite clear to me.

  • 3. Re: Using JNDI to connect to Websphere MQ, without hardcoded info
    zecas zecas Newbie

    Hi,

     

    First of all, thank you for your help and precise replies. Untill today, I had given up temporarily on this subject, and rolled back to using just the JBoss Messaging, as I had lot's of other things going on, things to be developed.

     

    Now I'm again, back to this subject, and I'll give it another try.

     

    Some things about the subject are a bit confusing, but your last post gave me a fresh new hope about putting this thing up and running.

     

    About the incomming/outgoing messaging, I will have both, an MDB to consume from an MQ queue, and an injected JMS connection to send up messages to another MQ queue, both with diferent jndi names, etc.

     

    So since I was going for an MDB in EJB3, I was not thinking about the need for an ejb-jar.xml on the project ... I'll have to try it out.

     

    If I can take everything that is specific to the environment out of code, I'll have exactly what I'm looking for.

     

    I'll re-try this all over again, starting from the incomming MDB message consuming first.

     

    I'll post my findings, so someone else may get some more insight examples from my mess

     

     

    Thanks.

  • 4. Re: Using JNDI to connect to Websphere MQ, without hardcoded info
    Stuart Clayton Newbie

    zecas, you write: "So since I was going for an MDB in EJB3, I was not thinking about the need for an ejb-jar.xml on the project". Of course you weren't ! What we are doing here is fighting EJB3 tooth and nail, in order to get back to EJB2

     

    Of course EJB2 was a terrible mess, but it did get one thing exactly right: a clean separation of "deployment" and "development" mechanisms. One aspect of deployment was the ability to configure without having to change code. 

     

    EJB3 has now melted deployment and development together to get one inflexible mechanism: "annotations". I'll tell you why I think this was done: so that inexperienced programmers who don't have a clue about what's involved can quickly write code that "runs" in a fixed environment. EJB3 creates an illusion of productivity improvement. The price you pay for this illusion is administrative nightmares, but you discover this only when it's too late.

     

    The primary reason that EJB3 administration (configuration) is a nightmare is that it's so poorly documented. So why is it poorly documented ? Because the creators of EJB3 want people to concentrate on the "productivity improvement", and not realize that configuration is no longer standardized as in EJB2, but has returned to being very provider-specific.

  • 5. Re: Using JNDI to connect to Websphere MQ, without hardcoded info
    Stuart Clayton Newbie

    One of the people at my current project hit on the best solution of all: no ejb-jar.xml and jboss.xml, and only one "hard-coded" configurable property in the class annotations that nevertheless can be put in a single, central place in your code: the name of the resource adapter jar.

     

     

    @MessageDriven(activationConfig = { @ActivationConfigProperty(propertyName = "destinationType", propertyValue = CommonValue.JMS_QUEUE_CLASS),
              @ActivationConfigProperty(propertyName = "destination", propertyValue = "IncomingGpsQ4"),
              @ActivationConfigProperty(propertyName = "DeliveryActive", propertyValue = "false"),
              @ActivationConfigProperty(propertyName = "useJNDI", propertyValue = "true") })
    @TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED)
    @ResourceAdapter(value = CommonValue.JMS_RESOURCE_ADAPTER_NAME)
    @AspectDomain("IncomingGpsDomain4")
    public class IncomingMdbQ4 implements MessageListener {
    

     

    He actually had the hard-coded MQ name "wmq.jmsra.rar" in there, but I have just moved it to CommonValue.JMS_RESOURCE_ADAPTER_NAME because I hope that this will allow me to switch from MQ to HornetQ as external JMS provider by changing only the constant value (after deploying the appropriate HornetQ descriptors and resource adapter, of course).

  • 6. Re: Using JNDI to connect to Websphere MQ, without hardcoded info
    Rodrigo Valentim Newbie

    Hi Zecas and Stuart,

     

    Unbelievable but I am facing exactly the same problem.

     

    I got pretty much the same error messages when I put my MQ configuration directly in the console (it does not work), however, when I use them via annotations, it works.

     

    Did you guys find a way to keep the configurations out of the code?

     

    Thank you for the opportunity to grow our knowledge together!

     

    Cya

     

    Rodrigo Valentim

  • 7. Re: Using JNDI to connect to Websphere MQ, without hardcoded info
    zecas zecas Newbie

    Well, I got a way of getting rid of annotation @ResourceAdapter and avoid the use of @AspectDomain.

     

    I added another one that I cannot remember at this time, that references a provider configuration on JBoss. I was hopping to get rid of it by using AOP in JBoss, as it is specific to JBoss and I could inject it there, but had no success in doing it.

     

    I'll post my findings here soon, and in the meanwhile, I'm looking into implementing a bridge between JBoss and MQSeries, but that seems to be another struggle!

  • 8. Re: Using JNDI to connect to Websphere MQ, without hardcoded info
    zecas zecas Newbie

    Hi,

     

    I have tried another solution that I believe will getting me closer to no dependencies on project code.

     

    As I said, I'm posting my findings here.

     

    Instead of connecting to MQ Series using the resource adapter wmq.jmsra.rar, as described in this document:

    Using WebSphere MQ Series with JBossAS Part IV - Integration using the IBM WebSphere JMS Resource Adapter  (RECOMMENDED WAY!!)

    http://community.jboss.org/docs/DOC-12535

     

    I followed the document:

    Using WebSphere MQ Series with JBossAS Part III - Integration using an external context

    http://community.jboss.org/docs/DOC-12534

     

    I have copied the following libs:

     

    Directory of C:\...\jboss-5.1.0.GA\server\default\lib 
    30-03-2011  10:21           698.737 commonservices-2.3.jar 
    30-03-2011  10:21           446.549 defaultconfig-2.3.jar 
    30-03-2011  10:21         2.011.835 dhbcore-1.0.jar 
    30-03-2011  10:21           356.293 headers-2.3.jar 
    30-03-2011  10:21         1.904.071 jmqi-2.3.jar 
    30-03-2011  10:21           438.016 mq-2.3.jar 
    30-03-2011  10:21            17.657 mqcontext-2.3.jar 
    30-03-2011  10:21         3.229.664 mqjms-1.1.jar 
    30-03-2011  10:21            13.968 Nojndi-2.3.jar 
    30-03-2011  10:21           103.980 pcf-1.4.2.jar 
    30-03-2011  10:21           124.522 pcf-6.1-6.1.jar 
    30-03-2011  10:21         7.758.362 postcard-2.3.jar 
    30-03-2011  10:21           893.796 rmm-1.0.jar 
    30-03-2011  10:21           101.628 soap-1.4.2.jar 
    30-03-2011  10:21            31.996 tools.ras-1.4.2.jar
    

     

    These dependencies were copied from my MQ Series java lib folder, the names are a bit different (with versions), maven style .

     

    I created a provider definition for Websphere MQ in C:\...\jboss-5.1.0.GA\server\default\conf\jboss-service.xml:

     

    <?xml version="1.0" encoding="UTF-8"?> 
    
    <!-- $Id: jboss-service.xml 88695 2009-05-12 03:32:03Z bstansberry@jboss.com $ --> 
    
    <!-- ===================================================================== --> 
    <!--  JBoss Server Configuration                                           --> 
    <!-- ===================================================================== --> 
    
    <server> 
    
        <!-- 
        ... 
        --> 
    
    <!-- WebSphere MQ context JNDI --> 
    <mbean code="org.jboss.naming.ExternalContext" 
    name="DefaultDomain:service=ExternalContext,jndiName=wsmq"> 
    <attribute name="JndiName">wsmq</attribute> 
    <attribute name="Properties"> 
    java.naming.factory.initial=com.ibm.mq.jms.context.WMQInitialContextFactory 
    java.naming.provider.url=192.168.1.30:1414/SYSTEM.DEF.SVRCONN 
    java.naming.security.authentication=none 
    </attribute> 
    <attribute name="InitialContext">javax.naming.InitialContext</attribute> 
    </mbean> 
    
    </server>
    

     

    Then I defined my connection factories on C:\...\jboss-5.1.0.GA\server\default\deploy\wsmq-ds.xml:

     

    <?xml version="1.0" encoding="UTF-8"?>
    <connection-factories>
    <!-- ==================================================================== -->
    <!-- WSMQ connection factories -->
    <!-- ==================================================================== -->
    <!-- The WSMQ JMS provider loader -->
    <mbean code="org.jboss.jms.jndi.JMSProviderLoader"
    name="jboss.mq:service=JMSProviderLoader,name=WSMQJMSProvider">
    <attribute name="ProviderName">WSMQJMSProvider</attribute>
    <attribute name="ProviderAdapterClass">org.jboss.jms.jndi.JNDIProviderAdapter</attribute>
    <attribute name="QueueFactoryRef">wsmq/QM_server01</attribute>
    <attribute name="TopicFactoryRef">wsmq/QM_server01</attribute>
    </mbean>
    <!-- The WSMQ JMS connection factory -->
    <no-tx-connection-factory>
    <jndi-name>WSMQJms</jndi-name>
    <rar-name>jms-ra.rar</rar-name>
    <connection-definition>org.jboss.resource.adapter.jms.JmsConnectionFactory</connection-definition>
    <config-property name="SessionDefaultType" type="java.lang.String">javax.jms.Topic</config-property>
    <config-property name="JmsProviderAdapterJNDI" type="java.lang.String">java:/WSMQJMSProvider</config-property>
    <max-pool-size>20</max-pool-size>
    </no-tx-connection-factory>
    </connection-factories>
    

     

    Last but not least, my Message Driven Bean:

     

    @MessageDriven( 
            activationConfig = { 
                    @ActivationConfigProperty(propertyName="destinationType", propertyValue="javax.jms.Queue"), 
                    @ActivationConfigProperty(propertyName="destination", propertyValue="wsmq/TestQ"), 
                    @ActivationConfigProperty(propertyName="providerAdapterJNDI", propertyValue="java:/WSMQJMSProvider") 
            })
    public class TestMQ implements MessageListener {
    
        public void onMessage(Message message) {
            System.out.println(message.toString());
        }
    
    }
    

     

    At this time, any message that falls into TestQ on MQ Series will be delivered to my Message Driven Bean.

     

    I'm yet to try to send a message to the queue, that should use the "no-tx-connection-factory" defined in the "wsmq-ds.xml" file (correct me if I'm wrong), but at least, I have a startup point without many dependencies to JBoss nor MQ Series on my project.

     

    The only dependency I have now is:

     

    @ActivationConfigProperty(propertyName="providerAdapterJNDI", propertyValue="java:/WSMQJMSProvider")
    

     

    Since I want to blindly deploy the project on a Websphere Application Server (latter on), I don't believe that property will go unnoticed there without some obscure deployment error :).

     

    So I was trying to inject the annotation in JBoss only, and using AOP whould seem a good feature ... inject on JBoss side.

     

    For that, I tried deploying the aop on C:\...\jboss-5.1.0.GA\server\default\deploy\wsmq-aop.xml:

     

    <?xml version="1.0" encoding="UTF-8"?>
    <aop xmlns="urn:jboss:aop-beans:1.0">
        <domain name="TestQ" extends="Message Driven Bean" inheritBindings="true">
            <annotation expr="!class(@org.jboss.ejb3.annotation.DefaultActivationSpecs)">
                @org.jboss.ejb3.annotation.DefaultActivationSpecs ({@javax.ejb.ActivationConfigProperty(propertyName = "providerAdapterJNDI", propertyValue = "java:/WSMQJMSProvider")})
            </annotation>
        </domain>
    
    </aop>
    

     

    And after removing the refered annotation, I'm not able to deliver messages to my MDB.

     

    So at this time, I need some opinions on this subject, any tip on what can I do to inject that annotation with JBoss AOP features (or something else on JBoss side). How am I supposed to inject that annotation?

     

    (At the same time, I'm trying to create an alternative bridge between my local JBoss queues and remote MQ Series queues. That can give me some more knowledge about JBoss features and may help save the day, latter on ... in this project or on any future one)

     

    Any help is welcomed.

     

    Thanks

  • 9. Re: Using JNDI to connect to Websphere MQ, without hardcoded info
    senthil kumar Newbie

    Have you got any success in this?