Re: Alternative to org.apache.pluto.useJaxp system property for 1.1.5

[Eric Dalquist]

I figured you'd just been ignoring me ;)

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.

-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).

What do you think?

E


Eric Dalquist wrote:

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.

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:










Thanks
-Eric
||

||

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.

smime.p7s
Description: S/MIME Cryptographic Signature