-
1. Re: Providing metadata, services to pojo resources
ivelin.ivanov Apr 16, 2004 6:00 PM (in response to starksm64)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
starksm64 Apr 16, 2004 6:11 PM (in response to 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; } ...
-
3. Re: Providing metadata, services to pojo resources
adrian.brock Apr 16, 2004 6:11 PM (in response to starksm64)Generically it is a callback interface like MBeanRegistration
for services that want to know about their container and their configurationpublic interface ContainerRegistration { void setContainer(Container container); void setMetaData(MetaData metaData); }
-
4. Re: Providing metadata, services to pojo resources
starksm64 Apr 16, 2004 6:28 PM (in response to 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 -
5. Re: Providing metadata, services to pojo resources
adrian.brock Apr 16, 2004 7:13 PM (in response to starksm64)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 Apr 17, 2004 4:48 AM (in response to starksm64)"adrian@jboss.org" wrote:
Generically it is a callback interface like MBeanRegistration
for services that want to know about their container and their configurationpublic 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