"ALRubinger" wrote :
| Its real value is in a wire protocol that's tested for both forward- and
backward-compatibility. Basically the class InvocationImpl and its tests.
|
I really enjoyed that.
"ALRubinger" wrote :
| But then again, that's the scope of the thing. Its intended to be extended via
composition to add on your requirements, or supplemented w/ JBMAR or R3.
|
If it's intended to be generally extensible, then isn't "ejb3" in the
package names misleading? How about "invokable" in place of "ejb3"?
"david.lloyd(a)jboss.com" wrote :
| If what you're implementing is a service (such as JNDI for example) which can be
expressed in terms of a fixed set of request and reply types, it's
better/cleaner/simpler/more efficient to get rid of the remote proxy idea and just use
straight request/reply objects directly.
|
OK, makes sense. One nice thing about the proxy factories, though, is that they have a
built in mechanism for handling interceptors. I guess there's no reason a chain of
interceptors couldn't be downloaded by a Naming client, but
1. the Naming client would probably end up packaging an invocation and sending it down the
interceptor chain, acting just like a proxy, and
2. the Naming client would have its own implementation of the general proxy mechanism.
"ron.sigal(a)jboss.com" wrote :
| And what about the org.jboss.proxy.* stuff? Will it stay where it is, or, maybe, move
to invokablecontainer?
|
If invokablecontainer doesn't want the proxy stuff, how about a Proxy project that
builds on invokablecontainer?
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4267378#...
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...