geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevan Miller <kevan.mil...@gmail.com>
Subject Re: Geronimo in year 2008
Date Tue, 12 Feb 2008 23:27:11 GMT

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

Mime
View raw message