Re: VOTE: Approach for sharing code

[Francois Orsini]

Yes many things are possible technically - I did not mention the classloader thing because 1) it's very likely not going to be the most common use case (80-20 rule), 2) I think the original idea is to come up with a simple solution to the issue of code sharing between the client and the derby engine - if people want to come up with sophisticated frameworks to allow loading of specific classpath/archives, then it is fine; but I don't think we should make this the default case/solution - to me this belongs to the real of application server framework, not the database one which is Derby's main focus. This is something that can be done even today outside of Derby.

--francois

On 9/12/05, Jeremy Boynes <[EMAIL PROTECTED]> wrote:

Francois Orsini wrote:
<snip/>

> Due to the requirement of supporting a different version of the derby client
> and server in the same JVM, it's not like there are a lot of other and
> simpler alternatives out there indeed...Am guessing we're not going to
> support the loading of 2 different DerbyClient versions in the same
> JVM...(although one could envision db2jcc.jar and DerbyClient.jar running in
> the same JVM...we should not be seeing any conflict if the package structure
> is different)

I see no reason why we should not support that assuming the
infrastructure allows them to be loaded into different classloaders. For
example, each could be packaged inside a different RAR file and deployed
to an application server. A use case for this is different applications
talking to different databases.

Similarly I think we should also allow multiple versions of the engine
to be loaded as well (although not accessing the same data files).
Support for this though requires evolution away from the reliance on
system properties.

The use case here is isolation between the engines - for example, if an
application server is being used to host applications from different
organizations.

--
Jeremy