db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David W. Van Couvering" <David.Vancouver...@Sun.COM>
Subject Re: [jira] Updated: (DERBY-289) Enable code sharing between Derby client and engine
Date Fri, 18 Nov 2005 00:27:54 GMT
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...


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

View raw message