db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Knut Anders Hatlen <knut.hat...@oracle.com>
Subject Re: More. Trouble with JVMInfo
Date Tue, 27 Sep 2011 14:26:29 GMT
Kathey Marsden <kmarsdenderby@sbcglobal.net> writes:

> On 9/27/2011 5:21 AM, Rick Hillegas wrote:
>> This use-case would be satisfied by having a separate clone of
>> sysinfo for each of the jar files: sysinfoEngine, sysinfoClient,
>> sysinfoTools.
>>
> I don't think that's a practical solution at this point.  in addition
> to support needing  to ask the customer to run 5 commands to
> understand the installed derby software, and confusing a lot of Derby
> users  it breaks  a public API and the very first command we have
> always told users  to run with Derby.

Another question is whether mixed versions is a configuration we need to
support (I don't think it's stated explicitly anywhere that we actually
do support it?). Is this a configuration we expect to be used in
production, or is it just something we need in order to be able to run
ad-hoc compatibility tests?

The scenario I think has been mentioned in earlier discussions, is
application servers where different servlets come with different
versions of the driver. But I think in these configurations the servlets
typically use separate class loaders, and they wouldn't be affected by
the class collisions.

10.7 has been out for a year with this problem, and there haven't been
any bug reports mentioning it yet, which indicates that mixed versions
in the same class loader isn't a very common configuration.

-- 
Knut Anders

Mime
View raw message