Spring newbie q: best practice accessing ApplicationContext

[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?

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?

[Alarmnummer]

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.

[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. Would there be an example you'd share?

[Alarmnummer]

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.

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

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

[bonnyr]

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.

[manifoldronin]

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.

[Alarmnummer]

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

[manifoldronin]

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.