On Fri, Sep 4, 2009 at 1:11 PM, Les Hazlewood<[email protected]> wrote: > Did you have any ideas on how you the 'configuration source API' > should function? I think you or Kalle (or both!) might have mentioned > a proposed new architecture for the configuration components a few > months ago - my memory is a little fuzzy on that at the moment.
I had two main suggestions. First, to favor composition over inheritance in regards to configuration (IniConfiguration, IniWebConfiguration) and to support programmatic configuration. Second, I suggested that perhaps Shiro should use it's own Filter interface rather than servlet filter. The reasoning is that because nobody's going to configure specific Shiro Filters in web.xml anyway, there's no point sticking to that interface. The signature of servlet Filter forces to use HttpServletRequest (and ..Response) but independent Filter interface and corresponding SecurityRequest etc. object would allow them to be used in non-servlet environment such as in portlets or even in non-http environments. Les, I see that you had another thread on that topic, I'll respond to it as well. Kalle > 2009/9/4 Tamás Cservenák <[email protected]>: >> Well, I would object it :) >> >> I had a lot of trouble tampering with it in Nexus (yes, it was JSec >> 0.9, i bet a lot of things changed since then). Major problem for me >> back then was that configuration (the "ini" one) was processed/stored >> in very deep class hierarchy, and I had to do a lot of trickery to >> tamper with it. >> >> I would first extract the configuration into some form of >> "configuration source API" (even a trivial one). So, in short, I would >> not go "on direct path", but introduce some level of indirection, and >> would leave to JSecurity consumer to decide where he want's to go. I >> prefer Scala over Groovy ;) >> >> And finally, yes, the "reference implementation" for that API could be >> done with Groovy, but you would not impose any lock-in for >> integrators. All the "fancy" stuff (like circular path detection, >> lifecycle) should be delegated to API implementors (and re-implemented >> in the "default" Groovy one), since almost all environments (Spring, >> J2EE, Pico, Guice, Plexus) do support those, but naturally, in vastly >> different -- and usually incompatible -- ways. >> >> >> ~t~ >> >> On Fri, Sep 4, 2009 at 8:02 PM, Les Hazlewood<[email protected]> wrote: >>> What about using Groovy as the default configuration format? Then an >>> end user would be building a real object graph and still has the >>> ability to call whatever lifecycle methods they want. And, Groovy >>> allows natural Domain Specific Languages if we want to leverage that. >>> And our end-users would be able to easily understand it, with little >>> or no learning curve. Finally, groovy syntax is really clean and easy >>> to follow. >>> >>> And the only additional dependency would be the groovy .jar. >>> >>> I like it! Does anyone have any thoughts about using (or not using) Groovy? >>> >>> - Les >>> >> >
