Eric Dalquist wrote:
I figured you'd just been ignoring me ;)
Awww :)
I would be using one of these solutions to set the property if needed. I
think the JDK sniffing would be the easiest and actually the most
reliable. If you look
athttp://java.sun.com/j2se/1.5.0/docs/api/java/lang/System.html#getProperties()
you get a list of all of the properties a JDK will provide. From those
descriptions I believe the "java.specification.version" will have a
simple X.Y version number string representing the Java spec version the
JVM implements regardless of JVM vendor.
I'll get a patch whipped up this week and submit a Jira issue for the work.
Awesome :)
E
-Eric
Elliot Metsger wrote:
Hey Eric,
Sorry I've been offline for a few days.
Would you be using one of your proposed solutions to set
org.apache.pluto.useJaxp or would you prefer to just remove the
property all together? Note that 1.1.4 uses this property so as hacky
as it is it should probably still be supported (the original issue is
https://issues.apache.org/jira/browse/PLUTO-347).
I'm fine with the most simplest solution, #1. I'm not a fan of JVM
sniffing - I have no real experience on any other JVM's but Sun - but
it seems simple enough and if anyone complains we can probably patch
it pretty easily.
What do you think?
E
Eric Dalquist wrote:
I realized I sent this to the -user list the first time. Any thoughts
on this issue?
Thanks,
-Eric
Eric Dalquist wrote:
I would like to propose an alternative to the
org.apache.pluto.useJaxp system property. The problem with the
property for our use case is we know the user will be running in a
JDK1.5+ environment and we would like a way to ensure JAXP is used
by Pluto without having to make sure the user has configured the
start scripts for their container correctly.
I have a few ideas for possible solutions:
1. Simple JDK version checking. Use
System.getProperty("java.specification.version") to determine the
JDK version and choose the appropriate Castor configuration to use.
That property returns values such as: 1.1, 1.2, 1.3, ...
2. Look for a pluto_descriptor.properties file in the classpath.
Before checking the system property check if a file
/pluto_descriptor.properties exists in the classpath and read the
property from that file. That would allow Pluto implementers to
include a .properties file with the correct configuration for their
portal.
3. Make a portal callback API to determine the configuration. This
would be fairly complex as I'm thinking the descriptor service would
need to queue up parsing of the descriptor XML files until the
portal context was up and running and could provide the configuration.
I'm more than happy to implement any of the solutions or consider
others.
Thanks
-Eric
||
||
