Mailing-List: contact derby-user-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Derby Discussion" <derby-user@db.apache.org>
Received-SPF: neutral (asf.osuosl.org: local policy)
Message-ID: <43797E13.5060906@apache.org>
Date: Mon, 14 Nov 2005 22:20:03 -0800
From: Jeremy Boynes <jboynes@apache.org>
User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc3 (X11/20050929)
MIME-Version: 1.0
To: Derby Discussion <derby-user@db.apache.org>
Subject: Re: Question about using URLClassLoader and Derby
References: <43722A1E.4000402@sbcglobal.net> <43752762.2030605@sun.com>
 <43789D4A.1040507@sbcglobal.net> <fb7efbdb41e6.4378e8d0@sun.com>
In-Reply-To: <fb7efbdb41e6.4378e8d0@sun.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Binod.Pg@Sun.COM wrote:
> 
> BTW, where would your application run? I am assuming it is outside of
> any managed environment like application server.
> 

I think this use-case is applicable to both raw J2SE applications and
also those running inside an application server.

For a raw J2SE application it may well be that there are different
components inside the application that have been written against
different versions or even just different configurations of Derby. For
example, consider Eclipse where two different plugins both want to use a
database; or Maven, where two plugins or something simple like two unit
tests want different database configurations.

Both these environments have classloading that can be used to load
different versions of Derby but that's not going to solve the System
properties problems.

The same problem applies in an application server as well. Multiple
end-user applications may, assuming the appropriate permissions are
granted, want to access separate databases. Even loading them as J2CA
connectors will run into the properties problems.

In an ideal world, I would like to be able to specify all the properties
for a Derby engine (rather than a database) during some explicit startup
phase. For example, in a J2CA environment it could (portably) be done
during bootstrap of the ResourceAdapter; in Eclipse or Maven it could be
done as part of plugin initialization; in JUnit it could be done during
fixture initialization. This could also be used by the standalone
network server to start its embedded engine.

I can envision the API for this as a simple JavaBean with setters for
the various properties and start/stop methods to control the engine.

Compatibility with existing applications could be maintained by simply
starting a singleton engine in the Driver having set its bean properties
from the current system properties; this is very similar to how the
Monitor is bootstrapped now when the first connection is made.

--
Jeremy