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 17:50:04 GMT
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