Shiro
  1. Shiro
  2. SHIRO-364

Add "bean listener" feature to Ini factories

    Details

    • Type: New Feature New Feature
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: 1.3.0
    • Component/s: None
    • Labels:
      None

      Description

      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.

        Issue Links

          Activity

          Hide
          Les Hazlewood added a comment -

          Hi Jared,

          I just implemented SHIRO-395 - I'm assuming this BeanEvent stuff could leverage this as well. If you get a chance, please review - I'm curious to know what you think.

          Cheers,

          Les

          Show
          Les Hazlewood added a comment - Hi Jared, I just implemented SHIRO-395 - I'm assuming this BeanEvent stuff could leverage this as well. If you get a chance, please review - I'm curious to know what you think. Cheers, Les
          Hide
          Jared Bunting added a comment -

          So far, I have implemented the majority of this and am committing what I have. One thing to note is that I send an instantiation notification for every bean in the map, including those passed in as "defaults" (if they are not overridden). Same for "notifyPropertiesSet", it is invoked on every bean in the map, whether it specifically had any properties set or not.

          I have not implemented "notifyPropertySet" simply because I'm not sure how to keep it consistent with the behavior that I just described.

          Anyways, comments welcome.

          Show
          Jared Bunting added a comment - So far, I have implemented the majority of this and am committing what I have. One thing to note is that I send an instantiation notification for every bean in the map, including those passed in as "defaults" (if they are not overridden). Same for "notifyPropertiesSet", it is invoked on every bean in the map, whether it specifically had any properties set or not. I have not implemented "notifyPropertySet" simply because I'm not sure how to keep it consistent with the behavior that I just described. Anyways, comments welcome.
          Hide
          Les Hazlewood added a comment -

          '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.

          Show
          Les Hazlewood added a comment - '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.
          Hide
          Jared Bunting added a comment -

          Also, I should note that I had planned on calling notifyCreated after properties were set, but if I were to add these new methods it would make more sense to add it before.

          Show
          Jared Bunting added a comment - Also, I should note that I had planned on calling notifyCreated after properties were set, but if I were to add these new methods it would make more sense to add it before.
          Hide
          Jared Bunting added a comment - - edited

          So right now, my interface looks something like this:

          public interface IniBeanListener

          { void notifyCreated(String name, Object bean); void notifyDestroyed(String name, Object bean); }

          Are you proposing that I also include:

          void notifyPropertySet(String name, Object bean, String propertyName, String propertyValue)
          and
          void notifyPropertiesSet(String name, Object bean)

          ?

          Show
          Jared Bunting added a comment - - edited So right now, my interface looks something like this: public interface IniBeanListener { void notifyCreated(String name, Object bean); void notifyDestroyed(String name, Object bean); } Are you proposing that I also include: void notifyPropertySet(String name, Object bean, String propertyName, String propertyValue) and void notifyPropertiesSet(String name, Object bean) ?
          Hide
          Les Hazlewood added a comment -

          In thinking about this a bit, I think we might want to take this a bit further and have methods like:

          beanInstantiated = new instance
          beanPropertySet = foo.bar = $whatever
          beanPropertiesSet = after all properties have been set

          Show
          Les Hazlewood added a comment - In thinking about this a bit, I think we might want to take this a bit further and have methods like: beanInstantiated = new instance beanPropertySet = foo.bar = $whatever beanPropertiesSet = after all properties have been set
          Hide
          Jared Bunting added a comment -

          The idea here is a "IniBeanListener" with a "notify(String name, Object bean)" that will be called once for every bean that is a part of the factory.

          Show
          Jared Bunting added a comment - The idea here is a "IniBeanListener" with a "notify(String name, Object bean)" that will be called once for every bean that is a part of the factory.

            People

            • Assignee:
              Jared Bunting
              Reporter:
              Jared Bunting
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:

                Development