Hi,
I like the idea of being able to pass arbitrary contexts
with the invocation request.
I guess that it means we should agree to some context
naming convention.
Are you talking about org.jboss.ejb.MethodInvocation?
Why should that class be Serializable?
It is only used locally on the server.
I guess that a Map would be right for the contexts
of the MI, but IMHO we should only use it for optional
context information. The mandatory context information
(like the Method and argument list, and possibly tx,
principal and credentials), we should keep in seperate
variables in the MI to avoid the Map lookup.
The MI is passed forth and back in the invocation
chain, so we could use that to pass context changes
back towards the caller within the local VM.
For passing contexts across the wire: This depends on
the invocation transport used, and not all transports
may support it.
For the JRMP transport, org.jboss.ejb.plugins.jrmp.interfaces.RemoteMethodInvocation
has same role as MI over the wire.
I guess that it could be changed to support contexts.
But it is only passed in the invocation request, and
not returned with the invocation reply. If we want to
pass context changes back to the caller (and we want
that, we may want it even in case of exceptions), I
guess that we have to package all invocation replies
(return values and returned exceptions) into some
return value object over the wire.
Best Regards,
Ole Husgaard.
P.S: I'll better go nuke that TPC import in the MI
now...
"Jung , Dr. Christoph" wrote:
>
> -----Ursprüngliche Nachricht-----
> >Von: marc fleury [mailto:[EMAIL PROTECTED]]
> >Gesendet: Donnerstag, 28. Juni 2001 18:03
> >An: [EMAIL PROTECTED]
> >Betreff: RE: [JBoss-dev] METHOD-INVOCATION (introducing profiling
> >support)
>
> >I believe we should in fact move EVERYTHING to the map, the user the method
> >the tx everything
> >so that the MI is just a big
>
> >MI {
> >Map
> >}
>
> >and in the map we have pairs
> >user Object
> >method Object
> >params Object[]
> >myInformationThatIOnlyUseInMyOwnLittleApplication
> >Object[Maps[Array[OfMyStuff]]]]
>
> >would that cut it? yes we pay a price (map lookup) but it is on a small
> >map.
>
> that would perfectly cut it.
>
> >The only tricky part is that it needs to be serializable, (or not actually
> >but we would need to write the map item by item and catch the
> >non-serializability).
>
> as a first approach I would say that it is in the responsibility of the
> invoker/interceptor
> developers to either put only serializable instances in there or to remove
> any non-serializable stuff
> before returning to their predecessor in the chain
>
> ... now that I write it, there was once this idea of having
> a "tree of responsibility" or at least of several invokers feeding the same
> chain, maybe we could realise this also in RabbitHole? ...
>
> hence we could rely on a serializable HashMap or whatever.
>
> I´d be glad to assist you wherever possible in that respect ...
>
> CGJ
>
> _______________________________________________
> Jboss-development mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-development
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
