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 16:32:10 -0800
From: "David W. Van Couvering" <David.Vancouvering@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: <437D210A.3010803@sun.com>
MIME-version: 1.0
Content-type: multipart/mixed; boundary="Boundary_(ID_SP1+mjUjL3od5sJNTpaqVw)"
User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923)
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>

This is a multi-part message in MIME format.

--Boundary_(ID_SP1+mjUjL3od5sJNTpaqVw)
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT

By the way, this solves the message versioning problem, but doesn't 
solve the overall forward/backward compatibility issue and the code 
cruft that it will engender.

In reading Kathey's email, I also seem to understand that there are 
issues beyond code compatibility.  In particular, we seem to have a 
hardcoded dependency on system properties (rather than say a properties 
file which can be loaded via a classloader), which means multiple app 
instances in the same VM can "pollute" each others' configurations even 
if you use multiple classloaders; it's like having system-wide global 
variables ala COBOL or Fortran...  If we are saying we support multiple 
apps in the same VM, isn't this a bug?  I am thinking of logging a JIRA 
on this.

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

--Boundary_(ID_SP1+mjUjL3od5sJNTpaqVw)
Content-type: text/x-vcard; charset=utf-8; name=david.vancouvering.vcf
Content-transfer-encoding: 7BIT
Content-disposition: attachment; filename=david.vancouvering.vcf

begin:vcard
fn:David W Van Couvering
n:Van Couvering;David W
org:Sun Microsystems, Inc.;Database Technology Group
email;internet:david.vancouvering@sun.com
title:Senior Staff Software Engineer
tel;work:510-550-6819
tel;cell:510-684-7281
x-mozilla-html:TRUE
version:2.1
end:vcard


--Boundary_(ID_SP1+mjUjL3od5sJNTpaqVw)--