Return-Path: Delivered-To: apmail-geronimo-dev-archive@www.apache.org Received: (qmail 97818 invoked from network); 13 Feb 2008 08:17:25 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 13 Feb 2008 08:17:25 -0000 Received: (qmail 247 invoked by uid 500); 13 Feb 2008 08:17:16 -0000 Delivered-To: apmail-geronimo-dev-archive@geronimo.apache.org Received: (qmail 193 invoked by uid 500); 13 Feb 2008 08:17:16 -0000 Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: dev@geronimo.apache.org List-Id: Delivered-To: mailing list dev@geronimo.apache.org Received: (qmail 182 invoked by uid 99); 13 Feb 2008 08:17:16 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 13 Feb 2008 00:17:16 -0800 X-ASF-Spam-Status: No, hits=2.0 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of shivahr@gmail.com designates 64.233.166.182 as permitted sender) Received: from [64.233.166.182] (HELO py-out-1112.google.com) (64.233.166.182) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 13 Feb 2008 08:16:44 +0000 Received: by py-out-1112.google.com with SMTP id a25so6165459pyi.11 for ; Wed, 13 Feb 2008 00:16:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; bh=F31yGONW6PaBFA/fGFteiE57u5JhYRu3nvcQ4IhBgu4=; b=Acmb7ZGS22wAQeiI9UBGwBA6RPeMTn1jawh7DffRgLl3dJkU4mor/cFSlhzJ/dEsBBy7F1YbtPmzNE2zaUNFpzLWczLef5Cpz+N2Hgm4dRPXnzJn5Akqyafp/VfkN8ENQWqXBYjZ8bElMlLS6cv4UsAUVuTITF5QGcrFkF2Atog= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=ZF3SbBQVtBUDFpq+XdzR8vnfJnjvxgwrKoGkMpc2lTMrxPQ7UQJvT6WJvAGopZAveALASTCjO2AVv8bpjcAWZ7yqDOdX8e6pGEC+yO+U9hRY6Bof5aK8Cl+cXHsPzP/9CVcFK6dIkF6q4bFM8XtieRE25Twl2V5fsLsivmHn910= Received: by 10.65.240.17 with SMTP id s17mr3191644qbr.74.1202890612242; Wed, 13 Feb 2008 00:16:52 -0800 (PST) Received: by 10.65.81.17 with HTTP; Wed, 13 Feb 2008 00:16:52 -0800 (PST) Message-ID: <5da94e5a0802130016x3bae55c4h176575ebebafbb44@mail.gmail.com> Date: Wed, 13 Feb 2008 13:46:52 +0530 From: "Shiva Kumar H R" To: dev@geronimo.apache.org Subject: Re: Geronimo in year 2008 In-Reply-To: <97C908EB-10CB-463B-809C-A13395BF0AA4@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_12326_24364586.1202890612226" References: <22d56c4d0802070658m21b95bb1uec328778804a39e8@mail.gmail.com> <886036B8-F051-4E29-8764-1A065D86FF04@gmail.com> <97C908EB-10CB-463B-809C-A13395BF0AA4@gmail.com> X-Virus-Checked: Checked by ClamAV on apache.org ------=_Part_12326_24364586.1202890612226 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Feb 13, 2008 4:57 AM, Kevan Miller 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 > ------=_Part_12326_24364586.1202890612226 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

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


------=_Part_12326_24364586.1202890612226--