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 16:17:49 GMT
On 9/27/2011 7:25 AM, Rick Hillegas wrote:
> Hi Kathey,
> We may be talking past one another. What are the 5 commands that would 
> have to be run? I only see 2:
> 1) On the client machine, you would run
>   java org.apache.derby.tools.sysinfoClient
> 2) On the server machine, you would run
>   java org.apache.derby.tools.sysinfoEngine
> For backward compatibility reasons, we might let the version in the 
> tools jar keep the old name. So this would work too:
> 3) If derbytools is in the classpath, you can run
>   java org.apache.derby.tools.sysinfo
I am loathe to say this as I think multiple sysinfo's is unacceptable, 
but if we kept sysinfo only in one place it would be least disruptive if 
it were in derby.jar as I think most deployments are just with that jar.

> Since these programs are clones, you only have to run one of these 
> commands.
We would also need java org.apache.derby.tools.sysinfoNet  and I was 
thinking one for the locales, but perhaps those would print with all the 
sysinfo variants?,  but regardless, four or five  is unacceptable.  We 
need one sysinfo  and need to find a solution that does not disrupt our 

>> 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.
> Thanks. That's practical, incremental improvement.
>> For the others, e.g. ProductVersionHolder, I wonder if we could have 
>> separate packages as you suggested earlier in this thread, 
> I was suggesting different class names for clones of this class. But 
> cloning the packages is another interesting solution.
>> 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.
> Right. One way or another, we have to patch up sysinfo so that it 
> pulls in the correct clone. This runtime disambiguation sounds tricky 
> and brittle to me. I would be more comfortable with a compile-time 
> solution whose correctness we can reason about.
>> 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.
> I think that tech support can be educated. I don't think that the 
> end-user cares whether tech support says "run sysinfoEngine" or "run 
> sysinfo".
and run sysinfoClient and sysinfoNet and sysinfo, to get the complete story.

I think it is important to understand the scope of derby sysinfo usage.

Google on derby sysinfo  (both words) yeilds over 21000 hits.   There is 
not just our documentation there are countless tutorials, tech notes, 
documentation for consuming products and even books that would be now be 
wrong in the most basic instructions for setting up Derby. There are 
email archives that people reference that will be wrong.

I think it is simply unacceptable to break sysinfo or require multiple 
invocations of different commands to get the same information.   We need 
to find a technical solution that doesn't do that.

I will respond separately to Knuts mail about mixed jars.



View raw message