4 Replies Latest reply on Apr 27, 2009 12:38 AM by ataylor

    Changes in our JCA Adapter

    clebert.suconic

      There are two ways of configuring our JCA Adapter:

      On MDBs (Inbound), there are Activation properties on the MDBs:

      @MessageDriven(name = "MessageMDBExample", activationConfig = { @ActivationConfigProperty(propertyName = "destinationType", propertyValue = "javax.jms.Queue"),
       @ActivationConfigProperty(propertyName = "destination", propertyValue = "queue/testQueue"),
       @ActivationConfigProperty(propertyName = "acknowledgeMode", propertyValue = "Auto-acknowledge"),
      
      })
      public class MDBExample implements MessageListener



      All of this is just passed straight to the Resource-adapter. EJB3 doesn't know anything about this. So, if we have any complains about how this is configured it's going to be our fault.


      As a way of allowing the user to connect the MDB to a remote server, I'm adding two activation properties there:

      Example:

      ...
      @ActivationConfigProperty(propertyName = "TransportType", propertyValue = "org.jboss.messaging.integration.transports.netty.NettyConnector"),
      @ActivationConfigProperty(propertyName = "TransportConfiguration", propertyValue = "jbm.remoting.netty.port=9945")
      ...
      






      Simarly, the outbound connection definition, has a similar way of configuring it:



      This is how our current jms-ds.xml looks like ATM:

       <tx-connection-factory>
       <jndi-name>JmsXA</jndi-name>
       <xa-transaction/>
       <rar-name>jms-ra.rar</rar-name>
       <connection-definition>org.jboss.messaging.ra.JBMConnectionFactory</connection-definition>
       <config-property name="SessionDefaultType" type="java.lang.String">javax.jms.Topic</config-property>
       <config-property name="JmsProviderAdapterJNDI" type="java.lang.String">java:/DefaultJMSProvider</config-property>
       <max-pool-size>20</max-pool-size>
       <security-domain-and-application>JmsXARealm</security-domain-and-application>
       </tx-connection-factory>
      



      all the config-property you see here, are just passed straight to the resource adapter. All of these is under our domain.


      Again, as a way of allowing the user to connect the Outbound connection to a remote server I'm similarly adding two config-properties here:

      <tx-connection-factory>
      ...
       <config-property name="TransportType" type="java.lang.String">org.jboss.messaging.integration.transports.netty.NettyConnector</config-property>
       <config-property name="TransportConfiguration" type="java.lang.String">jbm.remoting.netty.port=9945</config-property>
      ...
      



      The user will also have the option of changing the ra.xml or deploying multiple rars. There is a @ResourceAdapter tag it could be used on the MDB also, so if we have multiple adapters.. the user will have the option of choosing the adapter file name.



        • 1. Re: Changes in our JCA Adapter
          timfox

           

          "clebert.suconic@jboss.com" wrote:
          There are two ways of configuring our JCA Adapter:

          On MDBs (Inbound), there are Activation properties on the MDBs:

          @MessageDriven(name = "MessageMDBExample", activationConfig = { @ActivationConfigProperty(propertyName = "destinationType", propertyValue = "javax.jms.Queue"),
           @ActivationConfigProperty(propertyName = "destination", propertyValue = "queue/testQueue"),
           @ActivationConfigProperty(propertyName = "acknowledgeMode", propertyValue = "Auto-acknowledge"),
          
          })
          public class MDBExample implements MessageListener



          All of this is just passed straight to the Resource-adapter. EJB3 doesn't know anything about this. So, if we have any complains about how this is configured it's going to be our fault.


          So you're saying these values *override* any value specified in ra.xml?



          As a way of allowing the user to connect the MDB to a remote server, I'm adding two activation properties there:

          Example:

          ...
          @ActivationConfigProperty(propertyName = "TransportType", propertyValue = "org.jboss.messaging.integration.transports.netty.NettyConnector"),
          @ActivationConfigProperty(propertyName = "TransportConfiguration", propertyValue = "jbm.remoting.netty.port=9945")
          ...
          



          I'm not sure I understand what these new properties do.. how do they map to the current properties in ra.xml ?





          • 2. Re: Changes in our JCA Adapter
            clebert.suconic



            Properties defined on the ra.xml, are being set on org.jboss.messaging.ra.JBMResourceAdapter. Which contains the resource-adapter global config.


            Properties defined on the @MDB ActionConfigs, are being set on org.jboss.messaging.ra.inflow.JBMActivationSpec, which contains the MDB Inbound configuration.


            Properties defined on tx-connection-factory, are being set on org.jboss.messaging.ra.JBMMCFProperties, which contains the Connection Outbound configuration.


            Currently, the connection is only defined on JBMResourceAdapter. Both the inbound and outbound are aways getting the connection from this global place on the RA.


            My proposal, is to add properties on both the Spec and JBMMCFProperties. If the user specify any connection property at JBMMCFProperties or JBMResourceAdapter I will ignore the global-config, giving the user the sensation of overriding the property.

            This is actually the same way it is done with other properties such as User, Password and destination-type. The ra.xml defines the default/global value and that could be changed at either MDB of tx-connection-factory.

            • 3. Re: Changes in our JCA Adapter
              clebert.suconic

              There are a couple of Activation properties the user can define, that are just ignored (for"backward compatilibity")

              But it happens that this is not really compatible. I would prefer the user having to change its properties to something more suitable that works, than our adaptor pretending it's doing what the user asked to be done.


              It confused me... and it will certainly confuse the user later.

              I would prefer an exception for a non-existent property.

              Any thoughts?


              Follows the code:


              /**
               * The activation spec
               * These properties are set on the MDB ActivactionProperties
              
              ....
              */
              public class JBMActivationSpec implements ActivationSpec
              {
               ...
              
              
               <b> This is actual code from JBMActivationSpec: </b>
              
               //here for backwards compatibilty
               public void setUseDLQ(boolean b)
               {
              
               }
              
               public void setDLQJNDIName(String name)
               {
              
               }
              
               public void setDLQMaxResent(int maxResent)
               {
              
               }
              
               public void setProviderAdapterJNDI(String jndi)
               {
              
               }
              


              • 4. Re: Changes in our JCA Adapter
                ataylor

                Theres some code in the AS that sets some defaults on the adapter, I can't rememeber where. We'll have to leave these in till at least we do proper integration.