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 Sun, 15 May 2011 21:50:25 GMT
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 <> wrote:
>>> 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