Hi Les, sorry for being too silent lately. Yes, I was very occupied with the next 1.4 release of Nexus (internally dubbed: Snow Nexus, with motto: not much on surface, but much-much more in core :) ....
Sadly, configuration was something I did not tackle, so I am a little bit out-of-sync with current JSecurity -- oops, Shiro (damn, I gave away my naming preference!) -- changes, and it's current state (since the version I dived into, was the famous 0.9-RC2). Just to sync up, are you talking about this iface? http://svn.apache.org/viewvc/incubator/shiro/trunk/core/src/main/java/org/apache/shiro/config/Configuration.java?view=markup http://svn.apache.org/viewvc/incubator/shiro/trunk/core/src/main/java/org/apache/shiro/mgt/SecurityManagerFactory.java?view=markup As I see, this is similar what I thought of. If I am correct, this means you are able to "pull" a preconfigured SecurityManager from any source, even from things like IoC containers... Where does the Groovy fits? Will it be a Configuration implementation just like IniConfiguration is? I have to refresh my Shiro knowledge....! Keep up the good work! Thanks, ~t~ On Fri, Sep 4, 2009 at 10:11 PM, Les Hazlewood<[email protected]> wrote: > Hi Tamás, > > Good to hear from you again :) I hope all is well over at Sonatype - > I know I enjoy using Nexus with the ASF and at work - great job! > > But I hear you - the biggest change that needs to occur is to get rid > of the deep hierarchy you mention and definitely clean up the > internals. And yes, any format I talk about (groovy, YAML, etc), > would definitely be a default implementation of a pluggable interface > so integrators like yourself could easily swap things. > > 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. > > There is already the Configuration interface, which I thought was the > 'configuration source' API you mention. Is there something else we > could/should use? > > All comments welcome! > > - Les > > 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 >>> >> >
