Oh, one more thing which I think is also critical path for the health
of the server and its community...
LOGGING REFORM
We've talked about this here and there, most folks agree we need to
reform our logging usage... but so far its yet to happen. It is a
fairly simple task IMO, but its huge, since it pretty much touches
almost everything. But its something that can be easily staged and
then divided up amongst the surfs (and lords) for code weeding.
IMO, we need to...
1) Decide on slf4j or commons-cli
2) Define a general logging usage policy
3) Implement said policy on existing logging usage
4) Improve, add, augment, whatever, existing logging to be more
useful (for users and developers)
For #1 I'm obviously for slf4j... for a few reasons which I've
outlined in previous emails. I list this as the first step, as if we
do go for it, then it has some slight impact on the policy and
implementation work (like its varargs support instead of requiring
log.isDebugEnabled() guarding).
IMO, this is low handing fruit, which we can easily pick and which
our users (and developers) can feast upon the juicy flesh of... yummy.
--jason
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.
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
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?)
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