It is confusing for me to discuss how Shiro's configuration should be
overhauled, because there are different types of configuration that
are suited to different configuration mechanisms. I think in order to
have an effective discussion about overhauling the configuration, we
need to break these down.
I would divide the configuration needs of Shiro into these buckets:
1) Properties that need to be setup to use it properly (e.g.
unauthorized URL, login URL, cookie encryption key)
2) Defining realms, filters, and overriding default implementations of
core classes
3) Declarative URL security configuration (e.g. /secure/** = user)
#1 Properties
Currently Shiro treats properties the same as objects and essentially
has a "poor man's" IoC framework for injecting these. The problem is
that sometimes these properties need to be used deep in the hierarchy,
resulting in either ugly nested property names or "pass through"
property code which is equally ugly and strange. (see
DefaultWebSecurityManager.setRememberMeCookiePath() and
WebRememberMeManager.setCookiePath() for an example)
I think the best solution here is to introduce a true properties file
that would be available (somehow) to anyone no matter how deep they
are in the hierarchy. This would essentially define defaults that
could be used by internal classes without having to pass the variables
deep into the hierarchy.
#2 Defining realms, filters, and overriding default implementations
Currently this is done with the "poor man's" IoC implementation as
well. At this level I think we should support using several IoC
frameworks but NOT WRITE OUR OWN. Support Guice out of the box for
this. Support Spring out of the box for this. Support
programmatically doing this out of the box. But if you want to use
IoC - dang it, use one that already exists.
#3 Declarative URL security
Currently this is declared in INI format either in the web.xml file or
in a shiro.ini file. I think this actually still makes sense.
Alternatively it could be injected directly into the ShiroFilter (if
you are using an IoC container.
Thoughts?
Jeremy
On Sep 4, 2009, at 4:11 PM, Les Hazlewood 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
