Bruno - I would *love* a "how to propagate any context with Jeremie" writeup; if you have time to write it, I'd sure benefit from it! Wayne Stidolph / Lutris Technologies -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Bruno Dumant Sent: Thursday, February 15, 2001 1:33 AM To: 'Shane Muffat' Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; Jonathan Subject: Re: a "mini" transaction service for implicit context data Shane, You certainly need the kind of mechanisms described by Wayne to do what you want. I will just bring in my small contribution about remote context propagation. Jeremie provides an extensible way to add context information in the messages exchanged. What you need to do is to provide an object implementing the org.objectweb.david.apis.services.handler.Service interface, and then register it in the Jonathan configuration. If you really want to do that, I can give you more precise information. Philippe Coq has already provided you with the description of the transaction and security context propagation mechanism; If you (or other people) need it, I could write something about "how to propagate any context information with Jeremie". In particular, this mechanism could easily be used to propagate the Enhydra contexts. About using Jeremie inside Weblogic, I am afraid the first answer is no. Jeremie is not an implementation of RMI (small differences in the API, different protocol, no distributed gc, slightly different stub structure), and you thus cannot use it directly. Having a different protocol and no gc is not necessarily a problem. The first real requirement is the modification of the Jeremie APIs to match exactly those of RMI (actually, it's not a (technical) problem, we already experimented it). But the real problem is to understand how Weblogic transmits the security and transactional contexts. If the context transmission is implemented in the stubs, then it should be possible to adapt Jeremie so that it can use the Weblogic stubs. If it is achieved through some proprietary mechanism inside the Weblogic machinery, I am afraid we can't do much for you, except telling you to switch to Jonas ! RMI/IIOP won't help much in this respect. The good points are that the API will be standard, and the lack of distributed gc a standard "feature", but the problems mentionned above will still be there. Best regards, Bruno Wayne Stidolph wrote: > Shane, > > Getting to what I *think* was your original question... first, if all you're > worried about is tracking the user, and if your app is written using > servlets and EJBs, then note that you have standardized context calls to get > the caller principal in both those environments. Nothing fancy needed, just > getUserPrincipal() stuff (one method on servlet context, another on EJB > Context). > > Or, you could use a Logging Decorator that logs every business call into a > user-specific log at each step of the work request tracing through the > server. This lets you log/bill/whatever on a method invocation on a specific > component (or many of them - up to you) without doing anything at all in > your business logic. We expect this to be a powerful technique. > > Or, you may want more/different information. In that case, you can look to > our context propagation, described below. In summary, we will be passing > contexts using ThreadLocal variables, to avoid altering business APIs, and > we expect to serialize that data over remote calls too. > > (Note - some of what I'm describing below is in place now, some is still in > the design/implementation phase. But it's what we expect in Ver 4) > > (Or at least, it's what *I* expect ... life is changeable ...) > > In Enhydra Enterprise, the plan is that we attach some Contexts to the > thread that handles a work request. For example, the WebContainer attaches a > SecurityContext and an ApplicationContext to each HTTP Request... the > SecurityContext identifies the user/client for the work request; and the > AppContext provides data which is visible to every component and thread > working for that application. We use the AppContext for various things > (tracking namespace roots might go there, for example) but we also will let > you write name/value pairs of application environment variables into it just > as you do in an Enhydra 3 context. (Though I'd rather see those bound into > JNDI in an app: namespace, at least for Enhydra Ver 4 apps.) > > We have not decided where to put the session ID in the internal context > structure: a new context - the session context? (That's my candidate) ... an > attached element on the app context? (but the session id isn't constant > across the app, since there are multiple session actyive in the app at > once)... a new Principal in the security context? (That oughta wake up > Craig! but isn't the session id a sort of name?) > > The important point in response to your question is that we do context > tracking with ThreadLocal variables which then pass through the business > APIs transparently, and we serialize and propagate those objects during > remote calls, so you could put session or user-tracking code into your > application components and the data would be available wherever the call > goes. > > At this point you're probably thinking about two things: what else you can > do with this facility, and how we do our part, propagation ... at least, > that's what *I'm* thinking about :) > > You can do a lot, more than I can likely imagine. But, an unresolved issue > might keep us from immediately doing part of the propagation for you - we > have some policy decisions to take about keeping the various copies of > AppCtx running around "sufficiently consistent" - those policy debates > haven't hit the Architecture WG yet ... so dynamic data attached to the app > context by the user may not get propagated in the next release. We'll try - > join that discussion when we get started (another week or two away, I think. > Gotta get the next "release" dropped to Enhydra.org) > > As to how we will do our part ... our choices are to extend the approach > that is being used now, or to look for "better" approaches. This is likely > not interesting to many folks, but a little background just in case: the > propagation can take place at the RMI layer (by manipulating the > rmic-generated source for stubs and skels, as JOnAS does with RMI 1.1 > support), or in the IIOP layer (as would be done with Handlers in Jeremie or > (I think) RMI-IIOP); or, Rikard Oberg showed a nice trick for doing this > with a plug-in to an undoc'ed API in the JDK1.2 RMI structure (see his > ctxrmi example, over at www.dreambean.com) We are looking at how these play > together, and which ones might support the intra-VM optimization that > Jeremie uses to such good benefit. We have things to learn about managing > threads in the Sun RMI implementation! > > Back to your questions: The issue of plug-play compatibility is, ummm, > interesting. Even if we assume you take the Enhydra-generated stubs, > skeletons, support classes etc and install them on a BEA etc server, I don't > think it'll work; all of these approaches assume some code that provides the > context data to be marshalled, and there isn't a good standard there for how > to set up that interoperability, so the answer is probably no when we using > these propagation techniques. (What would an Enhydra SessionID context mean > on a BEA server, even if we got the data unmarshalled? etc) RMI-based > interoperability is fine as far as the spec goes ... but it doesn't go far > enough for all the customer needs... > > Hope I got to the question you cared about. > > Wayne Stidolph / Lutris Technologies > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Christophe > Ney > Sent: Wednesday, February 14, 2001 10:37 AM > To: 'Shane Muffat' > Cc: [EMAIL PROTECTED] > Subject: RE: a "mini" transaction service for implicit context data > > I am not sure. > I would ask this on the JOnAS user mailling list. > Thanks > Christophe > Christophe Ney - mailto:[EMAIL PROTECTED] > Enhydra Project - http://www.enhydra.org > Lutris Technologies - http://www.lutris.com > >-----Original Message----- > >From: Shane Muffat [mailto:[EMAIL PROTECTED]] > >Sent: Wednesday, February 14, 2001 7:10 PM > >To: 'Christophe Ney' > >Cc: [EMAIL PROTECTED] > >Subject: RE: a "mini" transaction service for implicit context data > > > > > >Yes! Exactly! Is Jeremie available and plug-in compatable...with > >say...just about any EJB Application Server that supports RMI...in this > >particular case where we are testing...Weblogic 5.1...with Weblogics > >implementation of RMI??? > > > > > > > >-----Original Message----- > >From: Christophe Ney [mailto:[EMAIL PROTECTED]] > >Sent: Wednesday, February 14, 2001 1:08 PM > >To: Shane Muffat > >Cc: [EMAIL PROTECTED] > >Subject: RE: a "mini" transaction service for implicit context data > > > > > > > >What you need is context propagation. This has not much to > >do with the TM except that context propagation is used to > >pass the transactional context. > >This is done with Jeremie that support attching any context > >to the rmi call. There is also an rmi version in jonas > >that patches the rmi stub to attach the context. > > > >thanks, > >christophe > >Christophe Ney - mailto:[EMAIL PROTECTED] > >Enhydra Project - http://www.enhydra.org > >Lutris Technologies - http://www.lutris.com > > > > > >>-----Original Message----- > >>From: Shane Muffat [mailto:[EMAIL PROTECTED]] > >>Sent: Wednesday, February 14, 2001 5:52 PM > >>To: 'Christophe Ney' > >>Subject: RE: a "mini" transaction service for implicit context data > >> > >> > >>That is actually besides the point...it should be able to be any bean > >>type...we are trying to build infrastructure type context > >>passing here...and > >>when I talk about TM...it is just something similiar that I think does > >>things sort of like the way we need them. I don't care what type of > >>bean...a business developer creates...or how they implement an RMI > >>server...and I don't have control over either...I just need to > >>be able to > >>"piggy-back" a simple attribute onto each and every call in our J2EE > >>environent and have that data available everywhere...so maybe > >>I was being > >>misleading when talking about the transaction service... > >> > >> > >>-----Original Message----- > >>From: Christophe Ney [mailto:[EMAIL PROTECTED]] > >>Sent: Wednesday, February 14, 2001 11:31 AM > >>To: Shane Muffat > >>Subject: RE: a "mini" transaction service for implicit context data > >> > >> > >>What kind of bean are you writting > >>session, CMP, BMP. > >>What kind of transaction attribute > >> > >>christophe > >>Christophe Ney - mailto:[EMAIL PROTECTED] > >>Enhydra Project - http://www.enhydra.org > >>Lutris Technologies - http://www.lutris.com > >> > >>>-----Original Message----- > >>>From: Shane Muffat [mailto:[EMAIL PROTECTED]] > >>>Sent: Wednesday, February 14, 2001 5:20 PM > >>>To: 'Christophe Ney' > >>>Subject: RE: a "mini" transaction service for implicit context data > >>> > >>> > >>>But...I really don't want a full-fledged distributed TM no matter how > >>>"simple" it is...I don't need to do any rollback...and don't > >>>need to manage > >>>resources...that all happens with a TM and causes overhead...I > >>>just want to > >>>implicitly pass a session id from component to component > >>>without changing > >>>any business interfaces!!!! > >>> > >>> > >>>-----Original Message----- > >>>From: Christophe Ney [mailto:[EMAIL PROTECTED]] > >>>Sent: Wednesday, February 14, 2001 11:19 AM > >>>To: Shane Muffat; [EMAIL PROTECTED] > >>>Subject: RE: a "mini" transaction service for implicit context data > >>> > >>> > >>>Hi Shane, > >>> > >>>In Enhydra Enterprise, services are pluggable and can be easily > >>>replaced with a simple configuration change. Now, I don't know > >>>if a distributed TM can be simpler than the JOnAS one. > >>> > >>>Thanks, > >>>Christophe > >>>Christophe Ney - mailto:[EMAIL PROTECTED] > >>>Enhydra Project - http://www.enhydra.org > >>>Lutris Technologies - http://www.lutris.com > >>> > >>> > >>> > >>>>-----Original Message----- > >>>>From: [EMAIL PROTECTED] > >>>>[mailto:[EMAIL PROTECTED]]On Behalf Of > >>>Shane Muffat > >>>>Sent: Wednesday, February 14, 2001 5:03 PM > >>>>To: '[EMAIL PROTECTED]' > >>>>Subject: a "mini" transaction service for implicit context data > >>>> > >>>> > >>>>Is there any way...to develop a transaction like service WITHOUT the > >>>>overhead to simply...implicitly pass a session ID from EJB to > >>>>EJB to RMI > >>>>Server...and possibly in reverse...??? The transaction service does > >>>>something like this...does it not? I've looked at everything > >>>>from dynamic > >>>>proxies...which really doesn't help because we need control > >>>>over development > >>>>of the business components...the IIOP layer...and the transaction > >>>>service...but am having a hard time with it. I am trying to > >>develop a > >>>>plugable framework here without having control over the business > >>>>development...this framework needs to track a user (session > >>>>ID) through the > >>>>entire application!!! > >>>> > >>>>Any help would be greatly appreciated! > >>>> > >>>>A perplexed java engineer, > >>>>Shane Muffat > >>>>---- > >>>>This list is cross-posted to two mail lists. To unsubscribe, > >>>>follow the instructions below for the list you subscribed to. > >>>>For objectweb.org: send email to [EMAIL PROTECTED] and > >>>>include in the body of the message "unsubscribe transaction-group". > >>>>For enhydra.org: send email to [EMAIL PROTECTED] and include > >>>>in the body of the message "unsubscribe transaction-group". > >>>> > >>> > >>>---- > >>>This list is cross-posted to two mail lists. To unsubscribe, > >>>follow the instructions below for the list you subscribed to. > >>>For objectweb.org: send email to [EMAIL PROTECTED] and > >>>include in the body of the message "unsubscribe transaction-group". > >>>For enhydra.org: send email to [EMAIL PROTECTED] and include > >>>in the body of the message "unsubscribe transaction-group". > >>> > >> > > > >---- > >This list is cross-posted to two mail lists. To unsubscribe, > >follow the instructions below for the list you subscribed to. > >For objectweb.org: send email to [EMAIL PROTECTED] and > >include in the body of the message "unsubscribe transaction-group". > >For enhydra.org: send email to [EMAIL PROTECTED] and include > >in the body of the message "unsubscribe transaction-group". > > > > ---- > This list is cross-posted to two mail lists. To unsubscribe, > follow the instructions below for the list you subscribed to. > For objectweb.org: send email to [EMAIL PROTECTED] and > include in the body of the message "unsubscribe transaction-group". > For enhydra.org: send email to [EMAIL PROTECTED] and include > in the body of the message "unsubscribe transaction-group". > > ---- > This list is cross-posted to two mail lists. To unsubscribe, > follow the instructions below for the list you subscribed to. > For objectweb.org: send email to [EMAIL PROTECTED] and > include in the body of the message "unsubscribe transaction-group". > For enhydra.org: send email to [EMAIL PROTECTED] and include > in the body of the message "unsubscribe transaction-group". ---- To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "unsubscribe jonas-users". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
