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] What next?
Date Mon, 03 Sep 2007 12:10:48 GMT
On Aug 30, 2007, at 5:12 PM, David Jencks wrote:
> Getting 2.0.1 out the door was a great step and now might be a good  
> time to start discussing where we want geronimo to head next.  Here  
> are some ideas I've had or think are important.  If I were to try  
> to write actual sentences about all of this I'd probably never send  
> the email so this is way too fragmentary but maybe can spark more  
> discussion.  I'm hoping everyone will chime in with their interests  
> and viewpoints, this is just what I've been thinking about lately.
>
> Modularity.
>
> For a long time we've been on the brink of having an actually  
> modular server, not just a conceptually modular server. As  
> reflected in a lot of recent discussion on the dev list, I think we  
> are so close we should really work hard to make this a pleasant  
> reality.  Some of the steps I see:
> - enhance the plugin framework so bits of more config files can be  
> added, in particular artifact_aliases.properties and  
> config_substitutions.properties.  IIUC Paul has some schema changes  
> and xml handling rewrites in the wings as well
> - finish up the pluggable admin console work and actually split the  
> admin console into appropriate bits for the plugins
> - rearrange the build so it is organized by plugin
> - actually assemble the servers we ship using plugins, perhaps  
> using gshell scripts
> - have more server-building tools.  For instance, a "button" to  
> push that spits out a server with just what is needed for a set of  
> apps and nothing else.

Yay... modularity is my friend... and enemy :-P  More modular server  
means more build muck to assemble it :-P  But IMO this is probably  
the most important feature (if you can call it that) which we need to  
implement to ensure the longevity and maintainability of Apache  
Geronimo.


> Clustering
>
> IIUC we have a lot of partial  clustering solutions.  For instance  
> there's WADI, native tomcat clustering, a terracotta integration,  
> and IIUC Jeff has been working on a clustering solution (my  
> apologies if I left any out).  I'd like to know where these efforts  
> are in terms of actual functionality and reliability and what they  
> can be extended to do.  We also need some kind of cluster admin tools.

Certainly a nice to have, and almost always on user's want to have  
list, though from past places I've worked we never have really made  
use (fully) of any application server's clustering facilities.  I'd  
like to see this added, and I'm sure we will get it sooner rather  
than later, but I think that the modularity (and inevitable  
decoupling) work is vastly more important to the project (perhaps not  
users).


> Other apps
> roller
> jetspeed
> proximity etc
> It would be great to get "all popular apps" available as geronimo  
> plugins.

Ya, would be nice to get the main G distribution to a point where you  
can *easily* (as in my eyes are closed and I'm clicking the install  
some neat feature button) get a fully functional, kick ass, easy to  
use and admin server ;-)



> Management and troubleshooting
> ARM

No LEG?


> Otherwise we discared it.
> server farm management (gshell?)

This is definitely on my "in my head" roadmap for the shell, though  
we need those clustering bits first to give it something to work  
with.  One thing we might want to add before then is some kind of  
reboot facility to the server, which is possible using the GShell  
launcher process.  So a user can install some muck, tweak some  
configuration, then tell the server to reboot and basically pick up a  
pristine configuration and working environment.  The same basic  
mechanism could be used to create a rollback configuration, or named  
configurations, etc.

I've been working on simplifying the GShell framework for the past  
week, and will continue for a few more me thinks as I've been re- 
inspired by the positive feedback I've heard so far, as well as my  
renewed desire for GShell to rule the world and make me coffee in the  
morning.

So expect to see some more GShell goodies on the way soon...


> Core
> Better Spring application management
> Investigate OSGI and figure out how it is different from what we  
> are doing, what it can do better, and what is missing from it.   
> Figure out an integration strategy whether it be "run OSGI as an  
> application" or "replace the kernel with OSGI"  Don't break stuff  
> if we start using OSGI more :-)

I think some investigate is defs in order here, though I'd really  
like to see the system split up into smaller manageable chunks before  
this is considered for implementation.  I don't think that the  
current gbean framework is so inflexible to make that a non-option.   
So lets split up the server, learn from that exercise, keeping in  
mind how we can make it easier, require less code and perhaps even do  
more... then lets do it.  I'd personally like to see us using  
annotations to define all those properties and operations and such on  
our components... I fricken love annotations.


> Figure out what to do with our "config.ser" in modules/ 
> configurations.  At least get it into real xml, maybe using  
> something like jaxb with schema/gbean.

OOOOH HEEEELLLL YA!!!!

I'd really like to see the configuration for a module, in plain xml,  
based on some schema that is descriptive and extensible enough to  
handle pretty much any kinda of configuration we want to toss at a  
set of beans (or anything users want to, and they will come up with  
some crazy shiz for sure).

And... I want to see those XML files deployed into the repository  
ASIS... IE... not in any *ucking jar/ear/war/whatever file.

And, on a related not... those damn CAR files that are expanded...  
well, they shouldn't be.  The repository should contain artifact  
*files* only... so if we need to unpack them on the fly, then do it.   
Or if users want to use an unpacked dir for their deployment, then  
use the deploy/* directory or something, but leave the repository/*  
as files.

  * * *

So, based on what I've just babbled about so far... I'd like to see  
2.1 focused on developer improvements (for us, and plugin  
developers), more application support to get users going faster, and  
administration support (that includes the xml stuff in the repo and  
gshell bits).

Anyways... just my comments.

--jason


Mime
View raw message