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
