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
