Announcement Announcement Module
Collapse
No announcement yet.
How can you get the first reference without using getBean method ? Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • How can you get the first reference without using getBean method ?

    A quote from the manual :
    static.springframework.org/spring/docs/2.5.x/reference/beans.html
    "> 3.2.4. Using the container
    > ...your application code should have no calls to the getBean(String) method at all,
    > and thus no dependency on Spring APIs at all."



    So, how will that first object become instantiated without invoking a factory method such as getBean ?

    For example, consider a configuration file ("application-config.xml") like this:
    Code:
    <beans>
        <bean id="transferService" class="com.bigbank.TransferServiceImpl">
            <property name="accountRepository" ref="accountRepository"/>
        </bean>
    
        <bean id="accountRepository" class="com.bigbank.JdbcAccountRepository">
            <property name="dataSource" ref="dataSource"/>
        </bean>
    
        <bean id="dataSource" class="oracle.jdbc.pool.OracleDataSource">
            <property name="URL" value="jdbc:..."/>
            <property name="user" value="scott"/>
            <property name="password" value="tiger"/>
        </bean>
    </beans>
    Now, if I would have a little console program, I might do something like this from a main method:
    ApplicationContext ctx = new ClassPathXmlApplicationContext("application-config.xml");
    TransferService transferService = ctx.getBean("transferService");


    Then, as far as I understand, the factory method getBean will create a transferService object, and will then instantiate a JdbcAccountRepository object, and will provide that instance to the transferService, by invoking 'transferService.setAccountRepository(theJdbcAccou ntRepositoryInstance)'.
    Similarly, the method 'theJdbcAccountRepositoryInstance.setDataSource(th eOracleDataSource)' will become invoked with an Oracle datasource that was instantiated by the Spring framework.

    The thing I do not understand, though, is how it will be possible to have _no_ calls to getBean _at all_.

    How would you get a reference to the "first/root" bean (transferService) without using 'getBean' as below ?

    Code:
    public static void main(String[] args) {
        String srcAcctId = args[0];
        String destAcctId = args[1];
        Double amount = new Double(args[2]);
    
        ApplicationContext ctx = new ClassPathXmlApplicationContext("application-config.xml");
    
        // How do I avoid using getBean here ???
        TransferService transferService = ctx.getBean("transferService");
    
        transferService.transfer(srcAcctId, destAcctId, amount);
    }

  • #2
    You can implement the lifecycle interface. This is what the Spring JMS does (e.g. DefaultMessageListenerContainer). See the Javadocs. As soon as you initialize a context somewhere (ie create a new context and point it at your Spring config file), all the lifecycle aware beans get initialized.

    So, why the aversion to getBean?

    Comment


    • #3
      If we speak about "little console program" there is no way do not have Spring dependencies somewhere, anyway you need to instantiate context.
      It this case a single call to a getBean() from the same class do no additional harm, dependency is anyway here.

      But if you wish to avoid getBean anyway ... . As soon as context is instantiated all singletons in that context are created (unless explicitly marked for lazy-init). Your program logic may be in the any of those singletons, so your main class only loads context. But is it any better then getBean call? I doubt so.

      Comment


      • #4
        Well, my feeling was not really that I wish to avoid getBean, since I consider it as being an unrealistic claim in the manual, but was open to see if someone can prove the opposite.
        And I do not understand how that Lifecycle interface could help you to instantiate the above "transferService" without using getBean.
        Though, I did understand the answer about the singleton (but me neither think it is better)

        The way I see it, someone, somehow needs to use dependency lookup to retrieve a root bean before dependency injection can be used for constructing the parts of that bean and its parts and so on...

        Regarding the "little console program", does it matter if it had been a swing application?
        Would it be easier for a swing program to magically construct the first bean without your own application code having to retrieve it with dependency lookup ?
        If someone would actually know it can be done, then is there any code example that can illustrate how a swing application can be implemented as the reference manual suggests is possible, without using getBean?
        (i.e. as in the quote: "your application code should have no calls to the getBean(String) method at all")

        Comment


        • #5
          No, Swing program would not be any better in this regard. But Spring is usually used for web applications, and there is a way to externally (i.e. outside of your Java code) initialize context as I have explained in the previous post. In this case it is possible to avoid Spring dependencies (including getBean) all together.

          And as wish bring to the focus - the problem is not to avoid getBean as such, but to avoid Spring dependencies. As in the desktop appliction (be it console or Swing does not matter) it is impossible as you need to instantiate context somewhere. So best that you can achive - is to have thise dependencies in a single class (typically, class with the main method).

          BTW, dependency injection occurs not after but before you fetch your "root" object with getBean.

          Regards,
          'Oleksandr

          Originally posted by tomjon View Post
          Well, my feeling was not really that I wish to avoid getBean, since I consider it as being an unrealistic claim in the manual, but was open to see if someone can prove the opposite.
          And I do not understand how that Lifecycle interface could help you to instantiate the above "transferService" without using getBean.
          Though, I did understand the answer about the singleton (but me neither think it is better)

          The way I see it, someone, somehow needs to use dependency lookup to retrieve a root bean before dependency injection can be used for constructing the parts of that bean and its parts and so on...

          Regarding the "little console program", does it matter if it had been a swing application?
          Would it be easier for a swing program to magically construct the first bean without your own application code having to retrieve it with dependency lookup ?
          If someone would actually know it can be done, then is there any code example that can illustrate how a swing application can be implemented as the reference manual suggests is possible, without using getBean?
          (i.e. as in the quote: "your application code should have no calls to the getBean(String) method at all")
          Last edited by al0; Jun 4th, 2008, 02:13 AM.

          Comment

          Working...
          X