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 Sat, 07 Oct 2006 20:31:22 GMT
This is in... I created a Jexl and Ongl parser... using Jexl at the  
moment.  Need to pick one and then tidy up the boot classpath,  
created GERONIMO-2474 to track this.

Also, created GERONIMO-2475 to track extending the scope to include  
plugins, etc.

--jason


On Oct 5, 2006, at 10:50 AM, Aaron Mulder wrote:

> On 10/5/06, Jason Dillon <jason@planet57.com> wrote:
>> The idea was to get something working now... and then refactor later.
>
> No problem -- once you check it in let's put in a Jira to link it up
> for runtime start operations too.
>
> Thanks,
>     Aaron
>
>> 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