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.
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.
Cheers,
-Rick
Kathey Marsden wrote:
Rick Hillegas wrote:
Here is a possible solution to the versioned message id problem:
[snip details ...]
o The Derby build can create message files whose names contain the
current value of DERBY_VERSION.
[snip more details]...
If the derby build is going to create extra message files, why not one
for server and one for client with different names. All that has to be
encoded in the message id is whether it is client, server or both. Then
there is no versioning worries I think. No?
