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
