I'd also probably leave off the 'Ini' in the BeanListener name as well - perhaps this could be used with other config too (like YAML or Groovy config, or whatever).
On Wed, May 23, 2012 at 11:19 AM, Les Hazlewood <[email protected]> wrote: > (Moving design discussion here, as Jira tends to be too noisy for this) > > Actually, even better, for the same compatibility reasons, have a > single event listener method: > > IniBeanListener { > void onBeanEvent(BeanEvent event); > } > > This way adding new event types in the future (if ever necessary) > won't break existing implementations (assuming they ignore events they > don't want to process). > > -- > Les Hazlewood > CTO, Stormpath | http://stormpath.com | 888.391.5282 > twitter: @lhazlewood | http://twitter.com/lhazlewood > blog: http://leshazlewood.com > stormpath blog: http://www.stormpath.com/blog > > > On Wed, May 23, 2012 at 11:14 AM, Les Hazlewood (JIRA) <[email protected]> > wrote: >> >> [ >> https://issues.apache.org/jira/browse/SHIRO-364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13281771#comment-13281771 >> ] >> >> Les Hazlewood commented on SHIRO-364: >> ------------------------------------- >> >> 'created' can be interpreted in a number of ways (e.g. after all of its >> properties have been set, only then is it finished being created). >> >> My vote would be: >> >> - notifyInstantiated(InstantiatedBeanEvent event); >> - notifyPropertySet(PropertySetBeanEvent event); The event's propertyValue >> could be an Object (resolved reference) or a String (primitive value yet to >> be converted). If the bean has a getter for that property, they can get the >> converted value by calling bean.getWhateverProperty(). >> - notifyPropertiesSet(ConfiguredBeanEvent event); >> - notifyDestroyed(DestroyedBeanEvent event); >> >> The reason for the event instead of multiple arguments is for compatibility >> over time: Coarse-grained arguments (an object) allow us to add properties >> to it later. Changing method signatures however would break backwards >> compatibility. >> >> The event could also have other useful information, for example, a reference >> back to the overall bean map in case the event listener wanted to inspect >> other beans if necessary. >> >>> Add "bean listener" feature to Ini factories >>> -------------------------------------------- >>> >>> Key: SHIRO-364 >>> URL: https://issues.apache.org/jira/browse/SHIRO-364 >>> Project: Shiro >>> Issue Type: New Feature >>> Reporter: Jared Bunting >>> Assignee: Jared Bunting >>> Fix For: 1.3.0 >>> >>> >>> The ini factory/configuration has been described as a poor man's >>> dependency injection. Even though other DI mechanisms are often used when >>> more power and configurability is required, the ini factory is still quite >>> popular. Adding the ability to register "bean listeners" that are notified >>> of the beans that get created would allow us to add some more complex >>> functionality to shiro, decouple it from our core classes, and support it >>> in all of our supported DI solutions. >> >> -- >> This message is automatically generated by JIRA. >> If you think it was sent incorrectly, please contact your JIRA >> administrators: >> https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa >> For more information on JIRA, see: http://www.atlassian.com/software/jira >> >>
