5 Replies Latest reply on Mar 1, 2010 10:04 PM by Jesper Pedersen

    Standalone JCA: JNDI binding for multiple connection factories...

    Scott Marlow Master

      RADeployer needs to deal with outbound resource adapters that have multiple connection factories (each of which should be bound to JNDI).

       

      For the JNDI binding, if the connection factory is a javax.resource.Referenceable, we will bind a javax.naming.Reference to JNDI.  The Reference represents the CF along with javax.naming.StringRefAddr values that contain configuration settings.  This is currently working in jboss-jca/trunk with a simple single CF design.  This note is about expanding our support to cover binding multiple CFs to jndi and other gap filling.

       

      I assume that we need to handle JNDI binding connection factories that are serializable but don't implement Referenceable.  If anyone knows otherwise, please speak up.  For the serializable case, we will bind the CF directly to JNDI.

       

      In either case, we will bind the CF under the jndi-name either specified in configuration or derived  from the resource adapter name (minus the ".rar").  We should look at any current JNDI naming conventions that might make sense to preserve.  It seems important to me that we bind under the expected name that applications will later use.

       

      At the very least, we should log (INFO level) the full jndi name that each CF is bound to.  I also propose that we consider a logging configuration that controls what is logged/monitored in jboss-jca (e.g. whether to log jndi names,  datasource/cci operations, enable debug wrappers).  I'll write more about this if others like this idea.

       

      Comments?

        • 1. Re: Standalone JCA: JNDI binding for multiple connection factories...
          Jesper Pedersen Master

          I assume that we need to handle JNDI binding connection factories that are serializable but don't implement Referenceable.  If anyone knows otherwise, please speak up.  For the serializable case, we will bind the CF directly to JNDI.

           

          It is a requirement that a CF implements the javax.resource.Referenceable and java.io.Serializable - so that will always be the case. Hence the current instanceof check.

           

          Dealing with resource adapters that doesn't implement this requirement could be something we could look at down the road - but ideally people should fix their code. That is why we have the validator.

           

          In either case, we will bind the CF under the jndi-name either specified in configuration or derived  from the resource adapter name (minus the ".rar").  We should look at any current JNDI naming conventions that might make sense to preserve.  It seems important to me that we bind under the expected name that applications will later use.

           

          An idea could be to create a unique name for each CF, and then create an alias for the unique name that the user will use. That would allow us to move the primary names in the JNDI without having to change any user code. I thinking of java:/eis/, java:global, and other scenarios depending where the JCA container is deployed.

           

          The key is to make it simple for users - a JNDI name should be optional, and in that case we would create an alias based on our default strategy, f.ex. java:/eis/resourceadapter as we have now.

           

          Also we should consider how the deployment of the same resource adapter multiple times - under different names should work. Making the resource adapter archive name part of the unique name could be an idea - we can always use the metadata repository to search for information.

           

          At the very least, we should log (INFO level) the full jndi name that each CF is bound to.

           

          Agreed.

           

          I also propose that we consider a logging configuration that controls what is logged/monitored in jboss-jca (e.g. whether to log jndi names, datasource/cci operations, enable debug wrappers).  I'll write more about this if others like this idea.

           

          That would be a requirement - currently discussed in TAG. David will probably have a lot of good ideas in near future.

          • 2. Re: Standalone JCA: JNDI binding for multiple connection factories...
            Scott Marlow Master

            It is a requirement that a CF implements the javax.resource.Referenceable and java.io.Serializable - so that will always be the case. Hence the current instanceof check.

             

            Dealing with resource adapters that doesn't implement this requirement could be something we could look at down the road - but ideally people should fix their code. That is why we have the validator.

             

             

            The 1.6 Final Draft November 2009 argues with itself over this:

             

            "20.6.1 Responsibilities In both managed and non-managed environments, registration of a connection factory instance in the JNDI namespace must use either the JNDI Reference or Serializable mechanism. ... "

             

            "6.5.1.3 Additional Requirements ... A connection factory implementation class must implement the interface javax.resource.Referenceable. ... "

             

            An idea could be to create a unique name for each CF, and then create an alias for the unique name that the user will use. That would allow us to move the primary names in the JNDI without having to change any user code. I thinking of java:/eis/, java:global, and other scenarios depending where the JCA container is deployed.

             

            The key is to make it simple for users - a JNDI name should be optional, and in that case we would create an alias based on our default strategy, f.ex. java:/eis/resourceadapter as we have now.

             

            Also we should consider how the deployment of the same resource adapter multiple times - under different names should work. Making the resource adapter archive name part of the unique name could be an idea - we can always use the metadata repository to search for information.

             

             

            +1 for not having to change any user code due to how we manage the CF jndi binding     I'm not sure about the unique name part though.

            What is the alias?  Do you mean generically or with something like a LinkRef (I've never used that before so not sure how it works yet).
            • 3. Re: Standalone JCA: JNDI binding for multiple connection factories...
              Jesper Pedersen Master

              The 1.6 Final Draft November 2009 argues with itself over this:

               

              Nah, 6.5.1.3, 17.5.1.1, 20.6.2, 20.6.3 specifies the implementation requirements for a CF (javax.resource.Referenceable + java.io.Serializable).

               

              The text in 20.6.1 gives a hint to the implementor, that if the naming server doesn't support both mechanisms, one can be used. See the 3 bullets in the section.

               

              I'm not sure about the unique name part though.

               

              Yes, this has to be designed.

               

              What is the alias?  Do you mean generically or with something like a LinkRef (I've never used that before so not sure how it works yet).

               

              Something like,

               

              java:/eis/myresourceadapter --> java:/uniquenamegeneratedbythecontainer
              

               

              LinkRef or other solutions is an implementation detail, we can worry about once we have the design for the unique names.

              • 4. Re: Standalone JCA: JNDI binding for multiple connection factories...
                Scott Marlow Master

                For resource adapter deployment, we could implement a CF jndi name distinguisher that generates the jndi name based on known variables (such as number of connection factories present and configuration properties if there are multiple factories).

                • 5. Re: Standalone JCA: JNDI binding for multiple connection factories...
                  Jesper Pedersen Master

                  I see 3 ways of defining the JNDI name for CFs and AOs:

                   

                  1. Container: The container defines the name - user-friendly - based on the strategy used
                  2. Static: JNDI binding names are defined in metadata - f.ex. jboss-ra.xml
                  3. "Dynamic": JNDI binding names are defined external to the resource adapter - f.ex. in a -ds.xml file

                   

                  We have to define an interface for the JNDI binding strategy for the container part - as we will most likely use different strategies based on the environment we are running in - standalone, embedded and inside AS.

                   

                  The best solution would be to have a "static" unique JNDI name defined for each connection factory and admin object - which the strategy then just links to.

                   

                  But lets start with the most common case, and most user-friendly: container defined, and only one connection factory and one admin object. Then we can go from there.