Announcement Announcement Module
Collapse
No announcement yet.
Spring newbie q: best practice accessing ApplicationContext Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Spring newbie q: best practice accessing ApplicationContext

    I'm new to Spring and IoC so bear with me if this has been asked before.

    I would like to use Spring for a new application which is standalone so I
    have to setup the application environment myself.

    I want to use a Spring ApplicationContext derived class for configuring
    the application, but I would like to know what best practice methods
    are for accessing this information from various application classes:

    1. In the RichClient project, I see a lot of Application.method ... so while
    there's one Singleton, it is still accessed from all over the place. Is this
    the recommended approach?

    2. What is the extent of IoC that people use with respect to application
    classes - is it reserved for Singleton access (PersistenceContext,
    LoggingContext, etc)? or is it also used to setup/initialise objects which
    require access to those application wide singleton, but which have a
    shorter life cycle or are created/disposed of many times during a
    single run of the application?

  • #2
    Re: Spring newbie q: best practice accessing ApplicationCont

    Originally posted by bonnyr
    I'm new to Spring and IoC so bear with me if this has been asked before.

    I would like to use Spring for a new application which is standalone so I
    have to setup the application environment myself.

    I want to use a Spring ApplicationContext derived class for configuring
    the application, but I would like to know what best practice methods
    are for accessing this information from various application classes:

    1. In the RichClient project, I see a lot of Application.method ... so while
    there's one Singleton, it is still accessed from all over the place. Is this
    the recommended approach?
    I think so.. Most of my 'service' like objects are singleton (they don`t implement the Singleton design pattern btw)

    2. What is the extent of IoC that people use with respect to application
    classes - is it reserved for Singleton access (PersistenceContext,
    LoggingContext, etc)? or is it also used to setup/initialise objects which
    require access to those application wide singleton, but which have a
    shorter life cycle or are created/disposed of many times during a
    single run of the application?
    You can apply IOC to all beans.. not only the singleton beans. But the life cycle management of non singleton beans is more complicated in Spring because the container doesn`t do any life cycle management after a non singleton bean is created.

    Comment


    • #3
      Thanks for the quick reply.

      Could you please elaborate on your comment below:
      You can apply IOC to all beans.. not only the singleton beans. But the life cycle management of non singleton beans is more complicated in Spring because the container doesn`t do any life cycle management after a non singleton bean is created.
      I still cannot get my mind around how an IoC implementation can take
      care of doing its magic on objects which are not those heavyweight,
      configurable objects, and how an application would go about using
      the container to do this. Would there be an example you'd share?

      Comment


      • #4
        Originally posted by bonnyr
        Thanks for the quick reply.

        Could you please elaborate on your comment below:
        You can apply IOC to all beans.. not only the singleton beans. But the life cycle management of non singleton beans is more complicated in Spring because the container doesn`t do any life cycle management after a non singleton bean is created.
        I still cannot get my mind around how an IoC implementation can take
        care of doing its magic on objects which are not those heavyweight,
        configurable objects, and how an application would go about using
        the container to do this.
        If a bean is created, a method could be called on that bean (initialize). And because the container registers all singleton beans ( I don`t know if it registers non singleton beans), the container could signal the beans as soon as the container shutsdown.

        Would there be an example you'd share?
        Mailer is a bean in my system that needs some life cycle management. You can see the 'init-method' and 'destroy-method' part.

        Code:
        <bean id="mailer"
        		class="mail2mail.server.sender.Mailer"
        		init-method="startup"
        		destroy-method="shutdown">
        
        		<!-- poolSize -->
        		<constructor-arg index="0">
        			<value>5</value>
        		</constructor-arg>
        
                <!-- de prioriteit van de verstuur thread.. 
                	1 = minimaal, 10 = maximaal, 5 = default
        			-->	
        		<constructor-arg index="1">
        			<value>3</value>
        		</constructor-arg>
        
        		<!-- maxBatchSize -->
        		<constructor-arg index="2">
        			<value>50</value>
        		</constructor-arg>
        
        		<!-- smtpConnectionSettings  -->
        		<constructor-arg index="3">
        			<ref bean="smtpConnectionSettings"/>
        		</constructor-arg>
        
        	</bean>

        Comment


        • #5
          See Section 3.2.5, Spring Reference:
          when deploying a bean in the prototype mode, the lifecycle of the bean changes slightly. By definition, Spring cannot manage the complete lifecycle of a non-singleton/prototype bean, since after it is created, it is given to the client and the container does not keep track of it at all any longer. You can think of Spring's role when talking about a non-singleton/prototype bean as a replacement for the 'new' operator. Any lifecycle aspects past that point have to be handled by the client.
          According to this, I guess if mailer in the example above were a prototype, the destroy method wouldn't get called by Spring.

          Comment


          • #6
            Originally posted by manifoldronin
            See Section 3.2.5, Spring Reference:
            when deploying a bean in the prototype mode, the lifecycle of the bean changes slightly. By definition, Spring cannot manage the complete lifecycle of a non-singleton/prototype bean, since after it is created, it is given to the client and the container does not keep track of it at all any longer. You can think of Spring's role when talking about a non-singleton/prototype bean as a replacement for the 'new' operator. Any lifecycle aspects past that point have to be handled by the client.
            According to this, I guess if mailer in the example above were a prototype, the destroy method wouldn't get called by Spring.
            That pretty much answers it for me (me thinks...): Use spring to organise
            scaffholding objects. Use the usual creation techniques for all other objects
            which are part of the business objectives of the application.

            Comment


            • #7
              That pretty much answers it for me (me thinks...): Use spring to organise
              scaffholding objects. Use the usual creation techniques for all other objects
              which are part of the business objectives of the application.
              You can still use Spring for managing the domain model - the benefit of dependency injection still applies. I don't see how Spring not managing the whole life cycle of prototype beans becomes a show stopper. IMHO, a non-singleton bean having a "destroy method" that must be called can be troublesome - about as troublesome as the C++ delete operator.

              Comment


              • #8
                Originally posted by manifoldronin
                - about as troublesome as the C++ delete operator.
                I do not agree. In c++ you always have to destruct object, so you will always call to call a destructor. But because Java doesn`t have destructors , but relies on garbage collection, it is difficult to garantee that a 'destructor' will be called. So: working with destructors is Java in much more complex than with c++.

                Comment


                • #9
                  Originally posted by Alarmnummer
                  I do not agree. In c++ you always have to destruct object, so you will always call to call a destructor. But because Java doesn`t have destructors , but relies on garbage collection, it is difficult to garantee that a 'destructor' will be called. So: working with destructors is Java in much more complex than with c++.
                  Which kind of enforces my original point - a prototype bean with a destroy method spells trouble?

                  Peace.

                  Comment

                  Working...
                  X