avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <dona...@apache.org>
Subject Re: Supporting application initialization via atomic an hierarchical objects.
Date Thu, 09 Aug 2001 02:57:06 GMT
On Wed,  8 Aug 2001 09:18, burtonator wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> This is mostly just thinking out loud.  I am not proposing anything just
> thinking...

;)

> A lot of the applications I work on make use of a number of different
> projects. Xalan, Xerces, Log4J, Avalon, Cocoon, etc, etc. etc.
>
> The problem I have seen is that when you build an application which makes
> use of this many projects, you end up with a complicated and ugly
> initialization system.

yep - and the configuration system is often worse ;) 

> 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 ?

> - - 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?

> So what I was thinking of doing was coming up with a quick "Initializer"
> which uses an XML based configuration file to support hierarchical
> inialization via SAX and also acts as a singleton so that your application
> can gain feedback about where you are at in your initialization.
>
> IE this would be something like:
>
> [Initializer]
>
> +getInstance(): Initializer //get an instance of the initializer.
> +init( String target ): boolean throws Exception
> +enabled( String feature ): boolean //return true if a given feature is
> enabled.
>
> ... 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. 

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.

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

>
> This would take a basic XML configuration file such as:
>
> <initializer>
>
>     <initpath>
>
>         <package value="org.openprivacy.reptile.init"/>
>
>     </initpath>
>
>     <entry name="urn:init/offline">
>
>         <level>
>
>             <class name="Log4JInitializer">
>
>                <enable feature="urn:logging"/>
>
>             </class>
>
>             <class name="GeneralInitializer">
>
>                 <verbose>Handling general initialization...</verbose>
>
>             </class>
>
>         </level>
>
>     </entry>
>
>     <entry name="urn:init/servlet">
>
>         <level>
>
>             <class name="ServletInitializer"/>
>
>             <level>
>
>                 <class name="Log4JInitializer">
>
>                    <enable feature="logging"/>
>                    <requires system-property="log4j.configuration"/>
>
>                 </class>
>
>                 <class name="GeneralInitializer"/>
>                 <class name="ContentFeedTasksInitializer"/>
>
>             </level>
>
>         </level>
>
>     </entry>
>
> </initializer>
>
>
> - --
> Kevin A. Burton ( burton@apache.org, burton@openprivacy.org,
> burtonator@acm.org ) Cell: 408-910-6145 URL: http://relativity.yi.org ICQ:
> 73488596
>
> Our nation should be split into warring factions, each ruled by a warlord
> who receives messages from God.... it has *got* to be better than this
> stupid Electoral college!
>
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.4 (GNU/Linux)
> Comment: Get my public key at: http://relativity.yi.org/pgpkey.txt
>
> iD8DBQE7cHdMAwM6xb2dfE0RAtrDAJ4iY9JWcf+wkrV8GaSUGcdVfBC15ACfQDql
> A4AOqPtfl25tX3oQTZM5zWM=
> =MMGF
> -----END PGP SIGNATURE-----
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: avalon-dev-help@jakarta.apache.org

-- 
Cheers,

Pete

*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof."                   |
|              - John Kenneth Galbraith               |
*-----------------------------------------------------*

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


Mime
View raw message