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:54:42 GMT
If another version of jexl or ognl is in the apps classpath (ear,  
war, whatever) won't that be used instead of the version on the boot  
classpath?

--jason


On Oct 7, 2006, at 1:41 PM, Hiram Chirino wrote:

> 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