jakarta-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Morgan Delagrange <mdela...@yahoo.com>
Subject RE: What is Jakarta?
Date Wed, 07 Feb 2001 18:56:49 GMT
I'm probably going to get flamed for this, but so be

If you don't have a common utility library, you're
virtually guaranteed that an environment deploying
multiple Jakarta projects will be configuration-rich.

To use the example of the day, I'd venture to say that
we don't have a good entry-level database pool that
one can just deploy in an arbitrary environment.  To
illustrate this point, go to Struts and find their
database pooling framework.  Or go to Turbine and find
theirs (a little easier).  Not as easy to find as you
thought, was it?  From their home pages, you wouldn't
even know that they featured database pooling.  In
both cases, JDBC pooling is mentioned in a one-off
page.  And in both cases it's not clear that it is a
stable library intended for generic use, rather than a
library specific to the task.

What we need is a utility subproject with a clear list
of sub-subprojects on the home page (a la Taglibs), so
developers can go to the site and quickly find the
feature they're looking for.

In the case of database pooling, let's either take
Turbine's database pooling or Rod's variant of the
Struts pooling
I can promote this database pooling framework, because
I use a version of it on a regular basis and it is
quite nice.) and run with it.

To Steve's point, it is important to keep your project
moving forward even if the utility project is lagging
behind.  Specifically, even if you use a generic
utility library, you should _still_ encapsulate it in
your own API rather than thread calls to it throughout
your product.

Database pooling is particularly easy to encapsulate. 
Make sure all your code obtains connections from the
same class, and you can easily alter that class to use
a new pooling mechanism if you have to.  I'm a fan of
pooling pseudo-drivers, because they're very
lightweight and network-efficient and don't require
custom code in the product itself.

- Morgan

--- Steve Downey <steve.downey@netfolio.com> wrote:
> The biggest problem with utility libraries is the
> release cycle and interim
> stability. What has inevetibly happend on projects
> I've been on is that
> project A  needs something fixed in the Foobar
> package. But they also depend
> on the current behavior of the Framis class. The
> current Framis class is,
> however, undergoing refactoring, and the next
> release, that will include the
> fixes they need in Foobar, will break Project A's
> app.
> The only good cases of this kind of thing are stuff
> that is _extremely_
> stable out of the box. The equivalent of libc, or
> rt.jar. With _long_
> release cycles.
> Otherwise you couple the release cycles of unrelated
> systems in pathological
> ways. 
> Or projects clone the code and hide it.
> -----Original Message-----
> From: Geir Magnusson Jr.
> [mailto:geirm@optonline.net]
> Sent: Wednesday, February 07, 2001 8:54 AM
> To: general@jakarta.apache.org
> Subject: Re: What is Jakarta?
> Ted Husted wrote:
> > 
> > On 2/7/2001 at 12:09 AM Geir Magnusson Jr. wrote:
> > > That's exactly what I am trying to say. I know I
> can't propose.
> > 
> > You or I can't call for a vote of the PMC * on * a
> proposal, but
> > absolutely anyone can submit a proposal for a
> subproject.
> Ok.  I read it that one of the duties of the PMC
> membership was to
> propose new projects.  My approach was to badger and
> lobby Jon and Craig
> (two PMC members that I have interacted with on
> other issues).
> > As David Weinrich mentioned, a good place to start
> is any package named
> > "util" in any of the Jakarta or Apache products.
> This could generate a
> > list of candidates, leading to a package
> heirarchy. The committers on
> > existing subprojects could be polled to see if
> anyone is interested in
> > creating and mainitaining such a set of Platform
> Tools. If so, the
> > proposal could then put this together and outline
> what might be in the
> > first release of the product, and who would be
> doing the work.
> Cool. 
> I am usually of the 'start small and iterate'
> mindset, so I would think
> a really good connection pool would be an
> *excellent* start.  Choose
> another tool as well so that the notion of the
> project as a multi-tool
> kit can be established from the beginning (ex.
> documentation and a
> multi-jar distribution), but keep the deliverables
> list small, to what
> people are making noise about.
> <noise>
> Connection pool, connection pool, connection pool.
> </noise>
> geir
> -- 
> Geir Magnusson Jr.                              
> geirm@optonline.com
> Velocity : it's not just a good idea. It should be
> the law.
> http://jakarta.apache.org/velocity
> To unsubscribe, e-mail:
> general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> general-help@jakarta.apache.org
> <><><><><><><><><><><><><><><><><><><><><>This
> electronic mail transmission
> may contain confidential information and is intended
> only for the person(s)
> named.  Any use, copying or disclosure by any other
> person is strictly
> prohibited.  If you have received this transmission
> in error, please notify
> the sender via e-mail.
> <><><><><><><><><><><><><><><><><><><><><>
> To unsubscribe, e-mail:
> general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:

Morgan Delagrange

Do You Yahoo!?
Yahoo! Auctions - Buy the things you want at great prices.

View raw message