You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by burtonator <bu...@relativity.yi.org> on 2001/08/08 01:18:37 UTC
Supporting application initialization via atomic an hierarchical objects.
-----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.
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.
- - 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.
- - Terminate initialization if anything wrong happens along the way.
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.
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
Re: Supporting application initialization via atomic an hierarchical objects.
Posted by burtonator <bu...@relativity.yi.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Peter Donald <do...@apache.org> writes:
<snip>
> 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.
<snip>
> >
> > ... 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.
yes.
> 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 ;)
<snip>
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
interest.
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!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: Get my public key at: http://relativity.yi.org/pgpkey.txt
iD8DBQE7cwIxAwM6xb2dfE0RAogjAKCEGxLdIHSC1nMeYUodqq+mFQj9HgCgj+gp
a0kkhYLEMsoYzEhLNKa5gP4=
=cNA2
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: Supporting application initialization via atomic an hierarchical objects.
Posted by Peter Donald <do...@apache.org>.
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