2011/12/20 David Jencks <[email protected]> > 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: http://svn.apache.org/repos/asf/geronimo/external/tags/blueprint-0.3.0.1/ 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.core-0.4.1-SNAPSHOT org.apache.aries.blueprint.jexl.evaluator-0.1.1-SNAPSHOT ( http://svn.apache.org/repos/asf/aries/trunk/blueprint/blueprint-jexl-evaluator/ ) 2. use the new namespace blueprint-ext 1.2.0 xmlns:ext="http://aries.apache.org/blueprint/xmlns/blueprint-ext/v1.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:default-properties> <ext:property name="name" value="value" /> <ext:property name="a" value="Hello " /> <ext:property name="b" value="FooBar" /> </ext:default-properties> <ext:location>file:///url</ext:location> </ext:property-placeholder> <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 " org.apache.aries.blueprint.ext.evaluator.name=jexl" to do the evaluate. Hope this helps, and I can help fix this issue after your commit. Merry Christmas and happy new year! -Rex > > 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 apache.org
