shiro-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Les Hazlewood <>
Subject [DISCUSS] ReflectionBuilder, Bean Events and the new EventBus
Date Wed, 02 Jan 2013 04:47:54 GMT
Hi all and Happy New Year!

Dev team, I know this is a long email, but it is quite important that you
read and understand it fully - it deals with a new fundamental
architectural concept to Shiro.  Please read it as soon as you're able.
 I'd also appreciate any feedback from the extended Shiro community should
they wish to participate.

Ok, so if you've been watching the commit logs over the last week (and to a
lesser extent the last month), you've noticed a lot of commits in the new
org.apache.shiro.event package.

I'm happy to say that I was able to (finally) incorporate a pluggable
EventBus mechanism within Shiro that we can leverage for not only more
robust/pluggable event notification, but for the architectural benefits
that come from a highly decoupled messaging paradigm.  We can leverage this
to much greater effect in future Shiro releases to reduce complexity in
things that currently require a higher degree of (unnecessary) coupling.
 (One such example, is the customizing of Request attributes by a native
session manager but without the ShiroFilter requiring knowledge of the
SessionManager implementation or a highly-specialized interface for that
purpose, but I digress...).

Please read the EventBus JavaDoc for more on how to send and receive
events.  The EventBusAware interface JavaDoc might also be of interest.

Now with a robust EventBus implementation, the first thing I wanted to do
was refactor Jared's most recent (and quite sensible)
org.apache.shiro.config.event.* BeanListener additions in trunk (yet to be
released) to use the newer event infrastructure.

This led me to refactor the ReflectionBuilder to incorporate first class
code citizens for working with the INI object graph definitions:
BeanConfigurationProcessor, BeanConfiguration and Statement (with
InstantiationStatement and AssignmentStatement subclasses) rather than the
previous yet inflexible loop-over-a-collection approach that I put in there
earlier.  These are currently embedded as nested classes at the bottom of
ReflectionBuilder as they are a bit ReflectionBuilder-specific at the
moment.  This afforded a much greater ability to query various states
during configuration processing and to react to things in an easier/cleaner
manner.  Please give it a look and feel free to discuss.

Now these changes all work quite well and as a nice verification, all of
the copious amounts of tests in the ReflectionBuilderTest class passed
successfully without modification - except for 1:  the testBeanListeners
method.  This brings up my question to you all (and Jared might have some
insight here):

The testBeanListeners test case is failing due to expectations of when
BeanEvents should be receivable by objects that are themselves also being
configured.  What are the expectations of when BeanEvents are triggered and
when should components be able to receive those events?

Here are things I am unsure about and would like some feedback on:

1.  If a bean is configured in INI, and it has @Subscribe annotated-methods
for Bean Events, should it be notified of its own instantiation?  That is,
should it receive its own InstantiatedBeanEvent?

If so, why would this be necessary?  The constructor itself is the place
for 'I'm instantiated and now I need to X' logic - why would an
InstantiatedBeanEvent be necessary also?  The InstantiatedBeanEvent in this
case is redundant, no?

2.  For a bean that subscribes to events, should it receive events if
itself is not yet finished being configured?

Scenario: if a subscribing bean is not yet fully configured, and it
receives a bean event that triggers the use of property not yet configured,
that logic will fail.  Registering the subscriber for events after it is
fully configured avoids this scenario.  But is it desirable?

Thanks for any feedback!

Les Hazlewood | @lhazlewood
CTO, Stormpath | | @goStormpath | 888.391.5282
Stormpath wins GigaOM Structure Launchpad Award!

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message