geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Genender <>
Subject Re: [DISCUSS] Geronimo 2.1 - what's next?
Date Mon, 02 Jul 2007 16:18:59 GMT
Great list.  I think we should start thinking about how we all want
Geronimo to be "known" as in the community.  Right now I think we are
known as the "J2EE/Java EE5" server.  I think we need to begin pushing
Geronimo more for what it is and what it can do...i.e. a pluggable
lightweight container with management.

IMHO the OSGI/Spring component is really huge!


Matt Hogstrom wrote:
> Seems like the dev list has been  a bit quiet lately as I know many
> folks have been working on getting 2.0 done and through some additional
> testing for Axis, fit and finish stuff, etc.  Although important, its
> not exactly the next generation so I thought I'd start this thread to
> get some ideas formed around the next step for AG.  These are just my
> thoughts and I'm soliciting input for ideas and discussion.
> I thought I'd put my thoughts in the form of a user describing what they
> need from Geronimo.  This is based on input I've heard from several
> folks as well as users and includes some of my own ideas as well.  It
> feels like we've been chasing the specs for so long that we haven't
> fully realized some of the other awesome ideas people have had.  Aaron's
> plugin architecture is workable but not fully consumable, Dain's
> repository work and a host of other ideas.  I think now is the time to
> have some fun.    To that end here is the list of requirements.
> Geronimo 2.1 Punch List
> *Flexible framework for building server assemblies that include only the
> components needed for an application*
> This means that a user could either build a custom assembly with only
> the needed parts or, alternatively, could run with all parts available
> but only start what they need.  The model is up to the user to decide
> based on their unique requirements.
> *Dynamically binding needed elements*
> Using the plugin architecture and Maven repo concepts one could install
> a needed element into the server by simply pointing to a remote
> repository and installing the element.  Other artifacts needed for
> execution would be obtained automagically from either the network or a
> shared filesystem as needed and based on the policies provided by the
> user.  The default mode of operation would provide the best user
> experience.
> *Dynamic Console for managing installed artifacts*
> Improve the console framework to allow installed artifacts to register a
> portlet for managing the configuration.  For highest level of
> flexibility a component would provide the required portlet elemtns and
> we would bind them into the navigation framework and security
> infracstructure.  We'd need a good set of docs and samples to help
> people in deploying this easy.  Ideally we would start with a minimal
> assembly and a mgmt console so that new functions could be loaded
> through the console.  I'm not sure that we'd need to have an assembly
> smaller than minimal at this point since we'd need a web container for
> the mgmt console anyway.
> *Cluster Aware Mgmt Application*
> For users that want to federate a number of servers together we need a
> clustering solution that will allow for configuration of nodes as well
> as autodiscovery.  This requires a clustering element for Geronimo that
> takes into account multiple clustering users (services).  I think Jeff
> has some of the foundation in GCache.
> *SOA Assembly*
> It would be great to have a SOA assembly (that works in a flexible way
> :) with AMQ, ServiceMix and a Tx Manager.  A LOT of people I talk to
> want something simple like a Tomcat and a Mule...let's give it to them.
> *Tooling*
> A really huge part of what people have talked about as being important
> is tooling integration (I've heard mostly about Eclipse and NetBeans).
> *OSGi and Spring*
> This has been kicked around for a long time.  I was talking with someone
> who said they needed a flexible runtime that would allow them to wire in
> OSGi bundles (seems like the traction is increasing) and use Spring for
> the configuration.  People smarter than I can weigh in on this area but
> this is seems to get Independent Software Vendors (ISV's) all hot under
> the collar.  If we could deliver this with the flexible server stuff I
> think we'd have a huge swell of interest.
> Other thoughts?

View raw message