Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: pass (asf.osuosl.org: domain of chirino@gmail.com designates
 64.233.162.206 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=i+hgaAy3tmyztKaLgxOiMGCuBjJl+2KlVmpgmAh8x5SgFl0VDR+/w1WqwBAhbrAGFN/1snREIOxcpBgh4d4XmbpACp6CsqpzOdk18MYhof9p3K7kvW8xOhY/E8FXUeimwvqg0Mrc2pwN1fMa4b2Fp48z/Ud+3GJAq9detCO6P+0=
Message-ID: <af2843cd0604251154m92163a0s3c7098dd95554f4b@mail.gmail.com>
Date: Tue, 25 Apr 2006 14:54:28 -0400
From: "Hiram Chirino" <hiram@hiramchirino.com>
Sender: chirino@gmail.com
To: dev@geronimo.apache.org
Subject: Re: Apache Geronimo Principles & Goals
In-Reply-To: <74e15baa0604232007p109de0f5hee3f6bd6e751c147@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <74e15baa0604232007p109de0f5hee3f6bd6e751c147@mail.gmail.com>

wow. nice post.

+1 on all counts.

On 4/23/06, Aaron Mulder <ammulder@alumni.princeton.edu> wrote:
> All,
>
> Here's a little something I've been assembling to help as we move past
> certification and look for what's next.  I'd like to post this (or
> something like it) to the web site, ideally for the 1.1 release so
> it'll be there for people wondering (at a high level) where we're
> going from here.
>
> Thanks,
>     Aaron
>
>
>
> Apache Geronimo Principles & Goals
>
>
> =3D=3D=3D Principles =3D=3D=3D
>
>
>  * Be competitive with other application servers
>  * Be flexible to include exactly what a user wants (lightweight, heavywe=
ight,
>    product integration, customized admin tools, etc.).  Make it easy to g=
et
>    there from the initial download.
>  * Be the IntelliJ of app servers (it thinks like you do, works like you
>    expect, etc.) -- alternately, be the OS X of app servers (easy to use =
and
>    even the hard stuff "just works")
>
>
> =3D=3D=3D Goals =3D=3D=3D
>
>
> Flexibility
> -----------
> Geronimo should meet anyone's needs from very lightweight to very heavywe=
ight.
> Generally, the distribution option should be:
>
> 1) Minimal -- kernel and command-line/script administration tools only
> 2) Web -- web container and web admin tools
> 3) J2EE -- certified J2EE stack with web admin tools
>
> The included tools must make it extremely easy to download and install
> additional features (e.g. plugins) to add on to the basic distribution.  =
And,
> of course, anyone is free to create more comprehensive distributions by
> bundling plugins and distributing the resulting package.
>
> It should be possible to get an app running and then have "1-click" optio=
ns
> to strip down the server to only what that application requires.  It shou=
ld
> also be possible to easily replicate a Geronimo installation to another
> machine (or to another existing Geronimo installation).  It should also b=
e
> possible to export an environment to run a J2EE application client in
> (ideally, export it as a dynamic Java Web Start configuration so you can =
just
> run it on your local PC by clicking a link in the console).
>
>
> Performance & Scalability
> -------------------------
> Performance must be comparable to other application servers in key areas.
> Geronimo should support clustering of web and EJB components for scalabil=
ity
> and fail-over fault tolerance.  Geronimo should work with common hardware
> load-balancers.
>
> Benchmarks should be made available with clear instructions for users to
> configure and run them on Geronimo as well as on other application server=
s.
> There should be clear performance tuning guidelines, and the performance
> tuning options should be extremely accessible (e.g. provide a dashboard-
> style page with all the settings to tune a web application in one place
> along with recommendations for the various settings).
>
>
> Application Portability
> -----------------------
> It should be as easy as possible to port applications to Geronimo, meanin=
g:
>  - reduce the need for Geronimo-specific XML configuration files
>  - simplify and minimize required settings in Geronimo-specific XML
>    configuration files (e.g. eliminate nested namespaces, provide optimiz=
ed
>    file formats for common things like database pools, eliminate target n=
ames
>    in references)
>  - Isolate the application classpath from Server internals (Spring, loggi=
ng)
>  - Make common but non-standard code work (global JNDI lookups, etc.)
>  - Support file layouts, config files, scripts, termininology from other
>    popular application servers (or stay as similar as possible)
>  - Provide conversion tools to import configurations from other app serve=
rs
>
> Some popular J2EE applications should be ported to Geronimo to confirm th=
at
> the process is as painless as possible.
>
>
> Administration & Management
> ---------------------------
> Geronimo should provide command-line, Ant, Maven, and web versions of all
> key tools.  This includes tools to:
>  - get a list of available plugins
>  - download and install plugins
>  - deploy/redeploy applications
>  - start and stop the server
>  - export an application client wrapped in Java Web Start, even including
>    auto-generated SSL keys/certs for mutual authentication.
>
> The web console should be at least as function as the BEA WebLogic web
> console.  It should make it easy to both configure the server and gather
> runtime statistics.  It should make it easy to run a second Geronimo inst=
ance
> on the same machine (using different network ports).  It should be possib=
le
> to rearrange the console content to suit the user's needs/style, or at le=
ast
> provide breadcrumb-type access to frequently used functions.
>
> It should be possible to set up several Geronimo configurations that shar=
e
> the same core installation files but have their own configuration files,
> deployments, etc. similar to WebLogic domains (but not like JBoss which
> copies too many JARs into each configuration).
>
> Geronimo should include a Windows Service to run the server.  Ideally, it
> would also have a service like BEA Node Manager to start and stop servers
> on remote machines.
>
> Geronimo should include scripts or command-line tools that make it easy t=
o
> perform and/or automate common tasks such as deploying a new database poo=
l or
> adding a new JMS destination.
>
> Geronimo should provide packaged integration for management tools such as=
 MC4J
> and JConsole.  It should be easy to construct custom management tools usi=
ng
> Geronimo maangement APIs.
>
> Individual plugins should be able to include management plugins that fit =
into
> both the console and the command-line tools.  The user should be able to
> update the layout and navigation to customize their own experience.
>
>
> Development Tools
> -----------------
> In additional the aforementioned tools, Geronimo should provide detailed
> integration with popular IDEs including Eclipse, IntelliJ, and NetBeans. =
 The
> integration should include starting and stopping the server, debugging, a=
nd
> generating Geronimo deployment plans for application modules.
>
> Geronimo should also include comprehensive XDoclet support.
>
> Geronimo should provide tools to streamline development wherever possible=
,
> including things like (note Rails influence):
>  - generating persistence classes and simple web screens on top of them
>  - populating a database with test data
>  - rolling back to a previous version of an application
>
>
> Developer Experience
> --------------------
> Geronimo should produce high-quality error message.  Every deployment sho=
uld
> be validated according to the relevent specification's rules before Geron=
imo
> attempts to configure and run it.  The deploy tool should always display
> relevant errors to the user (without additional arguments).
>
> It would be great to create a more robust error-handling system with code=
s
> for internationalized messages, linked to a Wiki with discussion and repo=
rts
> from the field on when each error was encountered, how to work around it,
> links to related Jira issues & patches, etc.
>
> It should be possible to easily enable performance traces that break down=
 the
> time spent in each user-provided method (or important Geronimo function s=
uch as
> a persistence operation or JTA commit) over the course of a single
> call/transaction.  It's OK if this introduces overhead, so long as it pro=
duces
> usable aggregate information (62% of each call to /myapp/hello spent "her=
e").
>
>
> Documentation
> -------------
> Geronimo should include comprehensive free documentation, including:
>  - Reference for server and application configuration, emphasizing why
>    particular settings are important, when you should use them, and how y=
ou
>    decide what to set them to
>  - Howto's for writing your first J2EE applications with Geronimo
>  - Howto's for advanced server / administration tasks
>  - Detailed guides for available plugins
>
>
> Production Integration
> ----------------------
> Geronimo should provide canned integration with popular open source and
> commercial products in categories such as:
>  - Databases
>  - Distributed caching
>  - LDAP, single sign-on, & identity management
>  - Portals
>  - SOAP/XML stacks
>  - ESB/JBI/integration tools
>  - Scheduling
>  - Reporting
>  - Web frameworks
>  - Debugging/optimization tools
>  - Performance testing
>  - ISP virtual hosting / control panels
>  - Applications (samples, business apps, bug trackers, CI, etc.)
> In many cases this will include an actual Geronimo plugin, but for some a=
reas
> it may only include documentation (how to configure the tool and Geronimo=
 to
> work together) or code and documentation (if the integration requires ext=
ensive
> customization so a plugin isn't flexible enough).  In any case, the packa=
ge for
> each product should include comprehensive documentation.
>
>
> Updates and Upgrades
> --------------------
> Geronimo should include a strategy for updating a server in-place to the =
latest
> maintenance release, or at least to apply critical fixes.  Ideally, this =
will
> not break any existing plugins or applications.
>
> For major new versions of Geronimo, there should be an upgrade tool to co=
nvert
> configuration files, in any cases where Geronimo will not accept configur=
ation
> files built for the previous version.
>


--
Regards,
Hiram