geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hernan Cunico <>
Subject Re: Apache Geronimo Principles & Goals
Date Wed, 26 Apr 2006 18:02:17 GMT
Hi Aaron,
I was looking at it as part of the documentation for v1.1.

Matt mentioned some graphics for deployment and based on those graphics I was planning to
expand on 
the "What's new - Architecture" section.

I think the outline is great and it should be easily accessible on the web site.


Aaron Mulder wrote:
> Hernan,
> I am really looking for more discussion/feedback before posting this
> as representative of the project at large.  It would be more helpful
> to have your comments on the content.
> Thanks,
>     Aaron
> On 4/26/06, Hernan Cunico <> wrote:
>>Hi All,
>>I put in confluence the Principles and Goals that Aaron wrote. These are listed as
the first bullet
>>in the Geronimo v1.1 documentation.
>>Matt, do you have those graphics for Geronimo deployment options? I can include them
if you send
>>them over :)
>>Here is the link to the Geronimo v1.1 documentation (well, just a few place holders
so far :)  )
>>Matt Hogstrom wrote:
>>>I agree with the general outline below.  I mentioned in one of the 1.1
>>>posts that in order to be competitive it would benefit the project to
>>>define some goals around the releases.  I think the principles below
>>>help to provide the framework for prioritization of goals.  I'd like to
>>>take your thoughts below along with representations of the scenarios we
>>>want to be effective.  I have a set of charts I noodled on about a month
>>>or two ago that shows graphically how Geronimo can be deployed. I'll
>>>look to get those out on the website and get people's feedback on them.
>>>I think this will help as well.
>>>Aaron Mulder wrote:
>>>>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.
>>>>    Aaron
>>>>Apache Geronimo Principles & Goals
>>>>=== Principles ===
>>>> * Be competitive with other application servers
>>>> * Be flexible to include exactly what a user wants (lightweight,
>>>>   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 ===
>>>>Geronimo should meet anyone's needs from very lightweight to very
>>>>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"
>>>>to strip down the server to only what that application requires.  It
>>>>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
>>>>and fail-over fault tolerance.  Geronimo should work with common hardware
>>>>Benchmarks should be made available with clear instructions for users to
>>>>configure and run them on Geronimo as well as on other application
>>>>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,
>>>> - 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
>>>>   file formats for common things like database pools, eliminate
>>>>target names
>>>>   in references)
>>>> - Isolate the application classpath from Server internals (Spring,
>>>> - 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
>>>>Some popular J2EE applications should be ported to Geronimo to confirm
>>>>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
>>>>on the same machine (using different network ports).  It should be
>>>>to rearrange the console content to suit the user's needs/style, or at
>>>>provide breadcrumb-type access to frequently used functions.
>>>>It should be possible to set up several Geronimo configurations that
>>>>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
>>>>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
>>>>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
>>>>be validated according to the relevent specification's rules before
>>>>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
>>>>for internationalized messages, linked to a Wiki with discussion and
>>>>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
>>>>usable aggregate information (62% of each call to /myapp/hello spent
>>>>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
>>>>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
>>>>configuration files, in any cases where Geronimo will not accept
>>>>files built for the previous version.

View raw message