geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aaron Mulder" <ammul...@alumni.princeton.edu>
Subject Re: Conditionally loading modules based on expression (and environment)
Date Thu, 05 Oct 2006 11:33:06 GMT
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