I’m not sure how much interest there would be in an osgi based javaee app server. I expect osgi-aware projects would likely try to avoid most of the javaee cruft and go directly to better-integrated-with osgi stuff such as that being demonstrated in enroute and non-osgi aware projects would be likely to want something lighter weight such as tomee.
However….. should anyone wish to revive Geronimo… my advice would be: - drop the geronimo framework. - (possibly) write a config admin management agent that reads something like current geronimo configuration files and turns them into osgi configurations. I think some way of representing data trees in an osgi configuration is essential. I tend to prefer encoding the path to a data element in the key, so values are all simple, but most osgi people seem to prefer encoding the data tree in json or yaml with simple keys and complex values. I think osgi R7 is likely to support the latter approach. - Rewrite all the integration code (most of geronimo) to use up-to-date (R7, actually) declarative services. As part of this, make actual bundles with only interfaces exported and all the implementation hidden. - Run it in plain Karaf. This would involve an extended period in which little to nothing worked. When I tried to osgi-ify geronimo, I was hampered by - trying to do it pretty much by myself — it is too large a job for one person IMO. - trying to keep a working product most of the time — starting over with a DS based component model is definitely the way to proceed - the DS implementation was too buggy, I didn’t know enough about DS, and the DS spec was too primitive — all of these have been fixed, although I don’t imagine I would participate much in a revival much beyond giving advice. good luck! david jencks > On Jan 6, 2017, at 11:49 AM, Eduardo Garcia <[email protected]> > wrote: > > I think Geronimo worth a chance to be updated. There are not that much OSGi > enable application servers out there, and this one is pretty stable. I think > the first steps toward a new version would include a rethink of its > architecture, considering how the projects used by Geronimo are evolving > right now (Karaf, Aries, Commons, etc.) and current market trends, including > new interesting features (cloud enabled micro-version of Geronimo perhaps, > OSGi annotations, small footprint, etc). One of the things people are > concern in open source is short live of projects. Geronimo has been there > for a while, so there is another good reason to keep pumping this project. > It would be appreciated any docs helping the process of updating Geronimo, > besides at this point, it could be needed a "from zero" start due long time > without an official release, in order to start a proof of concept. > > > > On 12/27/2016 04:17 PM, Kevan Miller wrote: >> Thanks Eduardo! >> >> If there are people interested in working on updating the Geronimo server, >> I'm sure the community would happily support these efforts. So, if you or >> anyone else are interested, please speak up! >> >> Also, if there are people interested in supporting the currently released >> version(s) of the Geronimo, server, I think the community would be >> supportive of these efforts, also. >> >> Unfortunately, there has not been much interest from the current community >> for either of these efforts. I confess that I'm not planning on providing >> support for the existing codebase or working on a new version of the >> Geronimo server. >> >> Mark, >> Your plan seems reasonable to me. Unless we plan on supporting the current >> version of the server (fixing bugs and security exposures) and/or developing >> a new updated server, I think we must move the server subproject to the >> Attic. >> >> I do not plan on participating in the community for either commons or server >> development. Once the future plans for the Geronimo Server have been >> finalized, I will plan on resigning from the PMC. >> >> kevan >> >> On Tue, Dec 20, 2016 at 7:21 AM, Eduardo Garcia <[email protected] >> <mailto:[email protected]>> wrote: >> It would be desirable to have an official new version, with full >> compatibility with new Java JDK's (this helps promoting people on using >> it), also updating official web page, and Eclipse Plugin. >> >> I had to put the front-end of a project into a TomEE due web-responsive >> JSF requirements, but still using Geronimo as the core (back-end), by >> using microservices (Restlet/Jackson). Geronimo really rocks, but I >> think it is time to get a renew version compatible with new key libraries. >> >> I really like Geronimo AppServer and hope it continue growing. In my >> case, I started using geronimo because it was really easy for me >> learning it with the Eclipse Tools available at that time (IBM OSGi >> Tools). Right now I have to use WAS or Liberty Tools with Eclipse Luna. >> >> My wish list for Geronimo: >> - Updated OSGi framework >> - Been able to install Camel >> - Updated MyFaces compatibility and fix some non-critical bugs >> - Compatibility with new JDK >> - Updated Eclipse Plugin >> - Try to deliver a new release once a year >> >> hope next year could join you guys in making some of this happen. >> >> >> >> On 12/16/2016 12:54 PM, Mark Struberg wrote: >> > Parts which I found to be actively maintained and very useful >> > >> > * specs >> > * xbean >> > * javamail >> > * transactionmanager >> > * flava (needed for specs) >> > >> > I'm sure there are others which are not on my radar,... >> > >> > LieGrue, >> > strub >> > >> >> Am 15.12.2016 um 21:41 schrieb David Jencks <[email protected] >> >> <mailto:[email protected]>>: >> >> >> >> I agree. Which components specifically are you thinking of? >> >> >> >> david jencks >> >> >> >>> On Dec 15, 2016, at 1:57 AM, Mark Struberg <[email protected] >> >>> <mailto:[email protected]>> wrote: >> >>> >> >>> Hi folks! >> >>> >> >>> There have been some thoughts about resurrecting activity on the >> >>> Geronimo AppServer. >> >>> So imo the first step is to find a spot which makes sense. Software >> >>> doesn't get built just for fun. >> >>> Of course if no fun is involved then a project is doomed as well. >> >>> But otoh if it doesn't get used then the quality suffers a lot and the >> >>> fun is gone as well. >> >>> >> >>> So we have a few Java App Servers (just at the ASF), sorted from >> >>> fastest/smallest to full EE >> >>> >> >>> * Mina as Socket Server >> >>> * Tomcat as native Servlet Container >> >>> * Brand new: OpenWebBeans Meecrowave as Microprofile server >> >>> (Tomcat9+OWB+Johnzon+CXF+log4j2). In a whooping 9MB all in one CLI >> >>> fatjar btw ;) >> >>> * TomEE WebProfile (EE6 and EE7) >> >>> * TomEE Full (EE6 and EE7) >> >>> * Geronimo (EE6, OSGi) >> >>> >> >>> + httpd of course (but not Java) >> >>> >> >>> To be honest I've not seen the Geronimo AppServer in production since >> >>> quite a few years. Otoh the components maintained over here are of great >> >>> quality and also an important puzzle part of many other projects. In my >> >>> eyes Geronio could re-focus on becomming kind of EE-comons of the ASF. >> >>> >> >>> What do others think? >> >>> >> >>> LieGrue, >> >>> strub >> >>> >> >>> >> > >> >> >
