JBossDeveloper

> > Yes on updatability but I am fuzzy as to how you
> > would change the client side.
>
> If I have a User object on the server I want
> interceptors for server stuff, like transactions etc.
> I don't want these on the client, because they make
> no sense there. I.e. as I pass User objects back and
> forth between
> client/server/otherserver/sameserveratlaterdate the
> interceptor stack needs to be replaced.
>

Ok so when you serialize your DP, you store the "aspect definition" name that was used to construct the interceptor stack. When the DP is un-serialized, the definition name is used to reconstruct the stack. Then on the client you setup that aspect definition different from the server.

What would be interesting to know is where do you store your aspect definitions (In the classpath??).

Regards,
Hiram

> > Currently I have no examples of interceptors that
> > need to be stateful, but I'm sure there will be in
> > the future. Can you give a good example of one?
>
> I think we are mis-communicating on the "state".
> State includes "configuration". Where does that
> configuration live is the question. Most of the
> current JBoss server interceptors are stateful in
> that respect. Most of the current JBoss client
> interceptors are stateless in that respect. See my
> point to Adrian as to why stateful/stateless is a
> dumb separation, both are going to be needed in
> something as simple as a read-ahead interceptor.
>

I also thing you 2 were mis-communicating. You can have "stateful" interceptors at different levels. Here's a list that comes to mind:

(1) per invocation interceptor instances (thread safe since they are created per invocation)
(2) per proxy interceptor instance. (Interceptor state from one proxy does not mix with another proxy)
(3) per aspect definition interceptor instance. (All proxys using the same aspect definition will share the interceptor instances)
(4) per VM (or classloader) interceptor instance. (totally stateless) Multiple aspect defiinitions will share the same interceptor instance.

The code I commited to CVS was originaly using model #4. Last night I changed it over to #3 since it simplified accessing the Interceptor configuration info.


Regards,
Hiram

As for the research, check out the tech report
http://www.cc.gatech.edu/~yannis/j-orchestra/git-cc-02-17.pdf

there is more stuff on the ~yannis webpage

Anatoly.