Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@apache.org Received: (qmail 74190 invoked from network); 4 Feb 2002 11:44:43 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 4 Feb 2002 11:44:43 -0000 Received: (qmail 9950 invoked by uid 97); 4 Feb 2002 11:44:38 -0000 Delivered-To: qmlist-jakarta-archive-commons-dev@jakarta.apache.org Received: (qmail 9934 invoked by uid 97); 4 Feb 2002 11:44:38 -0000 Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Jakarta Commons Developers List" Reply-To: "Jakarta Commons Developers List" Delivered-To: mailing list commons-dev@jakarta.apache.org Received: (qmail 9923 invoked from network); 4 Feb 2002 11:44:38 -0000 Reply-To: From: "Paulo Gaspar" To: "Jakarta Commons Developers List" , Subject: RE: [Logging] [VOTE] Commons Logging 1.0 Release Date: Mon, 4 Feb 2002 13:00:53 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <001001c1ad33$baf880f0$0100a8c0@realpulse.com> X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Aaron, you just touched on what is the usefulness of the commons. The idea is that the Tomcat team and other teams with _common_ use code can drop such _common_ use components here, and hence the _commons_ name. Of course that dropping such components here also means making them usable without depending on the mother project. Have fun, Paulo > -----Original Message----- > From: Aaron Smuts [mailto:aaron.smuts3@verizon.net] > Sent: Monday, February 04, 2002 5:24 AM > To: 'Jakarta Commons Developers List' > Subject: RE: [Logging] [VOTE] Commons Logging 1.0 Release > > > It doesn't sound like there is a clear dependency chain among the > projects. > > In JCS I've had a hell of a time trying to use utilities from Tomcat, > since they seem to move around. Maybe I just shouldn't have been using > them. Outside of Jakarta this would be fine, since I can control the > release version of 3rd party libraries, but inside it is more difficult. > > This is a difficult problem. You seem to have to stick to a project's > high level API or intended usage. I can use Tomcat as a servlet engine, > but not as a source of thread pool utility classes. > > When trying to use utilities, say the log4j configuration code or the > Tomcat thread pool, you have to pretty much copy and modify the code > (making appropriate citations to the source) and go on. I'm not sure > how to solve this. In my own projects I define a dependency hierarchy > and make sure that no one violates the chain. If commons becomes the > base then it will probably end up bloating and being filled with > redundant code and version with number in the names of classes . . . > Every committer will need commons commit access so they can keep all > their utilities that might be attractive to another project accessible > and stable, or there will need to be a common acceptance to giving code > a new home (my technique) to reduce the dependency complexity. > > For instance: JCS has a great indexed disk storage system, but I > wouldn't try to use it outside of the JCS framework, since it is subject > to change, but it has a much broader utility. > > Many of the log4j appenders are like this. In JCS I used some of the > socket appender code for a TCP lateral cache. If they could be > abstracted out into commons utilities they would be very useful, but > this would require building with added flexibility and wrappers. . . . > > This is a tough problem. > > Cheers, > > Aaron > > > > -- > To unsubscribe, e-mail: For additional commands, e-mail: -- To unsubscribe, e-mail: For additional commands, e-mail: