geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hiram Chirino" <hi...@hiramchirino.com>
Subject Re: Conditionally loading modules based on expression (and environment)
Date Sat, 07 Oct 2006 20:41:05 GMT
BTW.. hate to bring this up.. but since both jexl and ongl are libraries
that apps would use, doesn't putting them in the boot classpath potentially
break user level apps?  I thinking at best the user is locked into using
geronimo's version of the lib and at worst jexl/ongl won't be able to load
user classes.

On 10/7/06, Jason Dillon <jason@planet57.com> wrote:
>
> 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
> >> >>
> >>
> >>
>
>


-- 
Regards,
Hiram

Blog: http://hiramchirino.com

Mime
View raw message