8 Replies Latest reply on Jun 30, 2006 12:29 AM by jason.greene

    JBoss integration redesign

    jason.greene

      So, the 1.0.1 release identified a problem with the current jboss integration approach. The issue is that the lifecycle of the jbossws mc beans is decoupled from that of the jmx mbeans. This not only makes it impossible for dependency handling on core jboss services, it also allows for situations where the jbossws mbeans can deploy at different times than the mc beans.

      1.0.1 demonstrates this problem because one of the mc beans requires JNDI, and since there is no dependancy on the naming service, this results in a failure if the naming service loads afterwords. This is the case for AS installer builds because the naming service is loaded in naming-service.xml (loads after all sar files).

      The solution I have in mind is to develop an mbean that boostraps the kernel in start(). We can then set the appropriate dependencies on that mbean. This also allows us to simply the deployment somewhat.

      -Jason

        • 1. Re: JBoss integration redesign
          starksm64

          This is a mc/jmx kernel bridge issue that we should have better support for or else the beans deployer really does not integrate into the jboss-4.0.x release. What you need is an ability to import the foreign jmx kernel service into the mc as a bean for dependency purposes.

          With what your proposing, aren't you going to be duplicating a kernel and therefore breaking another mc bean deployment from interacting with the jbossws beans?

          • 2. Re: JBoss integration redesign
            jason.greene

             

            "scott.stark@jboss.org" wrote:
            This is a mc/jmx kernel bridge issue that we should have better support for or else the beans deployer really does not integrate into the jboss-4.0.x release. What you need is an ability to import the foreign jmx kernel service into the mc as a bean for dependency purposes.


            Yes, that would definately solve the problem.



            With what your proposing, aren't you going to be duplicating a kernel and therefore breaking another mc bean deployment from interacting with the jbossws beans?


            Yes, although this is what the current mc deployer does. It creates a new kernel per deployment.

            -Jason

            • 3. Re: JBoss integration redesign
              starksm64

               

              "jason.greene@jboss.com" wrote:

              Yes, although this is what the current mc deployer does. It creates a new kernel per deployment.


              Ok, I did not realize that. Then I guess its just a question of is it worth the extra time to add support for integration of dependencies on jmx kernel beans to the deployer vs essentially creating a custom bean deployer for the jbossws usecase. The former is what I would prefer. I'll post in the mc forum on what it would take to get this done. Lack of followup would a green light to do what you want.

              • 4. Re: JBoss integration redesign
                starksm64
                • 5. Re: JBoss integration redesign
                  jason.greene

                   

                  "scott.stark@jboss.org" wrote:

                  Ok, I did not realize that. Then I guess its just a question of is it worth the extra time to add support for integration of dependencies on jmx kernel beans to the deployer vs essentially creating a custom bean deployer for the jbossws usecase. The former is what I would prefer. I'll post in the mc forum on what it would take to get this done. Lack of followup would a green light to do what you want.


                  I agree, the former is ideal because this is a problem that will affect other projects as they migrate to the mc. I will monitor the thread.

                  -Jason



                  • 6. Re: JBoss integration redesign
                    thomas.diesler

                    Jason,

                    I suggest we stay away from a fix in the jbossws codebase. As we all agree, this should be solved in a general way for all MC beans with dependencies on jboss services.

                    For the next release, we disable the eventing subsription manager by default and document that it can only be enabled when the JNDI service is part of conf/jboss-service.xml

                    • 7. Re: JBoss integration redesign
                      heiko.braun

                      I agree with thomas. Especially since our deployment problem doesn't exists anymore. I managed to tweak the eventing parts to lazily access the naming service. That means we can take our time and start looking at the mc2jmx bridge scott suggested.

                      • 8. Re: JBoss integration redesign
                        jason.greene

                        An MC task was just created by scott to do this, so I have added a corresponding task on our side to make use of it.

                        http://jira.jboss.com/jira/browse/JBWS-1030

                        -Jason