db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Binod P G <Binod...@Sun.COM>
Subject Re: Question about using URLClassLoader and Derby
Date Tue, 15 Nov 2005 04:28:00 GMT
[cc'd Siva who owns ClassLoader stuff for GlassFish project]

Yes, you cannot have two different derby versions depending on different
values of one system property.

Also, if derby driver happen to use any third party library (say commons
logging) that is also used by appserver, then there may be
inconsistencies. Basically you might end up using the library in
application server rather than yours.

> Binod.Pg@Sun.COM wrote:
> 
> 
>>BTW, where would your application run? I am assuming it is outside of
>>any managed environment like application server.
>>
>> 
>>
> 
> 
> Well, probably the farthest I might take a practical implementation 
> myself  is to make some upgrade tests for Derby, but I want to provide
> an example of how to load Derby in a ClassLoader so that  a component
> that embeds Derby can run in any environment  without
> interference or interfering others.   For example,  lets say my
> component  was something that you could embed in your application to add
> a  dictionary capability.  I'd like you to use my component, be able to
> use Derby however you want to,  and be able to run in any environment at
> all without even knowing that I use Derby.  I also want to make sure the
> dictionary API  always uses the derby jars that I shipped and used for
> my QA.

As long as your api indicate a need to clean up (dictionary.close()) and
you destroy the ClassLoder properly, it would work. Otherwise, we might
open up a memory leak.

- Binod.

> 
> I think the System properties can  create  a  problem  for application
> servers too that might want to allow connection to different versions of
> Derby.
> 
> 
> Kathey
> 
> 

-- 





Mime
View raw message