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
