geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevan Miller <>
Subject Re: [Discuss] What next?
Date Fri, 14 Sep 2007 05:03:29 GMT
Apologies for such a late response. This thread came out while I was  
on vacation and got buried by a lot of other things...

This is a good list. Comments, below.

On Aug 30, 2007, at 8: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.

I wouldn't go so far as saying G is a "conceptually modular server",  
but would agree that the modularity can be a lot more user-friendly.  
And would like to see us building our server assemblies from plugin  
parts. Sounds like you've been making some good progress on this path.

One caveat -- I would not want our Java EE servers (or other assembly  
flavors) to become harder to use. One concern I have is ending up  
with a bunch of differently versioned server plugins that we have a  
hard time managing... I'd really like us to keep a critical eye on  

> 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?)

As Jason D has mentioned (and I really, really agree with him), we  
need to address logging. We need to create a logging policy and need  
to start addressing this in a consistent and rigorous manner...

> 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

I think our basic issues have been resolved... But there are some  
follow on improvements that should be implemented <hidden-classes>  
for children, a separate Spring module, etc.

> 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 have yet to see what I'd call a compelling argument for moving our  
kernel to an OSGI base. I can see motivations for allowing OSGI  
bundles to be deployed into a Geronimo server and an OSGI kernel  
would probably help, there, but don't see that it's necessary,  
either... We also tend to get focused on 'OSGI'. IMO that's only a  
part of the issue. Seems like the more fundamental question is what  
are we using for IoC (Geronimo Gbeans, Spring, something else).

I'd be interested to hear from users what they would like to see in  
the way of OSGI support... I'd also be interested in the current  
status of JSR-277.

Important thing, IMO, is to continue to develop sound component  
interfaces and dependencies.

> 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.

I really like the sounds of that...

In addition to adding new capabilities, I think it's very important  
that we not lose focus on addressing bugs and user issues (e.g.  
answering questions, providing usability improvements, documentation,  
samples, etc). This is where I've been spending most of my time,  
lately... IMO, Geronimo 2.0 already gives a lot of users the  
functional framework they want. We need to learn from user  
experiences and apply them to improve our usability and functional core.


View raw message