[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. > [EMAIL PROTECTED] 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 > > --
