struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ted Husted" <>
Subject Re: What is Jakarta?
Date Wed, 07 Feb 2001 12:50:12 GMT
There's been some talk on the General List about developing a Jakarta
connection pool product that other products could use as a utility.
Anyone interested in working on this should subscribe to the General
List to help determine the subproject's prospects.

Here's a recap.

On 1/31/01 8:53 PM, "David Weinrich" <> wrote:

> With the recent discussions about tinderbox/CJAN and related stuff, I
> started wondering about the cases where multiple jakarta projects
have areas
> of overlap/duplication. From digging into struts for a very short
time I
> notice that it also has a Database Connection Pooling component and
> string utilities ( I don't know if the string utilities are related
in any
> way to Avalon or Turbine ). That makes for three projects that
implement the
> same or very similar things.

On 2/1/2001 at 2:12 PM Sam Ruby wrote:

>I'm not sure why there isn't more reuse going on within Jakarta, but
>_theory_ is that the cost associated with versioning issues exceed the
>costs associated with dual maintenance.

On 2/1/2001 at 1:43 PM Craig R. McClanahan wrote:

>The issues that Sam raises (lack of attention to backwards
>of interfaces, plus arbitrary changes in current development with no
>consideration of the fact that other people are depending on interface

>stability) have bitten me
>every single time I've gotten involved in a "shared utilities" sort of
>environment.  IMHO there will not be any quality sharing of supposedly
>"reusable" code until:
>* People start designing code that is designed to be reused -- we
>  all have natural biases towards the original use for which we
>  scratched that itch in the first place, and tend to create either
explicit or
>  implcit dependencies on the remainder of the original project.
>* We find developers (for the "shared code" module) that are committed
>  to keeping the shared code stable, and to resolving the inevitable
>  disputes (I need StringUtils to do something this way; someone else
>  needs it to work that way).
>* The shared code base is around long enough to regain the confidence
>  of people like me that they can depend on it -- and not have to go
>  back
>  and retrofit every time someone else decides to tweak a shared class
>  in a manner that is not backwards compatible.

On 2/1/2001 at 5:54 PM Craig R. McClanahan wrote:

>The connection pool in Turbine does not implement the
>javax.sql.DataSource API
>(from the JDBC 2.0 standard extensions package), which makes it
>unsuitable for use
>in a J2EE environment (a very common deployment scenario for Struts

>In a J2EE app, the usual approach for acquiring resource instances
from an
>appropriate factory is to look up the factory instance in a
container-provided JNDI
>context.  The resource factory then returns an instance of the
appropriate class.
>To ensure portability, the APIs for common resource factories (and
therefore the
>resources that you can acquire from those factories) are standardized:
>* JDBC Connections - javax.sql.DataSource and
>* JMS Connections - javax.jms.QueueConnectionFactory
>  or javax.jms.TopicConnectionFactory
>* JavaMail connections - javax.mail.Session
>* URL connections -
>These requirements allow an application to be portable across
application servers --
>for example, to use whichever JDBC connection pool implementation is
provided by
>that container.
>Coding an app to the Turbine connection pool's API is certainly
feasible, and it
>will run in this kind of environment -- but you will not be using the
>built in facilities, which allow containers to implement things like
>transaction support, integrated authentication checking, and
everything else that is
>in the J2EE platform requirements.

On 2/2/2001 at 6:49 PM Jon Stevens wrote:
>I just *mostly* implemented the J2EE extensions for Turbine's
>Connection pool (the classes now at least implement the interfaces). 

On 2/7/2001 at 12:09 AM Geir Magnusson Jr. wrote:
>Not a library, or cache of code.  A 'product'.  Where there is
>dedication to the customers of that product, certainly the internal
>Jakarta projects, but also general users who just need a great
>Call it 'Jakarta Server Platform Tools' or something, and try to draft
>as committers interested people from the major internal consumers
>(Turbine, Struts, Jetspeed, Velocity)  It won't work if it produces
>Another Connection Pool to add to the charming array of
>offered by Jakarta.


View raw message