db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David W. Van Couvering" <David.Vancouver...@Sun.COM>
Subject Re: Modular build, was: VOTE: Approach for sharing code
Date Thu, 15 Sep 2005 21:13:55 GMT
On thinking further about this, I have a couple more questions/concerns

- I think Jeremy has a very good point that has not been directly 
answered.  If we do not allow potential compatibility issues by running 
multiple versions in the same VM, then doesn't that mean we are not 
going to be willing to incorporate third-party components like from 
Jakarta Commons?

I think this is a real problem, and I think a stance like this would not 
be looked upon positively from the rest of the Apache community.

- It seems to me that the environments in which mixed versions in the 
same VM occur are:

    * app servers, which already deal with this through multiple 

    * home-built servers in which case we can expect the user to be 
expert enough to know how to affect the order in which jars are loaded

- I agree with Jeremy that dealing with shared resources is a well-known 
problem and although mistakes can happen good app providers know how to 
deal with this.  Is it our responsibility to munge our code and paint 
ourselves into a corner regarding use of shared components to deal with 
app providers who don't know how to work with this?



Jeremy Boynes wrote:
> Daniel John Debrunner wrote:
>> Jeremy Boynes wrote:
>>> David W. Van Couvering wrote:
>>>> Can't you have the situation where common 10.2 and common 10.3 are
>>>> both included in the classpath (by accident, as Dan brings up)? 
>>>> Wouldn't you end up with order dependencies then?
>> I feel my scenario keeps being misrepresented by the choice of terms
>> used to decribe it. Using 'accident' makes it sounds as though it's not
>> an important problem to deal with, as seen in Jeremy's reponse here:
>>> To what extent do we need to cater for accidents?
>> The end user didn't accidently install two applications, they chose to
>> and didn't realise/know that one used client at version 10.2 and one
>> used engine at version 10.3. In many cases the use of Derby engine is
>> hidden by the application developer.
> I actually thought "accident" was appropriate here :-) The collision in 
> Derby versions is "an unexpected and undesirable event, especially one 
> resulting in damage or harm"[1] arising from the installation of two 
> applications.
> I would assign fault here to the application providers who are not 
> allowing for other applications using a common shared resource - the 
> system or user classpath; it's like if they both insisted in being 
> installed in the same directory.
> I would also say that most application providers are aware of this 
> problem (usually from some unfortunate prior experience) and take 
> explicit control of the classpath using mechanisms described elsewhere. 
> Their end-users are unaffected by this scenario.
> So whilst there is high impact from your scenario, it applies to 
> end-users who install multiple applications that do not exhibit 
> classpath discipline and which happen to use different versions of Derby 
> client and engine (but not two different engine versions or two 
> different client versions). And never mind that these users may be 
> affected by any other libraries these applications use.
> Rather than address this ourselves (and just for Derby) by convoluted 
> code-rewrites and avoidance of third party libraries we should encourage 
> the application providers avoid this entirely by exhibiting discipline 
> when using shared resources. We can even point them at something like:
> http://classworlds.codehaus.org/
> -- 
> Jeremy
> [1] http://dictionary.reference.com/search?q=accident

View raw message