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" <[EMAIL PROTECTED]> wrote: > With the recent discussions about tinderbox/CJAN and related stuff, I have > 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 some > 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 my >_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 compatibility >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 >based >applications). >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 - java.net.URL > >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 container's >built in facilities, which allow containers to implement things like distributed >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 toolkit. > >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 Yet >Another Connection Pool to add to the charming array of implementations >offered by Jakarta. ###
