> -----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

Reply via email to