On Sat, 30 Jun 2001, Ole Husgaard wrote:
> 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.
It is indeed reconstructed from the transport layer representation of the
invocation. We need a generic structure that would allow both simple
serializable contexts that can be passed along regardless to the
underlying transport layer and, perhaps, a way to specify that some
contexts are transport-layer sensitive. (Like the transaction context,
which would be handled by IIOP directly). Can we have some kind of
delegation model to let context-specific handlers map it's own context
into the underlying transport layer. The default one would be
serialization.
E.g.
provider of Transaction Ctx has handlers to map a Tx into IIOP, RMI, SOAP,
etc.
provider of Profiler Ctx can rely on serialization and be transport-layer
insensitive.
>
> 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.
>
Makes sense.
>
> 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
>
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
