Whoops, forgot to send this too.
> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of David > Jencks > Sent: Friday, February 21, 2003 5:02 PM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] TxInterceptor split is really really bad > > > I'm getting kind of tired of what I find vague complaints without detailed > explanations of the framework in which you think there might be a problem. > I don't think I was vague. I gave a specific example. The same object could be accessed locally and remotely. Locally through a regular/plain Java reference. Remotely, through a proxy. Because of the way you have defined the TM interaction, the "server"-side tx interceptor for AOP will have to know if the invocation passed through a Proxy since the object instance can be referenced directly locally. > I think remote AOP is going to need; > > 1. some representation of the object you are calling > > 2. client interceptors. For instance, to get the security context. > > 3. a transport mechanism > > 4. something on the other end of the transport mechanism to find the right > target > > 5. server side interceptors > Stop being obvious. > If you disagree please explain in detail what you propose. Personally I > think the AOP stuff should do this always, with a possible "null" > transport mechanism, at least for "remotable" objects. > Definately no "null" transport. This would require a proxy. This goes against the primary goal of the framework, to provide J2EE services and remoteness for plain Java objects/classes transparently. So a programmer could say, I have this ordinary Object, I want it accessible as a WebService and yet still access the object locally. For 1st iteration, I intend to require that POJOs can only be remotely accessed via a DynamicProxy. I think this is relatively trivial to implement and will allow us to get an AOP remoting framework out there pretty quickly. 2nd iteration, I want to remove this DynamicProxy requirement, but IMHO, this requires much more thought. > If you agree, then I hope you will agree that there has to be > some metadata > on the client side to define the client interceptors and the transport. > > If there is some place to put metadata, why can't I use it for the tx > support? > Again, it has nothing to do about metadata and all about keeping the "server" isolated from client quirkiness. I just think your tx separation is fragile in this respect. > > I would like to note that my future plans for this involve method specific > interceptor chains with a variety of "client side" and "server side" tx > interceptors, each one performing half of the TxSupport work. No maps, > just different specialized interceptors, with different interceptors per > method depending on the tx support. > > I also think you will admit that even in aop you could have two > interceptors even if both were on the server side: one to get the tx from > the context if appropriate or remove it if appropriate, one to start a new > tx if appropriate. > But if there is a remote proxy in between, the "client" stuff happens twice unless I specifically check to see if there was a proxy in front of the client. BIll ------------------------------------------------------- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
