Hi Charles, I've spent a very large amount of my time over the last year working towards basically this goal. Unfortunately most of the results are not public at the moment, being on my local git repo. If anyone is interested in actually looking at them I can see about making a github branch for the most advanced version of this stuff.
I wasn't all that successful with modifying the existing geronimo module/component framework to fit into osgi. There's a lot of useful integration code in geronimo, but tying it to the gbean/configuration framework makes it very hard to make osgi friendly. On the other hand I have been able to provide karaf with the facilities (working feature and kar creation, and working server assembly) so the idea of assembling something with geronimo's capabilities on top of karaf is plausible. At the moment I think the best way to proceed on such a project is to, module by module, convert the existing code to pure-osgi. For instance I've modified the connector/transaction components this way in my sandbox. Once we have several of the modules working in this way we could start thinking about running at least parts of the tck against it. There is quite a bit of useful functionality in the geronimo admin console. However, it's all written in portlets since at the time that was the only plausible way we could find to get an extensible web app. (I still don't know exactly how karaf web console works, whether it provides navigation similar to the g. console, etc). So I think we'd want to look into providing the useful bits in a way that integrates with the karaf console. I'm hoping to commit in the next day or two some work that moves geronimo to karaf 3 and actually uses karaf rather than copying and modifying the startup code. I'm not sure this will be a fully functioning server right off but at least would bring geronimo more up to date. If anyone is interested in pursuing specific bits of this I think the places to start would be with jpa, replacing our stuff as much as possible with the aries jpa code, and turning the geronimo jacc and jaspic security code into appropriate osgi services. One question to consider is whether to preserve geronimo's historical idea of processing all spec deployment plans (e.g. web.xml), annotations, and vendor deployment plans (geronimo-web.xml) into a single set of info and recording that the bundleized javaee app (or in a bundle's data area for a "javaee bundle" such as a wab) or whether to process all this info every time the bundle is started. I think that processing it once and saving the results is reasonable, but at least one component (openwebbeans) doesn't fit this model at all. Possibly some intermediate idea such as caching the set of annotated classes would work. In any case, all help is welcome, but expect this to be a lot of work, even before we get to the tck. thanks david jencks On Dec 15, 2011, at 1:55 AM, Charles Moulliard wrote: > Hi, > > Within mailing list of Karaf, we have started a discussion about the > idea to have a KarafEE release. This idea is similar to the reflection > that OpenEJB team has had with TomEE but using Tomcat as Java > Application Server. As Geronimo uses Karaf as their kernel (which is > not the case for Glassfish, JBoss, Eclipse Virgo, ...) that makes a > lot of sense that we continue to promote karaf as platform not only > for Integration Server like ServiceMix but also for J2EE platform. > Since EJB3 spec and CDI, we see more and more projects interested to > have/use an EJB container on Karaf and use it as an alternative to > Spring (Dynamic Module/Blueprint). Developing a server, certify it, > cost a lot. > > As we we do not want to re-invent the wheel and due to number of > resources available, we prefer to capitalize on the work/efforts done. > This is why we come to you to discuss the idea about collaborating > together to improve existing geronimo-karaf platform to address points > mentioned in this thread > (http://karaf.922171.n3.nabble.com/Proposition-Apache-KarafEE-td3585332.html) > to be able to provide a KarafEE or Geronimo distro but using "features > mechanism" of Karaf to deploy OpenEJB, OpenJPA, new Karaf web console, > ... > > What do you think about that ? > > Regards, > > Charles Moulliard > > Apache Committer > > Blog : http://cmoulliard.blogspot.com > Twitter : http://twitter.com/cmoulliard > Linkedin : http://www.linkedin.com/in/charlesmoulliard > Skype: cmoulliard > > > > > ---------- Forwarded message ---------- > From: James Strachan <[email protected]> > Date: Thu, Dec 15, 2011 at 9:54 AM > Subject: Re: [Proposition] - Apache KarafEE > To: [email protected] > > > Given Geronimo is already based on Karaf and focussed on EE; am not > sure why re-implementing Geronimo inside Karaf is a good idea - > wouldn't it be better to just work with the Geronimo community to fix > the issues you've raised (which seems to be about having more > Karaf-like approaches available inside Geronimo and fixing up the web > consoles - neither seem that big a deal to me to require forking a > community & project?). Am sure the Geronimo folks would be happy to > take contributions to enable more of Karaf's features in an EE context > etc. > > Certifying against EE is a massive amount of work; there has to be a > really really good reason (and a ton of volunteers with a massive > amount of free time who've got nothing better to do) to justify > duplicating that effort. > > Given how modular OSGi & Karaf are; am not sure why any of these goals > can't be solved inside Geronimo (e.g. take Geronimo uninstall its > console, install Karaf's console - no need to fork a community for > that?). > > On 14 December 2011 12:40, Charles Moulliard <[email protected]> wrote: >> Hi, >> >> As you probably knows, I work with OpenEJB community since a couple of >> weeks to be able to deploy OpenEJB 4.0.0-SNAPSHOT on Apache Karaf. The >> OpenEJB container can already been deployed and EJBs jars registered. >> Work should be done around OpenEJB to be able to easily scan (like we >> do for deploy directory in Karaf) new or updated EJB jars file and add >> karaf command. >> >> When this new brick will be ready, everything will be in place to >> propose/provide an Apache KarafEE (EE = Enterprise Edition) release >> packaging OpenEJB, OpenJPA, Aries JPA, Aries JNDI, Pax Web, Aries >> Transaction Manager. >> >> The first question/remark that I will receive from the communauty will >> be : Great/Brillant idea but Apache Geronimo is already there and use >> Apache Karaf. So why developing a new server : There a lot of good >> reasons why we should do that and study my suggestion carefully but >> some arguments could be : >> (1) concurrence in this area is always good comparing to what we have >> in J2EE world, JBoss, TomEE, Glassfish. J2EE are de facto servers used >> in major and many Java projects. OSGI is not yet recognized as a >> robust and simple solution to be used due to lack of tooling, >> complexity to package and create bundles. So having a new OSGI true >> J2EE server could help to spread the world, >> (2) The packaging and deployment approach of Apache Geronimo is a bit >> different from Karaf and some of the Karaf features are not enable >> (e.g : features, ...). >> (3) The Geronimo web console cannot be reused for Apache Karaf and now >> with our new WebConsole we are independent of Apache WebConsole Felix >> (4) EJB is back since spec EJB3 like also JPA and more and more >> project does not longer use de facto Spring ! >> (5) With Cellar/Fabric we have a strong foundation to >> deploy/manage/use Karaf in the cloud and design multi-servers >> architecture. >> >> KarafEE could be like Cellar, new WebConsole a subproject having its >> own assembly release process. It will contain assembly process, >> featurs, karaf commands, branding and web consoles stuffs. >> >> Remark : I have proposed also for OpenEJB that they have a >> karaf-assembly but our sub-project could be designed for that purpose >> - >> http://openejb.979440.n4.nabble.com/Proposition-New-maven-module-OpenEJB-Karaf-tt4194577.html >> >> What do you think about this proposition ? >> >> Regards, >> >> Charles Moulliard >> >> Apache Committer >> >> Blog : http://cmoulliard.blogspot.com >> Twitter : http://twitter.com/cmoulliard >> Linkedin : http://www.linkedin.com/in/charlesmoulliard >> Skype: cmoulliard > > > > -- > James > ------- > FuseSource > Email: [email protected] > Web: http://fusesource.com > Twitter: jstrachan, fusenews > Blog: http://macstrac.blogspot.com/ > > Open Source Integration and Messaging
