geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Dillon <ja...@planet57.com>
Subject Re: Conditionally loading modules based on expression (and environment)
Date Thu, 05 Oct 2006 17:36:49 GMT
The idea was to get something working now... and then refactor later.

--jason


On Oct 5, 2006, at 4:33 AM, Aaron Mulder wrote:

> The plugins should use this, since they have similar restrictions at
> install time but not at runtime.  It would be nice to carry that over
> so any installed Java 1.5-only plugins just wouldn't start if you
> started Geronimo under Java 1.4.
>
> Still, if you try to start a module manually (with the deploy tool or
> console), it won't go through the same logic, right?  It would just
> let you load it I think.  We should hook the module load process into
> that same conditional logic, which I think argues that we may want it
> to be a separate GBean rather than part of the persistent
> configuration list.  (The load logic is in ConfigurationManager I
> think.)
>
> Thanks,
>      Aaron
>
> On 10/2/06, Jason Dillon <jason@planet57.com> wrote:
>> Hi all... I was chatting with David Jencks in IRC today about GShell
>> and when server/trunk might be built with Java 1.5 and then it
>> occurred to me that if config.xml could include some extra
>> configuration to specify what version of Java a module required, that
>> we could ship an assembly with GShell but only enable it on JDK 1.5
>> since it requires 1.5 to run.
>>
>> And then it occurred to me that we could use this same mechanism to
>> load a Yoko ORB module or a Sun ORB based on one config and one
>> assembly... and then I thought that if we had a configuration for
>> GShell built against 1.5, and then another that was retrostranslated,
>> then we could define a module that would enable on 1.4 and another on
>> 1.5 and have both supported under one configuration.  Now I am not
>> suggesting that we actually do that, but if we had a flexible way to
>> define a condition for a module to load, then we certainly could if
>> we wanted to.
>>
>> So I took a stab at a quick example of how this might work.  I added
>> a new attribute to local-attributes.xsd to the moduleType/
>> configurationType called "condition" which is a plain string.  Then
>> in ConfigurationOverride I added a field of the same name that gets
>> initialized to the value, and then changed isLoad to:
>>
>>      public boolean isLoad() {
>>          return load && parseCondition();
>>      }
>>
>> And added parseCondition(), which at the moment just uses a simple
>> JexlExpression to evaluate the text to a boolean.  To give the
>> expression access to some system bits I bound a SystemUtils instance
>> (from commons-lang) and then ran some simple tests like:
>>
>>      <module name="org.apache.geronimo.configs/remote-deploy-jetty/$
>> {pom.version}/car"
>>          condition="!SystemUtils.IS_JAVA_1_5"/>
>>
>>      <module name="org.apache.geronimo.configs/hot-deployer/$
>> {pom.version}/car"
>>          condition="SystemUtils.IS_JAVA_1_5 and
>> SystemUtils.JAVA_VENDOR == 'sun'"/>
>>
>> In these examples, remote-deploy-jetty will only be loaded if the JVM
>> is not 1.5 and hot-deployer will only be loaded if the JVM is 1.5 and
>> the vendor is 'sun'.
>>
>> It appears to work well and I believe this adds some extra ability to
>> our configuration which can help to provide better JDK version
>> compatibility or vendor compatibility without needing to create new
>> assemblies.
>>
>> I believe that only a small number of modules would need to use the
>> "condition" and modules which do not provide a condition will
>> automatically evaluate to true (so they will load with no changes).
>> So, adding this feature will not break any existing configurations,
>> it only adds some new functionality.
>>
>> We could roll our own parser, though I think that Jexl is fairly
>> robust and flexible enough and not too big at ~130k.  Probably want
>> to define some helper objects to provide the functionality that gets
>> picked up from commons-lang as most of that stuff does not need to be
>> there... or we could simply extract a few classes out of the jar to
>> include in the boot classpath.
>>
>> Right now I only added this to module configurations, but it should
>> also be easy enough to expose this to gbean's too... so a module
>> could define a set of gbeans that would conditional load based on
>> configuration.  Basically add the same bits to GBeanOverrides adding
>> the "condition" attribute to be processed on isLoad(), blah, blah,  
>> blah.
>>
>>   * * *
>>
>> Any comments?
>>
>> --jason
>>


Mime
View raw message