db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@debrunners.com>
Subject Re: Modular build, was: VOTE: Approach for sharing code
Date Wed, 14 Sep 2005 18:52:57 GMT
Kathy Saunders wrote:


> 
> Thank you very much for the clear explanation.  From a usability
> perspective, I would vote for approach 2.  Requiring a classpath to be
> in a particular order is always an issue.  However, the saving grace is
> that it sounds like the ordering issue only comes up if you mix versions
> of the derby.jar and the derbyclient.jar in the same classpath.  I don't
> believe most users put the client and engine in the same classpath
> (unless there's a new requirement I don't know about), so that
> definitely helps.  Requiring classpath in a specific order can easily
> lead to complications though, so I'm not in favor of it in general.

Derby's client and engine may be in the same classpath and at different
versions if the JVM is hosting more than one application, or the
application installers have modified the system/user's classpath to add
their required jars.

The issue is that today this is fully supported because the client and
engine do not share code.

Some of the code sharing approaches regress Derby in this area by not
supporting this, or require class path ordering for it to be supported.

While it is true that multiple class loaders solve the issue, this
approach is not always possible, I believe, for example, some of the
major application servers do not support different class loaders for
different JDBC providers (eg. the Derby client at 10.3 and engine and 10.2).

Thus the argument really is, are we willing to accept regression in this
area to gain code sharing, or should the code sharing solution not
regress Derby?

Dan.



Mime
View raw message