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 Sun, 08 Oct 2006 04:11:58 GMT
not sure.. it might if the classloader is setup right.  If the classloader
is doing child first delegation, then I think so.. but I don't think this is
always the case.

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


-- 
Regards,
Hiram

Blog: http://hiramchirino.com

Mime
View raw message