The idea that Leo Simmons put forth brought about some thinking on my part.
You have an error in your RT at 1:23 - illegal duplication of literal 'm' :D
Why was XML originally used as a backing for the configuration object? Because it was easy to implement.
and because it was quickly becoming common practice, I'd say.
We have received a number of compliments on the usability of the configuration interface, esp. from people who prefer the passive
configuration that Avalon uses. We also know that some people prefer
active configuration, and as such develop their components more like
JavaBeans with setters/getters for the configuration points. Some
have gone so far as to move all configuration to the constructor
(Pico Container).
I doubt that the people who use setters/getters think of that as "active configuration", let alone that they are aware of the choice they make (most people into the "new IoC(tm)" hype make the choice on basis of syntax, not on a programming paradigm). PicoContainer doesn't move config to the constructor. It isolates container-component communication iside the constructor:
import org.apache.avalon.configuration.Configuration;
public class MyBlah {
public MyBlah( Configuration c ) {
doConfigure( c );
}
}That is, with the default ComponentAdapters it ships with. PicoContainer allows nearly complete customization of container-component configuration, including lifecycle, configuration, etc etc. Characteristic about PicoContainer is all the things it doesn't do and the choices it doesn't make (some would say: force upon you), or at least allows you to revert with a little effort.
So the question remains to be asked: what is simpler, more acceptable, to our users?
I think you're right on the spot:
- for administrators, a (probably JMX-based) GUI+web-based management console along with the same functionality using a commandline client
- for component programmers, something that feels beanlike
- and for all the windows buffs, something that is drag-and-droppable
How do we handle reconfiguration (which we don't at the moment)? I don't think any of us knows the answer to that, because the answer will be almost as varied as the number of users we have.
I have never found the need to handle reconfiguration of finegrained components. And when I did need to reconfigure stuff (like, once a week in a production system), a restart of the coarsegrained component did the trick pretty well. "apachectl graceful", if you will, is enough.
The impetus behind scripted configuration seems to be administrator simplicity, or something along those lines.
my argument was that scripted configuration simplifies container implementation, administration *and* component development.
So what could be done in a nice generic way?
I still believe in a command pattern, where you can have a container issue commands based on a configuration being parsed, or a remote admin interface based on buttons being pressed, or from a script file bundled with a jar. Have you looked at Twiddle (inside geronimo)?
JMX is only an option if we can generate the JMX MBeans for configuring the individual components automatically. We would be further from a simple solution if we have to write a JMX component by hand for each Avalon component.
phoenix has had mbean generation for ages. Same for JBoss and a bunch of other projects. With mx4j, it isn't that difficult no more. JBoss shows that JMX works. I still don't like it one little bit, but it works remarkably well :D
In the end, once we have one or two possible solutions, I think one of the best things we can do is to involve our users. Put up some explanation of the alternatives, and have an informal vote (an oppinion gathering vote) to assess where our users are. While the votes are not binding and we can still do whatever we want, we will at least be informed of what will be easiest for our users. We might even be pitched a couple alternatives that we haven't thought of before.
:D
Me, I'm just ranting as I go along. I'm not going to commit to implementing any of it, let alone do I have 'users' paying me enough to motivate me into seeing such an effort through :P
cheers!
- LSD
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
