wow. nice post. +1 on all counts.
On 4/23/06, Aaron Mulder <[EMAIL PROTECTED]> 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. > -- Regards, Hiram
