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 | http://stormpath.com | @goStormpath | 888.391.5282 Stormpath wins GigaOM Structure Launchpad Award! http://bit.ly/MvZkMk
