Its more like
DynamicProxy -> interceptor stack -> Target MBean
There should be no concept of server or client.
I also believe the interceptor chain, Aspect Oriented framework should be a
generic framework and should work with any type of Object. It should be
core to JMX. Sure, the MBeanDeployer could look at some XML and be the
bridge between Aspects and MBeans, but lets keep Aspects a separate,
lightweight framework.
We have totaly freedom as far as MBean XML config files go, right?
Here was my idea for an Aspect framework. I drew up the API while in
Germany. The features were:
- Interceptors could be services/singletons OR instantiated per chain.
- You could prepend or append an interceptor to the chain globally at
runtime
- You could prepend or append an interceptor to an individual chain.
- DynamicProxies would have a generic Aspect interface
interface AspectManager
{
void createChain(String name);
void registerInterceptorSingleton(String name, Interceptor interceptor);
// These methods globally modify the chain of any Aspect in system with
the given name
void prependAspect(String chainname, String interceptorName, Class clazz,
Element metadata);
void appendAspect(String chainname, String interceptorName, Class clazz,
Element metadata);
void prependAspect(String chainname, String singletonName);
void appendAspect(String chainname, String singletonName);
void removeAspect(String chainname, String interceptorName);
/**
* Given any old object, make it Aspect Oriented.
* metadata could hold InvocationContext-like information
*/
Aspect metamorphisis(String chainName, Class[] interfaces, Element
metadata, Object targetObject);
/**
* No target object, useful for remote invocations.
* metadata could hold InvocationContext-like information like MBean name
to invoke on
* and stuff like that.
*/
Aspect createAspect(String chainName, Class[] interfaces, Element
metadata);
}
/**
* Every DynamicProxy would implement this interface
*/
interface Aspect
{
String getAspectName();
/**
* Allows you to detach this particular aspect
*/
void setAspectName(String newName);
Object[] getInterceptors();
Interceptor findInterceptor(String name);
Object getTargetObject();
}
So, XML would look something like this. An AspectChain MBean would create
chains within the AspectManager. Add a new keyword to XML <aspect-chain>.
This would give the deployer a reference to the name of the interceptor
chain to use. The Deployer would create a Proxy via the AspectManager with
this chain name and register this Proxy with the MBeanServer.
<mbean code="stuff.stuff.stuff"
name="MyMBean">
<!-- add new keyword -->
<aspect-chain>jboss.AspectChains:name=SomeOldChain</aspect-chain>
</mbean>
<mbean code="org.jboss.aspect.AspectChain"
name="jboss.AspectChains:name=ClientProxyChain>
<attribute name="ChainConfiguration">
<aspect-chain>
<interceptor
name="Transaction"
type="instance"
class="org.jboss.proxy.TransactionInterceptor"
/>
<!--
<interceptor
name="JRMPInvokerProxy"
type="singleton"
/>
</aspect-chain>
</attribute>
</mbean>
<mbean code="org.jboss.aspect.AspectChain"
name="jboss.AspectChains:name=EJBProxyChain">
<attribute name="ChainConfiguration">
<aspect-chain>
<interceptor
name="TxInterceptorCMT"
type="instance"
class="org.jboss.proxy.TxInterceptorCMT"
/>
<interceptor
name="EntityLock"
type="instance"
class="org.jboss.proxy.EntityLockInterceptor"
/>
<!-- etc... -->
</aspect-chain>
</attribute>
</mbean>
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Hiram
> Chirino
> Sent: Thursday, September 12, 2002 2:25 PM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: Re: FW: [JBoss-dev] configuration of interceptors
>
>
>
> Ok I imagine a client invocation chain will look like:
>
> clientproxy -> client-interceptor-stack ->
> serverproxy -> server-interceptor-stack -> targetMbean
>
> Would doing some think like this satisfy you client-server requirments? :
>
> serverproxy = factory.createAspect("server-interceptor-stack",
> targetMbean);
> clientproxy = factory.createAspect("client-interceptor-stack",
> serverproxy
> );
>
> Please note: that "server-interceptor-stack" in essence will resolve to
> a set of { server-interfaces[], server-interceptors[],
> server-configurations[] }
>
> On another note, right now the factory that generates the proxys
> for say the
> "server-interceptor-stack", is configured through static xml
> files. If we
> provide a JMX interface to the factory so that you can view/update stack
> configurations, would that satisfy your requirement "to have
> these puppies
> manageable."
>
> Regards,
> Hiram
>
>
> >From: "marc fleury" <[EMAIL PROTECTED]>
> >To: <[EMAIL PROTECTED]>
> >Subject: FW: [JBoss-dev] configuration of interceptors
> >Date: Thu, 12 Sep 2002 13:44:03 -0400
> >
> >
> >
> > > -----Original Message-----
> > > From: [EMAIL PROTECTED]
> > > [mailto:[EMAIL PROTECTED]] On
> > > Behalf Of marc fleury
> > > Sent: Thursday, September 12, 2002 1:23 PM
> > > To: 'Bill Burke'; 'juha lindfors'; 'Adrian Brock'
> > > Cc: 'Hiram Chirino'; 'Jboss-Development@Lists. Sourceforge. Net'
> > > Subject: [JBoss-dev] configuration of interceptors
> > >
> > >
> > > Ok
> > >
> > > just had an interesting IM with hiram. He essentially has
> > > implemented the proxy factory we were talking about. I think
> > > he is missing the client/server side of it but we can very
> > > simply add these.
> > >
> > > Essentially it would revolve around a central
> > > proxyFactory.createProxy(Interfaces[], client-interceptors[],
> > > client-configurations[], server-interceptors[],
> > > serverconfigurations[] targetMbean);
> > >
> > > that returns a Dynamic Proxy, hooked up for remote/local
> > > calls with client and server side interceptors. If you are
> > > in one vm you can safely assume client=server and only
> > > configure one or the other. (meaning if one is null then
> > > don't configure transport it will be invm
> > > only)
> > >
> > > In the case of hiram he has only one aspect of it (and he
> > > calls it aspect everywhere) but that construct is really what
> > > we need. I also think we should have the "MBean" in there,
> > > even though we are talking about a POJO.
> > >
> > > I believe he has solid code for it and I am really interested
> > > in adding this to the base. I am not sure it is a JMX level
> > > construct (due to the pojo nature) but having the JMX base
> > > manage these configurations and associations between target
> > > and interceptors/configuration is the only sane way I can
> > > imagine to have these puppies manageable. I want visibility
> > > on that configuration for a given mbean (the generalized
> > > mbean againg being just a pojo or target). This is our generalized
> > > proxy factory.
> > >
> > > The AOP framework of the future is staring us in the eye...
> > > we got it.
> > >
> > > marc f
> > >
> > >
> > > xxxxxxxxxxxxxxxxxx
> > > Marc Fleury, Ph.D.
> > > President, Founder
> > > JBoss Group, LLC
> > > xxxxxxxxxxxxxxxxxx
> > >
> > >
> > >
> > > -------------------------------------------------------
> > > This sf.net email is sponsored by:ThinkGeek
> > > Welcome to geek heaven.
> > > http://thinkgeek.com/sf
> > > _______________________________________________
> > > Jboss-development mailing list [EMAIL PROTECTED]
> > > https://lists.sourceforge.net/lists/listinfo/jboss-development
> > >
>
>
>
>
> _________________________________________________________________
> Join the world’s largest e-mail service with MSN Hotmail.
> http://www.hotmail.com
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Jboss-development mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-development
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
