Page History

Roadmap for 2.1

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

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

plugable admin console framework

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 (component/feature)

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

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.

...

Management and troubleshooting

ARM

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

...

Better Spring application management

OSGi-aware kernel

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"

Quote from Felix's Karl Pauls:

"It makes sense to go down the "replace the kernel with OSGi" route. Most projects start with the other approach but in the end realize that it is a lot more work without many of the
benefits "

and further along this path

"Geronimo would be perfect as a starting point because it integrates a lot of other projects (hence, might "convert" them along the way)."

and the last but not least

"I'd be willing to help. Alas, my time is limited as well but I can provide help and insides where necessary."

and as a starting point

"At Apache Felix, we have developed a maven2 plugin that might be helpful in migrating to OSGi. Maybe that can be a starting point:

http://felix.apache.org/site/maven-bundle-plugin-bnd.html

Felix itself is very small (~300k) and can be easily embedded:

http://felix.apache.org/site/launching-and-embedding-apache-felix.html

See [Discuss] What next? for more information on the topic"

Annotation-based gbean configuration injection mechanism

...