geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Dillon <ja...@planet57.com>
Subject Re: [DISCUSS] Geronimo 2.1 - what's next?
Date Tue, 03 Jul 2007 11:37:20 GMT
+1

I'm all for more work on the console bits.

--jason


On Jul 3, 2007, at 4:07 AM, Shiva Kumar H R wrote:

> I would be happy to see the work on "Admin Console Portlet for Auto  
> Generating Geronimo Deployment Plan" getting complete and shipped  
> with AG 2.1. May be I am a bit too ambitious, but an ultimate test  
> would be: portlet auto generating the deployment plan for  
> 'Daytrader' application ;-)
>
> - Shiva
>
> On 7/2/07, Matt Hogstrom <matt@hogstrom.org> 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?
>
>
>


Mime
View raw message