You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Daniel Gandara <da...@neosur.com> on 2006/08/10 18:48:41 UTC
[classlib] [ldap] support for multiple VMs?
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.
Thanks,
Daniel
Re: [classlib] [ldap] support for multiple VMs?
Posted by Alexey Varlamov <al...@gmail.com>.
2006/8/28, Paulex Yang <pa...@gmail.com>:
> Oliver Deakin wrote:
> > Hi Alexey,
> >
> > I have taken a look at the patch - generally it looks good to me, and
> > if it all
> > works ok when you test it, it's fine by me.
> >
> > I think if there are cases where some functionality is repeated many
> > times, it
> > would be good to see it split out somewhere central. However, Im not sure
> > the port library is the right place for these functions - the port
> > library is really a
> > generic front hiding platform specific operations. These functions do
> > not really
> > fit into that category - perhaps they would be better placed in the
> > common
> > library (luni/src/main/native/common)? This component provides a set of
> > helper functions required by many native modules, and seems like the
> > right
> > place to put them.
> Agree, portlib is designed to encapsulate OS/architecture difference,
> and it should be taken care to be concise, so that it can be ported
> easily to as many platforms as possible(at least to those Harmony
> planned to support), it is not a common library.
Paulex, Oliver,
Sorry for late response, I fully agree with your considerations. I was
just not familiar enough with luni natives structure and was drawn
away with idea of runtime code sharing. But indeed common lib with
static linkage is appropriate for the case.
So I rearranged the patch for HARMONY-1243, please review and commit.
Seems there are good cases for using these common functions, for
example issue #1386.
--
WBR,
Alexey
> >
> > Regards,
> > Oliver
> >
> > Alexey Varlamov wrote:
> >> Oliver,
> >>
> >> Please take a look at a HARMONY-1243 patch. I fixed all bugs noticed
> >> and made parsing a bit more robust. Also, added a define for
> >> "org.apache.harmony.boot.class.path" name to vmi.h - to enforce that
> >> there is 2-sided contract for this property.
> >>
> >> I still think that some of those functions may worth to be added to
> >> the portlib, namely:
> >> char * str_concat (HyPortLibrary * portLibrary, ...);
> >> int props_read_from_file(HyPortLibrary * portLibrary, const char
> >> *filename,
> >> key_value_pair** properties, U_32 *number);
> >> void props_free(HyPortLibrary * portLibrary, key_value_pair *
> >> properties);
> >>
> >> Justification: the same functionality is duplicated at least in
> >> launcher/shared/main.c, and there are other property files to be read
> >> by VM.
> >>
> >> If nobody object, I will try to add these 3 functions to portlib.
> >>
> >
>
>
> --
> Paulex Yang
> China Software Development Lab
> IBM
>
>
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib] [ldap] support for multiple VMs?
Posted by Paulex Yang <pa...@gmail.com>.
Oliver Deakin wrote:
> Hi Alexey,
>
> I have taken a look at the patch - generally it looks good to me, and
> if it all
> works ok when you test it, it's fine by me.
>
> I think if there are cases where some functionality is repeated many
> times, it
> would be good to see it split out somewhere central. However, Im not sure
> the port library is the right place for these functions - the port
> library is really a
> generic front hiding platform specific operations. These functions do
> not really
> fit into that category - perhaps they would be better placed in the
> common
> library (luni/src/main/native/common)? This component provides a set of
> helper functions required by many native modules, and seems like the
> right
> place to put them.
Agree, portlib is designed to encapsulate OS/architecture difference,
and it should be taken care to be concise, so that it can be ported
easily to as many platforms as possible(at least to those Harmony
planned to support), it is not a common library.
>
> Regards,
> Oliver
>
> Alexey Varlamov wrote:
>> Oliver,
>>
>> Please take a look at a HARMONY-1243 patch. I fixed all bugs noticed
>> and made parsing a bit more robust. Also, added a define for
>> "org.apache.harmony.boot.class.path" name to vmi.h - to enforce that
>> there is 2-sided contract for this property.
>>
>> I still think that some of those functions may worth to be added to
>> the portlib, namely:
>> char * str_concat (HyPortLibrary * portLibrary, ...);
>> int props_read_from_file(HyPortLibrary * portLibrary, const char
>> *filename,
>> key_value_pair** properties, U_32 *number);
>> void props_free(HyPortLibrary * portLibrary, key_value_pair *
>> properties);
>>
>> Justification: the same functionality is duplicated at least in
>> launcher/shared/main.c, and there are other property files to be read
>> by VM.
>>
>> If nobody object, I will try to add these 3 functions to portlib.
>>
>
--
Paulex Yang
China Software Development Lab
IBM
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib] [ldap] support for multiple VMs?
Posted by Oliver Deakin <ol...@googlemail.com>.
Hi Alexey,
I have taken a look at the patch - generally it looks good to me, and if
it all
works ok when you test it, it's fine by me.
I think if there are cases where some functionality is repeated many
times, it
would be good to see it split out somewhere central. However, Im not sure
the port library is the right place for these functions - the port
library is really a
generic front hiding platform specific operations. These functions do
not really
fit into that category - perhaps they would be better placed in the common
library (luni/src/main/native/common)? This component provides a set of
helper functions required by many native modules, and seems like the right
place to put them.
Regards,
Oliver
Alexey Varlamov wrote:
> Oliver,
>
> Please take a look at a HARMONY-1243 patch. I fixed all bugs noticed
> and made parsing a bit more robust. Also, added a define for
> "org.apache.harmony.boot.class.path" name to vmi.h - to enforce that
> there is 2-sided contract for this property.
>
> I still think that some of those functions may worth to be added to
> the portlib, namely:
> char * str_concat (HyPortLibrary * portLibrary, ...);
> int props_read_from_file(HyPortLibrary * portLibrary, const char
> *filename,
> key_value_pair** properties, U_32 *number);
> void props_free(HyPortLibrary * portLibrary, key_value_pair *
> properties);
>
> Justification: the same functionality is duplicated at least in
> launcher/shared/main.c, and there are other property files to be read
> by VM.
>
> If nobody object, I will try to add these 3 functions to portlib.
>
--
Oliver Deakin
IBM United Kingdom Limited
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib] [ldap] support for multiple VMs?
Posted by Alexey Varlamov <al...@gmail.com>.
Oliver,
Please take a look at a HARMONY-1243 patch. I fixed all bugs noticed
and made parsing a bit more robust. Also, added a define for
"org.apache.harmony.boot.class.path" name to vmi.h - to enforce that
there is 2-sided contract for this property.
I still think that some of those functions may worth to be added to
the portlib, namely:
char * str_concat (HyPortLibrary * portLibrary, ...);
int props_read_from_file(HyPortLibrary * portLibrary, const char *filename,
key_value_pair** properties, U_32 *number);
void props_free(HyPortLibrary * portLibrary, key_value_pair * properties);
Justification: the same functionality is duplicated at least in
launcher/shared/main.c, and there are other property files to be read
by VM.
If nobody object, I will try to add these 3 functions to portlib.
--
Alexey
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib] [ldap] support for multiple VMs?
Posted by Oliver Deakin <ol...@googlemail.com>.
Alexey Varlamov wrote:
> A bit offttopic for this thread, but I'd like to discuss the following
> points for the boot.class.path property:
> 1) Whose responsibility is to set this property (launcher, VM or
> classlib)? Now we have at least 3 implementations:
> a) readClassPathFromPropertiesFile() in
> classlib\modules\archive\src\main\native\archive\windows\jclglob_harmony.c
>
I just deleted this file, did a rebuild and it built fine. Looking in
the Windows
makefile for archive it's not even listed, so I guess it's never been built!
I think it can safely be deleted from svn - Ill raise a JIRA.
Regards,
Oliver
> b) readClassPathFromPropertiesFile() in
> classlib\modules\luni\src\main\native\luni\shared\luniglob.c
> c) load_full_api_files_path_names_list() in
> drlvm\vm\vmcore\src\init\properties.cpp
> BTW, the first 2 seems to be just copy-paste copies. I believe there
> should be just single agent doing this task, most natural candidate is
> shared VM launcher.
>
> 2) Current parsers of the bootclasspath.properties are fragile in
> relation to format of this file: the file must end with line delimiter
> and must have strict platform line delimiters, otherwise jvm just
> hangs. Should I file new JIRA or this is intentional?
>
>
> 2006/8/11, Tim Ellison <t....@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).
>>
>> 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
>>
>> --
>>
>> Tim Ellison (t.p.ellison@gmail.com)
>> IBM Java technology centre, UK.
>>
>> ---------------------------------------------------------------------
>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
--
Oliver Deakin
IBM United Kingdom Limited
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [general] *.boot.class.path propoerty setting (Was Re: [classlib] [ldap] support for multiple VMs?)
Posted by Alexey Varlamov <al...@gmail.com>.
2006/8/11, Geir Magnusson Jr <ge...@pobox.com>:
> I was going to talk about the exact thing when I had a chance, so glad
> you beat me to it. I'm just changing the subject line so it's clearer.
>
> Inline.
>
> Alexey Varlamov wrote:
> > A bit offttopic for this thread, but I'd like to discuss the following
> > points for the boot.class.path property:
> > 1) Whose responsibility is to set this property (launcher, VM or
> > classlib)? Now we have at least 3 implementations:
> > a) readClassPathFromPropertiesFile() in
> > classlib\modules\archive\src\main\native\archive\windows\jclglob_harmony.c
> > b) readClassPathFromPropertiesFile() in
> > classlib\modules\luni\src\main\native\luni\shared\luniglob.c
> > c) load_full_api_files_path_names_list() in
> > drlvm\vm\vmcore\src\init\properties.cpp
> > BTW, the first 2 seems to be just copy-paste copies. I believe there
> > should be just single agent doing this task, most natural candidate is
> > shared VM launcher.
>
> I also thought the launcher was the right place, but not so sure, as you
> wouldn't want to handcuff the VM implementations as to what kinds of
> features they can add here. Maybe VM launcher sets it originally, but
> the VM is free to override?
>
I suggest that launcher pass the bootclasspath string among other
VMOptions. It can even (re)use "-Xbootclasspath:" argument - that is,
such argument would be specified either by user or by the launcher
itself.
> >
> > 2) Current parsers of the bootclasspath.properties are fragile in
> > relation to format of this file: the file must end with line delimiter
> > and must have strict platform line delimiters, otherwise jvm just
> > hangs. Should I file new JIRA or this is intentional?
>
> Please file a JIRA. Hanging can never be intentional. :)
>
> geir
>
> >
> >
> > 2006/8/11, Tim Ellison <t....@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).
> >>
> >> 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
> >>
> >> --
> >>
> >> Tim Ellison (t.p.ellison@gmail.com)
> >> IBM Java technology centre, UK.
> >>
> >> ---------------------------------------------------------------------
> >> Terms of use : http://incubator.apache.org/harmony/mailing.html
> >> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> >> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> >
> >
> >
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [general] *.boot.class.path propoerty setting
Posted by Tim Ellison <t....@gmail.com>.
Geir Magnusson Jr wrote:
> I was going to talk about the exact thing when I had a chance, so glad
> you beat me to it. I'm just changing the subject line so it's clearer.
>
> Inline.
>
> Alexey Varlamov wrote:
>> A bit offttopic for this thread, but I'd like to discuss the following
>> points for the boot.class.path property:
>> 1) Whose responsibility is to set this property (launcher, VM or
>> classlib)? Now we have at least 3 implementations:
>> a) readClassPathFromPropertiesFile() in
>> classlib\modules\archive\src\main\native\archive\windows\jclglob_harmony.c
>> b) readClassPathFromPropertiesFile() in
>> classlib\modules\luni\src\main\native\luni\shared\luniglob.c
>> c) load_full_api_files_path_names_list() in
>> drlvm\vm\vmcore\src\init\properties.cpp
>> BTW, the first 2 seems to be just copy-paste copies. I believe there
>> should be just single agent doing this task, most natural candidate is
>> shared VM launcher.
>
> I also thought the launcher was the right place, but not so sure, as you
> wouldn't want to handcuff the VM implementations as to what kinds of
> features they can add here. Maybe VM launcher sets it originally, but
> the VM is free to override?
Not in the launcher, it has to be set for any application that calls
JNI_CreateJavaVM.
>> 2) Current parsers of the bootclasspath.properties are fragile in
>> relation to format of this file: the file must end with line delimiter
>> and must have strict platform line delimiters, otherwise jvm just
>> hangs. Should I file new JIRA or this is intentional?
>
> Please file a JIRA. Hanging can never be intentional. :)
Agreed, create JIRAs for these problems.
Regards,
Tim
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
[general] *.boot.class.path propoerty setting (Was Re: [classlib]
[ldap] support for multiple VMs?)
Posted by Geir Magnusson Jr <ge...@pobox.com>.
I was going to talk about the exact thing when I had a chance, so glad
you beat me to it. I'm just changing the subject line so it's clearer.
Inline.
Alexey Varlamov wrote:
> A bit offttopic for this thread, but I'd like to discuss the following
> points for the boot.class.path property:
> 1) Whose responsibility is to set this property (launcher, VM or
> classlib)? Now we have at least 3 implementations:
> a) readClassPathFromPropertiesFile() in
> classlib\modules\archive\src\main\native\archive\windows\jclglob_harmony.c
> b) readClassPathFromPropertiesFile() in
> classlib\modules\luni\src\main\native\luni\shared\luniglob.c
> c) load_full_api_files_path_names_list() in
> drlvm\vm\vmcore\src\init\properties.cpp
> BTW, the first 2 seems to be just copy-paste copies. I believe there
> should be just single agent doing this task, most natural candidate is
> shared VM launcher.
I also thought the launcher was the right place, but not so sure, as you
wouldn't want to handcuff the VM implementations as to what kinds of
features they can add here. Maybe VM launcher sets it originally, but
the VM is free to override?
>
> 2) Current parsers of the bootclasspath.properties are fragile in
> relation to format of this file: the file must end with line delimiter
> and must have strict platform line delimiters, otherwise jvm just
> hangs. Should I file new JIRA or this is intentional?
Please file a JIRA. Hanging can never be intentional. :)
geir
>
>
> 2006/8/11, Tim Ellison <t....@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).
>>
>> 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
>>
>> --
>>
>> Tim Ellison (t.p.ellison@gmail.com)
>> IBM Java technology centre, UK.
>>
>> ---------------------------------------------------------------------
>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib] [ldap] support for multiple VMs?
Posted by Alexey Varlamov <al...@gmail.com>.
A bit offttopic for this thread, but I'd like to discuss the following
points for the boot.class.path property:
1) Whose responsibility is to set this property (launcher, VM or
classlib)? Now we have at least 3 implementations:
a) readClassPathFromPropertiesFile() in
classlib\modules\archive\src\main\native\archive\windows\jclglob_harmony.c
b) readClassPathFromPropertiesFile() in
classlib\modules\luni\src\main\native\luni\shared\luniglob.c
c) load_full_api_files_path_names_list() in
drlvm\vm\vmcore\src\init\properties.cpp
BTW, the first 2 seems to be just copy-paste copies. I believe there
should be just single agent doing this task, most natural candidate is
shared VM launcher.
2) Current parsers of the bootclasspath.properties are fragile in
relation to format of this file: the file must end with line delimiter
and must have strict platform line delimiters, otherwise jvm just
hangs. Should I file new JIRA or this is intentional?
2006/8/11, Tim Ellison <t....@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).
>
> 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
>
> --
>
> Tim Ellison (t.p.ellison@gmail.com)
> IBM Java technology centre, UK.
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib] [ldap] support for multiple VMs?
Posted by Alexey Varlamov <al...@gmail.com>.
[snip]
> >> 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?
> >>
> >
> > Besides, the luni init only recognizes "-Xbootclasspath:" runtime
> > parameter, but not "append"/"prepend" variants
> > ("-Xbootclasspath[/a|/p]:"). Yet another argument to unify and share
> > such code. Is there any reason to do this in classlib?
>
> Where else would you do it?
> As Tim mentioned earlier in this thread, we cannot do this in the launcher.
> Remember that the Harmony java launcher is not the only launcher that will
> ever run with Harmony code. If we put the bootclasspath.properties
> parsing code into the launcher, then that means anyone who writes their own
> launcher will get an empty bootclasspath unless they parse the file
> themselves.
I agree, launcher appears to be irrelevant to this task.
>
> IMHO, I would say that:
> - the launcher should not too Harmony specific. Anything special we do
> there
> may well have consequences for other more generic launchers.
> - the bootclasspath.properties file is read by classlib because it
> relates to the
> classlib component. It is a file that is specific to the Harmony
> classlib, and we should
> not expect any other component (launcher/VM) to have knowledge of it. If
> bootclasspath.properties parsing is moved out of classlib, there will also
> be a knock-on effect for VMs that use the Harmony classlib via
> classlibadapter,
> as they will no longer get the correct bootclasspath for free.
> - the VM should prepend its kernel jars to the bootclasspath. They are
> a part of the
> VM half of the Harmony runtime (i.e. any other VM provider would have to
> provide
> them in its VM bundle, as the IBM VME does), and thus should be handled
> by the
> VM itself. At the moment the kernel jars are called luni-kernel.jar and
> security-kernel.jar,
> but there is nothing to stop another VM wanting to call them something
> different and
> still use Harmony classlib. If the addition of the kernel jars to the
> bootclasspath was
> done in classlib, then only the hardcoded names would be valid. I think
> this adds
> another contract between the classlib and VM that is unnecessary. All
> classlib should
> expect is that the VM will provide those classes at runtime.
Evidently there must be some contract between VM(s) and classlib,
defining which artifacts of the classlib VM should use. Currently, VM
have to load certain shared libraries and somehow obtain (ordered)
list of jars for bootstrap. Surely, there are at least 2 ways:
1) Read the bootclasspath.properties file directly;
2) Load particular dll/so and query for particular property value.
Besides, this list may be extended or modified by the VM itself or by
user via some arguments like -Xbootclasspath (or more specific ones).
This basically means that only VM may define the complete list
reliably, and in some cases may not ever ask the classlib for it.
Now let's clarify usage context for this property. I'm aware of the following:
- it is used in classlib to lookup resources like available locales;
- it is used in classlib to spawn another VM process (via
-Xbootclasspath and such);
- it is quite possibly used by a VM to maintain actual bootpath;
Looking at the usage points, I'd say we better sync exact value of
"boot.class.path" property in classlib and actual bootclasspath in VM,
which includes all kernel and user's jars. This appears to be another
part of VM<>classlib contract - i.e. VM should be aware of this
property and when it is created and should update it with complete
value at certain moment. I guess IBM VME follows to this exactly.
One more issue, list of jars may be needed in VM already during
processing of init arguments, but loading classlib libraries is a bit
premature until arguments are processed completely.
Summing up the above, a compromise solution would be to provide a
common property-file-parser somewhere in a shared portlib and leave
everything else to VM (or classlibadapter - which is effectively VM
component). All the more there may be other VM-specific property
files, the parser would be handy anyway. And with proper instrumental
support, the "knock-on effect" would be quite minimal.
What do you think?
--
Alexey
>
> I think that what really needs to be done is to improve the code that is
> already, IMO,
> in the right place, rather than move it elsewhere.
>
> Regards,
> Oliver
>
> >
> > --
> > Alexey
> >
> >
> >>
> >> 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
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> >
> >
>
> --
> Oliver Deakin
> IBM United Kingdom Limited
>
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib] [ldap] support for multiple VMs?
Posted by Oliver Deakin <ol...@googlemail.com>.
Alexey Varlamov wrote:
> 2006/8/11, Gregory Shimansky <gs...@gmail.com>:
>> 2006/8/11, Tim Ellison <t....@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?
>>
>
> Besides, the luni init only recognizes "-Xbootclasspath:" runtime
> parameter, but not "append"/"prepend" variants
> ("-Xbootclasspath[/a|/p]:"). Yet another argument to unify and share
> such code. Is there any reason to do this in classlib?
Where else would you do it?
As Tim mentioned earlier in this thread, we cannot do this in the launcher.
Remember that the Harmony java launcher is not the only launcher that will
ever run with Harmony code. If we put the bootclasspath.properties
parsing code into the launcher, then that means anyone who writes their own
launcher will get an empty bootclasspath unless they parse the file
themselves.
IMHO, I would say that:
- the launcher should not too Harmony specific. Anything special we do
there
may well have consequences for other more generic launchers.
- the bootclasspath.properties file is read by classlib because it
relates to the
classlib component. It is a file that is specific to the Harmony
classlib, and we should
not expect any other component (launcher/VM) to have knowledge of it. If
bootclasspath.properties parsing is moved out of classlib, there will also
be a knock-on effect for VMs that use the Harmony classlib via
classlibadapter,
as they will no longer get the correct bootclasspath for free.
- the VM should prepend its kernel jars to the bootclasspath. They are
a part of the
VM half of the Harmony runtime (i.e. any other VM provider would have to
provide
them in its VM bundle, as the IBM VME does), and thus should be handled
by the
VM itself. At the moment the kernel jars are called luni-kernel.jar and
security-kernel.jar,
but there is nothing to stop another VM wanting to call them something
different and
still use Harmony classlib. If the addition of the kernel jars to the
bootclasspath was
done in classlib, then only the hardcoded names would be valid. I think
this adds
another contract between the classlib and VM that is unnecessary. All
classlib should
expect is that the VM will provide those classes at runtime.
I think that what really needs to be done is to improve the code that is
already, IMO,
in the right place, rather than move it elsewhere.
Regards,
Oliver
>
> --
> Alexey
>
>
>>
>> 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
>>
>>
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
--
Oliver Deakin
IBM United Kingdom Limited
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib] [ldap] support for multiple VMs?
Posted by Alexey Varlamov <al...@gmail.com>.
2006/8/11, Gregory Shimansky <gs...@gmail.com>:
> 2006/8/11, Tim Ellison <t....@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?
>
Besides, the luni init only recognizes "-Xbootclasspath:" runtime
parameter, but not "append"/"prepend" variants
("-Xbootclasspath[/a|/p]:"). Yet another argument to unify and share
such code. Is there any reason to do this in classlib?
--
Alexey
>
> 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
>
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib] [ldap] support for multiple VMs?
Posted by Gregory Shimansky <gs...@gmail.com>.
2006/8/11, Tim Ellison <t....@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
Re: [classlib] [ldap] support for multiple VMs?
Posted by Daniel Gandara <da...@neosur.com>.
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 (t.p.ellison@gmail.com)
> IBM Java technology centre, UK.
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib] [ldap] support for multiple VMs?
Posted by Tim Ellison <t....@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).
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
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org