Re: boot problem

[Matt Hogstrom <ma...@hogstrom.org>]

In HEAD now and 1.1 when it comes out there will be a message indicating if the 
JDK level your using isn't supported so people will at least have a heads up. 
Given JDK 6 is on the horizon this sounds like an additional dependency.  Dain, 
does XBean have this as one of the attributes so a check can be made?  I'd hate 
to see multiple CARs (one for each JVM level).

Paul McMahan wrote:
> Based on the number of problems people have encountered trying to use
> the 1.5 JRE I'd say this is a very prudent suggestion.  I personally
> like the second approach best because IIUC it doesn't affect the
> schema.  It might also be neat for Geronimo to have a stock GBean that
> compares the properties it gets passed against the runtime env and
> provides a clear error message and/or fails to start if they don't
> match. Applications/components with specific runtime reqs could
> optionally reference it in their plans.   Just a thought...
> 
> Best wishes,
> Paul
> 
> On 3/1/06, John Sisson <jr...@gmail.com> wrote:
> 
>>It sounds like we could run into this issue in the future where a
>>configuration (possibly provided by a third party) has a minimum JDK
>>requirement.
>>
>>Would it make sense to have the minimum JDK requirements in the plan XML
>>so we can gracefully skip loading configurations when the hosting VM
>>does not meet the requirements?
>>
>>Another approach could be to specify configuration activation criteria
>>(e.g. like Maven 2's activation element in the pom) so one could provide
>>an assembly with some configurations for specific JDK levels or possibly
>>for specific operating systems (e.g. if you have configurations that use
>>JNI to provides access to particular O/S features) where the
>>configurations only get started if they are running in the appropriate
>>environment.
>>
>>Not high priority, but thought it might be worth discussing for the future..
>>
>>John
>>
> 
> 
> 
> 

Re: boot problem

[Dain Sundstrom <da...@iq80.com>]

No this is not something XBean has addressed.  In the future we are  
going to lean on maven artifact for dependency resolution, and I  
think they have a way to have artifacts with multiple jar files each  
of which is targeted to a  specific jvm version.

-dain

On Mar 2, 2006, at 12:07 AM, Matt Hogstrom wrote:

> In HEAD now and 1.1 when it comes out there will be a message  
> indicating if the JDK level your using isn't supported so people  
> will at least have a heads up. Given JDK 6 is on the horizon this  
> sounds like an additional dependency.  Dain, does XBean have this  
> as one of the attributes so a check can be made?  I'd hate to see  
> multiple CARs (one for each JVM level).
>
> Paul McMahan wrote:
>> Based on the number of problems people have encountered trying to use
>> the 1.5 JRE I'd say this is a very prudent suggestion.  I personally
>> like the second approach best because IIUC it doesn't affect the
>> schema.  It might also be neat for Geronimo to have a stock GBean  
>> that
>> compares the properties it gets passed against the runtime env and
>> provides a clear error message and/or fails to start if they don't
>> match. Applications/components with specific runtime reqs could
>> optionally reference it in their plans.   Just a thought...
>> Best wishes,
>> Paul
>> On 3/1/06, John Sisson <jr...@gmail.com> wrote:
>>> It sounds like we could run into this issue in the future where a
>>> configuration (possibly provided by a third party) has a minimum JDK
>>> requirement.
>>>
>>> Would it make sense to have the minimum JDK requirements in the  
>>> plan XML
>>> so we can gracefully skip loading configurations when the hosting VM
>>> does not meet the requirements?
>>>
>>> Another approach could be to specify configuration activation  
>>> criteria
>>> (e.g. like Maven 2's activation element in the pom) so one could  
>>> provide
>>> an assembly with some configurations for specific JDK levels or  
>>> possibly
>>> for specific operating systems (e.g. if you have configurations  
>>> that use
>>> JNI to provides access to particular O/S features) where the
>>> configurations only get started if they are running in the  
>>> appropriate
>>> environment.
>>>
>>> Not high priority, but thought it might be worth discussing for  
>>> the future..
>>>
>>> John
>>>