Kathey Marsden wrote:
David W. Van Couvering wrote:
You also avoid strange behavior such as slightly different SQL States
between client and server,
There is absolutely nothing stopping you from using the same source
property files that we have for server for client messages. They aren't
java files so don't have the same problems of cloning and can let you
get the messages localized without all this controversy I think.
That's actually not true. The server-side messages are *huge* and are
currently not available in derbyclient.jar. Adding them would cause
major client bloat (on disk if not at runtime), and only a small
percentage of them are shareable. This problem isn't solvable by
cutting/pasting code. If I don't want client bloat, I'd have cut/paste
all shared messages *and* their translations.
It makes much more sense to migrate shared messages to a common
location. This requires a shared code infrastructure.
<snip a whole bunch of stuff about future needs>
In terms of your particular issue, I'd like to challenge that it is as
bad as you say it is.
Why would someone want to run at different patch versions of the same
minor version in the same VM
See my response to Rick. Nobody wants it they just get it. It is one
totally unrelated appllication affecting another.
I want to make sure I understand. I think you're saying that there can
be situations where there is a VM which gets its classes in some
untransparent way. For example, Application A puts its classes in one
directory and Application B puts its jars in another directory, and then
the VM is configured (somehow) to load classes from the union of these
directories. I'm sure there are other examples, but this is the one
that comes to mind.
The common thread here is there is an application hosting environment
where multiple applications are deployed into the same VM, and if the
same jar files are deployed into both applications, then you can not
guarantee that a particular instance of a class within these duplicated
jars will actually be loaded at runtime, unless you carefully manage
your classloading order or using separate classloaders.
It seems to me that in such an environment Derby already has this
problem. If Application A is running an embedded database and
Application B is running an embedded database, and the Derby jar files
for A precede B in the classloading order, then a bug fix in the engine
code for B will be shadowed by the code in A. The same is true if two
applications are running with the network client and have a separate set
of Derby jar files.
So what shared code is introducing is an incremental increase in the
environments where such problems already exist, where one application is
running with the network client driver and another is running the
embedded driver.
It would seem to me the situation where there are two applications both
running embedded would be more likely than the network/embedded case.
Yet none of us seem to have ever heard anyone complaining that they have
encountered this shadowing problem (or I'm sure it would have come up in
the context of this discussion). My suspicion is that this is because
such an environment is extremely rare, if it exists at all. All
application hosting environments I know of use classloaders, and this
type of shadowing issue is one of the primary reasons for this.
At any rate, my main point is I don't think that shared code is
introducing a major regression to the product.
We need, I think, to discourage jar mixing by changing the
documentation to encourage application developers to use classloaders to
insulate their application and protect others from it, printing warnings
to the log file when jars are mixed or there is more than one copy or
version of derby in the classpath, providing a way to print sysinfo to
the log when classes have been loaded with classloaders and possibly
even deprecating the ability to mix jars if the community wills it
because of the impact on development, but it can't happen overnight like
this. It is an application developer education issue and even those
that understand the need for classloaders now need some notice.
I would be happy to write some information to the log so people know
they have mixed versions. This would help with the problem that already
exists, and will continue to help when we have shared code.
To your point about "not doing this overnight," I suspect what you're
saying is "warn people about it in 10.2 and then do it in 10.3". You
also seem to indicate that you feel all the needs for shared code are
"future needs."
I'm not convinced of that. I think that, particularly as the community
continues to grow, there is a timely need for this that really can't
wait another year (assuming six month cycles for minor releases) before
it sees the light of day. I am sure I am not the only one who is
working on a feature where shared code would help or is needed. I know
Rick wants to do this, and I suspect there are others.
I'd like to poll other folks on this list for their own views on this
(I'll send it on a separate email to make sure it's called out).
Thanks,
David
begin:vcard
fn:David W Van Couvering
n:Van Couvering;David W
org:Sun Microsystems, Inc.;Database Technology Group
email;internet:[EMAIL PROTECTED]
title:Senior Staff Software Engineer
tel;work:510-550-6819
tel;cell:510-684-7281
x-mozilla-html:TRUE
version:2.1
end:vcard
