Hi Nick, > -----Original Message----- > From: Nicholas Lesiecki [mailto:[EMAIL PROTECTED] > Sent: 31 December 2003 06:36 > To: Cactus Developers List > Subject: Re: [Vote/Action plan/Feedback] Cactus2 > > Sorry it's taken me so long to respond to your excellent proposal Vincent, > the holidays have been very busy for me. > > On 12/24/03 4:21 AM, "Vincent Massol" <[EMAIL PROTECTED]> wrote: > > > Hi cactus committers, > > > > As every day goes by, I am more and more excited about Cactus v2 (see > > http://blogs.codehaus.org/people/vmassol/archives/000520_cactus_v2_archi > > tecture_proposal.html). I'd like to start pumping some cactus v2 code. > > > > Before going on, I'd like to know what you think about Cactus v2 and to > > decide on how we progress. I believe we have several options: > > > > 1/ create a jakarta-cactus/sandbox/cactus2 directory and write cactus v2 > > code in there > > 2/ request the creation of a jakarta-cactus2 CVS module (It will still > > be under the umbrella of the Cactus project - it's not the creation of a > > new project). > > I think I prefer solution 2 as well--if only because it would be nice to > work in a clean area without all of the Cactus1 baggage.
I agree but Chris doesn�t and as I'm interested in making progress than in the form, I'll commit something in jakarta-cactus/scratchpad/cactus2 as soon as I have something decent to show (say in 1-2 week's time). > > > > I personally much prefer solution 2/ as it is cleaner (and it works > > better with Eclipse projects too). > > > > We have also the option to request the creation of a > > [EMAIL PROTECTED] mailing list. If not, then all traffic > > will go to the existing cactus-dev ML. I also prefer to request the > > creation of such a list. > > Nah, let's keep the discussion here as Chris suggests. ok > > > > I'm also curious to know how many of you are interested in participating > > to Cactus 2 (or is it too early at this stage for you to know)? I've > > been talking to Jonas Boner (AspectWerkz author) and Chad Woolley > > (VirtualMock author) and I'd like to invite them to participate to the > > Cactus2 project if they're interested (it will be easier to do if we > > have separate jakarta-cactus2 CVS module I think). > > More interested than I am in participating in Cactus1--if only because > there's more work/more fundamental work to do on Cactus2. However, my > limiting factor (as always) is time. I find it extremely hard to scare up > the 6 hours it takes to get some momentum behind Cactus development. > (Perhaps a minor goal for Cactus2 could be a lighter-weight build > process?) I'd like to use Maven and I believe the build will *much* lighter as a consequence. > Still, there's always room for someone to write docs and provide > thought... yep > I've been talking to VMS (my company) about donating some time to the > Cactus > project, perhaps that will help. Cool! Congrats for your new job at VMS! :-) > > On the subject of new team members. I think Chad would be an excellent > addition to the Cactus team. He has intelligence, a passion for the > subject, > and way more time than I do :) I recommend him highly. > > If Chad should join VMS (a subject currently under discussion), we could > actually have a live pair on the Cactus project. That would be cool. Hey, very cool! > > As for Jonas, his creation of AW is credentials enough for me. If he does > join, we are likely to get AW tailored to our needs which is great. > > > > > > Anyway, I'm interested in any feedback you have! > > As for the proposal itself, I have 3 areas of feedback. > > 1) AW vs. AJ > > I think I prefer the stability and maturity of AspectJ, but I understand > that it requires more tool support. > > One question I have, how well do AspectJ and AspectWerkz play together? I don�t know. Haven't tried. > Personally, I am planning on integrating AspectJ into our production > system > in the near future. I would hate to be shut out of Cactus2 because of that > decision. I agree that whatever internal fwk we use must be as transparent as possible for Cactus end users. > (I'm not convinced that AspectWerkz is mature enough to use in > production.) I would actually cite AspectJ's tool support (crosscut > browsing, for instance) as a bonus for users committed to the idea of AOP. > The only users I would worry about would be those who did not wish to do > AOP > except for Cactus. Yes and there are a lot (about 99.99999% for the moment :-)). > > We could consider a dual implementation approach (AspectWerkz and AspectJ) > as Chad Wooley did for EasyMock. This could be a lot of trouble, but might > be manageable if we delegate a lot of the actual code to POJO's. I'd like to start by doing simple things first. The first goal I have in mind is to see if we can expose the AW API directly to the test case writer. If it's too complex, there are 2 possibilities: - convince the AW team to improve AW to make it more user-friendly - provide some helper aspects/classes for Cactus end users I'd rather not hide the underlying aspect fwk with a completely new API. I can see drawbacks with this approach: - you don�t get the full power of the aspect fwk (least common denominator) - you don't benefit from any new feature (you'll need to explicitely add support for it) - a new "language" to learn for end users (there's a better probability they'll know about the underlying fwk) - doc to write - testing to add - lots of support to do, whereas by using directly AW for example, if there's a question related to AW you can redirect the user to the AW forums/lists/docs/etc. In any case, I'd like to start simple and see what happens. It may happen that the outcome is that we absolutely need this fa�ade API. But I'd like to try without one to start with... > > 2) I'm not sure I like the idea of forcing the user to call their > component > externally using HTTPUnit or another tool. Most of the time that I use > Cactus nowadays, I simply need to be in the container. I use > ServletTestCase > merely because it is legal to instantiate local EJBs and call their > methods > within the container. I believe Chris reported a similar usage pattern. > The > ease of Cactus is in not needing to go through all the trouble of > stimulating the code as if a client had done it. For testing actual HTTP > protocol behavior this idea could be good. However, for testing EJBs I see > less purpose. I don�t think using HTTPUnit is radically more complex that using current Cactus API: WebConversation conversation = new WebConversation(); WebRequest request = new GetMethodWebRequest( "http://localhost:8080/test/SampleServlet?param1=value1¶m2=value2";); Versus WebRequest.addParameter("param1", "value1"); WebRequest.addParameter("param2", "value2"); + configuration However, what we could always do is provide a helper class so that you would write: WebConnection connection = new WebConnection(); connection.addParameter("param1", "value1"); connection.addParameter("param2", "value2"); connection.connect(); or something similar. But what I am very convinced about is that this should NOT be hardcoded into the core Cactus framework. I'm ok to add it to the servlet layer on top of the core which would provide some easier way to write test cases for servlets/filters/jsp/etc, but not to the generic code layer. > > 3) Obviously, bringing in Aspects opens up whole new realms of unit > testing > possibilities. Yes. It opens up server-side expectations for example, which is very exciting. For me, this expectation stuff is the reunification of Cactus + Pattern Testing (http://patterntesting.sourceforge.net/). > The question is, what will Cactus contribute on top of > those? It'll contribute several things: - ability to continue a test started on the client side to the server side - ability to get test result back to the client side - end to end test automation through the use of the Cactus front ends - helper classes/aspects for even easier testing of specific technologies: for example servlets (and extensions: Filters, Jsp, Taglibs). - docs > Will we have our own mocking framework that uses AOP? I don�t see the need. We can integrate with any existing mocking framework, be it EasyMock/DynaMock/JMock or VirtualMock. > > > I haven't yet fully thought through this feedback, but I preferred getting > it out tonight to polishing my response. Cool. Keep the questions/feedback/ideas comings! :-) Thanks -Vincent > > Cheers, > Nick > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
