On Nov 14, 2005, at 10:58 AM, Kathey Marsden wrote:

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.

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

I agree that a tricky part is how to specify properties for the different Derby databases that use different code bases. There is only one System Properties for a VM, and it's nailed pretty tight (you have to have privileges just to look at them!).

Maybe the answer is for the Derby instance bound to the class loader to be passed the Properties that it would normally look for in System Properties. So instead of DataSource newDataSource(ClassLoader loader, String databaseName) it could be DataSource newDataSource(ClassLoader loader, Properties whatWouldNormallyBeInSystemPropertiesIncludingDatabaseName).



Craig Russell

Architect, Sun Java Enterprise System http://java.sun.com/products/jdo

408 276-5638 mailto:Craig.Russell@sun.com

P.S. A good JDO? O, Gasp!