> Ok I imagine a client invocation chain will look like:
>
> clientproxy -> client-interceptor-stack ->
> serverproxy -> server-interceptor-stack -> targetMbean
not quite there is no typed serverproxy in the middle just a straight
invoke() stack.
The server/client nature just appear do to a invoker in the JBoss sense.
so...
> 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
> );
>
so... no that would be overkill as you introduce an additional Dynamic
Proxy in the middle. Right now there are straight invoke().
The point of the separation is that you may want travelling proxies and
you may want inVM proxies all the time. While our client/server
separation works today as inVM proxies (we have the EJB proxies working
this way).
It needs to be a construct in the factory whether you want distributable
proxies or standalone. Note that the full client/server merged with no
distribution would cover both cases however.
> 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."
It is a bit more deep than that. I am really looking for a central
repository of that name-> configuration mapping and a way to interact
with it, clearly JMX is the way to go and it needs to be centralized.
Don't worry about it for now. Bill and I are thinking about that
centralization. There also needs to be a callback in the interceptors
for configuration changes. This dynamicity of configuration is
completely missing from the current codebase and the EJB spec in
general. This would take care of that.
Gents I really think we got it this time. This is the end of our
journey... the real AOP framework in JBoss. 10 years of industry
dominance... a monopoly in the making
marc f
>
> 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
