Thanks for taking time to respond to this, Les. Why ini bothers me? It's just a matter of personal taste, really. It feels polluted to me. I'll try to show you why but as it touches personal preferences it may sound silly.
For starters, I feel that by introducing ini parsing you add something that's alien to Java programmers who are used to property files and xml. Now they need to grasp another format (so it's the case against YAML as well). Not to mention you need to create special parsers instead of using familiar standard language provided classes and clutter application with unnecessary classes or library dependencies. Now, if I get it correctly (haven't looked at the actual code, sorry), you have used ini blocks to separate concerns. I get that (see, you wanted the name of the block changed so it would correctly reflect the behavior in the code). But plain property files can't do that, so ini was a natural and easy choice. 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. You asked on my take on the problem. Well, I don't have enough experience with Shiro to give any solutions or educated guesses but this is what comes to my mind. Look, if your configuration gets big - 1000 users, hundreds of URI to configure - the one ini file starts to make things ugly. It will take more and more time to find specific bits of configuration. It would be much easier if URI, user and bean specific configs would be stored in separate files. I don't see how multiple config files are bad but I get that someone can dislike that. So that leaves us with another feasible option - you still have XML, which has been designed with that problem in mind exactly (hint: hierarchical data and namespaces). I know that XML is verbose but doesn't have to be; with a careful design. You could give users choice by writing separate adapters - INI, XML and property files. But I would advise against that. In the end you will spend more and more time on getting every config to work instead of focusing on what's important (like getting new versions of auth schemes to work). So my advise would be to stick to standards - properties or xml; which one I don't really care. BUT. With latest trends to configure everything in a strongly typed environments (Spring Configuration, Google Guice, etc) I would vote for a standardized Java only configuration as the main way. And to provide xml, properties (or even ini) adapters for the people who like to keep their configuration this way. 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. Of course one could tweak everything later but it would be so much easier for new people to jump on this wagon. Well, I wanted to make things concise and I failed. Sorry for ranting :) Best regards, Michal On Mon, May 10, 2010 at 11:02, Les Hazlewood <[email protected]> wrote: > Hi Michał, > > I'm not sure why INI should bother you - INI is nothing more than > .properties segmented by section headers. I personally much prefer > Shiro's INI config or something like YAML, over say, verbose XML. But > for those that do like XML, there is always Spring XML which works > quite well for configuring Shiro if that's your flavor. Any > JavaBeans-friendly text-based configuration mechanism would be fine > for Shiro really. But here is a little interesting back story: > > Shiro's earliest incarnation of configuration was in fact a > .properties file. But it quickly showed its problems: Configuring the > SecurityManager object graph(s), the URL-specific filter chains (a > concept that the servlet specification/web.xml doesn't even support), > and static users and roles are all significantly different > configuration efforts - doing it all in a single .properties file was > a huge pain for end-users because of the lack of namespacing - you > pretty much had to come up with weird prefixing schemes for all the > properties (user.1.foo = bar, user.2.baz = blah, etc). > > The only reasonable choice was to 'chunk' up those 4 different efforts > somehow - we could have broken them out into multiple files (which > most people would hate), or you find a way to make namespacing work in > a clean way without weird prefixes to properties. INI seemed to fit > that need perfectly with its section construct. > > Also note that Shiro's INI configuration does not need to be embedded > in web.xml. It can be located in any resource location > (file:///some/path/to/some.ini or url:http://some/location/shiro.ini > or classpath:some/package/location/shiro.ini), but many just drop a > shiro.ini at the root of the classpath which is picked up > automatically. I do this for my apps, because I too don't like to > bloat the web.xml file. But you have choices :) > > I hope that helps clarify some of the reasons why things exist as they > do today. But, more importantly, if you have any suggestions on the > configuration format to make it better - we're all ears! We always > appreciate feedback :) > > Best regards, > > Les > > 2010/5/10 Michał Minicki <[email protected]>: >> For what it's worth, I don't like the "ini" configuration as it's just >> not a standard Java way of setting stuff. I would prefer plain >> .properties over that. And even that should reside in a separate file; >> in order not to clutter web.xml with two different sets of option >> types (it has xml extension for a reason there). >> >> I'm pretty new to Shiro but I do like it's design. It's clean and is >> well designed. In fact I like it much better that Spring Security >> (Acegi) which is simply ugly to me. But this ini config makes Shiro >> look hackish on a first glance. Or at least that was the case when I >> first read about Shiro. >> >> I'm sorry for talking a little bit off topic. But this whole >> discussion about main/beans naming made me snap. >> >> Best regards, >> Michał >> >> On Mon, May 10, 2010 at 03:53, Brian Demers <[email protected]> wrote: >>> I don't really have much of an opinion either way, but... If I were to pick >>> sides I would favor something like [setup] or [config] rather then [beans] >>> or [main]. >>> I agree with most of the previous comments, beans is very developer oriented >>> (bad for support engineers), main is not descriptive enough. >>> >>> >>> 2010/5/9 Tamás Cservenák <[email protected]> >>>> >>>> IMO too, "beans" would sound kinda misleading.... even if it does cover >>>> what is actually happen ("bean wiring") more better than "main". >>>> Thanks, >>>> ~t~ >>>> >>>> On Sun, May 9, 2010 at 9:20 AM, Les Hazlewood <[email protected]> >>>> wrote: >>>>> >>>>> Actually Juan, your point is well taken - we'll keep [main] :) If we >>>>> need another section for 'meta config', we can figure out what that >>>>> name would be later. >>>>> >>>>> Thanks for your feedback - it has been valuable! >>>>> >>>>> Best, >>>>> >>>>> Les >>>>> >>>>> On Sat, May 8, 2010 at 9:38 PM, Juan Chung <[email protected]> wrote: >>>>> > how about "SecurityManagerConfig" ? As I know, currently "main" section >>>>> > in >>>>> > Shiro is responsbile for initializing SecurityManager >>>>> > and different kinds of realms. >>>>> > >>>>> > On 2010-5-9 11:29, Kalle Korhonen wrote: >>>>> >> >>>>> >> I would agree with Erik. Bean just doesn't exist in Shiro vocabulary >>>>> >> so why introduce it now. "main" may or may not be a weak choice but >>>>> >> that's what it's been and we don't know now any better what the future >>>>> >> holds, so I'd be inclined to just leave it as "main". >>>>> >> >>>>> >> Kalle >>>>> >> >>>>> >> >>>>> >> On Sat, May 8, 2010 at 8:19 PM, Les Hazlewood<[email protected]> >>>>> >> wrote: >>>>> >> >>>>> >>> >>>>> >>> Ah, interesting Erik - that could work too. Thanks for the feedback! >>>>> >>> >>>>> >>> If anyone else wants to offer feedback, please do so soon - I hope to >>>>> >>> wrap this up as soon as possible to be code complete for 1.0 by >>>>> >>> Monday >>>>> >>> at the latest. >>>>> >>> >>>>> >>> Thanks, >>>>> >>> >>>>> >>> Les >>>>> >>> >>>>> >>> On Sat, May 8, 2010 at 8:02 PM, Erik Beeson<[email protected]> >>>>> >>> wrote: >>>>> >>> >>>>> >>>> >>>>> >>>> I understand what you're saying, but "beans" doesn't seem very >>>>> >>>> meaningful in >>>>> >>>> the context of Shiro. I think "config" (which would be a bit >>>>> >>>> redundant) >>>>> >>>> or >>>>> >>>> "setup" might make more sense. Or leave it "main" and have a new >>>>> >>>> global >>>>> >>>> options section be called "options" or "settings" or something? >>>>> >>>> >>>>> >>>> In the end, I don't think it matters much. We'll use whatever you do >>>>> >>>> :) >>>>> >>>> >>>>> >>>> --Erik >>>>> >>>> >>>>> >>>> >>>>> >>>> On Sat, May 8, 2010 at 10:44 PM, Les >>>>> >>>> Hazlewood<[email protected]>wrote: >>>>> >>>> >>>>> >>>> >>>>> >>>>> >>>>> >>>>> Hi Juan, >>>>> >>>>> >>>>> >>>>> I think you might have missed my point: >>>>> >>>>> >>>>> >>>>> The [main] section today IS the same thing as a Spring-style >>>>> >>>>> configuration - it just uses INI instead of XML. It configures >>>>> >>>>> JavaBeans and builds object graphs and nothing else. That's why >>>>> >>>>> I'd >>>>> >>>>> like to change the name to [beans] - so the section name correctly >>>>> >>>>> reflects the current behavior. >>>>> >>>>> >>>>> >>>>> I also wanted to change the name so that if we ever decided to >>>>> >>>>> bring >>>>> >>>>> back the [main] section, it could be used for things other than >>>>> >>>>> beans-style configuration. You can't mix them both in the same >>>>> >>>>> section. >>>>> >>>>> >>>>> >>>>> Does that make sense? >>>>> >>>>> >>>>> >>>>> Les >>>>> >>>>> >>>>> >>>>> On Sat, May 8, 2010 at 7:06 PM, Juan Chung<[email protected]> >>>>> >>>>> wrote: >>>>> >>>>> >>>>> >>>>>> >>>>> >>>>>> [beans] is a more general name, it likes spring-style >>>>> >>>>>> configuration. >>>>> >>>>>> so >>>>> >>>>>> it cannot clearly express this section's function in Shiro. >>>>> >>>>>> >>>>> >>>>>> but [main] is a more meaningful name for Shiro, it tells the >>>>> >>>>>> end-user >>>>> >>>>>> it >>>>> >>>>>> lies in the Core of Shiro, without it Shiro will not be able to >>>>> >>>>>> work. >>>>> >>>>>> >>>>> >>>>>> I think [main] is a better name than [beans] in Shiro. >>>>> >>>>>> >>>>> >>>>>> On 2010-5-9 7:27, Les Hazlewood wrote: >>>>> >>>>>> >>>>> >>>>>>> >>>>> >>>>>>> The [main] section now exists for the sole purpose of >>>>> >>>>>>> java-beans-style >>>>> >>>>>>> creation, configuration, and object graph assembly. >>>>> >>>>>>> >>>>> >>>>>>> Because of this, I'm thinking the [main] section should be >>>>> >>>>>>> renamed to >>>>> >>>>>>> [beans] to indicate this. The idea is that it is easily >>>>> >>>>>>> conceivable >>>>> >>>>>>> that we'll need a [main] section at some time for framework-wide >>>>> >>>>>>> directives that might not be able to be represented as a >>>>> >>>>>>> bean/property >>>>> >>>>>>> configuration line. >>>>> >>>>>>> >>>>> >>>>>>> Thoughts? >>>>> >>>>>>> >>>>> >>>>>>> Les >>>>> >>>>>>> >>>>> >>>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>>> >>>> >>>>> >>> >>>>> >>> >>>>> > >>>>> > >>>> >>> >>> >> >> >> >> -- >> Michał Minicki >> [email protected] >> > -- Michał Minicki [email protected]
