| 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 < [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
>> >>
>>
>>
--
Regards,
Hiram
Blog: http://hiramchirino.com |
