> well, aside from my and babelfish's inability to translate that...
Yeah... That's because I did a mistake... Shame... It is not "Ortille", but
"Ortie", which means "nettle". That gives:
"Maybe I am pushing Grand Mother in the nettles" (i.e. maybe I go too
far...)
> 1. I was planning to move the invocation reassembly and
> targeting into a
> bunch of interceptors on the server side.
Ok, so my loosy argument is in fact something you wanted to do ;)
> 2. I think your argument applies with exactly equal force to
> the client
> side interceptors and if we put the functionality for IIOP
> into the invoker
> on the server side we should for exactly the same reason
> eliminate client
> side interceptors everywhere and put them in the client side of "more
> capable" (than IIOP) invokers.
No, that's not what I mean. I meant that with IIOP we have *no* way to do
something on the client-side anyway i.e. with IIOP we are *forced* to do
everything on the server side. Nevertheless, because IIOP imply that does
*not* mean that it should dictate it for java clients able to use client
side interceptor. Don't forget that CSI (client side interceptors) are not
only used to populate information in the invocation but also to get
information from the client side JVM/environment. Oviously, this cannot be
mimic'ed on the server side.
> Just because we haven't used
> the client
> interceptors for any customization doesn't mean they aren't a
> good idea.
Sure.
> If we ever found a use for including additional context
> information, we
> would be able to include it in all transports simply be
> writing one client
> and one server interceptor and adding it to the chains for
> the objects we
> wanted it for. For IIOP, I think this would result in the
> fewest changes:
> I think basically we'd just have to add the C++ (or whatever)
> code to send
> the additional context info.
OK, but, again, in this case, the SSI (server side interceptor) is only used
to do something useful: the extraction of the context information can be
done in a generic way inside the invoker (or any other object that satisfy a
lambda design pattern...): the "IIOP-packet"-to-"JBoss-Invocation-object"
conversion must take place at a single place as once the conversion is done,
we forget about the original IIOP packet.
Sorry if what I say is a non-sense for DTMs: I am really focused on a
specific case: non-necessarly-Java IIOP clients. Am I making (partial)
sense?
Cheers,
Sacha
-------------------------------------------------------
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
