avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Re: [RT] Simplification
Date Mon, 06 Oct 2003 15:41:31 GMT
Leo Simons wrote:

> 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: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org

View raw message