This is a problem we're going to face many times.
I don't see commented out config as a solution. First, at this point, when the file is re-written following an update, comments are lost. That may change, but in general using the file as documentation is fragile. Second, if we added commented out sections for all the various options different subsystems may want to expose, we'll soon have a 1,00 line file full of confusing stuff.
I think we're going to need a mix of things to solve this:
1) Ship a few different canned configs files for the most common profiles, with the user able to select which they want via a command line switch.
2) An "examples" dir in the dist where some less common choices can be highlighted.
3) Most importantly, an installer application where users can easily tell us what subsystems they want in their profile. This is the most important part; #1 is mostly to provide a very easy out-of-the-box experience.
Yeah, the commented-XML approach surely doesn't scale.
On the profile approach, in order to make that scale it might make sense to allow splitting it over multiple files to keep them manageable. These files could be merged at runtime into a single logical XML document possibly using something like XML xinclude. This might make the rewriting following an update 'interesting', however
I like the command line switch. Maybe we can do something like what maven has and support the definition of multiple profiles combined, so if I want to add my webconsole to the default profile I could call standalone.sh -Pdefault,osgi-webconsole or something like that...
Agreed on the IzPack approach.
In discussions last week there were a lot of calls for breaking the config into multiple files. I expect we'll keep hearing that, so it's good to think about it. There are a couple problems I see:
1) The file write problem David pointed out. The domain model would have to start carrying around info about what files various pieces came from, plus generally messier parsing and persisting.
2) The logical thing to separate out into an included file is a subsystem config. But that config isn't entirely self-contained. For example, a subsystem could reference a socket-binding config that's in the socket-binding-groups section and a thread group defined in the threads subsystem. Plus it needs to be recorded as an extension. So to be really useful bringing in that subsystem's config isn't a simple matter of an include; it would be more of a merge.
Thomas Diesler wrote:
I'd say an IzPack installer like we have in jbosgi is the way to go
Not that I'm against an installer for AS7, but one reason why the installer was considered problematic for choosing AS profiles, was because QA testing all possible combinations of profiles wasn't really easy. AS 4.0.x had an installer (IzPack iirc) but from what I know, it was discontinued due to the above reason.
There's an easy answer to that, which is that an installer is part of community AS and not part of the product. That's not very satisfying though. And I know Rich Sharples is interested in an installer-like capability, although in a quick scan I didn't that in any formal requirements doc. In the June discussions we had with Rich where we brainstormed a bit in that we didn't think about the QE implications though.
Another question is what does an installer really mean in terms of added QE and support burden. It's basically a tool for configuring the AS. So is the shell and a text editor; i.e. users have always been able to alter the AS "profile" and make it run a configuration that's not part of our formal test plan. So an installer doesn't add anything new there. What does seem new:
1) If we make it completely trivial to run a particular profile (e.g. we ship a domain-messaging.xml with a nothing-but-messaging profile, or include in an installer a single checkbox to create such a canned profile) then users could expect that we've quite thoroughly QE'd that particular profile.
2) Users might expect that the installer would only allow valid, bootable combinations; i.e. if subsystem X requires subsystem Y and socket-binding A, then a profile can't be created that doesn't include X, Y and A. Confirming the installer enforces that would be a QE burden.
This sounds more like a configuration utility than a installer. Perhaps some independent tool we should add to bin.
Yes, "configuration utility" is a better term. I'm not talking about something that does any sort of provisioning here.