geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shiva Kumar H R" <shiv...@gmail.com>
Subject Re: Geronimo in year 2008
Date Wed, 13 Feb 2008 08:16:52 GMT
On Feb 13, 2008 4:57 AM, Kevan Miller <kevan.miller@gmail.com> 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
>

Mime
View raw message