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 <[EMAIL PROTECTED]>:
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 ([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]
--
Oliver Deakin
IBM United Kingdom Limited
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
