Berin Loritsch wrote:
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
Doh! :)
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.
Most likely. It does have certain advantages over properties based configuration--espl. for components. My initial design for a component based system used a property file for each job that needed to be processed. It was a major PITA to maintain and run.
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
Active in the sense that the configuration mechanism is active, not in the pure view of component writer.
(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.
Right. Well I'm not trying to open up a can of worms.
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
:) See, no one answer for everything. Remember JMX is just a "protocol" so to speak. It is a buffer for the configuration aspects of a container.
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.
In a production environment, that is quite true. In a development environment, sometimes it is helpful to "play" with the values to see how it affects the overall performance and weight of the system.
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.
Essentially it moves some of the logic elsewhere. I would still need to see if it "feels" right. Such an implementation would need to be completely sandboxed so that only certain methods are allowed to be called--even when the thing is signed.
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)?
I haven't had a chance to.
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
Right. I think it would be benificial to port that over to Merlin.
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
Hmmm. Maybe we should introduce a new header tag. Instead of [RT] for Random Thought, how about [B&M] for Bitch and Moan... ;P
So it isn't enough of a scratch to itch... that's ok, but I still want to see some simplification, but I am not sure how to move it forward yet.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
