db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Hillegas <rick.hille...@oracle.com>
Subject Re: More. Trouble with JVMInfo
Date Tue, 27 Sep 2011 12:21:29 GMT
On 9/26/11 2:22 PM, Kathey Marsden wrote:
> On 9/26/2011 11:13 AM, Rick Hillegas wrote:
>> Can you refresh my memory: why is sysinfo included in all of our 
>> jars? Why can't we ask people to wire in the tools jar if they want 
>> to run sysinfo?  I think sysinfo was thought to be stable but because 
>> it uses classes like JVMInfo that are used for other things, it is 
>> not.   How would this plan work in relation to the single sysinfo 
>> invocation?
> This practice predates me, but I am pretty sure it is because sysinfo 
> is/was  the primary tool for verifying proper classpath settings  and 
> collecting information for support regarding what jars and versions 
> are being used and for what versions, jvm, os  information, etc.  Many 
> (most?) applications do not deploy derbytools.jar, so it doesn't make 
> sense to require that jar be installed or the classpath you are trying 
> to diagnose be changed to include it in a support situation.
This use-case would be satisfied by having a separate clone of sysinfo 
for each of the jar files: sysinfoEngine, sysinfoClient, sysinfoTools.

> I reopened DERBY-1046 to remove the JVMInfo duplication which I think 
> was closed accidentally.  I think this class changes too frequently to 
> be expected to be stable and part of sysinfo.  If a bit of code needs 
> duplication in sysinfo, then that seems the way to go.  
> ProductVersionHolder might need something more elaborate.

View raw message