geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Mulder <>
Subject Re: Installation UI?
Date Tue, 17 May 2005 13:57:42 GMT
	I think we'd need to change some of our configurations for this to
work.  For example, we need some UI to decide between Jetty and Tomcat,
and I don't really want to offer two totally separate editors for the two
web containers and no way to enforce that one of the two must be available
and that the ports shouldn't conflict and all that.

	Generally it would be nice to have some multi-component-spanning 
validation so you could, for example, ensure that *no* ports conflict -- I 
guess that's not critical in the first release, and editors for each 
configuration could be a good start.

	For installation, we'd have to either customize or replace IzPack.  
Do you have an alternative in mind?

	If we were going to offer this for installation purposes, we might
as well make it a general-purpose configuration UI that can be used
post-installation too.  Again, one of my priorities is the ability to
change configurations without starting the server.  So would the GUI edit
the configuration information in place?  I still have a strong preference
for XML as opposed to serialized stuff -- I expect this would mean we'd 
want to define a startd XML format that all config stores would use (so 
they'd store the same XML, regardless of whether they store it in a DB, 
filesystem, etc. as opposed to each config store defining its own XML 
format or something).


On Mon, 16 May 2005, Jeremy Boynes wrote:
> Aaron's installation questions got me thinking about the UI for the 
> installer and the challenge of doing the initial configuration. We don't 
> really want people editing plans (vi + an XML file does not seem 
> user-friendly to me) so how can we provide them an alternative.
> How about if we added a UI component to the configuration bundle? So in 
> addition to the state file (config.ser) there was also a UI component 
> that the bundle could provide for editing its manageable persistent 
> attributes.
> This would have the advantage of allowing each bundle to provide a 
> better UI than a set of name/value pairs, and would avoid hard coding 
> any particular UI code into the installer.

View raw message