Configuration overhaul - need your feedback

classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Configuration overhaul - need your feedback

Les Hazlewood-2
For me, the biggest thing yet to be done for 1.0 (and there's not even
a Jira issue for this yet - I'll create one asap) is a configuration
overhaul.

I've never been happy with how tightly coupled the Configuration /
.ini mechanisms are - it is not flexible and definitely should be
overhauled.  The existing .ini support falls way short for proper
object-graph (OG) configuration, which is essentially what we require.

Also since Shiro can be used in any environment, we need something
that fully supports standalone configuration, configuration in JEE
environments, and embedded web.xml configuration cleanly and easily.
Since we're essentially configuring an OG, we came to a consensus a
while ago that .ini is probably not the right tool for the job and
that we should probably be using something else.  There was consensus
that YAML was at the least a better choice than .ini.

With YAML however, we still have to write our own lifecycle management
- you essentially need init/destroy method support (and maybe
start/stop support - I dunno yet), as well as circular dependency
checks and similar OG issues.  Things that have been solved elsewhere
(e.g. Spring), that we would have to re-invent.

So the question is - we'll probably need to depend on a 3rd party
library (or set of libraries) for nice OG definition support.  What
library/libraries should that be?

Do we want to go through the effort of supporting OG/lifecycle
concerns and rolling our own using a YAML library?  Seems like a lot
of unnecessary work when Spring does this all already, and very well.
But would we want to use Spring as the default configuration
mechanism? I'm _only_ talking about for initial configuration and not
suggesting that we have a required dependency on Spring or its
components at runtime.

Its a tough call, when you think of what we may have to write from scratch.

Thoughts?  Ideas?

Les
Reply | Threaded
Open this post in threaded view
|

Re: Configuration overhaul - need your feedback

Brian Demers
I don't think the default impl should be based on Spring.  Maybe the default
impl should just be really simple, based in an ini or some pojo or something
(would be nice if the current ini config would still work).  Opional
packages should made available for other implementations something like
shiro-config-spring, shiro-config-guice, shiro-config-etc.

Or something like that anyway (I don't like the names, i am just trying to
illustrate my point)

On Fri, Sep 4, 2009 at 12:01 PM, Les Hazlewood <[hidden email]>wrote:

> For me, the biggest thing yet to be done for 1.0 (and there's not even
> a Jira issue for this yet - I'll create one asap) is a configuration
> overhaul.
>
> I've never been happy with how tightly coupled the Configuration /
> .ini mechanisms are - it is not flexible and definitely should be
> overhauled.  The existing .ini support falls way short for proper
> object-graph (OG) configuration, which is essentially what we require.
>
> Also since Shiro can be used in any environment, we need something
> that fully supports standalone configuration, configuration in JEE
> environments, and embedded web.xml configuration cleanly and easily.
> Since we're essentially configuring an OG, we came to a consensus a
> while ago that .ini is probably not the right tool for the job and
> that we should probably be using something else.  There was consensus
> that YAML was at the least a better choice than .ini.
>
> With YAML however, we still have to write our own lifecycle management
> - you essentially need init/destroy method support (and maybe
> start/stop support - I dunno yet), as well as circular dependency
> checks and similar OG issues.  Things that have been solved elsewhere
> (e.g. Spring), that we would have to re-invent.
>
> So the question is - we'll probably need to depend on a 3rd party
> library (or set of libraries) for nice OG definition support.  What
> library/libraries should that be?
>
> Do we want to go through the effort of supporting OG/lifecycle
> concerns and rolling our own using a YAML library?  Seems like a lot
> of unnecessary work when Spring does this all already, and very well.
> But would we want to use Spring as the default configuration
> mechanism? I'm _only_ talking about for initial configuration and not
> suggesting that we have a required dependency on Spring or its
> components at runtime.
>
> Its a tough call, when you think of what we may have to write from scratch.
>
> Thoughts?  Ideas?
>
> Les
>
Reply | Threaded
Open this post in threaded view
|

Re: Configuration overhaul - need your feedback

kaosko
Absolutely not Spring. Don't get me wrong, I've used and currently use
Spring in many many projects, but it's a heavy-weight and still
doesn't match core feature-wise with the latest in IoC, guice and
tapestry-ioc. Yes, it'll be a tough call - I can see there's a quite a
bit of boilerplate code in Shiro that would just go away if it was
using an IoC container, but at the same time if the project has gone
this far without it, why introduce a new dependency now? Pico, Guice
and tapestry-ioc should all be included in the evaluation together
with Spring if one must be chosen, but I tend to agree with Brian -
the optional packages could fill the void even if the default
configuration scheme doesn't offer it all.

Kalle


On Fri, Sep 4, 2009 at 9:13 AM, Brian Demers<[hidden email]> wrote:

> I don't think the default impl should be based on Spring.  Maybe the default
> impl should just be really simple, based in an ini or some pojo or something
> (would be nice if the current ini config would still work).  Opional
> packages should made available for other implementations something like
> shiro-config-spring, shiro-config-guice, shiro-config-etc.
>
> Or something like that anyway (I don't like the names, i am just trying to
> illustrate my point)
>
> On Fri, Sep 4, 2009 at 12:01 PM, Les Hazlewood <[hidden email]>wrote:
>
>> For me, the biggest thing yet to be done for 1.0 (and there's not even
>> a Jira issue for this yet - I'll create one asap) is a configuration
>> overhaul.
>>
>> I've never been happy with how tightly coupled the Configuration /
>> .ini mechanisms are - it is not flexible and definitely should be
>> overhauled.  The existing .ini support falls way short for proper
>> object-graph (OG) configuration, which is essentially what we require.
>>
>> Also since Shiro can be used in any environment, we need something
>> that fully supports standalone configuration, configuration in JEE
>> environments, and embedded web.xml configuration cleanly and easily.
>> Since we're essentially configuring an OG, we came to a consensus a
>> while ago that .ini is probably not the right tool for the job and
>> that we should probably be using something else.  There was consensus
>> that YAML was at the least a better choice than .ini.
>>
>> With YAML however, we still have to write our own lifecycle management
>> - you essentially need init/destroy method support (and maybe
>> start/stop support - I dunno yet), as well as circular dependency
>> checks and similar OG issues.  Things that have been solved elsewhere
>> (e.g. Spring), that we would have to re-invent.
>>
>> So the question is - we'll probably need to depend on a 3rd party
>> library (or set of libraries) for nice OG definition support.  What
>> library/libraries should that be?
>>
>> Do we want to go through the effort of supporting OG/lifecycle
>> concerns and rolling our own using a YAML library?  Seems like a lot
>> of unnecessary work when Spring does this all already, and very well.
>> But would we want to use Spring as the default configuration
>> mechanism? I'm _only_ talking about for initial configuration and not
>> suggesting that we have a required dependency on Spring or its
>> components at runtime.
>>
>> Its a tough call, when you think of what we may have to write from scratch.
>>
>> Thoughts?  Ideas?
>>
>> Les
>>
>
Reply | Threaded
Open this post in threaded view
|

Re: Configuration overhaul - need your feedback

pledbrook
In reply to this post by Les Hazlewood-2
> Its a tough call, when you think of what we may have to write from scratch.
>
> Thoughts?  Ideas?

What type of configuration are we talking about? I'm a little confused
by the references to Spring.

The Grails plugin supports two different types of configuration. The
first uses config files based on Groovy's ConfigSlurper, which are
similar(ish) to YAML. It's used for setting the session mode, whether
authentication is required by default, etc. The second allows users to
override individual Spring beans and provide their own
implementations.

Cheers,

Peter
Reply | Threaded
Open this post in threaded view
|

Re: Configuration overhaul - need your feedback

Les Hazlewood-2
In reply to this post by kaosko
My Spring suggestion might have been too specific of a reference - I
only really care about lifecycle management and a declarative
mechanism (XML, YAML, etc) that suits object graph definitions and
handles lifecycle management well - and ideally one that we wouldn't
have to support from scratch.

Our current .ini mechanism fails quickly when it comes to lifecycle
management.  We'd have to write code to support that and probably
change the format to be something like a subset of the Velocity
Template Language (VTL) to support these more complicated mechanisms.

This all translates into things that we would have to code, and we'd
essentially be re-inventing the wheel.  And it would be non-standard
and yet-another-format that end-users would have to learn, which I
would love to avoid.

I just wanted to explore other possibilities before we go down a
potentially time-consuming road and perhaps use another tool that is
well suited for the job.

If we just have to 'suck it up' and roll our own to guarantee a lowest
common denominator for all of our users, then so be it.  But I'd only
like to do that if everyone feels we must ;)

Any suggestions on what should be the default, either our own or some
other mechanism?

- Les

On Fri, Sep 4, 2009 at 12:29 PM, Kalle Korhonen
<[hidden email]> wrote:

> Absolutely not Spring. Don't get me wrong, I've used and currently use
> Spring in many many projects, but it's a heavy-weight and still
> doesn't match core feature-wise with the latest in IoC, guice and
> tapestry-ioc. Yes, it'll be a tough call - I can see there's a quite a
> bit of boilerplate code in Shiro that would just go away if it was
> using an IoC container, but at the same time if the project has gone
> this far without it, why introduce a new dependency now? Pico, Guice
> and tapestry-ioc should all be included in the evaluation together
> with Spring if one must be chosen, but I tend to agree with Brian -
> the optional packages could fill the void even if the default
> configuration scheme doesn't offer it all.
>
> Kalle
>
>
> On Fri, Sep 4, 2009 at 9:13 AM, Brian Demers<[hidden email]> wrote:
>> I don't think the default impl should be based on Spring.  Maybe the default
>> impl should just be really simple, based in an ini or some pojo or something
>> (would be nice if the current ini config would still work).  Opional
>> packages should made available for other implementations something like
>> shiro-config-spring, shiro-config-guice, shiro-config-etc.
>>
>> Or something like that anyway (I don't like the names, i am just trying to
>> illustrate my point)
>>
>> On Fri, Sep 4, 2009 at 12:01 PM, Les Hazlewood <[hidden email]>wrote:
>>
>>> For me, the biggest thing yet to be done for 1.0 (and there's not even
>>> a Jira issue for this yet - I'll create one asap) is a configuration
>>> overhaul.
>>>
>>> I've never been happy with how tightly coupled the Configuration /
>>> .ini mechanisms are - it is not flexible and definitely should be
>>> overhauled.  The existing .ini support falls way short for proper
>>> object-graph (OG) configuration, which is essentially what we require.
>>>
>>> Also since Shiro can be used in any environment, we need something
>>> that fully supports standalone configuration, configuration in JEE
>>> environments, and embedded web.xml configuration cleanly and easily.
>>> Since we're essentially configuring an OG, we came to a consensus a
>>> while ago that .ini is probably not the right tool for the job and
>>> that we should probably be using something else.  There was consensus
>>> that YAML was at the least a better choice than .ini.
>>>
>>> With YAML however, we still have to write our own lifecycle management
>>> - you essentially need init/destroy method support (and maybe
>>> start/stop support - I dunno yet), as well as circular dependency
>>> checks and similar OG issues.  Things that have been solved elsewhere
>>> (e.g. Spring), that we would have to re-invent.
>>>
>>> So the question is - we'll probably need to depend on a 3rd party
>>> library (or set of libraries) for nice OG definition support.  What
>>> library/libraries should that be?
>>>
>>> Do we want to go through the effort of supporting OG/lifecycle
>>> concerns and rolling our own using a YAML library?  Seems like a lot
>>> of unnecessary work when Spring does this all already, and very well.
>>> But would we want to use Spring as the default configuration
>>> mechanism? I'm _only_ talking about for initial configuration and not
>>> suggesting that we have a required dependency on Spring or its
>>> components at runtime.
>>>
>>> Its a tough call, when you think of what we may have to write from scratch.
>>>
>>> Thoughts?  Ideas?
>>>
>>> Les
>>>
>>
>
Reply | Threaded
Open this post in threaded view
|

Re: Configuration overhaul - need your feedback

Les Hazlewood-2
In reply to this post by pledbrook
On Fri, Sep 4, 2009 at 1:32 PM, Peter Ledbrook <[hidden email]> wrote:
>> Its a tough call, when you think of what we may have to write from scratch.
>>
>> Thoughts?  Ideas?
>
> What type of configuration are we talking about? I'm a little confused
> by the references to Spring.

Basically any configuration format that can be used to build an object
graph.  Spring's XML is just one example that I surfaced.  YAML is
another.

> The Grails plugin supports two different types of configuration. The
> first uses config files based on Groovy's ConfigSlurper, which are
> similar(ish) to YAML. It's used for setting the session mode, whether
> authentication is required by default, etc. The second allows users to
> override individual Spring beans and provide their own
> implementations.

Actually, the Grails reference surfaces Groovy, which I can't believe
I did not think of before.  I think Groovy would be a fantastic
'embeddable' text-based format since it doesn't require compilation.

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
Reply | Threaded
Open this post in threaded view
|

Re: Configuration overhaul - need your feedback

Tamás Cservenák
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<[hidden email]> 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
>
Reply | Threaded
Open this post in threaded view
|

Re: Configuration overhaul - need your feedback

Les Hazlewood-2
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 <[hidden email]>:

> 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<[hidden email]> 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
>>
>
Reply | Threaded
Open this post in threaded view
|

Re: Configuration overhaul - need your feedback

Tamás Cservenák
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<[hidden email]> 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 <[hidden email]>:
>> 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<[hidden email]> 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
>>>
>>
>
Reply | Threaded
Open this post in threaded view
|

Re: Configuration overhaul - need your feedback

pledbrook
In reply to this post by Les Hazlewood-2
> I like it!  Does anyone have any thoughts about using (or not using) Groovy?

That depends. Do you have a link to a previous discussion about this?
Or the thread title, so I can search for it? I'm just wondering what
type of things the configuration API is expected to do. I'm still
unsure whether it has anything to do with wiring different beans
together, or whether it's simply configuration of already wired beans.
Or something else entirely.

Thanks,

Peter
Reply | Threaded
Open this post in threaded view
|

Re: Configuration overhaul - need your feedback

Manoj Khangaonkar
On Mon, Sep 7, 2009 at 9:15 AM, Peter Ledbrook <[hidden email]>wrote:

> > I like it!  Does anyone have any thoughts about using (or not using)
> Groovy?
>
> That depends. Do you have a link to a previous discussion about this?
> Or the thread title, so I can search for it? I'm just wondering what
> type of things the configuration API is expected to do. I'm still
> unsure whether it has anything to do with wiring different beans
> together, or whether it's simply configuration of already wired beans.
> Or something else entirely.
>
> Thanks,
>
> Peter
>


I did not fully get what configuration we are talking about but that idea of
depending on any third
party library for configuration did not appeal to me.

One of things I like about Shiro is its simplicity. As long as you know java
, you can understand and use shiro
in several places. This is a competetive advantage for shiro because most
security frameworks/products are quite
hard to use.

If I need to know spring or any other library to use shiro, it will reduce
the appeal of shiro for those not familiar
with that library.

In reality Shiro could and should support several configuration formats. So
users may choose which format they want.

But the lowest common denominators , such as simple text based configuration
 should be always be supported.

Manoj Khangaonkar
Reply | Threaded
Open this post in threaded view
|

Re: Configuration overhaul - need your feedback

Jeremy Haile-2
In reply to this post by Les Hazlewood-2
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 <[hidden email]>:
>> 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<[hidden email]> 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
>>>
>>

Reply | Threaded
Open this post in threaded view
|

Re: Configuration overhaul - need your feedback

Les Hazlewood-2
In reply to this post by pledbrook
On Mon, Sep 7, 2009 at 12:15 PM, Peter Ledbrook <[hidden email]> wrote:
>> I like it!  Does anyone have any thoughts about using (or not using) Groovy?
>
> That depends. Do you have a link to a previous discussion about this?
> Or the thread title, so I can search for it? I'm just wondering what
> type of things the configuration API is expected to do. I'm still
> unsure whether it has anything to do with wiring different beans
> together, or whether it's simply configuration of already wired beans.
> Or something else entirely.

I'm basically looking for 2 things with an overhaul

1) Agree upon a default text-based configuration format conducive to
defining object graphs
2) Refactor the existing Configuration codebase to favor OO
composition instead of inheritance to allow other (non default)
configuration mechanisms easier to write and support.

I don't have any links, but here are the interfaces to which I was referring:

org.apache.shiro.config.Configuration
org.apache.shiro.web.config.WebConfiguration

The first interface is empty and is a sub-interface of
org.apache.shiro.mgt.SecurityManagerFactory which just has one method:

getSecurityManager() : SecurityManager

The current default mechanism is to use the .ini format to build an
object graph.  My suggestion with Groovy was to use the Groovy syntax
as the text-based format itself (instead of .ini) as the default,
since it is much better suited for building an object graph.

Any other implementation could be plugged in do whatever it wanted -
e.g. to pull the already-built SecurityManager from a Spring
ApplicationContext, or to look it up from JNDI, or whatever...

Does that help clarify things?

Les
Reply | Threaded
Open this post in threaded view
|

Re: Configuration overhaul - need your feedback

Les Hazlewood-2
In reply to this post by Jeremy Haile-2
On Tue, Sep 8, 2009 at 3:43 PM, Jeremy Haile <[hidden email]> wrote:
> 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.

Whatever mechanism(s) we choose, I feel they should all be in the same
physical file (or single block of text).  I wouldn't want end-users to
specify multiple files - that would be an inconvenience that I at
least would like to avoid as an end 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.

I don't know how to support this cleanly - there could be tons of
properties to support and we'd still have to find a way to define them
and then set those values on the underlying objects.

Would we be required then to use a 'pull' model, where our classes
need to know how to acquire these values themselves?  I don't
particularly like that model - all of our classes are configuration
agnostic, which is very nice.  Maybe some mediator that would know how
to apply configured values...

> #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.

We've already done this with our .ini mechanism, but it falls short in
a few key areas.  This is something I was looking to Groovy for - to
'pick up the slack' so to speak.  Not a full blown IoC container, but
still useful while remaining simple.

Using Groovy could allow us to do other things as well - it'd be easy
to config urls and 'global' properties in #1 using Groovy syntax,
given how nice it is for custom Domain Specific Languages.

> #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.

See my thoughts above on groovy-based configuration - it can handle
declarative security just fine and would still be easy to read.

But I wonder - should our default Lowest Common Denominator
configuration mechanism have _zero_ dependencies?

Currently we don't even meet that criteria - our .ini mechanism
requires Commons BeanUtils, and I haven't heard anyone complain about
that as a dependency.  If we went the Groovy config-based approach,
we'd just swap out the BeanUtils dependency for the groovy .jar.
Seems like a fair trade-off for the additional benefits it would
provide.

Thoughts?

- Les
Reply | Threaded
Open this post in threaded view
|

Re: Configuration overhaul - need your feedback

Jeremy Haile-2
Comments inline.

On Sep 9, 2009, at 11:54 AM, Les Hazlewood wrote:

> On Tue, Sep 8, 2009 at 3:43 PM, Jeremy Haile <[hidden email]> wrote:
>> 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.
>
> Whatever mechanism(s) we choose, I feel they should all be in the same
> physical file (or single block of text).  I wouldn't want end-users to
> specify multiple files - that would be an inconvenience that I at
> least would like to avoid as an end user.

I agree to some extent (properties file perhaps excluded) - but to me  
this implies if I'm using Spring I shouldn't have to go configure some  
groovy script too.  This is part of what feels wrong to me about the  
current config - why do I have to configure somethings in an ini file  
and others in Spring?


>> #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.
>
> I don't know how to support this cleanly - there could be tons of
> properties to support and we'd still have to find a way to define them
> and then set those values on the underlying objects.
>
> Would we be required then to use a 'pull' model, where our classes
> need to know how to acquire these values themselves?  I don't
> particularly like that model - all of our classes are configuration
> agnostic, which is very nice.  Maybe some mediator that would know how
> to apply configured values...

Tons of libraries and frameworks do this cleanly.  There *aren't* tons  
of properties to support; there are a handful.  It's also an  
extensible solution because once you figure out how deep objects can  
retrieve the properties they need for their configuration you are  
done.  You don't have to keep writing the ugly pass-through code that  
you see in our current codebase.  A mediator that applies configured  
values is a good idea - just not sure if it's over-engineering a  
configuration solution that should be simple.

>> #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.
>
> We've already done this with our .ini mechanism, but it falls short in
> a few key areas.  This is something I was looking to Groovy for - to
> 'pick up the slack' so to speak.  Not a full blown IoC container, but
> still useful while remaining simple.

But why should people need to use groovy if they're already using a  
"full blown" IoC container.  And why should our documentation and  
default examples show using groovy to do programmatic configuration  
when we actually think it's a better decision for our users to just  
embrace an actual "full blown" IoC container?  I don't want to require  
any particular IoC container - but I don't see building our own IoC/
configuration/whatever system as adding any value.


> Using Groovy could allow us to do other things as well - it'd be easy
> to config urls and 'global' properties in #1 using Groovy syntax,
> given how nice it is for custom Domain Specific Languages.

But what if I don't want to use groovy - can I still configure these  
in Spring?  Can I configure them in Guice?  I don't understand the big  
picture being proposed here.

>
>> #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.
>
> See my thoughts above on groovy-based configuration - it can handle
> declarative security just fine and would still be easy to read.
>
> But I wonder - should our default Lowest Common Denominator
> configuration mechanism have _zero_ dependencies?

I agree here.  Our Lowest Common Denominator is Java.  "Want zero  
dependencies? Use Java and programmatically configure your Shiro  
installation.  Want nice configuration and dependency injection - then  
use an actual IoC container.  We have great integration with Spring,  
Grails, Guice, X, Y, and Z."

> Currently we don't even meet that criteria - our .ini mechanism
> requires Commons BeanUtils, and I haven't heard anyone complain about
> that as a dependency.  If we went the Groovy config-based approach,
> we'd just swap out the BeanUtils dependency for the groovy .jar.
> Seems like a fair trade-off for the additional benefits it would
> provide.

BeanUtils is an apache-commons project that most big Java projects use  
anyway.  Groovy seems a much stranger core dependency to me.  Don't  
get me wrong - I heavily use Groovy at work and love it.  I just don't  
see how it makes sense here as a core dependency of the Shiro  
project.  Seems like we're reinventing the wheel and going way out of  
our way to not use actual IoC, when in reality most of our users will  
be using actual IoC.

One last point: if our Lowest Common Denominator is Java configuration  
- there's no reason you can't write Groovy code that does the  
programmatic Java configuration.  Why do we need to add a dependency  
for that?

Jeremy
Reply | Threaded
Open this post in threaded view
|

Re: Configuration overhaul - need your feedback

Les Hazlewood-2
Comments inline :)

>> Whatever mechanism(s) we choose, I feel they should all be in the same
>> physical file (or single block of text).  I wouldn't want end-users to
>> specify multiple files - that would be an inconvenience that I at
>> least would like to avoid as an end user.
>
> I agree to some extent (properties file perhaps excluded) - but to me this
> implies if I'm using Spring I shouldn't have to go configure some groovy
> script too.  This is part of what feels wrong to me about the current config
> - why do I have to configure somethings in an ini file and others in Spring?

Nope, you wouldn't have to - I've recently discovered that we've
probably been doing Spring-based config in a less-optimal way all
along. There is a much better way to configure Shiro when using
Spring, and we're not using it in any of our samples:

We need to change all the Spring samples to show in web.xml that the
DelegatingFilterProxy should be used.  Then the ShiroFilter itself and
everything about it can be configured in a spring.xml file and benefit
from things like the PropertyPlaceHolderConfigurer and other things.
Much nicer.

>> Would we be required then to use a 'pull' model, where our classes
>> need to know how to acquire these values themselves?
...
> A mediator that applies configured values is a good idea - just
> not sure if it's over-engineering a configuration solution that should be
> simple.

I'm not sure it is over engineering - configuring the components is
definitely a separate concern than how they operate.  Keeping a clean
separation of concerns has the added benefit that the components can
be easily configured by any other configuration mechanism - something
valuable to the integrators and framework developers that use Shiro
(Trails, Wicket Security, Grails, etc).

I wouldn't want to clutter up our components with configuration based
concerns when our default configuration mechanism (a mediator?) can
work like any of the other config mechanisms of 3rd party frameworks.

>> We've already done this with our .ini mechanism, but it falls short in
>> a few key areas.  This is something I was looking to Groovy for
>
> But why should people need to use groovy if they're already using a "full
> blown" IoC container.

They shouldn't.  They should use whatever their IoC container provides
and what we can enable via a 'support' module for that IoC container.

> And why should our documentation and default examples
> show using groovy to do programmatic configuration when we actually think
> it's a better decision for our users to just embrace an actual "full blown"
> IoC container?  I don't want to require any particular IoC container - but I
> don't see building our own IoC/configuration/whatever system as adding any
> value.

I think this is where we probably disagree.  I feel strongly there
should not be a requirement, or even assumption, that an IoC container
would or should be used when using Shiro.  Sure, we should make it
super simple in an IoC environment, but we shouldn't depend on that.

If this is to hold true - that we can't assume an IoC environment (and
I'll definitely advocate it since many non-IoC-based frameworks are
looking to us now for security) - then you have two options left for a
Lowest Common Denominator config mechanism:

- text based
- Java programming.

If not depending on an IoC container, as an end-user I for one sure
wouldn't like to recompile my application every time I needed to
change configuration.  That leaves text-based configuration.

Groovy, IMO offers the best text-based configuration mechanism
available.  You don't need to recompile it, and it can even feel like
a normal properties mechanism:

securityManager.rememberMeManager.cookie.path = "/blah"

As you know, that actually translates to object graph navigation and
calling a final setter method - but it 'feels' like a simple property
config.  Very nice.

>> Using Groovy could allow us to do other things as well - it'd be easy
>> to config urls and 'global' properties in #1 using Groovy syntax,
>> given how nice it is for custom Domain Specific Languages.
>
> But what if I don't want to use groovy - can I still configure these in
> Spring?  Can I configure them in Guice?  I don't understand the big picture
> being proposed here.

Yep, you could, via the corresponding IoC-specific 'support' module.
I'm talking about using just Shiro, in any environment - no
assumptions on an IoC container or web environment.  This is very
important for the integrators and usages of Shiro in lightweight
environments (I've been contacted by people working on a cell phone
app - they probably don't have access to an IoC container or a web
server).

If all people ever did was use Shiro in Spring-based web-apps, this
project probably wouldn't be necessary since most would just resort to
Acegi/Spring Security.  But because we can be used in any environment
and be configured in any way because of JavaBeans compatibility, we
offer a much more flexible (and still easier to understand!)
alternative ;)

>> But I wonder - should our default Lowest Common Denominator
>> configuration mechanism have _zero_ dependencies?
>
> I agree here.  Our Lowest Common Denominator is Java.  "Want zero
> dependencies? Use Java and programmatically configure your Shiro
> installation.  Want nice configuration and dependency injection - then use
> an actual IoC container.  We have great integration with Spring, Grails,
> Guice, X, Y, and Z."

I agree that the LCD is Java.  But that's an LCD that most people
won't like.  There is a need and community desire for a
no-compile-necessary configuration mechanism that does not assume
container or web app environment.  At least that's my feeling from the
non-Spring users and framework developers that are integrating Shiro.

> BeanUtils is an apache-commons project that most big Java projects use
> anyway.  Groovy seems a much stranger core dependency to me.  Don't get me
> wrong - I heavily use Groovy at work and love it.  I just don't see how it
> makes sense here as a core dependency of the Shiro project.

Actually, I don't think BeanUtils should be a core dependency anymore
- it is only there to support .ini based 'poor man's IoC'
configuration.  And I agree that Groovy shouldn't be a core dependency
either - it should be an addition as a support module.  Then the end
user can choose whatever they want based on what module(s) they
include in their project.

That sounds pretty good to me - separate modules depending on the
configuration mechanism you desire, with the default just being
programmatic Java (by implementing the Configuration interface in
normal Java code).

Thoughts?

Les
Reply | Threaded
Open this post in threaded view
|

Re: Configuration overhaul - need your feedback

Jeremy Haile-2
>> And why should our documentation and default examples
>> show using groovy to do programmatic configuration when we actually  
>> think
>> it's a better decision for our users to just embrace an actual  
>> "full blown"
>> IoC container?  I don't want to require any particular IoC  
>> container - but I
>> don't see building our own IoC/configuration/whatever system as  
>> adding any
>> value.
>
> I think this is where we probably disagree.  I feel strongly there
> should not be a requirement, or even assumption, that an IoC container
> would or should be used when using Shiro.  Sure, we should make it
> super simple in an IoC environment, but we shouldn't depend on that.

I didn't say it should be a requirement - just that I don't think we  
should "roll our own".  If we want to support a dependency-injection  
based model of configuration (i.e. like our current INI config), it  
makes no sense to me for us to build our own and make that a core  
requirement.  We should just support existing frameworks.

> If not depending on an IoC container, as an end-user I for one sure
> wouldn't like to recompile my application every time I needed to
> change configuration.  That leaves text-based configuration.
>
> Groovy, IMO offers the best text-based configuration mechanism
> available.  You don't need to recompile it, and it can even feel like
> a normal properties mechanism.

Well - let's support this via a "support" module just like Spring.  
shiro-groovyconfig.jar

>> But what if I don't want to use groovy - can I still configure  
>> these in
>> Spring?  Can I configure them in Guice?  I don't understand the big  
>> picture
>> being proposed here.
>
> Yep, you could, via the corresponding IoC-specific 'support' module.
> I'm talking about using just Shiro, in any environment - no
> assumptions on an IoC container or web environment.  This is very
> important for the integrators and usages of Shiro in lightweight
> environments (I've been contacted by people working on a cell phone
> app - they probably don't have access to an IoC container or a web
> server).

I never said they needed an IoC container - I just said they could use  
Java to easily configure it.  If we want to support a groovy config  
option, let's make it a "support" module just like Spring or Guice.


>>> But I wonder - should our default Lowest Common Denominator
>>> configuration mechanism have _zero_ dependencies?
>>
>> I agree here.  Our Lowest Common Denominator is Java.  "Want zero
>> dependencies? Use Java and programmatically configure your Shiro
>> installation.  Want nice configuration and dependency injection -  
>> then use
>> an actual IoC container.  We have great integration with Spring,  
>> Grails,
>> Guice, X, Y, and Z."
>
> I agree that the LCD is Java.  But that's an LCD that most people
> won't like.  There is a need and community desire for a
> no-compile-necessary configuration mechanism that does not assume
> container or web app environment.  At least that's my feeling from the
> non-Spring users and framework developers that are integrating Shiro.

Great - if that's their desire then let's create a support module for  
that configuration option.  The LCD in the core can still be Java and  
groovy is one of several options for configuring it.  I feel like a  
broken record - sorry.

>> BeanUtils is an apache-commons project that most big Java projects  
>> use
>> anyway.  Groovy seems a much stranger core dependency to me.  Don't  
>> get me
>> wrong - I heavily use Groovy at work and love it.  I just don't see  
>> how it
>> makes sense here as a core dependency of the Shiro project.
>
> Actually, I don't think BeanUtils should be a core dependency anymore
> - it is only there to support .ini based 'poor man's IoC'
> configuration.  And I agree that Groovy shouldn't be a core dependency
> either - it should be an addition as a support module.  Then the end
> user can choose whatever they want based on what module(s) they
> include in their project.

I don't think BeanUtils should be a dependency either.  Let's shed off  
our "poor man's IoC" implementation completely and just support  
several different configuration mechanisms that can be chosen based on  
your environment. (including simple, pure Java-based configuration)

> That sounds pretty good to me - separate modules depending on the
> configuration mechanism you desire, with the default just being
> programmatic Java (by implementing the Configuration interface in
> normal Java code).

Yep - I agree.  The core has no IoC or config dependencies.  Then you  
include a support module JAR for groovy config, Spring, Guice,  
whatever if you want to use that environment to configure it.  Our  
docs should have a section per support module to explain how to setup  
Shiro using each mechanism.

The broken record responder,
Jeremy


Reply | Threaded
Open this post in threaded view
|

Re: Configuration overhaul - need your feedback

Les Hazlewood-2
That all sounds good to me :)

On Fri, Sep 11, 2009 at 2:20 PM, Jeremy Haile <[hidden email]> wrote:

>>> And why should our documentation and default examples
>>> show using groovy to do programmatic configuration when we actually think
>>> it's a better decision for our users to just embrace an actual "full
>>> blown"
>>> IoC container?  I don't want to require any particular IoC container -
>>> but I
>>> don't see building our own IoC/configuration/whatever system as adding
>>> any
>>> value.
>>
>> I think this is where we probably disagree.  I feel strongly there
>> should not be a requirement, or even assumption, that an IoC container
>> would or should be used when using Shiro.  Sure, we should make it
>> super simple in an IoC environment, but we shouldn't depend on that.
>
> I didn't say it should be a requirement - just that I don't think we should
> "roll our own".  If we want to support a dependency-injection based model of
> configuration (i.e. like our current INI config), it makes no sense to me
> for us to build our own and make that a core requirement.  We should just
> support existing frameworks.
>
>> If not depending on an IoC container, as an end-user I for one sure
>> wouldn't like to recompile my application every time I needed to
>> change configuration.  That leaves text-based configuration.
>>
>> Groovy, IMO offers the best text-based configuration mechanism
>> available.  You don't need to recompile it, and it can even feel like
>> a normal properties mechanism.
>
> Well - let's support this via a "support" module just like Spring.
>  shiro-groovyconfig.jar
>
>>> But what if I don't want to use groovy - can I still configure these in
>>> Spring?  Can I configure them in Guice?  I don't understand the big
>>> picture
>>> being proposed here.
>>
>> Yep, you could, via the corresponding IoC-specific 'support' module.
>> I'm talking about using just Shiro, in any environment - no
>> assumptions on an IoC container or web environment.  This is very
>> important for the integrators and usages of Shiro in lightweight
>> environments (I've been contacted by people working on a cell phone
>> app - they probably don't have access to an IoC container or a web
>> server).
>
> I never said they needed an IoC container - I just said they could use Java
> to easily configure it.  If we want to support a groovy config option, let's
> make it a "support" module just like Spring or Guice.
>
>
>>>> But I wonder - should our default Lowest Common Denominator
>>>> configuration mechanism have _zero_ dependencies?
>>>
>>> I agree here.  Our Lowest Common Denominator is Java.  "Want zero
>>> dependencies? Use Java and programmatically configure your Shiro
>>> installation.  Want nice configuration and dependency injection - then
>>> use
>>> an actual IoC container.  We have great integration with Spring, Grails,
>>> Guice, X, Y, and Z."
>>
>> I agree that the LCD is Java.  But that's an LCD that most people
>> won't like.  There is a need and community desire for a
>> no-compile-necessary configuration mechanism that does not assume
>> container or web app environment.  At least that's my feeling from the
>> non-Spring users and framework developers that are integrating Shiro.
>
> Great - if that's their desire then let's create a support module for that
> configuration option.  The LCD in the core can still be Java and groovy is
> one of several options for configuring it.  I feel like a broken record -
> sorry.
>
>>> BeanUtils is an apache-commons project that most big Java projects use
>>> anyway.  Groovy seems a much stranger core dependency to me.  Don't get
>>> me
>>> wrong - I heavily use Groovy at work and love it.  I just don't see how
>>> it
>>> makes sense here as a core dependency of the Shiro project.
>>
>> Actually, I don't think BeanUtils should be a core dependency anymore
>> - it is only there to support .ini based 'poor man's IoC'
>> configuration.  And I agree that Groovy shouldn't be a core dependency
>> either - it should be an addition as a support module.  Then the end
>> user can choose whatever they want based on what module(s) they
>> include in their project.
>
> I don't think BeanUtils should be a dependency either.  Let's shed off our
> "poor man's IoC" implementation completely and just support several
> different configuration mechanisms that can be chosen based on your
> environment. (including simple, pure Java-based configuration)
>
>> That sounds pretty good to me - separate modules depending on the
>> configuration mechanism you desire, with the default just being
>> programmatic Java (by implementing the Configuration interface in
>> normal Java code).
>
> Yep - I agree.  The core has no IoC or config dependencies.  Then you
> include a support module JAR for groovy config, Spring, Guice, whatever if
> you want to use that environment to configure it.  Our docs should have a
> section per support module to explain how to setup Shiro using each
> mechanism.
>
> The broken record responder,
> Jeremy
Reply | Threaded
Open this post in threaded view
|

Re: Configuration overhaul - need your feedback

kaosko
In reply to this post by Les Hazlewood-2
On Fri, Sep 4, 2009 at 1:11 PM, Les Hazlewood<[hidden email]> 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 <[hidden email]>:
>> 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<[hidden email]> 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
>>>
>>
>
Reply | Threaded
Open this post in threaded view
|

Re: Configuration overhaul - need your feedback

Les Hazlewood-2
On Wed, Sep 16, 2009 at 1:33 PM, Kalle Korhonen
<[hidden email]> wrote:
> I had two main suggestions. First, to favor composition over
> inheritance in regards to configuration

Yep, my latest refactoring has us well on the way towards that goal.
See the FilterChainResolver and FilterChainManager interfaces and
their implementations that I added this week.  Now any configuration
mechanism can utilize both of these components instead of having to
subclass an existing Configuration class.  Hopefully this helps
alleviate Tamás's concerns.

> Second, I suggested that perhaps Shiro should use it's own Filter
> interface rather than servlet filter.

We had a WebInterceptor interface at one time, but removed it since
the servlet Filter interface seemed to satisfy all of our needs.  Even
then, WebInterceptor was still Servlet Request/Response specific.

Can you elaborate as to how this might work, with maybe a sample/intro API?

My fear is that this approach would require us to replicate the
Filter/FilterChain APIs and would probably break all of the existing
Shiro filter end-user configurations - I don't know if we'd want to
risk that :/

> Les, I see that you had
> another thread on that topic, I'll respond to it as well.

Looking forward to it!

- Les
12