On 11/2/05, David W. Van Couvering <[EMAIL PROTECTED]> wrote:
I thought we would still allow that as long as version compatibility allows it? do we want to completely prevent users from running different versions of Derby in the same classloader?
I guess the expanded 'sysinfo' you're talking about would be something we could run against a remote Derby instance or against the same JVM? Are you thinking of having such utility running within a separate classloader of its own _or_ interact with other classloaders in order to find out what versions of Derby are running in a particular JVM?
Regarding the instructions on how to not do that - are you thinking of suggesting the users to run the different versions of Derby in separate classloaders?
I mean that in version 10.2 we document that "in version 10.3 (or 10.4)
of Derby, we will no longer support environments where multiple versions
of Derby are available in the same classloader."
I thought we would still allow that as long as version compatibility allows it? do we want to completely prevent users from running different versions of Derby in the same classloader?
Then in version 10.3 (or 10.4) if/when someone sends an email saying
"I've got this weird bug where upgrades don't seem to have any impact"
or "when I upgrade I'm getting weird exceptions about methods not being
found" we can say "run this tool (some form of sysinfo that works with
classloaders)" and if it shows they have mixed versions we can say
"don't do that, here are instructions on how to not do that" instead of
"let's try to fix this."
I guess the expanded 'sysinfo' you're talking about would be something we could run against a remote Derby instance or against the same JVM? Are you thinking of having such utility running within a separate classloader of its own _or_ interact with other classloaders in order to find out what versions of Derby are running in a particular JVM?
Regarding the instructions on how to not do that - are you thinking of suggesting the users to run the different versions of Derby in separate classloaders?
David
Francois Orsini wrote:
> Hi David,
>
> What does it mean to "deprecate" support of
> mixed client/embedded version environments in 10.2, and officialy remove
> support in 10.3 or 10.4?
>
> If you could be a little more specific that would be great.
>
> Thanks,
>
> --francois
>
> On 11/2/05, *David W. Van Couvering* <[EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED] >> wrote:
>
> Not only in our discussions, but in the coding I am doing, ensuring
> forward and backward compatibility in mixed version environments is
> achievable but fairly onerous.
>
> I think there has been some discussion of this, but I wanted to make it
> a more direct question: is it possible that we "deprecate" support of
> mixed client/embedded version environments in 10.2, and officialy remove
> support in 10.3 or 10.4? This would reduce the overhead of
> adding/supporting common code significantly. But I am not in support
> and I am not clear of the impact of doing this.
>
> Thanks,
>
> David
>
>
>
>
