You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shiro.apache.org by Les Hazlewood <lh...@apache.org> on 2009/04/04 21:25:09 UTC
Ki's default configuration format
As most of you know, Ki's default configuration format is .ini. We
basically use it like a properties file, but naturally the section headers,
ala [someName], provide context of how to apply the next block of
properties.
However I've been wishing for a long time, and have voiced it a couple of
times only in passing, that we could use something different - something
more efficient yet adequately expressive for defining configuration.
With the exception of a [urls] section in our .ini files, pretty much
everything else is declared for the purpose of defining an object graph.
I feel that .properties and .ini are pretty poor mechanisms for configuring
an object graph. They become even more verbose than XML since pretty much
every property configured requires its own line. XML is better when you
consider things like Spring's XML bean definition mechanism for object
graphs. But even then I don't like XML's verbosity and cluttered 'feel'.
Also, we naturally shouldn't create a required dependency on Spring just for
a reasonable configuration mechanism.
So, I've been doing some searching and out of many alternate text-based
configuration formats, I feel that YAML would probably fit that 'sweet spot'
for our project for a simple and human readable, yet still very
'declaration-efficient' format. It beautifully supports object graph
definitions, object references, circular dependencies, as well as general
scalar definitions (e.g. our urls section).
For example, check this out: http://jyaml.sourceforge.net/tutorial.html
and this: http://yamlbeans.sourceforge.net/
Look at the yaml text compared to even normal Spring definitions. jyaml
even supports Spring-like configuration, without depending on Spring (
http://jyaml.sourceforge.net/yaml4spring.html - very bottom of the page).
After reasearching yaml and JSON and other formats, I feel that YAML has
learned tremendously from XML and resulted in a clean and easy to understand
text-based format. Given its ease of use and understanding, yet expressive
capabilities, I feel this would be far better suited to our project for a
default config format over .properties or .ini. And we don't have to write
the parser/config mechanisms like we do with the .ini solution in place now
- we just depend on a 3rd party parser so there isn't much to maintain -
even better.
What do you all think about using YAML as our default config mechanism for
1.0 moving forward?
- Les
P.S. This goes without saying, but we should naturally allow end-users to
supply their own configuration - I'm just talking about what could be Ki's
default.
Re: Ki's default configuration format
Posted by Les Hazlewood <lh...@apache.org>.
Sounds good, I'll post updates to the list.
Cheers,
Les
On Sat, Apr 4, 2009 at 7:33 PM, Kalle Korhonen
<ka...@gmail.com>wrote:
> On Sat, Apr 4, 2009 at 3:22 PM, Les Hazlewood <lh...@apache.org>
> wrote:
>
> > I'm going to take a stab at refactoring the configuration classes this
> > weekend as discussed previously (maybe a month ago?) to use composition
> > instead of inheritance. It will still be .ini-based pending more
> feedback
> > on this thread, but it should alleviate the problems you had with all
> that
> > custom coding.
> >
>
> Thanks. I wouldn't consider it a problem though apart from not being able
> to
> use any common super classes. Configuring things programmatically fits to
> Tapestry style better anyway, so I'm not going back to the ini files, but I
> plan on keeping the implementation up-to-date with Ki and taking of new
> common code whenever appropriate.
>
> Kalle
>
>
> On Sat, Apr 4, 2009 at 5:21 PM, Kalle Korhonen
> > <ka...@gmail.com>wrote:
> >
> > > +1. For the same reasons and more, I've implemented a programmatic
> > > JSecurity/KI configuration for Tapestry5 (and in doing so, bypassing
> many
> > > of
> > > the base classes meant to be used in Ki). Besides the clutter of
> > describing
> > > an object graph in a property file, the default implementation didn't
> > AFAIK
> > > support using multiple ini files. I might re-consider using
> configuration
> > > files if the implementation would support loading them from multiple
> > > locations and merging the configuration.
> > >
> > > Kalle
> > >
> > >
> > > On Sat, Apr 4, 2009 at 12:25 PM, Les Hazlewood <lhazlewood@apache.org
> > > >wrote:
> > >
> > > > As most of you know, Ki's default configuration format is .ini. We
> > > > basically use it like a properties file, but naturally the section
> > > headers,
> > > > ala [someName], provide context of how to apply the next block of
> > > > properties.
> > > >
> > > > However I've been wishing for a long time, and have voiced it a
> couple
> > of
> > > > times only in passing, that we could use something different -
> > something
> > > > more efficient yet adequately expressive for defining configuration.
> > > >
> > > > With the exception of a [urls] section in our .ini files, pretty much
> > > > everything else is declared for the purpose of defining an object
> > graph.
> > > >
> > > > I feel that .properties and .ini are pretty poor mechanisms for
> > > configuring
> > > > an object graph. They become even more verbose than XML since pretty
> > > much
> > > > every property configured requires its own line. XML is better when
> > you
> > > > consider things like Spring's XML bean definition mechanism for
> object
> > > > graphs. But even then I don't like XML's verbosity and cluttered
> > 'feel'.
> > > > Also, we naturally shouldn't create a required dependency on Spring
> > just
> > > > for
> > > > a reasonable configuration mechanism.
> > > >
> > > > So, I've been doing some searching and out of many alternate
> text-based
> > > > configuration formats, I feel that YAML would probably fit that
> 'sweet
> > > > spot'
> > > > for our project for a simple and human readable, yet still very
> > > > 'declaration-efficient' format. It beautifully supports object graph
> > > > definitions, object references, circular dependencies, as well as
> > general
> > > > scalar definitions (e.g. our urls section).
> > > >
> > > > For example, check this out:
> > http://jyaml.sourceforge.net/tutorial.html
> > > > and this: http://yamlbeans.sourceforge.net/
> > > >
> > > > Look at the yaml text compared to even normal Spring definitions.
> > jyaml
> > > > even supports Spring-like configuration, without depending on Spring
> (
> > > > http://jyaml.sourceforge.net/yaml4spring.html - very bottom of the
> > > page).
> > > >
> > > > After reasearching yaml and JSON and other formats, I feel that YAML
> > has
> > > > learned tremendously from XML and resulted in a clean and easy to
> > > > understand
> > > > text-based format. Given its ease of use and understanding, yet
> > > expressive
> > > > capabilities, I feel this would be far better suited to our project
> for
> > a
> > > > default config format over .properties or .ini. And we don't have to
> > > write
> > > > the parser/config mechanisms like we do with the .ini solution in
> place
> > > now
> > > > - we just depend on a 3rd party parser so there isn't much to
> maintain
> > -
> > > > even better.
> > > >
> > > > What do you all think about using YAML as our default config
> mechanism
> > > for
> > > > 1.0 moving forward?
> > > >
> > > > - Les
> > > >
> > > > P.S. This goes without saying, but we should naturally allow
> end-users
> > > to
> > > > supply their own configuration - I'm just talking about what could be
> > > Ki's
> > > > default.
> > > >
> > >
> >
>
Re: Ki's default configuration format
Posted by Kalle Korhonen <ka...@gmail.com>.
On Sat, Apr 4, 2009 at 3:22 PM, Les Hazlewood <lh...@apache.org> wrote:
> I'm going to take a stab at refactoring the configuration classes this
> weekend as discussed previously (maybe a month ago?) to use composition
> instead of inheritance. It will still be .ini-based pending more feedback
> on this thread, but it should alleviate the problems you had with all that
> custom coding.
>
Thanks. I wouldn't consider it a problem though apart from not being able to
use any common super classes. Configuring things programmatically fits to
Tapestry style better anyway, so I'm not going back to the ini files, but I
plan on keeping the implementation up-to-date with Ki and taking of new
common code whenever appropriate.
Kalle
On Sat, Apr 4, 2009 at 5:21 PM, Kalle Korhonen
> <ka...@gmail.com>wrote:
>
> > +1. For the same reasons and more, I've implemented a programmatic
> > JSecurity/KI configuration for Tapestry5 (and in doing so, bypassing many
> > of
> > the base classes meant to be used in Ki). Besides the clutter of
> describing
> > an object graph in a property file, the default implementation didn't
> AFAIK
> > support using multiple ini files. I might re-consider using configuration
> > files if the implementation would support loading them from multiple
> > locations and merging the configuration.
> >
> > Kalle
> >
> >
> > On Sat, Apr 4, 2009 at 12:25 PM, Les Hazlewood <lhazlewood@apache.org
> > >wrote:
> >
> > > As most of you know, Ki's default configuration format is .ini. We
> > > basically use it like a properties file, but naturally the section
> > headers,
> > > ala [someName], provide context of how to apply the next block of
> > > properties.
> > >
> > > However I've been wishing for a long time, and have voiced it a couple
> of
> > > times only in passing, that we could use something different -
> something
> > > more efficient yet adequately expressive for defining configuration.
> > >
> > > With the exception of a [urls] section in our .ini files, pretty much
> > > everything else is declared for the purpose of defining an object
> graph.
> > >
> > > I feel that .properties and .ini are pretty poor mechanisms for
> > configuring
> > > an object graph. They become even more verbose than XML since pretty
> > much
> > > every property configured requires its own line. XML is better when
> you
> > > consider things like Spring's XML bean definition mechanism for object
> > > graphs. But even then I don't like XML's verbosity and cluttered
> 'feel'.
> > > Also, we naturally shouldn't create a required dependency on Spring
> just
> > > for
> > > a reasonable configuration mechanism.
> > >
> > > So, I've been doing some searching and out of many alternate text-based
> > > configuration formats, I feel that YAML would probably fit that 'sweet
> > > spot'
> > > for our project for a simple and human readable, yet still very
> > > 'declaration-efficient' format. It beautifully supports object graph
> > > definitions, object references, circular dependencies, as well as
> general
> > > scalar definitions (e.g. our urls section).
> > >
> > > For example, check this out:
> http://jyaml.sourceforge.net/tutorial.html
> > > and this: http://yamlbeans.sourceforge.net/
> > >
> > > Look at the yaml text compared to even normal Spring definitions.
> jyaml
> > > even supports Spring-like configuration, without depending on Spring (
> > > http://jyaml.sourceforge.net/yaml4spring.html - very bottom of the
> > page).
> > >
> > > After reasearching yaml and JSON and other formats, I feel that YAML
> has
> > > learned tremendously from XML and resulted in a clean and easy to
> > > understand
> > > text-based format. Given its ease of use and understanding, yet
> > expressive
> > > capabilities, I feel this would be far better suited to our project for
> a
> > > default config format over .properties or .ini. And we don't have to
> > write
> > > the parser/config mechanisms like we do with the .ini solution in place
> > now
> > > - we just depend on a 3rd party parser so there isn't much to maintain
> -
> > > even better.
> > >
> > > What do you all think about using YAML as our default config mechanism
> > for
> > > 1.0 moving forward?
> > >
> > > - Les
> > >
> > > P.S. This goes without saying, but we should naturally allow end-users
> > to
> > > supply their own configuration - I'm just talking about what could be
> > Ki's
> > > default.
> > >
> >
>
Re: Ki's default configuration format
Posted by Les Hazlewood <lh...@apache.org>.
Hi Kalle,
I'm going to take a stab at refactoring the configuration classes this
weekend as discussed previously (maybe a month ago?) to use composition
instead of inheritance. It will still be .ini-based pending more feedback
on this thread, but it should alleviate the problems you had with all that
custom coding.
Cheers,
Les
On Sat, Apr 4, 2009 at 5:21 PM, Kalle Korhonen
<ka...@gmail.com>wrote:
> +1. For the same reasons and more, I've implemented a programmatic
> JSecurity/KI configuration for Tapestry5 (and in doing so, bypassing many
> of
> the base classes meant to be used in Ki). Besides the clutter of describing
> an object graph in a property file, the default implementation didn't AFAIK
> support using multiple ini files. I might re-consider using configuration
> files if the implementation would support loading them from multiple
> locations and merging the configuration.
>
> Kalle
>
>
> On Sat, Apr 4, 2009 at 12:25 PM, Les Hazlewood <lhazlewood@apache.org
> >wrote:
>
> > As most of you know, Ki's default configuration format is .ini. We
> > basically use it like a properties file, but naturally the section
> headers,
> > ala [someName], provide context of how to apply the next block of
> > properties.
> >
> > However I've been wishing for a long time, and have voiced it a couple of
> > times only in passing, that we could use something different - something
> > more efficient yet adequately expressive for defining configuration.
> >
> > With the exception of a [urls] section in our .ini files, pretty much
> > everything else is declared for the purpose of defining an object graph.
> >
> > I feel that .properties and .ini are pretty poor mechanisms for
> configuring
> > an object graph. They become even more verbose than XML since pretty
> much
> > every property configured requires its own line. XML is better when you
> > consider things like Spring's XML bean definition mechanism for object
> > graphs. But even then I don't like XML's verbosity and cluttered 'feel'.
> > Also, we naturally shouldn't create a required dependency on Spring just
> > for
> > a reasonable configuration mechanism.
> >
> > So, I've been doing some searching and out of many alternate text-based
> > configuration formats, I feel that YAML would probably fit that 'sweet
> > spot'
> > for our project for a simple and human readable, yet still very
> > 'declaration-efficient' format. It beautifully supports object graph
> > definitions, object references, circular dependencies, as well as general
> > scalar definitions (e.g. our urls section).
> >
> > For example, check this out: http://jyaml.sourceforge.net/tutorial.html
> > and this: http://yamlbeans.sourceforge.net/
> >
> > Look at the yaml text compared to even normal Spring definitions. jyaml
> > even supports Spring-like configuration, without depending on Spring (
> > http://jyaml.sourceforge.net/yaml4spring.html - very bottom of the
> page).
> >
> > After reasearching yaml and JSON and other formats, I feel that YAML has
> > learned tremendously from XML and resulted in a clean and easy to
> > understand
> > text-based format. Given its ease of use and understanding, yet
> expressive
> > capabilities, I feel this would be far better suited to our project for a
> > default config format over .properties or .ini. And we don't have to
> write
> > the parser/config mechanisms like we do with the .ini solution in place
> now
> > - we just depend on a 3rd party parser so there isn't much to maintain -
> > even better.
> >
> > What do you all think about using YAML as our default config mechanism
> for
> > 1.0 moving forward?
> >
> > - Les
> >
> > P.S. This goes without saying, but we should naturally allow end-users
> to
> > supply their own configuration - I'm just talking about what could be
> Ki's
> > default.
> >
>
Re: Ki's default configuration format
Posted by Kalle Korhonen <ka...@gmail.com>.
+1. For the same reasons and more, I've implemented a programmatic
JSecurity/KI configuration for Tapestry5 (and in doing so, bypassing many of
the base classes meant to be used in Ki). Besides the clutter of describing
an object graph in a property file, the default implementation didn't AFAIK
support using multiple ini files. I might re-consider using configuration
files if the implementation would support loading them from multiple
locations and merging the configuration.
Kalle
On Sat, Apr 4, 2009 at 12:25 PM, Les Hazlewood <lh...@apache.org>wrote:
> As most of you know, Ki's default configuration format is .ini. We
> basically use it like a properties file, but naturally the section headers,
> ala [someName], provide context of how to apply the next block of
> properties.
>
> However I've been wishing for a long time, and have voiced it a couple of
> times only in passing, that we could use something different - something
> more efficient yet adequately expressive for defining configuration.
>
> With the exception of a [urls] section in our .ini files, pretty much
> everything else is declared for the purpose of defining an object graph.
>
> I feel that .properties and .ini are pretty poor mechanisms for configuring
> an object graph. They become even more verbose than XML since pretty much
> every property configured requires its own line. XML is better when you
> consider things like Spring's XML bean definition mechanism for object
> graphs. But even then I don't like XML's verbosity and cluttered 'feel'.
> Also, we naturally shouldn't create a required dependency on Spring just
> for
> a reasonable configuration mechanism.
>
> So, I've been doing some searching and out of many alternate text-based
> configuration formats, I feel that YAML would probably fit that 'sweet
> spot'
> for our project for a simple and human readable, yet still very
> 'declaration-efficient' format. It beautifully supports object graph
> definitions, object references, circular dependencies, as well as general
> scalar definitions (e.g. our urls section).
>
> For example, check this out: http://jyaml.sourceforge.net/tutorial.html
> and this: http://yamlbeans.sourceforge.net/
>
> Look at the yaml text compared to even normal Spring definitions. jyaml
> even supports Spring-like configuration, without depending on Spring (
> http://jyaml.sourceforge.net/yaml4spring.html - very bottom of the page).
>
> After reasearching yaml and JSON and other formats, I feel that YAML has
> learned tremendously from XML and resulted in a clean and easy to
> understand
> text-based format. Given its ease of use and understanding, yet expressive
> capabilities, I feel this would be far better suited to our project for a
> default config format over .properties or .ini. And we don't have to write
> the parser/config mechanisms like we do with the .ini solution in place now
> - we just depend on a 3rd party parser so there isn't much to maintain -
> even better.
>
> What do you all think about using YAML as our default config mechanism for
> 1.0 moving forward?
>
> - Les
>
> P.S. This goes without saying, but we should naturally allow end-users to
> supply their own configuration - I'm just talking about what could be Ki's
> default.
>