cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Re: [C2] DataSourcese Proposal (first draft)
Date Tue, 09 Jan 2001 13:42:32 GMT
Giacomo Pati wrote:

> Berin Loritsch wrote:
> 
>> I added the code for a robust JdbcDataSources Proposal.
>> Please cross-check and pound on it.  The second phase
>> (J2eeDataSource) will be much simpler because we are
>> relying on the J2EE Container to implement the pooling.
> 
> 
> I'll test it out tomorrow. You'll get feedback (probabbly as CVS Update
> mails :)

Kool Beans!  Please note, you can still use the archaic
methodology of specifying the connection parameters and
creating a new Connection object for EACH request.  Or
you can use the high powered pooled DataSources and keep
the configurations for the entire site in one location!

As a side note, I found that the SQLTransformer sample
in CVS used and closed no fewer than 11 connections--
no wonder it's performance lagged behind esql logicsheet!
Can the maintainer of the SQLTransformer work on getting
that down to one per connection actually needed?


>> If you have any questions as to its use, feel free to
>> ask--although it should be pretty clear.
> 
> 
> I've just seen you don't use defaults on the
> conf.getChild("user").getValue() which will throw a
> ConfigurationException. But your further code allows that for
> user/pasword encoded in the dburl, right?

Actually, as a result of synching up with Avalon
code, and Avalon started throwing ConfigurationExceptions
when an element did not exist, I asked for a feature
enhancement.  Basically, when you ask for a child
configuration object that is not defined in the file,
the parent creates an empty child element--with a null
value.

Also, the AbstractConfiguration has been updated to
eliminate NullPointerExceptions escaping from the
get[Value|Attribute]As[Boolean|Int|Long|Float|Double]();
calls.


Mime
View raw message