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