8 Replies Latest reply on Mar 2, 2006 12:59 PM by starksm64

    POJOizing(TM) the naming services

    starksm64

      As part of JBAS-2865 (Move org.jboss.naming package from server module to naming module) I need to POJOize the existing naming services to remove the static compile time dependency on jmx and jboss service classes. For backward compatibility with existing deployment descriptors, I will need to add implicit support for treating an mbean as having an xmbean descriptor. So a deployment like:

       <mbean code="org.jboss.naming.LinkRefPairService"
       name="jboss.jms:alias=TopicConnectionFactory">
       <attribute name="JndiName">TopicConnectionFactory</attribute>
       <attribute name="RemoteJndiName">ConnectionFactory</attribute>
       <attribute name="LocalJndiName">java:/JmsXA</attribute>
       <depends>jboss:service=Naming</depends>
       </mbean>
      


      will be treated as:
       <mbean code="org.jboss.naming.LinkRefPairService"
       name="jboss.jms:alias=TopicConnectionFactory"
       xmbean-dd="resource:xmdesc/LinkRefPairService-xmbean.xml">
       <attribute name="JndiName">TopicConnectionFactory</attribute>
       <attribute name="RemoteJndiName">ConnectionFactory</attribute>
       <attribute name="LocalJndiName">java:/JmsXA</attribute>
       <depends>jboss:service=Naming</depends>
       </mbean>
      


      without the failure if there is no xmdesc/LinkRefPairService-xmbean.xml.

      I'll add this to jboss-head to be consistent, but I'm wondering if we want to start moving core services over to an mc based configuration.

      I would like to put together a project plan that identifies what we need to get done before we tear down and rebuild jboss5 in the image of the MC.


        • 1. Re: POJOizing(TM) the naming services

           

          "scott.stark@jboss.org" wrote:

          I would like to put together a project plan that identifies what we need to get done before we tear down and rebuild jboss5 in the image of the MC.


          Can you make your mind up? ;-)

          So far in the ongoing JBossMC strategy we have gone from:
          1) Use JBossMC/ServiceController facade in JBoss5
          2) POJO Server
          3) Tripoli
          4) Standalone JBossMC release for embedded EJB3
          5) Embeddable JBossMC generalizing EJB3 work
          6) back to (1) in this post

          The biggest stumbling block to using MC based services in JBoss5 is
          making POJOs JMX manageable.
          There is a prototype for this in Aspects, but I'd like to get the AOP integration
          work finished in the "Embeddable MC" before we cutover JBoss5 to it.

          We already agreed that we would use UnifiedClassLoader3 for the classloader
          so the only other issue is writing the ServiceController facade JMX model over the MC's
          controller.

          • 2. Re: POJOizing(TM) the naming services

             

            "adrian@jboss.org" wrote:
            writing the ServiceController facade JMX model over the MC's
            controller.


            I can do this now if you are only interested in POJOs and MBeans taking part
            in the same dependency space/granularity.

            • 3. Re: POJOizing(TM) the naming services
              starksm64

               

              "adrian@jboss.org" wrote:

              Can you make your mind up? ;-)

              So far in the ongoing JBossMC strategy we have gone from:
              1) Use JBossMC/ServiceController facade in JBoss5
              2) POJO Server
              3) Tripoli
              4) Standalone JBossMC release for embedded EJB3
              5) Embeddable JBossMC generalizing EJB3 work
              6) back to (1) in this post


              These are all parallel uses as I see it. What I'm really looking for is population of this task http://jira.jboss.com/jira/browse/JBAS-63 (MicroContainer work for JBoss-5.0.0 Alpha) with which of the N is going to be the approach for the alpha. If it's 1(or 3 since I have no idea what that is and I like the unknown), let's set that in stone(jira) and define/link the related tasks so we can get an alpha out.


              • 4. Re: POJOizing(TM) the naming services
                starksm64

                Two classes in the server org.jboss.naming.* (NamingService, HttpNamingContextFactory), org.jboss.naming.interceptors.*, and org.jboss.naming.client.java.* are really integration classes around the detached invoker stuff. The NamingService could be broken up into a pojo with an xmbean deployment that handles the detached invoker stuff via interceptors, but the rest are pure integration addons that really don't belong in naming. So there will be a few naming integration classes in the server module. I need to look at how much different the configuration of the NamingService would be to see if that would be too disruptive a change for 4.0.4.

                • 5. Re: POJOizing(TM) the naming services

                   

                  "scott.stark@jboss.org" wrote:
                  [
                  These are all parallel uses as I see it.


                  Yes, they also overlap and will eventually converge, but which is the priority?

                  The MC/JMX dependency integration of JBoss5 (ServiceController)
                  or the pure MC suitable for embedding/standalone use.


                  What I'm really looking for is population of this task http://jira.jboss.com/jira/browse/JBAS-63 (MicroContainer work for JBoss-5.0.0 Alpha) with which of the N is going to be the approach for the alpha. If it's 1(or 3 since I have no idea what that is and I like the unknown), let's set that in stone(jira) and define/link the related tasks so we can get an alpha out.


                  Ok. I've added the main ones.

                  I don't know whether we have a task for the MetaData Repository or the
                  AOP ProxyAdvisor.
                  If we do then these need to be linked to that task.

                  • 6. Re: POJOizing(TM) the naming services
                    starksm64

                    I don't see MetaData Repository or the AOP ProxyAdvisor so those tasks are needed.

                    I would like the alpha to include the new VDF framework, so these tasks along with related deployers should be added:

                    http://jira.jboss.com/jira/browse/JBAS-2380 (VFS Aspect for deployments)
                    http://jira.jboss.com/jira/browse/JBMICROCONT-57 (Add VFS prototype for review/testing)
                    http://jira.jboss.com/jira/browse/JBMICROCONT-6 (Virtual Deployment Framework)

                    jboss5 with an mc core, and vdf I think is a good alpha. Some class loading abstraction may be needed as well? Attacking class loaders, profile service should define the next release.

                    • 7. Re: POJOizing(TM) the naming services

                      Ok. I've added the missing tasks for the metadata repository and AOP proxy
                      and linked some stuff together to give a better view of the dependencies.

                      I'll flesh this out a bit more once I've completed my 4.0.4 testing.

                      I thought we were going to use UnifiedClassLoader3 for the initial rev?
                      There is this task on defining a proper integration api
                      http://jira.jboss.com/jira/browse/JBMICROCONT-31
                      i.e. one that does not depend upon the implementation choice.

                      • 8. Re: POJOizing(TM) the naming services
                        starksm64

                         

                        "adrian@jboss.org" wrote:

                        I thought we were going to use UnifiedClassLoader3 for the initial rev?
                        There is this task on defining a proper integration api
                        http://jira.jboss.com/jira/browse/JBMICROCONT-31
                        i.e. one that does not depend upon the implementation choice.


                        Yes we did, and JBMICROCONT-31 getting pulled in via the JBMICROCONT-7(Classloading deployer) is satifies the abstraction issue.