avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From burtonator <bur...@relativity.yi.org>
Subject Re: Supporting application initialization via atomic an hierarchical objects.
Date Thu, 09 Aug 2001 21:35:45 GMT
Hash: SHA1

Peter Donald <donaldp@apache.org> writes:

> yep - and the configuration system is often worse ;) 

Yes.  I don't think we will every get to a point where you have one isolated and
clean configuration system but we could provide a common set of Facades in one
location for initializing systems like Turbine/Cocoon/etc.

> > For example you end up needing the following:
> >
> > - - Selectively initialize systems based on configuration.  IE if you are
> > running as a servlet enable a background thread pool system but if you are
> > running in "offline" mode you don't really want this feature.
> Kinda like unixes runlevel ?

Sort of.  But with unix(linux) runlevels you can shut services down.  I don't
know if it would be possible to shut things down.

... of course it might be a decent idea though.  Maybe instead of an Initializer
it would be something like a Runlevel with start/stop methods.

Although I don't like the concept of a Runlevel in Java I am sure we could find
an analogous name.

> > - - Enable features in your system such as logging.  Of course you don't
> > want this happening too soon because if you enable a feature which hasn't
> > been initialized you will get unusual behavior.
> >
> > - - Support initialization via a named target.
> unix runlevel again?

Unix runlevels don't use names but numbers.  Not very nice.  I was thinking we
could use URNs for the targets.  IE urn:myapp/offline would init your
application for offline mode.  

> >
> > ... Of course this would be very simple to develop and would be very simple
> > to add to existing projects.  It would really only need one class
> > (Initializer) and a given XML file.
> >
> > Anyway... feedback would be nice.
> It looks like a different approach to the problem we tackle with
> Avalon/Phoenix. ie Essentially constructing an "application" from a set of
> components.

I don't think it is a different approach... just a complimentary approach. I
think that this system would be somewhat pragmatic and allow you to initialize
anything in an elegant manner, component or not.

If a certain component system has support for component based initialization we
could provide a facade for dealing with this component type.

> The main differences (besides syntax et al) being that you implicitly define
> dependencies/relationships and that you have different setups/runlevels
> contained in one file.


> I prefer to make dependencies explicit - so instead of having certain
> components enable a feature when they come up instead you require all users
> declare a dependency on component. That way ordering becomes irrelevent.

Yes.  I was thinking that you could have a centralized set of "features" and
your initializers could require() these features.  So for example I could do a

Initializer.requireFeature( "urn:feature/logging" )

And this would enable Log4J/LogKit/JSR for your specific appliction.  Future
initializers could require a feature or check if it is enabled.

> However I like the notion of runlevels. It is definetly a good idea ;)

I have started to work on it in my spare time.  Right now it is just called
Genesis and it will be under the OpenPrivacy CVS soon.  Of course I don't know
where this will end up... I have no problem donating it if there is enough

Our initialization (in Reptile) is *very* messy and it is starting to scare
me. :( We depend on WAY too many projects and this has started to "bleed" into
our application dependability. :(

- -- 
Kevin A. Burton ( burton@apache.org, burton@openprivacy.org, burtonator@acm.org )
        Cell: 408-910-6145 URL: http://relativity.yi.org ICQ: 73488596 

The dawn is rising on a new day!
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: Get my public key at: http://relativity.yi.org/pgpkey.txt


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

View raw message