Announcement Announcement Module
Collapse
No announcement yet.
Retrieving Spring configured Beans Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Retrieving Spring configured Beans

    I have Java Objects, which in some circumstances need information from a Spring configured Bean. I could have them get the bean through the application context. this would introduce a dependency on Spring in a application layer which otherwise does'nt have any.

    My question:
    Is the following pattern to retrieve the beans advisable or considered bad style? Are there pitfalls?

    Code:
    public class SomeClass implements InitializingBean {
    
        private static SomeClass INSTANCE;
    
        /**
         * Configured properties
         */
    	
        .... 
    
        /*
         * (non-Javadoc)
         * 
         * @see org.springframework.beans.factory.InitializingBean#afterPropertiesSet()
         */
        public void afterPropertiesSet() throws Exception {
            init();
            INSTANCE = this;
    
        }
    
        public static ApplikationsParameter getInstance() {
            return INSTANCE;
    
        }
    
        /**
         * Bean Style setters
         */
        .....
    
    }

    Any feedback appreciated.
    Christoph

  • #2
    What are you trying to do ? sorry but I did not understood your code...
    Anyways you have the init-method for beans inside the XML configuration so you can get rid of Initializing Bean interface.
    Moreover you can create a post processor or extend the existing beanFactories to mimic the Spring dependent configuration with your app specific configuration - create a interface with an init() method and make the bean factory call that method (mimic the InitializingBean mechanism).
    You are using static and singleton inside your class which is usually a bad practice.
    Why don't you inject the beans with Spring inside the application layer where they are needed?

    Comment


    • #3
      What are you trying to do ? sorry but I did not understood your code...
      I just realized, i got the code is wrong. Sorry for the confusion:

      Code:
      public class SomeClass implements InitializingBean {
      
          private static SomeClass INSTANCE;
      
          /**
           * Configured properties
           */
         
          ....
      
          /*
           * (non-Javadoc)
           *
           * @see org.springframework.beans.factory.InitializingBean#afterPropertiesSet()
           */
          public void afterPropertiesSet() throws Exception {
              INSTANCE = this;
      
          }
      
          public static SomeClass getInstance() {
              return INSTANCE;
      
          }
      
          /**
           * Bean Style setters
           */
          .....
      
      }
      Why don't you inject the beans with Spring inside the application layer where they are needed?
      They are not bean's ... but "real" POJO's. Bean's are either singleton's and shared or prototypes. In my case the application layer is made up of a deeply nested object graphs. So injection is no option.

      In order to retrieve the spring configured bean,
      I would have to either have to make the object graph application context aware with some retrieval mechanism or upon construction of the object's pass the needed bean along.... or use the method outlned in the example...

      I am aware that Spring helps to avoid the Singleton pattern... and that the Singleton pattern has become a "bad" smell ;-) .... but i would'nt say the the Singleton pattern is per se bad. Also since bean's are "Singleton's"....
      Ok, i rely on the fact that by default Bean's are shared (1 instance)....

      Comment


      • #4
        Why don't you use a factory for creating/retrieving the POJOs - the factory can be dependent of Spring context and set the graph accordingly before returning the result.
        Singleton pattern is per se bad
        I wrote that 'usually' singletons are a bad practice not always.

        Comment


        • #5
          Why don't you use a factory for creating/retrieving the POJOs.
          That actually what i am doing. the factories are even Spring configured.

          But i rejected setting the application context, because i did'nt want to introduce a additional dependency. for the sake of using in two of 92 classes the singleton pattern's getInstance(), since it really is a Singleton...
          The alternative is that a that i have in a good 25+ classes a reference to a application context, which is never used....

          But maybe i'll reconsider :?

          But you have'nt really convinced me yet, that the approach in this context is "per se" bad, you just said it's is "usually" bad

          Comment


          • #6
            Singletons are best avoided for many many reasons, not least of which is the difficulty they raise when unit testing

            If you absolutely must use a singleton, try and reduce the amount of code that uses it as small as possible. I sometimes (simply for unit testing ) have an interface with a default implementation which can be override, i.e.:

            Code:
            class MyClass() {
              interface BeanProvider {
                Bean getTheBean();
              }
              private BeanProvider provider = new BeanProvider() {
                Bean getTheBean() {
                  return NastySingleton.getBean();
                }
              }
            
              void setBeanProvider(final BeanProvider provider) {
                this.provider = provider;
              }
            }
            A less intrusive way would be to call an "init" method which could be overriden in unit tests, but our idiotic checkstyle rules prevent non-final methods with non-empty bodys

            Comment

            Working...
            X