Hi Chris, > -----Original Message----- > From: Christopher Lenz [mailto:[EMAIL PROTECTED] > Sent: 30 November 2003 13:16 > To: Cactus Developers List > Subject: Re: [proposal] Cactus new vision (2) > > Vincent Massol wrote: > > Ok, here's the vision proposal for the Cactus architecture and how users > > would be able to use it: > > > > http://cvs.apache.org/~vmassol/cactus_new/archi_users.jpg > > > > Nothing revolutionary but it better shows the extensibility and the > > willingness to open up cactus to other protocols and other proxies (for > > lack of a better word - feel free to suggest name ideas). > > > > Comments? > > My concern with this proposal is that we might be introducing additional > abstraction layers without really having thought/discussed about the > requirements of the "other" parts in the diagram (or have we?).
There has been several discussion/experimentations in the past on these "other" parts: - MDB testing (JMS protocol) - EJB testing (RMI protocol) > > Currently, Cactus is a rather lightweight package focussed on doing one > particular thing: getting into a web container for unit-testing > web-components. This also allows users to get into the J2EE container > for testing non-web-components such as EJBs. Yes and no. Yes, you're right about the current status. However, Cactus has always been from day one when it was named J2EEUnit a "framework for unit testing server-side java classes". > There has been some > experimentation for getting directly to the EJBs over RMI and such, but > no such code has been committed to the repo, and I've personally never > seen it. There are some code in CVS for the JMS part (on a 1.4 jms branch) and there were 2 submissions for the EJB redirector which never got committed because it was not matching exactly CVS head and it was too much work for me to merge (it would have been easier to simply rewrite it). > > I'd really like to see some discussion on how the SPIs might look before > taking any concrete actions. I also would prefer to see an > implementation other than the current HTTP/Servlet one, so that we have > a better idea of what the requirements for the SPIs will be. It usually > takes some working code and experience in at least two "extensions" > before effective abstract interfaces can be extracted for generic > extensibility. I agree. What I'm setting with this email is simply the high level architecture, not the implementation details, which is the next step I was about to do. The next step is to start separating what we *believe* is SPI from what is core. I doesn't have to be right the first time. It's a *first* definition of the SPI. Then we (or someone else) can start implementing a second protocol/broker and we can refine the SPI. This is what you did with the Ant task AFAICT. You've created a Java API with only one user, the Ant task. Now we're going to start using with from the Eclipse plugin and it will need to be tuned. This is fine. > > Further, I am afraid that the framework code common to all of the target > environments might be too thin. Maybe the common core is more of a > *pattern* than something that can effectively put into a API/SPI > framework. Yep, this is very possible. But there's only one way to discover... And there'll still be helper classes and things common even if thin. > > To summarize, I think it's premature to make this strategy "official", > because we (or at least I) don't have enough experience with integrating > different protocol/broker types with Cactus. Before we abstract, we > should have something that needs to abstracted, and the abstraction > needs to provide a real-world benefit. The real world benefit that I see is to get contributions to Cactus by others. There are several power-users who have been keen to improve cactus in the past (they even tried - several EJB redirectors, even someone who also wanted to continue the JMS redirectory) but it was too complex and not easily pluggable. By explaining what the SPI is, how it works and how people can write extensions, I'd like to open up Cactus and get more participation. I really believe we need to inject some fresh blood in cactus. > > Cheers, > -chris > > PS: For me, Cactus is just a great tool to perform unit tests inside a > web container, i.e. most of the time I only use it to test > servlet/taglib/struts stuff. So /my/ "vision" for Cactus is simply to > make that as easy and painless as possible :-) That's cool and I agree that whatever we do should not prevent this vision. I'd just like to augment the vision. Thanks for the feedback Chris. Useful as always. My next action is to try to define the SPI. I'll send another diagram for that. Thanks -Vincent --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
