db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kathey Marsden <kmarsdende...@sbcglobal.net>
Subject Re: [jira] Updated: (DERBY-289) Enable code sharing between Derby client and engine
Date Fri, 18 Nov 2005 00:10:12 GMT
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




Mime
View raw message