Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: pass (asf.osuosl.org: local policy)
Date: Thu, 17 Nov 2005 17:02:40 -0800
From: Rick Hillegas <Richard.Hillegas@Sun.COM>
Subject: Re: [jira] Updated: (DERBY-289) Enable code sharing between Derby
 client and engine
In-reply-to: <437D1BE4.5020505@sbcglobal.net>
To: derby-dev@db.apache.org
Message-id: <437D2830.7050700@sun.com>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)
References: <922737490.1131395000353.JavaMail.jira@ajax.apache.org>
 <437099FA.9000001@debrunners.com> <4371307C.5000608@sun.com>
 <4379EF2E.8030103@debrunners.com>
 <58ed70f50511151454j54c264edxafe1afee8df7960d@mail.gmail.com>
 <437A82FF.2040100@sun.com>
 <58ed70f50511152039h2ee33319w8ff1facf3c024e90@mail.gmail.com>
 <437CECD3.2030504@sun.com> <437CF49E.1050900@sbcglobal.net>
 <437D1480.1050304@sun.com> <437D1BE4.5020505@sbcglobal.net>

Hi Kathey,

Some comments follow. Cheers-Rick

Kathey Marsden wrote:

...

>>    
>>
>You can't have two client apps at different version levels in the same
>classloader.  The one loaded first will win.  
>
I'm not so sure this is true. If classes are added/deleted to/from the 
public API, then it may be possible to get behind the shadowing jar 
file. I think there are wormholes and heisenbugs in here.

...

>>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
>  
>

You can peek at the stack using Throwable.getStackTrace(). Done wrong, 
it could be a brittle piece of code. In any event, I don't recommend 
this approach because I think that versioned message files solve the 
problem of messages shared between client and server.