db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kathey Marsden <kmarsdende...@sbcglobal.net>
Subject Re: More. Trouble with JVMInfo
Date Tue, 27 Sep 2011 13:05:47 GMT
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.

I am sure we can find a technical solution that doesn't affect our 
users.  For JVMInfo I think it can safely be pulled out of use for 
sysinfo and the duplication removed (DERBY-1046). I am willing to work 
on that and get past the current issue.  For sysinfo itself, the 
separate and multiple copies should be fine.

For the others, e.g. ProductVersionHolder, I wonder if we could have 
separate packages as you suggested earlier in this thread, determine 
what jar the sysinfo class are using is loaded from ( I seem to recall 
this is possible but can't recall the API. I also seem to recall 
possible security manager concerns) and then use reflection to invoke 
the correct one.  I am not sure if this will all work, but just a thought.

Even if worst case we have to put everything needed for sysinfo  into 
the sysinfo class, we need to find a solution that keeps sysinfo and 
doesn't turn it into multiple new commands.



View raw message