On Feb 13, 2008 4:57 AM, Kevan Miller <[EMAIL PROTECTED]> wrote: > > 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. >
1 & 2 are just awesome. I too think we must support both styles. One immediate usage of #1 that's coming to mind is: Let's say I am an Application developer and have developed an application on top of Geronimo. Now let's say I want more & more people to start using my application and start providing their feedback. Typical way would have been to ask users to download & install Geronimo first and then install & configure my application on top of it. However if #1 above is available, things could become very simple. All I have to do is generate a custom server with just my application and its required dependencies, and probably create an install image out of it. Now, my users have to download & install just this image (of size significantly lower than G) and start using it right away! #2 as before could be used to build LittleG and higher assemblies. -- Thanks, Shiva > 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 >
