Interceptors seem reasonable, as long as there are no hidden costs behind them. Why not keep them seperated and more flexible? Also allows invokers to become a little bit simpler. The only down (aside from any performance & client-side class loading issues) are the read code as a story fluff which some of us have been pimping from day one. So that really isn't a down after all since I never bought into that garbage in the first place ;)
So are there any performance or other negative side effects which would be undesirable by making this seperation? If not, then the more flexible and pluggable the better I say. But then again what do I know, I haven't touched a bit of code in months :( Only evil servers to deal with... --jason On Tue, 25 Feb 2003, David Jencks wrote: > On 2003.02.25 02:58 Sacha Labourey wrote: > > Hello, > > > > This discussion is somehow strange because, and I agree with David: you > > don't seem to be speaking about the same thing at the same time... > > Asynchronous argumentation is hard to follow... > > > > - I think we should have interceptors > > - Yes, but the sky is blue > > - No! Invokers can't handle DTM in this case > > - You mean AOP? > > > > I understand David's point of view. David loves orthogonal designs and > > the > > idea to have somehow symetric interceptors (between the client and the > > server), possibly with a null invoker in the middle of the chain makes > > his > > design pleaseant. Nevertheless, where I think I agree with Bill is that > > we > > first have to check if we don't go too far just for the beauty of it. > > Let's > > take IIOP as an example. In the general case, IIOP can only transport the > > same kind of data: > > - invocations information (method name, arguments, etc.) > > - arbitrary context information > > > > In the arbitrary payload, you may find security information, transaction > > information, etc. The question is: at the end of the day, do we really > > need > > a stack of interceptors just to extract this set of information and > > populate > > a JBoss invocation object? Couldn’t we more simply just extract "all this > > stuff" and put it in the Invocation Object (and the server side Invoker > > could do that). > > > > I agree, it would look much smarter to have this "separation of concern" > > and > > have each interceptor from a virtual-client-stack (i.e. client side > > interceptors living on the server and mimic-ing client-side behaviour) > > put > > only what is needed inside the JBoss invocation object. NEVERTHELESS, as > > this information will always be similar, why not simply do that in a > > generic > > way inside the invoker: in-mass population of the invocation with > > well-known > > key names for well-known invocation content. > > > > If you think about it, the invoker already does that: it extracts the > > target > > MBean ObjectName from the invocation and push the invocation to it: if > > you > > push your reasoning far enough, that's already a concern that shouldn't > > be > > put in a pure "transport-focused invoker". But I agree, and as French > > say: > > "Je pousse mémé dans les ortilles". Translation left as an exercise. > > well, aside from my and babelfish's inability to translate that... > > 1. I was planning to move the invocation reassembly and targeting into a > bunch of interceptors on the server side. > > 2. I think your argument applies with exactly equal force to the client > side interceptors and if we put the functionality for IIOP into the invoker > on the server side we should for exactly the same reason eliminate client > side interceptors everywhere and put them in the client side of "more > capable" (than IIOP) invokers. Just because we haven't used the client > interceptors for any customization doesn't mean they aren't a good idea. > If we ever found a use for including additional context information, we > would be able to include it in all transports simply be writing one client > and one server interceptor and adding it to the chains for the objects we > wanted it for. For IIOP, I think this would result in the fewest changes: > I think basically we'd just have to add the C++ (or whatever) code to send > the additional context info. > > thanks > david > > > > > > Cheers, > > > > > > Sacha > > > > > > > -----Original Message----- > > > From: [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED] On > > > Behalf Of David Jencks > > > Sent: lundi, 24. février 2003 21:02 > > > To: [EMAIL PROTECTED] > > > Subject: RE: [JBoss-dev] TxInterceptor split is still the > > > best thing since sliced bread > > > > > > > > > On 2003.02.24 14:35 Bill Burke wrote: > > > > > > > > > > > > > > > > > > Bill, what I find really boring and unpleasant about this > > > discussion is > > > > > that I can't find any evidence that you read most of my > > > posts, or that > > > > you > > > > > > > > Ditto. > > > > > > > > I thought I did read your stuff and replied appropriately. Maybe I > > > > missed > > > > something. What I saw you propose for non-Java and I'll quote you: > > > > > > > > "outside world >>> something corba and proxy-like > ci1 > > > > ci2 > some kind > > > > of > > > > invoker-like thing > si1 > si2 > actual target object" > > > > > > > > My argument against this was that you would have to > > > maintain 2 separate > > > > interceptor chains on the server. > > > > > > > > For IIOP the chain would be (as you stated) > > > > > > > > IIOPInvoker > ci1 > ci2 > si1 > si2 > actual target object. > > > > > > > > For RMI/Java the chain would be > > > > > > > > DP > ci1 > ci2 > ---- network --- JRMPInvoker > si1 > si2 > > > > > > > > I voiced a similar problem with AOP where the AOP > > > interceptors would have > > > > to > > > > know whether the call had traveled through a remote proxy object. > > > > > > I wrote the lengthy description/picture below in an attempt > > > to find out > > > what you are talking about, since this argument doesn't make > > > sense to me. > > > I didn't see any response from you about it. > > > > > > I'll try to explain why, specifically, your argument makes no > > > sense to me. > > > > > > I think interceptors all implement required functionality. > > > If you put them > > > in the chain, it's for a reason: they are doing something you need. > > > Therefore, however many transport steps are in the middle, > > > any invocation > > > should go through the same (target specific) interceptors. > > > (IMO transport > > > layer interceptors on both ends are a good idea too, but > > > that's a separate > > > argument). If the interceptor chains have different > > > interceptors, you will > > > get different behavior, and you should be getting that > > > through other means > > > such as additional deployments. > > > > > > Therefore, for a conceptual interceptor chain of ci1 > ci2 > > > > si1 > si2, > > > this might end up as > > > > > > ci1 > ci2 > ||transport from client machine to server || > si1 > si2 > > > > target object. > > > > > > or > > > > > > ci1 > ci2 > ||do nothing "transport" on same machine || > si1 > si2 > > > > target object. > > > > > > It might be possible to arrange for > > > > > > ci1 > ci2 > si1 > si2 > target object but I don't see why > > > you'd want to > > > particularly. > > > > > > Furthermore, for corba, > > > > > > java-corba-endpoint on server > ci1 > ci2 > || possible "transport" > > > translation layer whose need is questionable || > si1 > si2 > target > > > object. > > > > > > To me these are all the same interceptor chain: they all have the same > > > members, with the exception of the one missing any kind of > > > transport. The > > > chain has 2 entry points: ci1 and si1. If you regard this as > > > more than one > > > interceptor chain please explain your point of view. As I > > > understand it, > > > this is also essentially how we handle ejbs today: certainly > > > we maintain > > > both the client and server interceptor stacks on the server. > > > > > > It occurs to me that what you write is consistent with not > > > having client > > > side interceptors for aop. Is this your plan? If so, how > > > will you gather > > > the context information for the invocation? If not, why do > > > you want to > > > put limits on what the client side interceptors can do? > > > > > > > > > thanks > > > david > > > > > > > > > > > > > > > remember the reasons for my design decisions for more than about > > > > > 5 minutes. > > > > > I've written fairly detailed explanations of my views of both > > > > interceptor > > > > > architecture and corba integration and asked for comments > > > or whether > > > > you > > > > > agree or disagree. I haven't seen any direct responses. > > > > > > > > > > At this point I don't want to read the same argument from > > > you again. > > > > > Please implement your idea for how dtm will work so we can discuss > > > > > something concrete. > > > > > > > > > > > > > I think I already have (see below), but will reread your > > > posts to make > > > > sure. > > > > > > > > Bill > > > > > > > > > > > > > > > > > thanks > > > > > david > > > > > > > > > > > > > > > On 2003.02.24 13:37 Bill Burke wrote: > > > > > > Sure. The TxSupport class is a nice change and makes > > > the code much > > > > more > > > > > > readable. I have stated this before. But.... > > > > > > > > > > > > Merge TxSupport.clientInvoke and serverInvoke into one method. > > > > Remove > > > > > > all > > > > > > logic from client interceptor except TX propagation. > > > Propagate the > > > > TX > > > > > > always. Again, my reasoning is to isolate the EJB > > > container from > > > > the > > > > > > transport mechanism. Currently, in 3.2, you can invoke > > > on an EJB > > > > from > > > > > > any > > > > > > protocol at the same time. With David's change, > > > non-Java clients > > > > that > > > > > > support TX propagation would require that > > > TxSupport.clientInvoke be > > > > run > > > > > > on > > > > > > the server thus requiring us to have transport specific > > > server-sdie > > > > > > interceptor chains and a change to the current > > > architecture. I think > > > > > > that > > > > > > this creates further complication in the server-side > > > architecture and > > > > > > will > > > > > > further bloat configuration. All just to save a tx > > > propagation for > > > > > > NotSupported and RequiresNew methods. > > > > > > > > > > > > Or are you talking about the AOP stuff? Well, it is > > > implemented, I > > > > do > > > > > > have > > > > > > an API. I have written the AOP Tx interceptor and it is tested > > > > within > > > > > > the > > > > > > testsuite. I am working on the Security one. So far, my > > > > > design seems to > > > > > > fit. The real test will be with the persistence > > > metadata since this > > > > is > > > > > > much more complicated. I've made an attempt to explain > > > my design > > > > with > > > > > > the > > > > > > bootcamp slides and the crappy documentation I put > > > together on the > > > > > > website > > > > > > /developers/projects/jboss/aop.jsp. > > > > > > > > > > > > > > > > > > Bill > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: [EMAIL PROTECTED] > > > > > > > [mailto:[EMAIL PROTECTED] > > > > > Behalf Of Dain > > > > > > > Sundstrom > > > > > > > Sent: Monday, February 24, 2003 12:36 PM > > > > > > > To: [EMAIL PROTECTED] > > > > > > > Subject: Re: [JBoss-dev] TxInterceptor split is still the best > > > > thing > > > > > > > since sliced bread > > > > > > > > > > > > > > > > > > > > > Bill, > > > > > > > > > > > > > > Where is you design? David's design looks totally > > > obvious to me. > > > > It > > > > > > > is well understood, and based on our existing "real-world" > > > > > experiences. > > > > > > > To me it looks like you are the one invent "the perfect > > > > design/API". > > > > > > > So can you present you invocation chain as did and show us > > > > > the error in > > > > > > > our logic? > > > > > > > > > > > > > > -dain > > > > > > > > > > > > > > On Monday, February 24, 2003, at 09:39 AM, Bill Burke wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >> -----Original Message----- > > > > > > > >> From: [EMAIL PROTECTED] > > > > > > > >> > > > [mailto:[EMAIL PROTECTED] Behalf > > > > Of > > > > > > > >> David > > > > > > > >> Jencks > > > > > > > >> Sent: Saturday, February 22, 2003 11:48 AM > > > > > > > >> To: [EMAIL PROTECTED] > > > > > > > >> Subject: RE: [JBoss-dev] TxInterceptor split is still the > > > > > best thing > > > > > > > >> since sliced bread > > > > > > > >> > > > > > > > >> > > > > > > > >> This is really boring and unpleasant, bill. We > > > don't seem to > > > > > > > > > > > > > > > > I am sorry I am boring you. Summarized, my major concern > > > > > with the TX > > > > > > > > refactor is that it will not work for clients that > > > cannot have > > > > > > > > interceptor > > > > > > > > chains (i.e. non-Java), but support Tx propagation > > > (CORBA) for > > > > all > > > > > > > > trans-attributes (specifically, NotSupported, and > > > RequiresNew). > > > > I > > > > > > > > thought > > > > > > > > Marc's vision for creating these generic, transport > > > > > specific invokers > > > > > > > > was to > > > > > > > > isolate the EJB Container from the transport layer, > > > and I see > > > > this > > > > > > > > refactor > > > > > > > > as breaking this vision. > > > > > > > > > > > > > > > > The only way I see this working is if we have separate > > > > > > > > transport-specific > > > > > > > > interceptor chains on the server to support > > > non-Java clients. I > > > > > > > > wanted to > > > > > > > > avoid this because this is what has happened when I put in > > > > support > > > > > > for > > > > > > > > multiple invokers. Client-side interceptor > > > configuration became > > > > > > > > bloated. > > > > > > > > All this to avoid creating and passing over a TxId. > > > See my point > > > > > > now? > > > > > > > > > > > > > > > > =========================== > > > > > > > > > > > > > > > > As far as AOP goes, I'm hoping that as we implement > > > services on > > > > top > > > > > > of > > > > > > > > the > > > > > > > > Framework and apply the framework to JMX and remoting, the > > > > > > > > requirements and > > > > > > > > API will be fleshed out as we iterate. I'd like the design > > > > > of AOP to > > > > > > > > be > > > > > > > > driven by "real-world" requirements and applications rather > > > > > than what > > > > > > > > we > > > > > > > > might think as the perfect (and probably bloated) > > > > > design/API might be > > > > > > > > currently. I'm not afraid of throwing code out or having to > > > > modify > > > > > > > > huge > > > > > > > > amounts of code to iterate. Iteration is key. > > > Allows us to get > > > > to > > > > > > > > market > > > > > > > > quick and to quickly notice bad designs. Didn't > > > somebody say > > > > > > "Release > > > > > > > > early, release often"? > > > > > > > > > > > > > > > > Bill > > > > > > > > > > > > > > > > > > > > > > > >> have a shared > > > > > > > >> understanding of how interceptors ought to work > > > with local and > > > > > > remote > > > > > > > >> calls. Most of your comments make no sense to me, > > > and I think > > > > > > > >> contrariwise. I'll try to explain my view one > > > more time, and > > > > > > > >> I'll write an > > > > > > > >> interceptor framework that satisfies my > > > understanding of what is > > > > > > > >> needed for > > > > > > > >> mbeans, ejbs, remoting, and aop (which I don't > > > understand all > > > > that > > > > > > > >> well). > > > > > > > >> If you don't like it and I can't understand your > > > objections, > > > > I'll > > > > > > let > > > > > > > >> you > > > > > > > >> indulge your previously expressed wish to write a > > > transaction > > > > > > > >> manager. You > > > > > > > >> might also get that wish fulfilled if you say the > > > following is > > > > > > > >> obvious. I > > > > > > > >> thought it was, but I don't think we have agreed on it. > > > > > I'm writing > > > > > > > >> it > > > > > > > >> down to try to form a basis for discussion, which > > > is currently > > > > > > > >> missing. > > > > > > > >> > > > > > > > >> ========================== > > > > > > > >> > > > > > > > >> Dave's mental model for invocations. > > > > > > > >> > > > > > > > >> Lets assume first you already have something representing > > > > > the object > > > > > > > >> you > > > > > > > >> are interested in (such as an ejb Remote interface > > > object, mbean > > > > > > > >> thingy, > > > > > > > >> aop-ized object, or some kind of proxy). Items > > > marked with a * > > > > > > might > > > > > > > >> be > > > > > > > >> removed for non-remotable objects. > > > > > > > >> > > > > > > > >> Key to symbols: > > > > > > > >> > > > > > > > >> \/ interceptor chain "invokeNext()" calls. > > > > > > > >> > > > > > > > >> > > > > > > > >> \/ > > > > > > > >> || method/field access/... calls whose nature may vary > > > > > > > >> depending on the > > > > > > > >> application and that are not part of the > > > interceptor/invocation > > > > > > > >> framework. > > > > > > > >> > > > > > > > >> \/ > > > > > > > >> \/ calls between "segments". These are of the form > > > > > > > >> invoke(invocation) > > > > > > > >> on a particular object found by the current interceptor. > > > > > > > >> > > > > > > > >> .......... sequence of interceptors in a chain. > > > > > > > >> > > > > > > > >> || > > > > > > > >> || transport mechanism. For a remote object, > > > this is the > > > > > > > >> boundary > > > > > > > >> between client and server. > > > > > > > >> > > > > > > > >> > > > > > > > >> =========================== > > > > > > > >> > > > > > > > >> > > > > > > > >> Some program does something on the "object" > > > > > > > >> > > > > > > > >> \/ > > > > > > > >> || > > > > > > > >> > > > > > > > >> The Object > > > > > > > >> > > > > > > > >> \/ > > > > > > > >> || > > > > > > > >> > > > > > > > >> Something that knows about interceptor chains and > > > metadata. It > > > > > > looks > > > > > > > >> at > > > > > > > >> the method (or field access, ...) call and its > > > environment and > > > > > > > >> determines > > > > > > > >> what interceptor chain to use. It constructs an Invocation > > > > object > > > > > > > >> that > > > > > > > >> includes an iterator over the selected chain, the > > > method call > > > > data, > > > > > > > >> and > > > > > > > >> some metadata. Then it starts the invocation down > > > the chain. I > > > > > > will > > > > > > > >> call > > > > > > > >> this a Container. I believe it corresponds to your aop > > > > Advisor(s). > > > > > > > >> > > > > > > > >> \/ > > > > > > > >> > > > > > > > >> Several interceptors (client side interceptors > > > specific to the > > > > > > > >> object/class you are calling) > > > > > > > >> > > > > > > > >> ..... > > > > > > > >> > > > > > > > >> \/ > > > > > > > >> > > > > > > > >> * Transport selector interceptor. This examines > > > the metadata > > > > and > > > > > > > >> picks a > > > > > > > >> transport endpoint. It calls invoke(invocation) > > > on the selected > > > > > > > >> transport > > > > > > > >> endpoint. It does not call > > > invocation.invokeNext(), so this may > > > > be > > > > > > > >> the end > > > > > > > >> of the use of the original interceptor iterator. > > > > > > > >> > > > > > > > >> \/ > > > > > > > >> \/ > > > > > > > >> > > > > > > > >> * Transport endpoint. If this is a local "do nothing" > > > > transport, > > > > > > it > > > > > > > >> may > > > > > > > >> simply call invocation.invokeNext(). Otherwise, > > > it replaces the > > > > > > > >> interceptor iterator with one for the client side transport > > > > > > > >> interceptor > > > > > > > >> stack. > > > > > > > >> > > > > > > > >> \/ > > > > > > > >> > > > > > > > >> * Several interceptors (client side interceptors > > > specific to the > > > > > > > >> transport > > > > > > > >> endpoint you are calling. Examples would include > > > the XAResource > > > > > > > >> representing a remote jboss instance (whenever the > > > branch is > > > > > > created, > > > > > > > >> you > > > > > > > >> still need an XAResource, and it needs to know > > > about the method > > > > > > > >> calls), and > > > > > > > >> the clustering thingy that picks a remote server) > > > > > > > >> > > > > > > > >> \/ > > > > > > > >> > > > > > > > >> * client side end of the transport. I believe this is > > > > essentially > > > > > > the > > > > > > > >> remoting framework. > > > > > > > >> || > > > > > > > >> || > > > > > > > >> || > > > > > > > >> * server side end of the transport. This may > > > include some kind > > > > of > > > > > > > >> relationship with a thread pool. Lets assume the work is > > > > > > > >> dispatched with a > > > > > > > >> thread, no matter how it is picked and how > > > > > > > >> synchronous/asynchronous it is. > > > > > > > >> Anyway, the reconstituted invocation object has > > > its interceptor > > > > > > > >> iterator > > > > > > > >> replaced with one for the transport specific server side > > > > > > interceptors > > > > > > > >> > > > > > > > >> \/ > > > > > > > >> > > > > > > > >> * Several interceptors (server side interceptors > > > specific to > > > > the > > > > > > > >> transport. In my current dtm implementation, one > > > of these would > > > > > > > >> import an > > > > > > > >> xid in the invocation into the server side tm) > > > > > > > >> > > > > > > > >> ..... > > > > > > > >> > > > > > > > >> * Target selector. Based on the metadata, this > > > interceptor > > > > picks > > > > > > and > > > > > > > >> locates a target object, and calls > > > invoke(invocation) on it. > > > > This > > > > > > is > > > > > > > >> the > > > > > > > >> end of the transport specific server side > > > interceptor chain. > > > > > > > >> > > > > > > > >> \/ > > > > > > > >> \/ > > > > > > > >> > > > > > > > >> * Server side target object. This is analogous to > > > the current > > > > > > > >> server side > > > > > > > >> ejb Container object. It replaces the > > > invocation's interceptor > > > > > > > >> iterator > > > > > > > >> and starts it off by calling invocation.invokeNext(). > > > > > > > >> > > > > > > > >> \/ > > > > > > > >> > > > > > > > >> Server side interceptors. For non remotable > > > objects and for "no > > > > > > > >> transport" > > > > > > > >> local remotable objects, the original interceptor > > > chain would > > > > > > continue > > > > > > > >> here. > > > > > > > >> > > > > > > > >> ....... > > > > > > > >> > > > > > > > >> \/ > > > > > > > >> > > > > > > > >> Final interceptor. This uses the metadata and the method > > > > > > > >> information to do > > > > > > > >> something to the actual object instance we are > > > working with. > > > > > > > >> > > > > > > > >> \/ > > > > > > > >> || > > > > > > > >> > > > > > > > >> object of interest. > > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > > >> Note that this requires, for remotable objects, > > > being able to > > > > get > > > > > > two > > > > > > > >> interceptor iterators: one for the client side > > > iterators, and > > > > one > > > > > > for > > > > > > > >> the > > > > > > > >> server side iterators. For "local only" objects, you > > > > > only need one > > > > > > > >> interceptor iterator. For objects that can be > > > local or remote, > > > > > > > >> looking up > > > > > > > >> the server side target object can be avoided if > > > the client side > > > > > > > >> interceptor > > > > > > > >> iterator also includes all the server side interceptors: > > > > > the (client > > > > > > > >> side) > > > > > > > >> Transport Endpoint would (after determining that > > > the call is > > > > local) > > > > > > > >> simply > > > > > > > >> call invokeNext() on the invocation. > > > > > > > >> > > > > > > > >> > > > > > > > >> Lets see if we can come to an agreement on this > > > much before we > > > > > > > >> consider > > > > > > > >> constructors or how to get something representing a remote > > > > object. > > > > > > > >> > > > > > > > >> Please remember that I consider this very > > > obvious, but I don't > > > > > > think > > > > > > > >> we > > > > > > > >> agree on it: I think if we did your comments would > > > make sense to > > > > > > > >> me, and so > > > > > > > >> far they don't. Saying something like "don't be > > > obvious" will > > > > > > > >> indicate to > > > > > > > >> me that you are not interested in discussing this aspect of > > > > jboss > > > > > > > >> architecture with me, so I will take your > > > recommendation and > > > > stop > > > > > > > >> working > > > > > > > >> with interceptors, at least until my curiousity > > > gets the better > > > > of > > > > > > my > > > > > > > >> sense. > > > > > > > >> > > > > > > > >> david > > > > > > > >> > > > > > > > >> > > > > > > > >> ------------------------------------------------------- > > > > > > > >> 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------- > > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------- > > > > > > 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 > > > > > > > > > > > > > > > > ------------------------------------------------------- > > > > 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 > > > > > > > > > > > ------------------------------------------------------- > > 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 > ------------------------------------------------------- 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
