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 <[EMAIL PROTECTED]> 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
