geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rex Wang <>
Subject Re: Geronimo 3 and karaf 3
Date Tue, 20 Dec 2011 16:18:26 GMT
2011/12/20 David Jencks <>

> I've been spending a lot of time working to rebase geronimo on karaf 3 so
> we can have a maintainable future and get stuff like osgi 4.3, up to date
> aries components, and the experimental region support now in karaf.
> After a lot of work I have everything except clustering building and after
> turning off a couple problematic modules the tomcat-javaee6 server starts
> and the web admin console appears to work at least a little bit.   I'd like
> a little vacation this year and would like to commit this work first so
> that others can help with the loose ends if they like.  I'll probably be
> around to answer questions in any case.
> The modules that don't start are:
> activemq-broker-blueprint.  The ${X + Y} stuff is not getting evaluated at
> all.  I don't know if this is an xbean-blueprint problem or an aries
> blueprint problem or a side effect of running in geronimo.
> As a result activemq-ra and tomcat-console-activemq can't be started.

Hi David, neither xbean-blueprint nor aries-blueprint can correctly do such
evaluation. So for 3.0-beta-1 release, I provided an  interim fix of
Aries-727 and  release our aries-blueprint in external folder:

However, we should not use this approach for trunk. I had refactored the
codes in Aries-727 based on the discussion in Aries mailing list. The new
approach has been applied to Aries trunk.
The current approach is as following:
1, depends on following
org.apache.aries.blueprint.jexl.evaluator-0.1.1-SNAPSHOT (

2. use the new namespace blueprint-ext 1.2.0

3. use the ext:property-placeholder with the new attribute *evaluator="jexl"
* to do evaluation
<ext:property-placeholder placeholder-prefix="$["
         placeholder-suffix="]" ignore-missing-locations="true"
        system-properties="override" *evaluator="jexl"*>
             <ext:property name="name" value="value" />
            <ext:property name="a" value="Hello " />
            <ext:property name="b" value="FooBar" />

<bean id="bar" class="org.apache.aries.blueprint.sample.Bar">
        <property name="value" value="$[a+b]">

basically, this will make the blueprint bundle reference a
"PropertyEvaluator" service with the property "" to do the evaluate.

Hope this helps, and I can help fix this issue after your commit.

Merry Christmas and happy new year!


> client-deployer.  I think this is a pretty simple gbean name problem but I
> haven't looked into it.
> Here are some of the changes:
> -- assemble the server using a combination of karaf assembly from features
> and kars and geronimo assembly from geronimo plugins.  We now use the same
> base karaf assembly stuff as the normal default full karaf assembly (except
> I might have left out the spring feature repository).
> -- basic geronimo components such as the kernel, configuration manager,
> dependency manager, deployer, and service config builder are set up as osgi
> declarative services so they start without any geronimo configuration.
>  They are generally configured through config admin as appropriate.  Most
> of these also have gbean wrappers so they can be accessed through gbean
> references.
> -- "geronimo" is started from a DS component, EmbeddedDaemon.
> -- I think I'm using the karaf remote jmx security rather than ours.  The
> capabilities are similar but not identical.
> Some other things that are not working yet:
> -- The (gogo) geronimo console commands that work through "remote" gbean
> proxies don't work AFAIK.  Probably one way to fix this would be to expose
> some more of the DS components using gbean wrappers, but I haven't looked
> into this yet.
> -- the app client (as well as the client-deployer) is not working yet at
> all.  We may be able to use command line args to tell the EmbeddedDaemon
> it's an app client, or possibly not.  We may be able to use a karaf
> instance to supply different ConfigAdmin settings to e.g. the local
> attribute manager to convince it it's an app client.  Similarly the
> separate console-like things presumably won't work either.
> -- the EditableConfigurationManager needs to be replaced by a separate
> component that edits the configuration it gets from the normal
> configuration manager.  I think this affects some part of the admin console.
> I'f there's no strong opposition I'd like to commit this tomorrow.
> Many thanks
> david jencks

Lei Wang (Rex)
rwonly AT

View raw message