Providing metadata, services to pojo resources

[starksm64]

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?

[ivelin.ivanov]

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

Ivelin

[starksm64]

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;
 }
...

[adrian.brock]

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);
}

[starksm64]

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

[adrian.brock]

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.

[juha]

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