On Feb 12, 2008, at 3:36 PM, David Jencks wrote:
On Feb 12, 2008, at 12:26 PM, Kevan Miller wrote:
Things that I haven't seen mentioned, yet:
EE 6 -- we should be seeing an initial EE 6 spec, soon. As other
projects begin implementing EE 6 capabilities, I expect that we'll
be rolling them into Geronimo. There are also new specifications
which we may need to implement ourselves. I know that Jarek has
looked at the Concurrency Utilities specification (which may be
part of EE 6). Hoping he can tell us about that...
Performance -- One area that I think we need to improve is startup
time. I think our startup has slowed down, and I'd like to see us
speed it up dramatically. We can measure current startup
performance and optimize our hot spots. Depending on what we find,
we can also investigate algorithmic enhancements.
I think most of this is because we're including more stuff to start
in our server. Framework start pretty fast -- less than 5 sec on my
overloaded mac.
Heh. We both need new Macs, I think. Come on Apple and release new MBPs!
Would you agree that faster startup time is a good thing? IMO 5
seconds is way too slow for a framework assembly. Were you using
'gsh'? IMO startup time for a framework assembly should be ~ 1 second.
I'd like to see a Java EE server in under 10 seconds...
Monitoring -- I think we need to get a handle on the metrics that
can be monitored in Geronimo, document them, and look for areas of
improvement.
Logging -- review our current logging infrastructure. Too many
components lack appropriate logging capabilities. This makes debug
and problem analysis more difficult than it should be. I think we
need to start addressing this problem with more. We're debugging
too many problems, still.
Also switch to slf4j
Yes, but the hard part is getting good logging info...
Plugin development -- I'd like to make it easier to develop
plugins. I think we should look into tooling support (Eclipse and
Netbeans). I'd also like to simplify the process for administrative
creation of plugins (admin console or admin commands).
I think you can turn a module into a plugin using the admin console,
but the support is incomplete and definitely too hard. Just
deploying an app should result in some kind of default plugin info.
Sounds like we're in basic agreement.
Server assembly -- We could look at simplifying this process. You
currently must have application plugins in order to include
application capabilities in a server assembly. Why not export based
on one or more installed applications? Also, in addition to our
current, low-level module/plugin focus, can we have a simpler/
higher-level focus? Some users would rather choose "JMS" rather
than "org.apache.geronimo.configs/activemq-ra/2.1/car", "JSP/
Servlet", "Deploy" capabilities, etc.
Why would someone choose "jms" rather than "my app, which uses jms,
so it will get pulled in automatically"? I think we definitely need
to make all deployed apps into plugins automatically but beyond that
I'm not yet seeing a big benefit... If you are constructing a
server that does more than support a set of apps, I think supplying
complete names of what you are getting yourself in for is valuable :-)
I'm sure that "you" do see the need for complete names... ;-) And I do
too... However, I think there's room for a beginner's mode (JMS, etc)
and an expert's mode... Or at least an expert's mode that is less
intimidating to a new user.
I see two styles of usage for custom assemblies:
1. Application centric: contain user applications and required server
components. These server images may not have "deploy" capabilities.
They're essentially disposable server images. When you need to upgrade
your user applications, you throw the server image away and install a
new one.
2. Function-centric: contain custom server components, but no user
applications. Users choose the desired function (e.g. web container
plus JMS). And then deploy/undeploy apps to the server.
I think you agree we can easily support both styles. There's simply
the question of how usable do we want to make scenario #2?
--kevan
