I see we agree to disagree, so that sums it up I suppose :)
And I'm perfectly ok with ini files, actually. Well, as long as I can
keep them out of web.xml - I honestly didn't know you could place the
file on the classpath, so thank you for that, Les. No more whining
from me. At least on that matter. There's a strong need for a decent
manual!
But it still would be great if you could consider java config style
which you have omitted in your reply. I guess I haven't been able to
state my thoughts clearly enough, so let me show you a little example
from Spring's Java Config manual to make things a little bit more
understandable (we all understand code better, right?). When I have
mentioned strongly typed config I had something like that in mind:
@Configuration
public class AppConfig {
@Bean
public Foo foo() {
return new Foo(bar());
}
@Bean
public Bar bar() {
return new Bar();
}
}
http://static.springsource.org/spring-javaconfig/docs/1.0.0.M4/reference/html/ch02s02.html
http://www.springsource.org/javaconfig
This is a thing worth placing in the issue tracker. But isn't it there already?
Best regards,
Michał
On Mon, May 10, 2010 at 19:55, Les Hazlewood <[email protected]> wrote:
> Hi Michał - thanks for the feedback! Please see inline below.
>
>> Now they need to grasp another format (so it's the case against
>> YAML as well).
>
> INI is nearly identical to .properties, and quite a few developers
> have had exposure to it in many contexts (mysql.ini, windows .ini), so
> it's not much to ask them to consider it. I personally don't agree
> with your arguments about not using it or YAML due to them not being
> common: YAML for me at least is a huge improvement over XML. I
> consider it progress :) But again, this is a preference issue.
>
>> Now, if I get it correctly (haven't looked at the actual code, sorry),
>> you have used ini blocks to separate concerns.
>
> Yep, exactly.
>
>> The thing is, the same ini file is
>> parsed differently based on context and I feel that separate property
>> files would be more fitting in that case; as it would hint that the
>> files are used to accomplish different things.
>
> That's a fair comment, but I can tell you that most of our users do
> prefer having all of their Shiro configuration in a single location
> because it makes it easy to manage it all from one place. But you're
> right, if the file got really large, it could be a burden (in practice
> though, most Shiro configurations are incredibly short since Shiro's
> defaults do so much for you out-of-the box). And if you're defining
> hundreds of users via text, I would consider that a warning sign that
> a proper data source should be used instead, like LDAP or an RDBMS.
>
> But this is all about preferences right? To that end, it would be
> _extremely_ easy for us to support this. Most people don't know this,
> but the Ini class actually uses Properties objects to create each each
> section into a Map<String,String> of properties - we just leverage
> existing Java functionality :)
>
> So, if you wanted to provide 4 Properties objects (or .properties
> files) - main, urls, users, roles - it would be extremely simple to
> support this. Trivial in fact. We would just create an INI to wrap
> those 4 properties objects and process it as we would have the INI
> file - there is no difference to the code.
>
> If you feel this would be valuable, please open a Jira feature request
> so the dev team can consider it for a future release. We'll do what
> the community wants in all cases: if a decent amount of people want
> separate .properties configuration support, we'll do it :)
>
>> One thing I would work on is to provide sensible defaults so that it
>> should suffice to place a filter on a webapp and it would just work on
>> defaults without any config at all.
>
> It does indeed work this way, with one notable exception: Realms. At
> least 1 Realm must be configured for Shiro to work properly - it has
> no idea how to get authentication or authorization data without at
> least one Realm. So, you can use the [users] section for very simple
> cases (which implicitly creates a Realm), or configure a Realm in
> [main] for more complex data connections.
>
> But that's it! Sensible defaults exist for literally every other part
> of Shiro out of the box :)
>
> Anyway, I am done causing your eyes to strain with so much text :)
> Your feedback is always appreciated! And again, if you feel you want
> .properties support, please open a Jira issue request. We are
> community driven after all!
>
> Cheers,
>
> Les
>
--
Michał Minicki
[email protected]
