You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Jason Dillon <ja...@planet57.com> on 2006/10/02 08:03:30 UTC
Conditionally loading modules based on expression (and environment)
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
Re: Conditionally loading modules based on expression (and environment)
Posted by Jason Dillon <ja...@planet57.com>.
I had considered using a gbean to handle the conditional bits, but
David Jencks meta-advised against it... basically saying he did not
like it. That and adding the attribute to <module> was soo easy.
--jason
On Oct 2, 2006, at 12:49 PM, Paul McMahan wrote:
> On 10/2/06, Jason Dillon <ja...@planet57.com> wrote:
>> Short of adding some warnings if modules are not loaded due to not
>> satisfying a condition... I don't see anything else in that thread
>> that is terrible useful. But maybe I missed something.
>
> Yeah, I think you got the crux of it. The main points of that idea
> were:
> - unsatisfied conditions can issue a warning or throw an error
> - implement the runtime check in a reusable gbean
> - allow conditionals to reference system properties
> Maybe you'll find something salvageable in that list.
>
> Best wishes,
> Paul
Re: Conditionally loading modules based on expression (and environment)
Posted by Paul McMahan <pa...@gmail.com>.
On 10/2/06, Jason Dillon <ja...@planet57.com> wrote:
> Short of adding some warnings if modules are not loaded due to not
> satisfying a condition... I don't see anything else in that thread
> that is terrible useful. But maybe I missed something.
Yeah, I think you got the crux of it. The main points of that idea were:
- unsatisfied conditions can issue a warning or throw an error
- implement the runtime check in a reusable gbean
- allow conditionals to reference system properties
Maybe you'll find something salvageable in that list.
Best wishes,
Paul
Re: Conditionally loading modules based on expression (and environment)
Posted by Jason Dillon <ja...@planet57.com>.
On Oct 2, 2006, at 6:48 AM, Paul McMahan wrote:
> +1 sounds like a great idea and would help limit the number of
> assemblies. I think the key is to keep the syntax simple and the
> runtime reqs to a minimum, limiting the functionality if necessary to
> achieve this. I don't know much about Jexl but it sounds like you've
> found a good candidate. FYI there was some good discussion about this
> issue a few months ago and some similar ideas came out that you might
> want to consider combining with your idea:
> http://mail-archives.apache.org/mod_mbox/geronimo-dev/200604.mbox/%
> 3c44513B9E.2080900@hogstrom.org%3e
Had to track down this thread in nabble... mail-archives.apache.org
is a PITA to use... :-(
Short of adding some warnings if modules are not loaded due to not
satisfying a condition... I don't see anything else in that thread
that is terrible useful. But maybe I missed something.
--jason
Re: Conditionally loading modules based on expression (and environment)
Posted by Jason Dillon <ja...@planet57.com>.
> I think the key is to keep the syntax simple and the
> runtime reqs to a minimum, limiting the functionality if necessary to
> achieve this. I don't know much about Jexl but it sounds like you've
> found a good candidate.
I think that Jexl is probably the best and easiest solution for now.
As I said before we could roll our own parser, but we'd want to have
most of the syntax/features that is in Jexl. I think the cost of
fixing bugs and other maintenance of our own parser is not worth the
trouble to save a few kb. Jexl only depends on commons-logging,
which we already pull in lib/* so there is no other hidden bloat.
For functions though, my test was using commons-lang's SystemUtils
for all of its JDK version/vendor muck... which does not justify the
other 150k of fluff that comes with it. So its probably best to just
pluck out the needed sources into a few function objects rather than
add this guy to the boot cp.
--jason
Re: Conditionally loading modules based on expression (and environment)
Posted by Paul McMahan <pa...@gmail.com>.
+1 sounds like a great idea and would help limit the number of
assemblies. I think the key is to keep the syntax simple and the
runtime reqs to a minimum, limiting the functionality if necessary to
achieve this. I don't know much about Jexl but it sounds like you've
found a good candidate. FYI there was some good discussion about this
issue a few months ago and some similar ideas came out that you might
want to consider combining with your idea:
http://mail-archives.apache.org/mod_mbox/geronimo-dev/200604.mbox/%3c44513B9E.2080900@hogstrom.org%3e
Best wishes,
Paul
Re: Conditionally loading modules based on expression (and environment)
Posted by Jason Dillon <ja...@planet57.com>.
On Oct 2, 2006, at 10:23 AM, Prasad Kashyap wrote:
> We should change the schema such that the conditions are neatly
> presented, more like in a xml format than like in java code style. The
> condition string value has the potential to become a very long string
> and thus difficult to read.
>
> <module name="org.apache.geronimo.configs/hot-deployer/$
> {pom.version}/car"
> condition="SystemUtils.IS_JAVA_1_5 and SystemUtils.JAVA_VENDOR
> == 'sun'"/>
I do not really anticipate that many modules will need to use this,
and I also think that the actual syntax needed to do the above check
will be much more terse.
The advantage of using a single attribute and a simple expression
language to process conditions is... well that it is simple and does
not require much change on the server to implement. I think if we
changed the schema to add more condition fluff as elements we
complicate things way to much for a feature that is intended to be
used infrequently... it also starts to make the attributes xml schema
look more like jelly which would be really poor direction.
Anyways, this is meant to be a simple hook to get some extra runtime
module selection into the JVM quick (and not too dirty and not need
to much heavy lifting). I imagine that if we start to see people
using this more, or if we start using it more to condense assemblies,
then we can revisit.
--jason
Re: Conditionally loading modules based on expression (and environment)
Posted by Prasad Kashyap <go...@gmail.com>.
+1
We should change the schema such that the conditions are neatly
presented, more like in a xml format than like in java code style. The
condition string value has the potential to become a very long string
and thus difficult to read.
<module name="org.apache.geronimo.configs/hot-deployer/${pom.version}/car"
condition="SystemUtils.IS_JAVA_1_5 and SystemUtils.JAVA_VENDOR == 'sun'"/>
But definitely a good idea with benefits.
Cheers
Prasad
On 10/2/06, Jason Dillon <ja...@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
>
Re: [REVIEW] Conditionally loading modules based on expression (and environment)
Posted by Jason Dillon <ja...@planet57.com>.
For the simple expressions we are using I don't think it matters...
and the jexl bits are already coded... once this is committed, if you
guys still want ognl we can look at replacing it. But right now I
don't care enough to change it.
--jason
On Oct 5, 2006, at 11:07 AM, Dain Sundstrom wrote:
> 40k is nothing so I don't think that should be the deciding factor.
>
> I personally think we should go with ognl on rep alone. I hear
> nothing but bad things about jexl and only praise for ognl.
>
> -dain
>
> On Oct 5, 2006, at 10:57 AM, Jason Dillon wrote:
>
>> ognl-2.6.9.jar is 164k compared to 129k for commons-jexl... so I'm
>> inclined to use jexl for now based on its size and relative
>> simplicity.
>>
>> --jason
>>
>>
>> On Oct 4, 2006, at 8:45 PM, Hiram Chirino wrote:
>>
>>> btw.. ongl might also be a good canidate to use as an expression
>>> language.
>>>
>>> On 10/4/06, Jason Dillon <ja...@planet57.com> wrote:
>>>> I cleaned up my quick POC into a patch suitable to be applied to
>>>> trunk:
>>>>
>>>> https://issues.apache.org/jira/browse/GERONIMO-2463
>>>>
>>>> Please review. If there are no objections I will apply this
>>>> over the
>>>> weekend.
>>>>
>>>> Thanks,
>>>>
>>>> --jason
>>>>
>>>>
>>>
>>>
>>> --
>>> Regards,
>>> Hiram
>>>
>>> Blog: http://hiramchirino.com
>
Re: [REVIEW] Conditionally loading modules based on expression (and environment)
Posted by Jason Dillon <ja...@planet57.com>.
I take it back... if ognl provides better errors when a syntax
problem occurs... then its probably better than jexl, since I spent a
few hours yesterday discovering that jexl does not handle public
field accessors... and does so quietly.
Anyone used ognl before know if it does?
--jason
On Oct 5, 2006, at 11:07 AM, Dain Sundstrom wrote:
> 40k is nothing so I don't think that should be the deciding factor.
>
> I personally think we should go with ognl on rep alone. I hear
> nothing but bad things about jexl and only praise for ognl.
>
> -dain
>
> On Oct 5, 2006, at 10:57 AM, Jason Dillon wrote:
>
>> ognl-2.6.9.jar is 164k compared to 129k for commons-jexl... so I'm
>> inclined to use jexl for now based on its size and relative
>> simplicity.
>>
>> --jason
>>
>>
>> On Oct 4, 2006, at 8:45 PM, Hiram Chirino wrote:
>>
>>> btw.. ongl might also be a good canidate to use as an expression
>>> language.
>>>
>>> On 10/4/06, Jason Dillon <ja...@planet57.com> wrote:
>>>> I cleaned up my quick POC into a patch suitable to be applied to
>>>> trunk:
>>>>
>>>> https://issues.apache.org/jira/browse/GERONIMO-2463
>>>>
>>>> Please review. If there are no objections I will apply this
>>>> over the
>>>> weekend.
>>>>
>>>> Thanks,
>>>>
>>>> --jason
>>>>
>>>>
>>>
>>>
>>> --
>>> Regards,
>>> Hiram
>>>
>>> Blog: http://hiramchirino.com
>
Re: [REVIEW] Conditionally loading modules based on expression (and environment)
Posted by Jason Dillon <ja...@planet57.com>.
Okay, I implemented a ognl condition parser... it appears that the
similar syntax can be used... so "!java.is1_5" appears to work in both.
Not sure which is better though, both provide some sort of syntax
errors... neither complains about invalid variable references.
I will update the patch with both impls and a few tests... and then
we can pick one.
--jason
On Oct 5, 2006, at 11:07 AM, Dain Sundstrom wrote:
> 40k is nothing so I don't think that should be the deciding factor.
>
> I personally think we should go with ognl on rep alone. I hear
> nothing but bad things about jexl and only praise for ognl.
>
> -dain
>
> On Oct 5, 2006, at 10:57 AM, Jason Dillon wrote:
>
>> ognl-2.6.9.jar is 164k compared to 129k for commons-jexl... so I'm
>> inclined to use jexl for now based on its size and relative
>> simplicity.
>>
>> --jason
>>
>>
>> On Oct 4, 2006, at 8:45 PM, Hiram Chirino wrote:
>>
>>> btw.. ongl might also be a good canidate to use as an expression
>>> language.
>>>
>>> On 10/4/06, Jason Dillon <ja...@planet57.com> wrote:
>>>> I cleaned up my quick POC into a patch suitable to be applied to
>>>> trunk:
>>>>
>>>> https://issues.apache.org/jira/browse/GERONIMO-2463
>>>>
>>>> Please review. If there are no objections I will apply this
>>>> over the
>>>> weekend.
>>>>
>>>> Thanks,
>>>>
>>>> --jason
>>>>
>>>>
>>>
>>>
>>> --
>>> Regards,
>>> Hiram
>>>
>>> Blog: http://hiramchirino.com
>
Re: [REVIEW] Conditionally loading modules based on expression (and environment)
Posted by Dain Sundstrom <da...@iq80.com>.
40k is nothing so I don't think that should be the deciding factor.
I personally think we should go with ognl on rep alone. I hear
nothing but bad things about jexl and only praise for ognl.
-dain
On Oct 5, 2006, at 10:57 AM, Jason Dillon wrote:
> ognl-2.6.9.jar is 164k compared to 129k for commons-jexl... so I'm
> inclined to use jexl for now based on its size and relative
> simplicity.
>
> --jason
>
>
> On Oct 4, 2006, at 8:45 PM, Hiram Chirino wrote:
>
>> btw.. ongl might also be a good canidate to use as an expression
>> language.
>>
>> On 10/4/06, Jason Dillon <ja...@planet57.com> wrote:
>>> I cleaned up my quick POC into a patch suitable to be applied to
>>> trunk:
>>>
>>> https://issues.apache.org/jira/browse/GERONIMO-2463
>>>
>>> Please review. If there are no objections I will apply this over
>>> the
>>> weekend.
>>>
>>> Thanks,
>>>
>>> --jason
>>>
>>>
>>
>>
>> --
>> Regards,
>> Hiram
>>
>> Blog: http://hiramchirino.com
Re: [REVIEW] Conditionally loading modules based on expression (and environment)
Posted by Jason Dillon <ja...@planet57.com>.
ognl-2.6.9.jar is 164k compared to 129k for commons-jexl... so I'm
inclined to use jexl for now based on its size and relative simplicity.
--jason
On Oct 4, 2006, at 8:45 PM, Hiram Chirino wrote:
> btw.. ongl might also be a good canidate to use as an expression
> language.
>
> On 10/4/06, Jason Dillon <ja...@planet57.com> wrote:
>> I cleaned up my quick POC into a patch suitable to be applied to
>> trunk:
>>
>> https://issues.apache.org/jira/browse/GERONIMO-2463
>>
>> Please review. If there are no objections I will apply this over the
>> weekend.
>>
>> Thanks,
>>
>> --jason
>>
>>
>
>
> --
> Regards,
> Hiram
>
> Blog: http://hiramchirino.com
Re: [REVIEW] Conditionally loading modules based on expression (and environment)
Posted by Hiram Chirino <hi...@hiramchirino.com>.
btw.. ongl might also be a good canidate to use as an expression language.
On 10/4/06, Jason Dillon <ja...@planet57.com> wrote:
> I cleaned up my quick POC into a patch suitable to be applied to trunk:
>
> https://issues.apache.org/jira/browse/GERONIMO-2463
>
> Please review. If there are no objections I will apply this over the
> weekend.
>
> Thanks,
>
> --jason
>
>
--
Regards,
Hiram
Blog: http://hiramchirino.com
[REVIEW] Conditionally loading modules based on expression (and environment)
Posted by Jason Dillon <ja...@planet57.com>.
I cleaned up my quick POC into a patch suitable to be applied to trunk:
https://issues.apache.org/jira/browse/GERONIMO-2463
Please review. If there are no objections I will apply this over the
weekend.
Thanks,
--jason
Re: Conditionally loading modules based on expression (and environment)
Posted by Rick McGuire <ri...@gmail.com>.
Jason Dillon 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?
+1 This certainly would have made life a lot easier trying to sort out
the Yoko/sunorb stuff.
>
> --jason
>
Re: Conditionally loading modules based on expression (and environment)
Posted by Hiram Chirino <hi...@hiramchirino.com>.
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 <ja...@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 <ja...@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 <ja...@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
Re: Conditionally loading modules based on expression (and environment)
Posted by Jason Dillon <ja...@planet57.com>.
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 <ja...@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 <ja...@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
Re: Conditionally loading modules based on expression (and environment)
Posted by Hiram Chirino <hi...@hiramchirino.com>.
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 <ja...@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 <ja...@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 <ja...@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
Re: Conditionally loading modules based on expression (and environment)
Posted by Jason Dillon <ja...@planet57.com>.
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 <ja...@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 <ja...@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
>> >>
>>
>>
Re: Conditionally loading modules based on expression (and environment)
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
On 10/5/06, Jason Dillon <ja...@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 <ja...@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
> >>
>
>
Re: Conditionally loading modules based on expression (and environment)
Posted by Jason Dillon <ja...@planet57.com>.
The idea was to get something working now... and then refactor later.
--jason
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 <ja...@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
>>
Re: Conditionally loading modules based on expression (and environment)
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
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 <ja...@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
>