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
