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.
I will respond separately to Knuts mail about mixed jars.
Thanks
Kathey
