"Application" scope.... (does something like this exist?)

[JeanNiBee]

Hi

Part of my Spring App (Using MVC) is to process statistics through a statistics engine. There are many engines (pojo's) and each would need to be queried by various pieces of the application.

Two part question.

1. How can I, in Spring, use a "plugin" (what it was called in Struts) to setup and initialize my engines?
2. How can I put these engines in a scope that is shared across the WHOLE application (as opposed to say putting stuff in the user session using a request.getSesion(). )

Thanks in advance.

[thebugslayer]

Hello JeanNiBee,

In the heart of any SpringMVC is it's configuration xml file you configured that match to your servlet dispatcher. In your web.xml, if you have setup "myspring" as name of your "org.springframework.web.servlet.DispatcherServlet ", then you can create a myspring-servlet.xml. In this config you may instanciate any pojo or beans of you engine. To add these references into Application scope, you will want to write a Bean/Class that implements "org.springframework.context.ApplicationContextAwa re" interface. When you create an instance of this class in your xml, the method "setApplicationContext(ApplicationContext applicationContext)" will get call with the context object your app runs on, and there you have full access to insert anything you want.

Hope this helps.

[JeanNiBee]

Hello JeanNiBee,

In the heart of any SpringMVC is it's configuration xml file you configured that match to your servlet dispatcher. In your web.xml, if you have setup "myspring" as name of your "org.springframework.web.servlet.DispatcherServlet ", then you can create a myspring-servlet.xml. In this config you may instanciate any pojo or beans of you engine. To add these references into Application scope, you will want to write a Bean/Class that implements "org.springframework.context.ApplicationContextAwa re" interface. When you create an instance of this class in your xml, the method "setApplicationContext(ApplicationContext applicationContext)" will get call with the context object your app runs on, and there you have full access to insert anything you want.

Hope this helps.

Sorry for the late reply had to put this on hold due to another issue.

So you're saying ANY bean I am using, that needs to get (or set) information, into the application context should implement org.springframework.context.ApplicationContextAwar e?

My goal I have is not ONLY to have a bean know about the context it's running in, but to ensure that ALL state on that bean is shared across the whole application no matter how it's instantiated by the framework.

Thanks.

[nate]

Decoupling objects from the container is a noble design goal, but you can't have your cake and eat it, too. The name "ApplicationContextAware" kind of spells out exactly what you're looking for, and it's fairly common to have several application context aware beans in an application. All controllers descended from Spring's abstract controllers implement it, for example.

[JeanNiBee]

Decoupling objects from the container is a noble design goal, but you can't have your cake and eat it, too. The name "ApplicationContextAware" kind of spells out exactly what you're looking for, and it's fairly common to have several application context aware beans in an application. All controllers descended from Spring's abstract controllers implement it, for example.

I'm sure I'm making a mountain out of a molehill here but how I will implement this concept to get my needed results is, unfortunately, still confusing to me.

What I am used to doing to satisfy my above need of sharing an Object across an Application is the following...

This code would be in a WebContextListener that 'sets up' my environment.

StatusAC status = new StatusAC("All good");
request.getSession().getServletContext().setAtttibute( "statusAC", status );

This code would be in the controllers that need to read the stauts (or update it)

// Any code needing to read or update the bean does this.
(StatusAC) ac = (StatusAC) request.getSession().getServletContext().getAttribute( "statusAC" );

Now from what I read implementing the ApplicationContextAware would allow me to have knowledge of where the given controller is being run but in the web sense I have this 'built-in' as "All controllers descended from Spring's abstract controllers implement it".

How can I 'springify' the above "WebContextLIster / getServletContext().get/setAttributes() methodology of doing things?

From what I'm reading I think the WebContextAware is not actually what I"m looking for (But I could be wrong).

Thanks for your patience (very new to this).

[nate]

I think I see where you're coming from.

Spring allows you to think about your application in a much more modular/decoupled way. I have seen apps do exactly what you have outlined: have a static "Application Context" that acts as a repository for anything that might be needed by multiple components.

In Spring, however, you can leverage your bean configuration files (e.g. appBeans.xml) to wire up dependencies whenever your app starts up (dependency injection). This makes it unnecessary to couple all of your resources together into a single object. (Example: define a database bean and wire it into any objects that require access to your database.)

If you need to pass messages between components (what it appears your example is illustrating), then that suggests some design decisions you need to make. You might use Spring's application event system to publish/consume events, or you might define a bean that holds state and inject it into just the beans that require this information.

Short answer: any bean (Java object) you define in your XML configuration is scoped to your application by definition. So keeping a static repository of your app's resources becomes (happily) unnecessary.

[JeanNiBee]

I think I see where you're coming from.

Spring allows you to think about your application in a much more modular/decoupled way. I have seen apps do exactly what you have outlined: have a static "Application Context" that acts as a repository for anything that might be needed by multiple components.

In Spring, however, you can leverage your bean configuration files (e.g. appBeans.xml) to wire up dependencies whenever your app starts up (dependency injection). This makes it unnecessary to couple all of your resources together into a single object. (Example: define a database bean and wire it into any objects that require access to your database.)

If you need to pass messages between components (what it appears your example is illustrating), then that suggests some design decisions you need to make. You might use Spring's application event system to publish/consume events, or you might define a bean that holds state and inject it into just the beans that require this information.

Short answer: any bean (Java object) you define in your XML configuration is scoped to your application by definition. So keeping a static repository of your app's resources becomes (happily) unnecessary.

Now I'm starting to understand.

So what happens to this 'StatuAC' bean if someone changes the scope of the bean definition to Prototype (from it's default of Singleton). Also assume that this object isn't loaded from a db but contains the "runtime" information of the application. So I NEED to ensure a single copy per application (not only just per class loader)

I was reading I could use "application" scope setting at the bean definition but then found out that this only works for a portlet based app, not a servlet based on like I have setup.

I"ll read up on the event system and see if that works for me too. (But man the 'app context' just seems so much easier)

[nate]

So what happens to this 'StatuAC' bean if someone changes the scope of the bean definition to Prototype (from it's default of Singleton).

It should be a singleton, just like probably 99% of beans in Spring apps. If someone changes this, you should say, "Hey, buddy, don't do that!" and change it back.

I'm being glib, but seriously, I wouldn't worry about that. As the developer, you control which beans are declared singleton and which are declared prototype. It should be safe to assume that a singleton bean will actually be singleton at runtime.

[JeanNiBee]

It should be a singleton, just like probably 99% of beans in Spring apps. If someone changes this, you should say, "Hey, buddy, don't do that!" and change it back.

I'm being glib, but seriously, I wouldn't worry about that. As the developer, you control which beans are declared singleton and which are declared prototype. It should be safe to assume that a singleton bean will actually be singleton at runtime.

I will be honest I thought the same originally but then was under the impression that if the single point of failure was the configs that maybe I find a better solution. (The whole reason for this thread).

I'm going to go with the singleton (Using statics) approach and keep an eye on the app for weird behaviour. Worse case if I have issues I can always resort to 'old school' methods as a short term fix before I port the app to a portlet.

Thanks to all for the input it's been VERY informative (even If it took a bit of hammering for me to absorb it)