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 >
