You are viewing a plain text version of this content. The canonical link for it is here.
Posted to pluto-dev@portals.apache.org by Eric Dalquist <er...@doit.wisc.edu> on 2008/02/06 16:00:17 UTC
Re: Alternative to org.apache.pluto.useJaxp system property for 1.1.5
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
> ||
>
> ||
>
Re: Alternative to org.apache.pluto.useJaxp system property for 1.1.5
Posted by Eric Dalquist <er...@doit.wisc.edu>.
Here it is: https://issues.apache.org/jira/browse/PLUTO-465
Unfortunately the patch uses a static initializer but without doing
further changes in the runtime code of the
AbstractCastorDescriptorService that appears to be the only option. The
static initializer should be safe and all possible exceptions should be
handled.
-Eric
Elliot Metsger wrote:
>
>
> 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
>>>>> ||
>>>>>
>>>>> ||
>>>>>
>>>>
Re: Alternative to org.apache.pluto.useJaxp system property for 1.1.5
Posted by Elliot Metsger <em...@jhu.edu>.
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
>>>> ||
>>>>
>>>> ||
>>>>
>>>
Re: Alternative to org.apache.pluto.useJaxp system property for 1.1.5
Posted by Eric Dalquist <er...@doit.wisc.edu>.
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).
>
> 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
>>> ||
>>>
>>> ||
>>>
>>
Re: Alternative to org.apache.pluto.useJaxp system property for 1.1.5
Posted by Elliot Metsger <em...@jhu.edu>.
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
>> ||
>>
>> ||
>>
>