Jon Stevens wrote:
> on 2/15/01 2:19 PM, "Craig R. McClanahan" <[EMAIL PROTECTED]>
> wrote:
>
> > Turbine's pool (still) does not do
> > this -- and that makes perfect sense, because it existed before the DataSource
> > API was standardized. Changing Turbine's pool to conform to this would break
> > the contracts for all existing Turbine apps that use it, which would not be a
> > Good Thing.
>
> I'm not sure that statement is true because...I have implemented all of the
> JDBC 2.0 API for Turbine except that single one. It didn't break any
> existing code to do so (except in one case where you now need to deal with a
> SQLException that is now being thrown in the API and wasn't before...not a
> big deal).
>
The one you haven't gotten to yet is the critical one that makes application code
portable. You will find that it is quite a bit more significant a change to
existing APIs than the ones you did.
The typical application usage pattern of a DataSource goes like this:
// Acquire a reference to the pool (typically from a JNDI
// context provided by the app server, or a servlet context
// attribute)
javax.sql.DataSource ds = ... acquire a reference ...
// Acquire a connection from the pool
javax.sql.Connection conn = ds.getConnection();
// Do your thing with the returned connection
Statement stmt = conn.createStatement("...");
stmt.execute();
// Return the connection to the pool
conn.close();
Note this last -- as far as the application is concerned, they are closing a JDBC
connection, but since the "Connection" was really provided by the pool, the
underlying real connection is *not* closed; it is simply returned to the pool.
Making org.apache.turbine.util.db.pool work like this (i.e. implement
java.sql.Connection) is certainly possible, but breaks the existing contract for
what DBConnection.close() does, among others. If that is OK, you're pretty much
reingineering the whole thing. If not, wrappers are the way to go.
>
> I didn't realize that I also needed to implement the DataSource interface,
> now that I do, I will go make it happen.
>
> At that point, will you use it Craig?
>
I will certainly document it as an available option -- assuming that the changes
were complete, using this connection pool in a Struts app would be as simple as the
following in the app config file:
<struts-config>
...
<data-sources>
<data-source type="org.apache.turbine.util.db.pool.ConnectionPool"
loginTimeout="30"
driver="org.postgresql.Driver"
maxCount="4"
url="jdbc:postgresql://localhost/mydatabase"
username="myusername"
password="mypassword"
/>
</data-sources>
...
</struts-config>
(assuming a few more property setters on ConnectionPool to set the rest of the
configuration properties).
However, I would not recommend it ... the turbine-pool.jar file drags along ~40
classes of Turbine infrastructure that aren't useful unless you are running inside
Turbine.
Of course, no third part connection pool at all is needed if your app server
provides one for you. And, as long as the server obeys the conventions described in
the servlet and J2EE specs w.r.t. <resource-ref> entries and the corresponding JNDI
context provided by the server (which is in the near-term plans for Tomcat 4 as
well, with plug-in of any conforming data source), the app doesn't care. It's
portable, instead of locked in to a particular implementation.
>
> I doubt it because you are so head strong in re-inventing everything that
> Turbine has done.
>
> I guess my main point here is that I really think it is messed up to simply
> say that you won't use something because it doesn't implement some Sun
> interface.
>
> The fact of the matter here is that in this case, you NEED an implementation
> of a database pool regardless of what interface that it implements. By
> saying that you would like to plug other pools into the back end is a
> separate issue entirely.
>
> On top of it, it took me all of 30 minutes to implement the majority of the
> interfaces in Turbine's pool. You are a better engineer than I (remember,
> according to some people, I only write crappy spaghetti code)...so I bet you
> could have done it in 15 minutes.
>
It's actually been quite a few more hours than that writing the wrappers for you so
far. But, if you're going to do it, I won't bother to finish.
>
> p.s. I spent some time reviewing Struts recently and it is absolutely
> hilarious how much of it clearly has been "borrowed" from Turbine...all the
> way down to the idea of "Actions" for the C portion of MVC. Struts is
> clearly Craig's refusal to work with the Turbine project which is clearly
> contrary to what he had originally stated when he proposed the project.
>
Turbine is a fine project, with a good group of developers and a solid base of
functionality. That's not my problem.
I just don't want to work with you (and the attitudes you carry) on Turbine. If you
wonder why, go read your "signature" quote again.
>
> -jon
>
> --
> If you come from a Perl or PHP background, JSP is a way to take
> your pain to new levels. --Anonymous
> <http://jakarta.apache.org/velocity/> && <http://java.apache.org/turbine/>
>
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
