> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Bill
> Burke
> Sent: Thursday, September 12, 2002 6:33 PM
> To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: RE: FW: [JBoss-dev] configuration of interceptors
>
>
> Its more like
>
> DynamicProxy -> interceptor stack -> Target MBean
>
That should be easy with the stuff I just commited.
> 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.
It's currently implemented like that.. seperate nice and light weight. The
only dependency it currently has is on the org.jboss.proxy.compiler.*
package. So we could take my stuff and the org.jboss.proxy.compiler.* stuff
and make it and standalone module that can provide an interceptor stack to
any POJO.
+ this should run on 1.2 JVM since the Proxy classes are BECL generated.
>
> 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.
My current implementation forces them to be singletons. But I don't think
this should be a major issue.
> - You could prepend or append an interceptor to the chain globally at
> runtime
> - You could prepend or append an interceptor to an individual chain.
So if you change a chain configuration when would it take effect on a proxy
that was using the previous configuration??
> - DynamicProxies would have a generic Aspect interface
I like the Aspect interface Idea.
>
>
>
> 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>
>
Looks cool. I'll send you the javadocs for what I commited to CVS today.
My stuff is lacking on the JMX features. Anyways.. I'm glad we are all
exited about this kinda stuff.
Regards,
Hiram
>
>
> > -----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
-------------------------------------------------------
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
