avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "hammett" <hamm...@apache.org>
Subject Re: [RT] avalon (merlin) == safe == programmer effort
Date Sun, 05 Oct 2003 14:09:13 GMT
> MyBlah.configurator.strict.bsh
> ------------------------------------------------------------------------
> import org.apache.avalon.framework.configuration.Configurator;
> import com.blah.MyBlah;
>
> public class MyBlahConfigurator implements Configurator
> {
>    public void configure( Object component )
>    {
>      assert component instanceof MyBlah :
>          "component must be instance of MyBlah!";
>
>      MyBlah blah = (MyBlah)component;
>      component.setNumberOfThreads( 15 );
>    }
> }

What's the difference? In order to perform configuration from Script
languages or a subset of java, the user will face a simple choice. We can
try for hours imagine if its human readable, if sysops will not suffer a
heart attack, but the actual decision is from users - who actually knows the
best for them.

I'd like to point out why Jini works the way it is. A server application,
which exports one or more services usually will have to choose a exporting
strategy, a simple proxy, RMI, or whatever exists or will be invented. So
this config file returns the exactly implementation of the desired Exporter
selected at runtime for that particulary environment. What? Are you saying
that this can be done through XML?

<component>
  <exporter type="RMI" />
</component>

Ok, that's valid. So a component needs to know every type of exporting
possibilities and know how to configure each of them.

What?

<component>
  <exporter class="net.jini.exporters.BasicExporter" />
</component>

Oh! That's better. And how the BasicExporter should be initiallized? It has
a important constructor, you know.

So now you see what they tried to solve :-)
Leo, you can shoot me now!  :-P


Regards,

hammett


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org


Mime
View raw message