6 Replies Latest reply on Apr 17, 2004 4:48 AM by Juha Lindfors

    Providing metadata, services to pojo resources

    Scott Stark Master

      I have added reflective setting of the MBeanServer and MBeanInfo for ModelMBean resources that support the corresponding setters:

       public void setResource(Object resource)
       {
       this.resource = resource;
       /* Pass on the MBeanInfo and MBeanServer to pojo resources if they
       support setMBeanServer(MBeanServer) and setMBeanInfo(MBeanInfo) methods
       */
       Class resClass = resource.getClass();
       // Check setMBeanServer(MBeanServer)
       try
       {
       Class[] sig = {MBeanServer.class};
       Object[] args = {server};
       Method setMBeanServer = resClass.getDeclaredMethod("setMBeanServer", sig);
       setMBeanServer.invoke(resource, args);
       }
       catch(NoSuchMethodException ignore)
       {
       }
       catch(Exception e)
       {
       log.trace("Failed to invoke setMBeanServer", e);
       }
       // Check setMBeanInfo(MBeanInfo)
       try
       {
       Class[] sig = {MBeanInfo.class};
       Object[] args = {info};
       Method setMBeanInfo = resClass.getDeclaredMethod("setMBeanInfo", sig);
       setMBeanInfo.invoke(resource, args);
       }
       catch(NoSuchMethodException ignore)
       {
       }
       catch(Exception e)
       {
       log.trace("Failed to invoke setMBeanInfo", e);
       }
       }
      


      In general going forward with a pojo microkernel, what are we thinking about in terms of mapping from a particular containers (JMX, EJB, WebService, ...) metadata and service interfaces onto a pojo that can be used in multiple containers?


        • 1. Re: Providing metadata, services to pojo resources
          Ivelin Ivanov Expert

          Scott, can you expand a bit more on the value of your addition. I am not able to follow.

          Ivelin

          • 2. Re: Providing metadata, services to pojo resources
            Scott Stark Master

            You can take a pojo and expose it as a service using an XMBean, but it has no ability to know what MBeanServer it is registered with, or access to its management metadata. This change allows for an IOC type of setting of the container context such as the MBeanServer by providing a setMBeanServer method:

            public class PackageVersionService
            {
             private MBeanServer server;
            
             public void setMBeanServer(MBeanServer server)
             {
             this.server = server;
             }
            ...
            




            • 3. Re: Providing metadata, services to pojo resources
              Adrian Brock Master

              Generically it is a callback interface like MBeanRegistration
              for services that want to know about their container and their configuration

              public interface ContainerRegistration
              {
               void setContainer(Container container);
               void setMetaData(MetaData metaData);
              }
              


              • 4. Re: Providing metadata, services to pojo resources
                Scott Stark Master

                Ok, good. One step of abstraction above this is the notion of container mediated services. So for example, in the case of my ModelMBean pojo wanting access to the MBeanServer, if it only needs this to access a service representable by an interface, it would be better if there was a dependency specification that was mapped onto a service binding which determined the implementation type: MBean, EJB, WebService, POJO, etc.

                This pulls in a lot of complexity that we don't transparently deal well with today but I would like to think about handling better:

                Dependency
                Redeployment and life cycle
                Transparency of redeployment
                Call context propagation; security, tx, call by value/reference handling

                • 5. Re: Providing metadata, services to pojo resources
                  Adrian Brock Master

                  On call context propagation I would like to use something similar to
                  what Bill has done container interceptors based on metadata.

                  i.e. if you POJO has the transaction demarcation aspect then when
                  you construct the remote proxy, it includes the client side transaction interceptor

                  I'd also like to have server side "demarshalling" interceptors so
                  we can treat remote/local invocations the same.
                  It also avoids the unnecessary promotion of thread local meta data to invocation level
                  on every local invocation.

                  • 6. Re: Providing metadata, services to pojo resources
                    Juha Lindfors Master

                     

                    "adrian@jboss.org" wrote:
                    Generically it is a callback interface like MBeanRegistration
                    for services that want to know about their container and their configuration

                    public interface ContainerRegistration
                    {
                     void setContainer(Container container);
                     void setMetaData(MetaData metaData);
                    }
                    


                    I would generalize it a tad further, following the per invocation EJB context model we have in EJB containers:

                    public interface ContainerRegisration
                    {
                     void setInvocationContext(Context ctx);
                    }
                    


                    where we give, per invocation, access to the component to the metadata via an invocation API, this gives the same per invocation granularity we have today in EJBs for caller principal metadata, for example (for per container, or VM or cluster metadata you just keep passing the same metadata references for all invocations, this should not cause additional overhead).

                    My .02