Tim Ellison wrote:
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).
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?
our goal is Harmony, but within our development and test procedure,
we do check against the RI, just to be sure our code is working ok.
It's not something that we would require for including the
LDAP code in Harmony.
:) next week we'll contribute the code for some classes that were missing
from 1.4 version of javax.naming.ldap, and after that we'll send code for
the
1.5 classes of the package.
Thanks,
Daniel
Regards,
Tim
--
Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
