db-derby-dev mailing list archives

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

>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.
>
>
>
>
>
>
>  
>
I don't think we should regress and I don't think we should have 
classpath ordering issues (sorry if my rambling mail last time was 
misleading).  I think that means I would vote for option 2 if we proceed 
with code sharing which means no change from a customer 
perspective--same number of jars and no ordering issues.


Mime
View raw message