Running the Container Launcher as a Daemon Thread

[klsateesh]

Hi All,

We have a Spring Application and the Beans in this are getting invoked from the Web Tier and have written a simple program which will instantiate the container. Currently we are running it as a Daemon Thread ..Are there better ways of doing this..

Thanks
Sateesh

[karldmoore]

You might want to check out ContextLoaderListener. If you have a look at the petclinic example that ships with Spring, the web.xml has comments to explain how this all works.

http://www.springframework.org/docs/...rListener.html

[klsateesh]

Hi,

I would like to run the Services Layer in a Different JVM and probably on a different Physical Machine and it has no Web Interface ( We don't want to run it in a Web Container as we don't need that overhead)..

Now this is the program i am using to launch the Spring Container and keep it running until the JVM goes down

public static void main(String[] args) {
		
		ServicesLauncher servicesLauncher = null;
		servicesLauncher = new ServicesLauncher();
		Thread t = new Thread(servicesLauncher);
		t.setDaemon(true);
		System.out.println("Starting the Spring Container as a Daemon thread");
	    t.start();
	    
	}
public void run(){
		
		ClassPathXmlApplicationContext applicationContext = new ClassPathXmlApplicationContext(this.getConfigFiles());
		System.out.println("Loaded the Spring Container with "+ applicationContext.getBeanDefinitionCount()+" Beans");
		
	}

This is partial as it doesn't hnadle proper shutdown of the Spring Container and restart..
I am not sure whether we need to take advantage of Spring JMX featues and expose the above class as Spring JMX Bean..( Spring JMX Bean to manage the life cycle of another Spring Container !!!)

Thanks
Sateesh

[Dave Syer]

I don't understand why you need to run this code in a separate thread. How does you application get access to a bean from the context - there has to be an entry point somewhere into the bean factory you have set up?

By the way, SingletonBeanFactoryLocator is the preferred method of loading bean factories in standalone applications. It helps with caching, so you don't accidentally start the same container twice, for instance. There are copious docos on the usage in java docs.

[klsateesh]

Hi,

Thanks for your reply..

We are using Mule and Spring together so Web Tier ( Tomcat+Spring+Mule) won't get a Handle of ApplicationContext form the Services Layer (Spring+Mule). It will send messages to the End Point and UMOs in Service Layer gets invoked by Mule..

                                 Web Tier                                       Services Tier Cluster
    Browser  -->        (Tomcat+Spring+Mule)       --->       (Spring+Mule Instnace 1)
                                                                                    (Spring+Mule Instnace 2)

So it depends on what End points we are using on the Web Tier to invoke the Services in the Service Tier (most probably It will not be in the same VM as Service Tier Instances might run on different physical machines than that of the WebServer+Servlet Engine...

Thanks
Sateesh

[Dave Syer]

That doesn't explain why you need a separate thread to launch the bean factory. And the overhead of using another web container for your Mule instance is really pretty minimal (but that is by the way, since you can use a standalone server if you feel like it).

Irrespective if that, I wouldn't recommend trying to re-load or refresh an application context in a running application (that's OSGi territory, so go ahead and look at the Spring OSGi project). You probably have to be very careful what kinds of beans you expose to such a context if you are going to try it.

Shutdown is easy: ApplicationContext.destroy() is supposed to clean up for you.