Another thing David, I don't see you always stuffing the Transaction into the invocation object. A few interceptors rely on the transaction being in the invocation object. Any objects to fixing this?
Bill > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Bill > Burke > Sent: Wednesday, February 12, 2003 5:36 PM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] TxInterceptor split is bad > > > > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]]On Behalf Of Hiram > > Chirino > > Sent: Wednesday, February 12, 2003 5:09 PM > > To: [EMAIL PROTECTED]; David Jencks > > Subject: Re: [JBoss-dev] TxInterceptor split is bad > > > > > > --- Bill Burke <[EMAIL PROTECTED]> wrote: > > > What if you don't have java on the client side? > > > What if you're CORBA with > > > OTS? You're making it harder for Non-JBoss/Java > > > clients to integrated with > > > us. I think this split should be undone. > > > > > > > How des OTS work? The corba guys tackled the DTM > > problem too right?? > > > > They have the concept of a ThreadLocal (Current) (My knowledge > is probably > outdated and foggy). In O2K the client side interceptor stuffs the value > from the transaction current into the IIOP service context, much the same > way we used to do before David's switch. > > -1 for refactor > > > > BTW, why the split besides code readability? Is the > > > DTM dependent on this > > > at all? Is the TM even accessed on the client side? > > > > > > > I think so. In the case were a client is a server the > > local TM is accessed to treat the remote TM like a > > XAResource. > > > > +1 for refactor > > > > Another problem I see is that the TxMethod map is > > > required on the client > > > side as well. Makes proxies even more heavy and > > > what do you do about a hot > > > deploy? > > > > > > > Yes.. but same argument could be made against any > > client side interceptor we create. The proxy on the > > client goes stale if a redeploy changes the proxy > > config. > > > > Ok, you're right. +2 for refactor > > > > Seems to me this is a bad idea. > > > > > > > I agree it is a complex solution. But the DTM problem > > is complex too. Any simpler sugestions?? > > > > Actually the code is much more readable. I guess my only concern now is > non-java/jboss clients. And, do we care? > > Another thing about this is that you're requiring the client to become > beafier and beafier. I've been kinda nervous about the whole JMX on the > client sort of thing and the start of deploying services on the > client side. > But maybe it doesn't matter. > > Bill > > P.S. Good to see you around again Hiram. > > > > ------------------------------------------------------- > 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 ------------------------------------------------------- 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
