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 16:50:41 GMT
On 9/27/11 9:17 AM, Kathey Marsden wrote:
> 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 users.
>
>
>>
>>>
>>> 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.
Understood. We made a blunder by bundling sysinfo in multiple jar files. 
Now we have to figure out how to recover from that blunder. The problem 
may be that we have to choose between two bad solutions. I am interested 
in your response to Knut's question.

If we really have to support multiple versions of Derby on the same 
classpath, then we need to do some math. There are 3 sysinfo-bearing jar 
files per release. The number of possible classpath orders is something 
like (3N)! where N is the number of Derby releases. There are now 16 
official releases on our download page. That works out to 48! classpath 
orders which have to be tested. A very large number. I would say that 
expecting that kind of compatibility testing is beyond unacceptable, it 
is impossible.

Thanks,
-Rick
>
> I will respond separately to Knuts mail about mixed jars.
>
> Thanks
>
> Kathey
>
>


Mime
View raw message