geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Boynes <jboy...@apache.org>
Subject Re: Installation UI?
Date Wed, 18 May 2005 04:43:43 GMT
Aaron Mulder wrote:
> 	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.
> 

I agree we need to change the configurations. Instead of two 
mega-configs containing everything and the kitchen sink, they should be 
more modular. However, doing this requires changes to the configuration 
class loader which I've been holding off on until after certification.

> 	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.
> 

I'm not sure this is practical - you don't know which other ports are in 
use, and even if you knew what Geronimo is using you don't know what 
other ports are going to be used at runtime.

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

No - we used InstallAnywhere for JOE but needed a license.

> 	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.  

I agree - it would be really cool if the UI components could be used in 
a web console, in MC4J or anywhere. We used portlets for the components 
in the console because they were pluggable and we could tweak the UI 
easily in the aggregator. JSF may also be an alternative - any other 
suggestions?

> 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?  

You don't need to start the server, just load the configuration to get 
to the GBean attributes.

"Edit in place" - we don't do that now. AIUI each config store dumps the 
data in its own place/way.

I actually that's a bug - there are some config store (e.g. the one that 
loads from a Maven repo) that don't have a good place to dump the state 
to. Also the local state is server specific. So instead of storing with 
the configuration, we should have a central store for attribute overrides.

> 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).
>

How the central store would persist the overrides would be down to its 
implementation. XML may a good format for this; alternatively we could 
put it in a database (say a Derby instance) - that way we could also 
make the updates transactional at some point.

--
Jeremy


Mime
View raw message