On 6/24/05, Bruce Snyder <[EMAIL PROTECTED]> wrote: > On 6/23/05, Aaron Mulder <[EMAIL PROTECTED]> wrote: > > On Thu, 23 Jun 2005, Bruce Snyder wrote: > > > While I respect your quest for simplicity, I disagree with this > > > approach because I think it's too minimal. I think Geronimo needs to > > > offer an easy to use, friendly installer/post configurator to the > > > community. Installation of commercial app servers is usually handled > > > through a GUI installer but configuration has traditionally meant hand > > > editing config files. This is not something that I think we can do > > > much better. > > > > We have an installer; I think it's reasonably easy to use. I'm > > sure it could be improved, but in all honesty, the biggest improvement > > would be to make it run faster. Right now it deploys the customized plans > > one by one -- it could use the start - multi deploy - stop routine of the > > assembly module, or we could just replace the whole mechanism with > > something to edit the configuration in place. > > IMO, installation and configuration are very similar and each can be > achieved using the same UI, but two different APIs underneath - one > for installation and the other for configuration. This is why I keep > talking about an installer and a configurator together. The installer > API should make use of the configurator API. > > We've already agreed that a GUI-only installer does not meet all > requirements. But many sys admins also want the ability to automate > installs via scripting. > > > (Actually, the biggest improvement would be to have whoever makes > > the unstable builds actually run the installer -- once you have IzPack > > installed you only need to run 1 command to do it!) > > > > > This is exactly why I'm suggesting that we create a library to handle > > > the installation and configuration tasks. It will allow any kind of > > > UI to be developed - GUI, text or web - as well as allow for > > > scriptable installations. This is extremely powerful and cannot be > > > undervalued. > > > > Sure. I mean, we could create an API that would edit the config > > info in place. Presumably now, it would deserialize the stored > > configuration, update it, and then reserialize it back to the config > > store. I have sample code that does this, and while we'd want some minor > > changes to the config store interface to support it, it's not at all out > > of the question. > > I agree that editing configurations in this manner is a good idea > because it suits performing a reconfiguration of existing installs. > > > However, it would be 10x easier if we just switch to the > > Spring-based configuration system. :) > > I agree that switching to a Spring-based configuration would be ideal! > I'm just not sure we want to require Spring. > > > In any case, if we define the API, we can change the background > > however we need to going forward. It could also support David J's > > suggestion of some kind of "configuration service" that would store the > > ports and similar info separate from the related GBean configuration. The > > main question to me is, do we create a static set of configuration > > information based on the services available in our "standard" J2EE > > configuration, or do we try to make it dynamic where each configuration > > lists its own configurable properties (using JSR-88, what else? :) The > > per-configuration system is much more flexible for general-purpose > > configuraitons of Geronimo, but will make our job a lot harder for things > > like sensibly choosing between Tomcat and Jetty (which would just be two > > generic services in that model). > > I think we need to prioritize these requirements to determine how to > design such an API. But this is exactly why I think an API should be > put together to handle this correctly rather than just hacking > together a simple config editor. Let's start a JIRA issue for it and > begin to list the requirements.
Actually, I just stumbled upon JSR 38 (Application Installation API Specification) and http://www.openinstallation.org/ which provides an implementation of this API named JIFI. This is an extensible API for creating cross platform installers for many environments, including non-GUI situations. > > I'm wandering here, but this isn't the first time I've thought of > > something that would be quite nice for the "J2EE Server Configuration" but > > not terribly useful outside it. I wonder if we should start a separate > > subproject/directory tree for J2EE-only stuff that does not need to be > > compatible with any general Geronimo configuration. Perhaps this will > > just be an expanded assembly module. I'm sure we'll struggle with this to > > some degree with the management console. > > I think what you speak of here are just many different custom > assemblies and the installation and configuration APIs need to be able > to handle them. Using Spring would simplify this tremendously, but I'm > not yet convinced that we want to require Spring. But doing what James > did for ServiceMix might nudge me a bit more. He wrote a custom Spring > bean factory to simplify the Spring configuration. The result is a > cleaner XML file, while still allowing all of Spring's niceties. This > would really be the best of both worlds. > > Bruce > -- > perl -e 'print unpack("u30","D0G)[EMAIL > PROTECTED]&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*" > );' > > The Castor Project > http://www.castor.org/ > > Apache Geronimo > http://geronimo.apache.org/ > -- perl -e 'print unpack("u30","D0G)[EMAIL PROTECTED]&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*" );' The Castor Project http://www.castor.org/ Apache Geronimo http://geronimo.apache.org/
