Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: pass (athena.apache.org: local policy)
Message-ID: <4E81DCD3.5070005@oracle.com>
Date: Tue, 27 Sep 2011 07:25:23 -0700
From: Rick Hillegas <rick.hillegas@oracle.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US;
 rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11
MIME-Version: 1.0
To: "derby-dev@db.apache.org" <derby-dev@db.apache.org>
Subject: Re: More. Trouble with JVMInfo
References: <204BEF24-0F42-40C4-A818-D10926780D34@sbcglobal.net>
	 <4E7C9F8B.2090605@oracle.com> <1316809886.3626.17.camel@tecra>
 <4E807F5E.2020506@oracle.com> <4E80A938.9090302@sbcglobal.net>
 <4E80C0DB.30100@oracle.com> <4E80ED12.10906@sbcglobal.net>
 <4E81BFC9.7070802@oracle.com> <4E81CA2B.6010906@sbcglobal.net>
In-Reply-To: <4E81CA2B.6010906@sbcglobal.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 9/27/11 6:05 AM, Kathey Marsden wrote:
> 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.
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

Since these programs are clones, you only have to run one of these commands.


>
> 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".

Thanks,
-Rick
>
> Thanks
>
> Kathey
>
>
>
>
>
>
>
>
>
>
>
>
>
>