You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Berin Loritsch <bl...@apache.org> on 2003/03/05 15:43:17 UTC
Presenting the Proxy Based DataSource
Please cross check this version of the Excalibur DataSource, and see
if it works just as well as the old version. If so, I will commit
my changes and we will all be happier.
Of particular interest:
This was compiled on JDK 1.4, please make sure it works with JDK 1.3.
I want to get away from the need to work around the two jars depending
on JDBC 2.0/3.0 version.
Re: Presenting the Proxy Based DataSource
Posted by Torsten Curdt <tc...@dff.st>.
>> The ESQL logicsheet could easily be altered (invisibly to the user)
>> so that calls to Connection are using the Connection object and calls
>> to the new methods are using the holder class.
>
>
> True.
>
> I'll have a look..
Will do this ASAP
--
Torsten
Re: Presenting the Proxy Based DataSource
Posted by Torsten Curdt <tc...@dff.st>.
>> ...you mean the EsqlConnection should not implement Connection?
>
> Shocking isn't it?
=8-O yes! :)
> And what new methods should it use?
I don't have the slightest idea :)
> The ESQL logicsheet could easily be altered (invisibly to the user)
> so that calls to Connection are using the Connection object and calls
> to the new methods are using the holder class.
True.
I'll have a look..
--
Torsten
Re: Presenting the Proxy Based DataSource
Posted by Berin Loritsch <bl...@apache.org>.
Torsten Curdt wrote:
> Berin Loritsch wrote:
>
>> Sylvain Wallez wrote:
>>
>>> Berin Loritsch wrote:
>>>
>>> So it seems to me that a simple way to avoid this JDBC mess (at least
>>> in Cocoon) would be for ESQLConnection to _hold_ a Connection instead
>>> of _extending_ it.
>
>
> ...you mean the EsqlConnection should not implement Connection?
Shocking isn't it? EsqlConnection is not *changing* functionality of
the Connection. It is cleaner and easier to maintain if you
hold a reference to the Connection instead of going through the added
complexity of conditional compilation when there is no real benefit
derived from it.
>> For ESQLConnection, definitely.
>
>
> Well, as long as the logicsheet only wants to use the methods from
> the old Connection interface this is true.
And what new methods should it use?
The ESQL logicsheet could easily be altered (invisibly to the user)
so that calls to Connection are using the Connection object and calls
to the new methods are using the holder class.
Re: Presenting the Proxy Based DataSource
Posted by Torsten Curdt <tc...@dff.st>.
Berin Loritsch wrote:
> Sylvain Wallez wrote:
>
>> Berin Loritsch wrote:
>>
>> So it seems to me that a simple way to avoid this JDBC mess (at least
>> in Cocoon) would be for ESQLConnection to _hold_ a Connection instead
>> of _extending_ it.
...you mean the EsqlConnection should not implement Connection?
> For ESQLConnection, definitely.
Well, as long as the logicsheet only wants to use the methods from
the old Connection interface this is true.
--
Torsten
Re: Presenting the Proxy Based DataSource
Posted by Berin Loritsch <bl...@apache.org>.
Sylvain Wallez wrote:
> Berin Loritsch wrote:
>
>> Sylvain Wallez wrote:
>>
>>> Berin Loritsch wrote:
>>>
>>> So it seems to me that a simple way to avoid this JDBC mess (at least
>>> in Cocoon) would be for ESQLConnection to _hold_ a Connection instead
>>> of _extending_ it.
>>
>>
>>
>> For ESQLConnection, definitely. For Excalibur DataSource, it extends
>> the close() and isClosed() methods to provide pooling. Any other
>> methods that we extend are taken care of in the proxy object so we can
>> still work with JDK 1.3 and JDK 1.4. At least that is the theory.
>
>
>
> Since close() and isClosed() are JDBC2, maybe compiling the full JDBC3
> version with JDK 1.4 and use it with JDK 1.3 may work ?
As I mentioned before, we have already done that. For some reason,
Cocoon complained about invalid clss files and such.
Can you confirm if my changes work on JDK 1.3? I think it is the
cleanest solution and allows people with JDK 1.3 to build the library
and it will still work with JDK 1.4.
Cocoon is the problem application for this package, which is why I
wanted you guys to verify it.
Re: Presenting the Proxy Based DataSource
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Berin Loritsch wrote:
> Sylvain Wallez wrote:
>
>> Berin Loritsch wrote:
>>
>> So it seems to me that a simple way to avoid this JDBC mess (at least
>> in Cocoon) would be for ESQLConnection to _hold_ a Connection instead
>> of _extending_ it.
>
>
> For ESQLConnection, definitely. For Excalibur DataSource, it extends
> the close() and isClosed() methods to provide pooling. Any other
> methods that we extend are taken care of in the proxy object so we can
> still work with JDK 1.3 and JDK 1.4. At least that is the theory.
Since close() and isClosed() are JDBC2, maybe compiling the full JDBC3
version with JDK 1.4 and use it with JDK 1.3 may work ?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Presenting the Proxy Based DataSource
Posted by Berin Loritsch <bl...@apache.org>.
Sylvain Wallez wrote:
> Berin Loritsch wrote:
>
> So it seems to me that a simple way to avoid this JDBC mess (at least in
> Cocoon) would be for ESQLConnection to _hold_ a Connection instead of
> _extending_ it.
For ESQLConnection, definitely. For Excalibur DataSource, it extends
the close() and isClosed() methods to provide pooling. Any other
methods that we extend are taken care of in the proxy object so we can
still work with JDK 1.3 and JDK 1.4. At least that is the theory.
Can someone verify the new DataSource (as I compiled it) works
on JDK 1.3 for them?
Re: Presenting the Proxy Based DataSource
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Berin Loritsch wrote:
> Sylvain Wallez wrote:
>
>> Berin Loritsch wrote:
>>
>>> Please cross check this version of the Excalibur DataSource, and see
>>> if it works just as well as the old version. If so, I will commit
>>> my changes and we will all be happier.
>>>
>>> Of particular interest:
>>>
>>> This was compiled on JDK 1.4, please make sure it works with JDK 1.3.
>>>
>>> I want to get away from the need to work around the two jars depending
>>> on JDBC 2.0/3.0 version.
>>
>>
>>
>>
>> Just some thoughts : AFAIK, we need JDBC wrappers to redefine methods
>> that are common to both JDBC 2 and 3, and we left untouched JDBC 3
>> method.
>>
>> So, can't a simple solution be an abstract JDBC wrapper that
>> implements all of JDBC3 and which is required (through its build.xml)
>> to be compiled with a JDK 1.4 ?
>>
>> A JDK 1.3 should not complain about unkown methods as long as they're
>> not used, allowing us to write concrete wrappers that would work
>> equally well in 1.3 and 1.4.
>
>
> That's what we tried to do, and it did not work.
>
> What methods actually have to be overridden?
Well, having looked closer at ESQLConnection, it seems that we wrap *no*
method of java.sql.Connection, but only *add* some.
So it seems to me that a simple way to avoid this JDBC mess (at least in
Cocoon) would be for ESQLConnection to _hold_ a Connection instead of
_extending_ it.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Presenting the Proxy Based DataSource
Posted by Berin Loritsch <bl...@apache.org>.
Sylvain Wallez wrote:
> Berin Loritsch wrote:
>
>> Please cross check this version of the Excalibur DataSource, and see
>> if it works just as well as the old version. If so, I will commit
>> my changes and we will all be happier.
>>
>> Of particular interest:
>>
>> This was compiled on JDK 1.4, please make sure it works with JDK 1.3.
>>
>> I want to get away from the need to work around the two jars depending
>> on JDBC 2.0/3.0 version.
>
>
>
> Just some thoughts : AFAIK, we need JDBC wrappers to redefine methods
> that are common to both JDBC 2 and 3, and we left untouched JDBC 3 method.
>
> So, can't a simple solution be an abstract JDBC wrapper that implements
> all of JDBC3 and which is required (through its build.xml) to be
> compiled with a JDK 1.4 ?
>
> A JDK 1.3 should not complain about unkown methods as long as they're
> not used, allowing us to write concrete wrappers that would work equally
> well in 1.3 and 1.4.
That's what we tried to do, and it did not work.
What methods actually have to be overridden?
Re: Presenting the Proxy Based DataSource
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Berin Loritsch wrote:
> Please cross check this version of the Excalibur DataSource, and see
> if it works just as well as the old version. If so, I will commit
> my changes and we will all be happier.
>
> Of particular interest:
>
> This was compiled on JDK 1.4, please make sure it works with JDK 1.3.
>
> I want to get away from the need to work around the two jars depending
> on JDBC 2.0/3.0 version.
Just some thoughts : AFAIK, we need JDBC wrappers to redefine methods
that are common to both JDBC 2 and 3, and we left untouched JDBC 3 method.
So, can't a simple solution be an abstract JDBC wrapper that implements
all of JDBC3 and which is required (through its build.xml) to be
compiled with a JDK 1.4 ?
A JDK 1.3 should not complain about unkown methods as long as they're
not used, allowing us to write concrete wrappers that would work equally
well in 1.3 and 1.4.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }