shiro-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Les Hazlewood <>
Subject Re: Request for feedback - name for Shiro component Map?
Date Tue, 17 May 2011 23:48:36 GMT
I just committed this support - I ended up with sticking with the
approach of having the Environment 'know' about the configuration
metadata (i.e. there is an IniWebEnvironment implementation).

I ditched the factory approach because the pure decoupling was
actually causing problems - there were times during the environment
lifecycle where config metadata was needed and I had very 'hacky' code
in the IniShiroFilter to try to get it to work.

The current incarnation proved to be more versatile and produced
cleaner code while still mostly favoring composition inheritance.  The
new preferred ShiroFilter (that replaces IniShiroFilter) is _much_
simpler than the existing IniShiroFilter as a result (only 6 lines of
code!).  IniShiroFilter on the other hand is much more complex.

In all, the effort went well, but I *really* lamented the fact that
there is no I/O 'Resource' abstraction in Java.  Our ResourceUtils,
while good for simple scenarios is 1) not Object-Oriented, which
causes nasty problems (i.e. I can't resolve InputStreams
polymorphically, regardless of the source) and 2) hard to use in tests
since there is no interface to mock.

I'll probably get around to adding such an abstraction at some point -
ResourceUtils really showed its brittle nature these last two days...



On Sun, May 15, 2011 at 2:50 PM, Les Hazlewood <> wrote:
> Actually, one of the interesting things about Spring's approach is
> that dynamic configuration changes are possible.  For example, their
> 'refresh' method on the XmlWebApplicationContext allows dynamic
> configuration changes at runtime, whereas a decoupled factory approach
> (as I've done) wouldn't easily allow that in the current incarnation.
> However, I don't think that's something that is too useful for Shiro
> because most of those dynamic things can be done by interacting with
> Shiro's object graph at runtime anyway, which I would contend is a
> slightly nicer approach than modifying INI config and wholesale
> replacing your existing environment.
> On Sun, May 15, 2011 at 2:41 PM, Les Hazlewood <> wrote:
>> Yep, exactly.  It could front any container, with the default
>> 'container' being a Map instance populated by Shiro INI config.
>> The Environment (and sub-interface) WebEnvironment is coming out
>> pretty clean so far, as it favors composition over inheritance.
>> For example, Spring combines the notion of resource loading into their
>> ApplicationContext implementations.(e.g. XmlWebApplicationContext).
>> I've decoupled that so far:  I've created a WebEnvironmentFactory and
>> that factory can generate WebEnvironment instances based on config.
>> In other words, I don't have an IniWebEnvironment (to parallel
>> Spring's concepts), but instead an IniWebEnvironmentFactory that
>> ingests INI and creates WebEnvironment instance.  To me, the parsing
>> of configuration metadata and the resulting object-graph output are
>> orthogonal concerns, so I've decoupled them in the current API.
>> Any thoughts/suggestions?
>> Les
>> On Sun, May 15, 2011 at 2:21 PM, Jared Bunting
>> <> wrote:
>>> Are we talking about a read only interface that can be implemented differently
for ini vs spring (or any other di container for that matter) ?
>>> Les Hazlewood <> wrote:
>>> Just an FYI, pending feedback, I'm using
>>> org.apache.shiro.env.Environment for this concept so I can move
>>> forward.  If anyone has any better ideas, please let me know.
>>> On Sun, May 15, 2011 at 12:39 PM, Les Hazlewood <>
>>>> While working on SHIRO-293 [1], I realized that the typical way of
>>>> setting up a Shiro web environment with the current Factory mechanism
>>>> isn't right.  That is, the following code for a web application isn't
>>>> sufficient:
>>>> Factory<SecurityManager> secMgrFactory = new
>>>> IniSecurityManagerFactory("classpath:shiro.ini");
>>>> SecurityManager secMgr = secMgrFactory.getInstance();
>>>> The reason is that web environments require more objects than just the
>>>> SecurityManager.  At a minimum, in addition to the SecurityManager, we
>>>> must be able to acquire the various Servlet Filters that might be
>>>> configured (authc, login, etc).
>>>> So, instead it makes more sense to have this for web apps:
>>>> Factory<Map<String,?>> environmentFactory = ....
>>>> where the map is composed of an object name in the INI config (the
>>>> key) to object (the value) mapping.  From there we can acquire
>>>> anything that was created as a result of INI config.
>>>> However, referencing Map<String,?> all over the place imposes a
>>>> sloppy-looking API.  So I believe we should create an interface that
>>>> represents that Map<String,?> of Shiro objects.
>>>> What should it be called?
>>>> In the Spring world, this concept is called an 'ApplicationContext',
>>>> which more or less makes sense.  But what should we call this one?
>>>> ApplicationEnvironment?  Keep in mind that this map of objects is
>>>> application-specific (i.e. static memory not necessary).
>>>> Any ideas?
>>>> Thanks,
>>>> Les
>>>> [1]

View raw message