geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: Geronimo 3 and karaf 3
Date Tue, 20 Dec 2011 18:13:51 GMT
OK, I just committed this stuff, with reference to GERONIMO-6240.

Some more hints....

I can build all the way through with 
MAVEN_OPTS="-XX:MaxPermSize=2048m -Xms2048m -Xmx4096m"

I can start karaf after setting

export JAVA_MAX_MEM=2048m
export JAVA_MAX_PERM_MEM=512m

The car packaging is set up to stop and wait if it gets stuck.  In an earlier version of this
you'd get the karaf console and you could use karaf commands to investigate what was going
on.  For some reason this isn't working now.  If you get into this situation, you need to
kill the maven java process some way.  Usually setting a breakpoint at DependencyManager line
571 will show you a bundle that has a resolution problem that you can then fix.

The problem with the console deploy-type commands I think relates to using the karaf RMIRegistry.
 I'm going to modify it so it includes the port as a service property, then we can look for
the osgi service and get its port instead of the port gbean attribute.

thanks
david jencks

On Dec 19, 2011, at 9:10 PM, David Jencks wrote:

> more not-yet-working inline
> 
> On Dec 19, 2011, at 5:08 PM, David Jencks wrote:
> 
>> 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.
>> 
>> 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 couldn't get the xml stream 1.2 and jaxb 2.2 to work with the spec jars as bundles.
   According to http://servicemix.396122.n5.nabble.com/DISCUSS-Enhance-specs-to-work-better-with-JRE-td5001108.html
even if you do get them to work (as we seem to have up to now by not exposing the packages
from the framework) that breaks other stuff.  I think we need to investigate the karaf-activator
stuff guillaume wrote and adapt our specs to use it.  At the moment I have the framework lying
and claiming later versions for the xmlstream and jaxb packages.  I haven't found any documentation
for karaf-activator yet.
> 
> -- the build uses a lot more memory.  I typically run out of permgen twice during the
build with MAVEN_OPTS =  -XX:MaxPermSize=512m -Xms1024m -Xmx2048m
> 
> -- startup AFAIK only works as ./bin/karaf -l rather than our geronimo scripts.  Again,
I have to increase memory settings for the server to fully start.
> 
>> 
>> 
>> I'f there's no strong opposition I'd like to commit this tomorrow.
>> 
>> Many thanks
>> david jencks
>> 
> 
> david jencks


Mime
View raw message