Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: pass (asf.osuosl.org: domain of gshimansky@gmail.com designates
 66.249.82.230 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references;
        b=rMlFCDFKnljhzBHswCc1d4XH7/70pG9RW6TJTrp5Ba01LoqlxZviBf/B9f58hxxBowev8fyaSBCgK5vmFEk0LXmNmeUyWztwqsXynz6lmS+Cg7W8NBc85KtFHbxopApCzWedn+qL0HL7mHtXoo3o9IGRma6Cy7JQImXM9+/X4co=
Message-ID: <208da7a50608110732v602724bbva1c552bb4b511d1b@mail.gmail.com>
Date: Fri, 11 Aug 2006 18:32:15 +0400
From: "Gregory Shimansky" <gshimansky@gmail.com>
To: harmony-dev@incubator.apache.org
Subject: Re: [classlib] [ldap] support for multiple VMs?
In-Reply-To: <44DC530E.7060005@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_44059_2947168.1155306735924"
References: <006401c6bc9c$d72b0a40$d500a8c0@neosur.com>
	 <44DC530E.7060005@gmail.com>

------=_Part_44059_2947168.1155306735924
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

2006/8/11, Tim Ellison <t.p.ellison@gmail.com>:
>
> Daniel Gandara wrote:
> > Hi all,
> >
> > We are working on the javax.naming.ldap and we are facing the
> > following issue when thinking about supporting multiple VMs.
> > Following the SPEC there is a method createExtendedResponse in the
> > StartTlsRequest class which states that the returning object must be
> > an instance of a concrete subclass of StartTlsResponse and must have
> > a public zero-argument constructor. The concrete subclass is
> > determined by reading the configuration file located in
> > META-INF/services/javax.naming.ldap.StartTlsResponse (see
> >
> http://java.sun.com/j2se/1.5.0/docs/api/javax/naming/ldap/StartTlsRequest.html
> )
> >
> > The search for this configuration file is done by looking in the
> > classpath, java.home and user.dir; also the Xbootclasspath should be
> > inspected, and that seems to be a problematic situation, since there
> > is not a standard property to look for its value. Different VM
> > implementations have different property names for the boot class path
> > value. In the old Harmony VM implementation was
> > com.ibm.oti.system.class.path; in the new one is
> > org.apache.harmony.boot.class. The property name in the Sun's VM is
> > sun.boot.class.path. We are wondering which property name to use in
> > the code. At first sight the Harmony new VM implementation property
> > seems to be the better option, but maybe looking for the other
> > properties will be interesting for compatibility purposes.
> >
> > We would be very interested in opinions.
>
> I'd ignore the com.ibm property and look through the path defined by
> org.apache.harmony.boot.class.path
>
> I don't know what property is set by the DRLVM / JCHEVM / etc., but it
> would be good if they set the same property (maybe in addition to their
> current property).


DRLVM sets two propeties with the same value. The one which is used by VM is
vm.boot.class.path and another added for compatibility with some
applications is sun.boot.class.path. It is not used inside of VM. I compared
values with org.apache.harmony.boot.class.path with is set in classlib luni
and foind that the only difference is with kernel.jar absent in it and
present in DRLVM properties. It is logical because they both read the same
bootclasspath.properties file but VM also adds kernel.jar before everything.

I wonder if DRLVM starts to use the same
org.apache.harmony.boot.class.pathproperty wouldn't it be overwritten
with luni initialization with value
wihout kernel.jar?


If you want the code to run on the Sun implementation too then you
> should *also* search the sun.boot.class.path, and of course be tolerant
> of o.a.harmony... or sun.boot... being absent.  Is running on Sun a goal
> for you?  It's not something that we would require for including the
> LDAP code in Harmony.
>
> Regards,
> Tim
>
>
-- 
Gregory Shimansky, Intel Middleware Products Division

------=_Part_44059_2947168.1155306735924--