You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Geir Magnusson Jr <ge...@pobox.com> on 2006/08/11 15:24:53 UTC
[general] *.boot.class.path propoerty setting (Was Re: [classlib]
[ldap] support for multiple VMs?)
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: [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