1 2 Previous Next 27 Replies Latest reply on Mar 31, 2007 2:51 AM by weston.price

    Implicit container dependencies

    starksm64

      One problem showing up in the mdb tests is that since we don't order deployments using packaging depth (Russian doll thing), tests that include jms destinations in the deployment are failing because the mdb container is not specifying a dependency on the jms destination. Since the actual jmx name/kernel name of the component that supplies the destination is arbitrary, one way to address this would be for the mdb container to declare a dependency on the supplier of the jndi name for the destination.

      Alternatively, and more correctly, we need the jms destination injected into the container. The issue with this is that we need a policy plugin for resolving the source of the destination provider. There could be a JndiLookupProvider, or jms specific providers that map the destination name onto the mc component name/property to inject.

        • 1. Re: Implicit container dependencies
          starksm64

          To ease this compatibility issue, and address a long outstanding issue with not being able to specify deployment module level dependencies (mdb.jar depends on test-destinations-service.xml), I think a feature of the structure parse should be to order the DeploymentContexts. This would be a superset of the old Russian doll ordering. One should be able to declare the directed graph of DeploymentContexts such that a BFS traversal from the deployment root runs the deployment through the deployers in the declared order.

          • 2. Re: Implicit container dependencies
            weston.price

            Technically we should be integrating destinations, connection factories etc via the AdminObject facility of JCA and establishing the dependencies in this manner. At the very least, we need to consider reworking some of this. By all rights, the JmsLookupProvider should dissapear as it is JBoss specific and prohibts using the JCA/JMS adapter in other app server environments.




            • 3. Re: Implicit container dependencies
              starksm64

              How does this apply to an mdb accessing a remote destination though?

              • 4. Re: Implicit container dependencies
                weston.price

                Feasibly those admin objects that are hosted remotely should be bound into our local JNDI tree with a proxy/wrapper for the remote admin object.

                The generic jms project is a good example of this integration approach.

                Note, this is effectively what the JmsJNDIProvider does today, or at least it can do. What we do in the case of a remote destination is bind to JNDI tree of the remote resource directly, or we force some sort of bridge layer (ie the WASMQ integration stuff on the Wiki).

                While this works, it effectively removes any dependency control we might have until the actual point of activation where we attempt the lookup on the destination.

                • 5. Re: Implicit container dependencies
                  bill.burke

                  The problem with implicit dependencies is that MDB's, traditionally, will create the topic/queue by default if it does not already exist.


                  Please add the nested first deployment ordering.

                  BTW, I don't understand why the ordering matters. It works like this right?

                  for (Deployer deployer : deployers)
                  {
                   for (Deployments deployment: deployments) deployer.process(deployment)
                  }
                  



                  Why doesn't the Queue/Topic get deployed before the MDB anyways?

                  • 6. Re: Implicit container dependencies
                    weston.price

                    In other words, the JmsJNDIProvider effectively provides 'AdminObject' like behavior today. This is currently how we do JMS provider integration. These facilities should be moved to the JCA/JMS adapter to be more in line with the JCA specfication.



                    • 7. Re: Implicit container dependencies
                      starksm64

                      This seems to be effectively pushing the mechanism for configuring the mc component providing the admin object to the jca layer. That's fine and makes sense. So if given an admin object (type, name) pair, there is a stable jca component containers can declare a dependency on, we are good. The details will fall to the admin object deployment.

                      • 8. Re: Implicit container dependencies
                        anil.saldhana

                        Also JCA integration will bring in that added value of potential security extensions like JSR-196.

                        • 9. Re: Implicit container dependencies
                          starksm64

                           

                          "bill.burke@jboss.com" wrote:
                          The problem with implicit dependencies is that MDB's, traditionally, will create the topic/queue by default if it does not already exist.


                          Please add the nested first deployment ordering.

                          BTW, I don't understand why the ordering matters. It works like this right?

                          for (Deployer deployer : deployers)
                          {
                           for (Deployments deployment: deployments) deployer.process(deployment)
                          }
                          



                          Why doesn't the Queue/Topic get deployed before the MDB anyways?


                          There is no ordering of the DeploymentContexts currently. When a DeploymentContext is added to the MainDeployer its children are simply added to the set to process. This should be part of the structural information. We could default to Russian doll and allow for complete specification as well, including cross top-level deployment ordering.


                          • 10. Re: Implicit container dependencies

                             

                            "weston.price@jboss.com" wrote:
                            Feasibly those admin objects that are hosted remotely should be bound into our local JNDI tree with a proxy/wrapper for the remote admin object.


                            An admin object is just a way to create the object in local jndi rather than
                            doing a remote jndi request.

                            There's an outstanding feature request to be able to define admin objects
                            in jboss.xml
                            1) So everything is together
                            2) You could create the admin object in java:comp just for that ejb

                            • 11. Re: Implicit container dependencies

                               

                              "bill.burke@jboss.com" wrote:
                              The problem with implicit dependencies is that MDB's, traditionally, will create the topic/queue by default if it does not already exist.


                              This has been turned off in JBoss5 (at least for EJB2).

                              1) The code was not (is not) portable

                              2) Just because remote access to jndi (either another member of the cluster
                              or a thirdparty jms provider) is flakey, you don't want it to create a queue

                              3) It obscures the most common problem, which is that you mistyped the jndi name


                              • 12. Re: Implicit container dependencies

                                I don't really understand why this is causing the test to fail?

                                The MDB is designed to recover from the missing jndi name
                                and keep trying to startup every 10 seconds until the binding becomes available?

                                I suspect the test is a bit impatient :-)

                                • 13. Re: Implicit container dependencies
                                  weston.price

                                  Just to clarify this is EJB3 or EJB2?

                                  This might be my bug/feature:-)

                                  I added a reconnect attempt state variable to the JMSActivation that halts reconnect attempts after a given threshhold has been exceeded.


                                  • 14. Re: Implicit container dependencies
                                    starksm64

                                     

                                    "weston.price@jboss.com" wrote:
                                    Just to clarify this is EJB3 or EJB2?

                                    This might be my bug/feature:-)

                                    I added a reconnect attempt state variable to the JMSActivation that halts reconnect attempts after a given threshhold has been exceeded.



                                    The tests I'm looking at are ejb2, but it should be using the same logic as ejb3 under jboss5. Certainly there are still legacy issues that need to be updated, the JMSContainerInvoker being one of them.


                                    1 2 Previous Next