I get your point that we don't want to have one classloader per data source, and we should use the default wherever possible.

I don't think we should depend on Env properties (I'm assuming you mean "java:comp/env" properties) because these are available only in J2EE environments.

A data source has properties on it, two of them could be derby.system.home and derby.system.classpath. If derby.system.classpath is not set then we could just use the default classloader (or perhaps the one that prevents shadowing that I am considering) to load derby classes.

Just thoughts at this point. All this needs to be demonstrated with working code...

David

Francois Orsini wrote:
Agreed - The challenge in this example is to separate the 2 properties set upon instancing appropriate datasources...Fundamentally, 2 separate classloaders have to be created - Obviously we would not want to have to create a separate classloader everytime we instantiate a new DataSource, except if we have a way/mechanism to find out that we need to do so (upon instantiating an EmbeddedDataSource object for instance)...Upon instantiating a specialized DataSource in derby, I wonder if it'd be possible to detect from the environment (i.e. Env Properties) if anyhing relevant has changed that would lead Derby to return the proper instantiated DataSource object based on the environment (Env properties) - which means that the DataSource Factory would have to be smart enough to figure this out (keeping track of the various Env Properties) in order to return the appropriate one (off a new or existing classloader)...Now which properties ("derby.system.home", "derby.system.classpath" - is that enough?) would be relevant enough to figure out that this DataSource should be instantiated in a non-default classloader but one that is either known or yet to be created...

Does this make any sense at all...?

--francois

On 11/23/05, *Daniel John Debrunner* < [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote:


    However, it does seem to me that JDBC already provides two factory
    classes for getting connections, Driver and DataSource. Do we really
    need another factory api?

    Dan.


begin:vcard
fn:David W Van Couvering
n:Van Couvering;David W
org:Sun Microsystems, Inc.;Database Technology Group
email;internet:[EMAIL PROTECTED]
title:Senior Staff Software Engineer
tel;work:510-550-6819
tel;cell:510-684-7281
x-mozilla-html:TRUE
version:2.1
end:vcard

Reply via email to