Return-Path: Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 54830 invoked from network); 18 Jan 2001 01:55:30 -0000 Received: from mail.alphalink.com.au (203.24.205.7) by h31.sny.collab.net with SMTP; 18 Jan 2001 01:55:30 -0000 Received: from donalgar (d225-ps1-mel.alphalink.com.au [202.161.106.99]) by mail.alphalink.com.au (8.9.3/8.9.3) with SMTP id MAA28128; Thu, 18 Jan 2001 12:55:33 +1100 Message-Id: <3.0.6.32.20010118115621.00ac8d10@alphalink.com.au> X-Sender: gdonald@alphalink.com.au X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Thu, 18 Jan 2001 11:56:21 +1100 To: "Java Apache Framework" From: Peter Donald Subject: Re: Proposal Migrating DataSourceComponent to Avalon Cc: cocoon-dev@xml.apache.org, Java Apache Framework In-Reply-To: <3A660AD4.5050208@apache.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N At 04:12 17/1/01 -0500, Berin Loritsch wrote: >I have been thinking, that the DataSourceComponent I developed >for Cocoon 2 is general enough to include in Avalon. For Cocoon, >it only means a package change--for Avalon it means that it now >has a standardized method of accessing DataSources. > >I think it can be a win-win situation in the long run as projects >like my DataXfer project (which I am determined to resurrect :P), >EAS (a new open source Enterprise Application Server project), JAMES, >and others adopt and use it. The pooling code will be made more >robust as it will be used by a much wider audience, and possibly >more flexible. (how about performing SQL queries on a delimited >text file or XML files?). The possibilities stagger the imagination. > >Of course I could be blowing wind... > >I am posting this message two both lists as it affects both >projects if I get sufficient +1s from both camps. Well I just looked at it and I like. There is one issue I can think of though. Namely there is nothing inside Avalon that directly *uses* the code. Consequently it may be possible to accidentally break it in Avalon without realizing. I guess there are two solutions really - you could write a Unit test for it ;) (yay!) or we could create yet another test block that uses it and run it through a functional test. Even if neither of those things happen I am still +1 on the idea ;) Cheers, Pete *-----------------------------------------------------* | "Faced with the choice between changing one's mind, | | and proving that there is no need to do so - almost | | everyone gets busy on the proof." | | - John Kenneth Galbraith | *-----------------------------------------------------*