I don't understand what you mean by "distinguish client from server
messages." Client messages would be in client-messages.properties,
server messages are in m_*.properties. When the engine asks for a
message, it specifies the appropriate m_*.properties file based on
message id. When the client asks for a message, it specified
client-messages.properties as the resource file.
In both cases, in the model I proposed, we look in
common-messages.properties to see if the message id is there first, and
then look in the client or server message properties file.
I think Kathey's suggestion of copying the common message file twice,
with different names for client and server, should work.
I also am interested in Kathey's idea that there is just a single
message file, and that the build separates out the client-specific and
engine-specific messages. I have to think about that some more...
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
