geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hiram Chirino" <>
Subject Re: Apache Geronimo Principles & Goals
Date Tue, 25 Apr 2006 18:54:28 GMT
wow. nice post.

+1 on all counts.

On 4/23/06, Aaron Mulder <> 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
> === Principles ===
>  * Be competitive with other application servers
>  * Be flexible to include exactly what a user wants (lightweight, heavyweight,
>    product integration, customized admin tools, etc.).  Make it easy to get
>    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")
> === Goals ===
> Flexibility
> -----------
> Geronimo should meet anyone's needs from very lightweight to very heavyweight.
> 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" options
> to strip down the server to only what that application requires.  It should
> also be possible to easily replicate a Geronimo installation to another
> machine (or to another existing Geronimo installation).  It should also be
> 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 scalability
> 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 servers.
> 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, meaning:
>  - 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 optimized
>    file formats for common things like database pools, eliminate target names
>    in references)
>  - Isolate the application classpath from Server internals (Spring, logging)
>  - 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 servers
> Some popular J2EE applications should be ported to Geronimo to confirm that
> 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 instance
> on the same machine (using different network ports).  It should be possible
> to rearrange the console content to suit the user's needs/style, or at least
> provide breadcrumb-type access to frequently used functions.
> It should be possible to set up several Geronimo configurations that share
> 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 to
> perform and/or automate common tasks such as deploying a new database pool 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 using
> 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, and
> 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 should
> be validated according to the relevent specification's rules before Geronimo
> 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 codes
> for internationalized messages, linked to a Wiki with discussion and reports
> 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 such 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 produces
> usable aggregate information (62% of each call to /myapp/hello spent "here").
> 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 you
>    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 areas
> it may only include documentation (how to configure the tool and Geronimo to
> work together) or code and documentation (if the integration requires extensive
> customization so a plugin isn't flexible enough).  In any case, the package 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 convert
> configuration files, in any cases where Geronimo will not accept configuration
> files built for the previous version.


View raw message