geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Dillon <>
Subject Re: [Discuss] What next?
Date Mon, 03 Sep 2007 18:30:18 GMT
FYI, I took a brief stab and making this into a wiki page here:

I've only really included my thoughts and davids, so please update  
this puppy... IMO this type of information is better captured in a  
wiki page, though its gotta start in an email and the discussion  
should remain here, but lets capture things in the page so we can  
have a living document to express what are general plans/desires are  
for the next major release.



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 and  
>  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.
> 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.
> Security
> jaspi
> triplesec
> administration
> beyond javaee security for jetspeed and roller
> There are some good things about javaee security such as the idea  
> of using Permissions and evaluating them in a policy but there are  
> also a lot of limitations and problems such as no support for  
> restricting access to user generated content that didn't exist when  
> the security was originally configured.  At least roller and  
> jetspeed have run into this problem.  I think triplesec may provide  
> a fairly generic solution and it might be interesting to see if  
> other projects are interested in this.
> Other apps
> roller
> jetspeed
> proximity etc
> It would be great to get "all popular apps" available as geronimo  
> plugins.
> Management and troubleshooting
> "trace on error" facility.  Have a list of info that each component  
> can add to as the request moves through the system.  If there's an  
> error, we can show the entire path taken with all data.  Otherwise  
> we discared it.
> server farm management (gshell?)
> Transaction manager
> implement a "do work in a new tx" interface, hook it up to  
> openjpa.  IIUC IBM has proposed an interface that lets server  
> pieces submit work to be done in a new transaction, thus  
> eliminating the need to deal with suspend etc yourself.  There's  
> been some discussion on the openjpa lists, and we should definitely  
> do this.  There may be more commonj work to do also, but I've more  
> or less lost track of that project.
> make sure recovery actually works
> 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 :-)
> 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.
> Personally I'm interested in most of these projects but only have a  
> finite amount of time.  Right now I'm concentrating on triplesec  
> and want to work on jetspeed integration after that.
> thanks
> david jencks

View raw message