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