By the way, this solves the message versioning problem, but doesn't
solve the overall forward/backward compatibility issue and the code
cruft that it will engender.
In reading Kathey's email, I also seem to understand that there are
issues beyond code compatibility. In particular, we seem to have a
hardcoded dependency on system properties (rather than say a properties
file which can be loaded via a classloader), which means multiple app
instances in the same VM can "pollute" each others' configurations even
if you use multiple classloaders; it's like having system-wide global
variables ala COBOL or Fortran... If we are saying we support multiple
apps in the same VM, isn't this a bug? I am thinking of logging a JIRA
on this.
David
Kathey Marsden wrote:
Rick Hillegas wrote:
Hi Kathey,
What you say is true if the classpath contains an embedded Derby app
and a client app. But I don't think it works if the classpath contains
two embedded Derby apps or two client apps (at different version
levels). I think that encoding a version number makes all cases work.
You can't have two client apps at different version levels in the same
classloader. The one loaded first will win. If they are in different
classloaders then they are separated anyway. We are looking at mixing a
single derbyclient.jar (version X) with a single derby.jar (version Y)
and we need to separate the m17_en.properties file when mixing the two
jars. We can differentiate on the version (#releases ever different
files) or on server vs client. (2 different files) so it seemed to me
2 was better until I read the next part of your mail ...
If for some reason we have to distinguish client from server messages,
then we could add that information to the encoded file names. I
suppose that the message resolver could pick a client vs server
message file based on a peek at the call stack and knowledge about
what packages live in which jar files.
This is a really good point about how to determine whether to load the
server or client messages since these are static methods in
MessageService. So I guess that part is what would be really hard. I
don't understand what you said about how to do it. Sounds complicated.
Kathey
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
