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]
> 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.
