We have an application context inside a web application. Whenever a typed-bean is requested which is not available in the context we have to create it and add it to the context.
The context will basically have to react to a NoSuchBeanDefinitionException by using a factory to create it.
For those wondering why we don't create them beforehand or use a FactoryBeans: Due to the highly dynamic nature of how the legacy middleware and the other layers interact we don't have a chance to know the service-types beforehand.
Any suggestions?
As mentioned in the comment below: Registering beans(prototype) at runtime in Spring
Related
Per the Spring Documentation, application context is:
Central interface to provide configuration for an application. This is read-only while the application is running, but maybe reloaded if the implementation supports this.
In some applications, there are multiple application contexts. What's the purpose and benefit of having multiple application contexts? I want to understand the logic behind it. Why would one do it?
P.S: In spring doc use is written. I want to know the pros of having multiple application contexts and the rationale behind it.
The root context is the parent of every dispatcher servlet context/child context. Beans defined in root context are visible to each dispatcher servlet context/child context but not vice-versa.
Typically, root context is used to define all cross-cutting beans such as security, transactions, and other configurational beans, while the dispatcher context or child context contains those beans that are specifically related to MVC.
We create multiple dispatcher servlets when we need multiple sets of MVC configuration. For e.g. we may have a REST API alongside a traditional MVC application or an unsecured and a secure section of a website.
Cannot comment so putting the answer:-
Java Spring multiple ApplicationContext
Hope this answer your question
It is useful to implement a layered architecture (model objects, data access, services, web services, mvc app etc).
As M.Deinum said it is good to have one root context that loads the others and helps keeping them separated.
Here is the official doc for the architecture of Spring Framework applications: https://docs.spring.io/spring/docs/3.0.x/spring-framework-reference/html/overview.html
I recently started learning java EE (jsp, servlets and some patterns for working with database like a DAO) and I dont understand where I should initialize my bussines logic? I think that create instances of it in body of do*** servlet methods is a bad practice. P.S. my app use DataSource and ConnectionPool for connection with db.
You need to specify your requirement somehow, what initialization you are looking for. Is it a EJB solution? Pure Servlet/JSP solution? etc.
Normally when deploying your application, after an invocation the application will load the required logic.
Of course you can do initialize to speed up the load, to make required code run before users enter the application etc.
In EJB we are talking about #Singleton and #Startup annotations.
For servlet you can use the annotation #WebServlet(name="startup", loadOnStartup="0"). Or put it in your web.xml. Depends how you code.
A more recommended way is to create you own listener, and override the contextInitialized and contextDestoryed methods. E.g. create db connection etc in initialized method and deregister the driver in contextdestory method. Use annotation #WebServletContextListener or add the listener to your web.xml
Also Java web server specific solutions exists, you need to check your vendor.
In Spring MVC, there are two contexts. One is the application context or global context which is booted up by ContextLoaderListener. It takes all the configuration files mentioned in contextConfigLocation parameter.
Now if you are using Spring MVC as well, then Dispatcher servlet is required, which boots up another container which is also known as web application container. This container takes the global container as a parent.
When integrating struts1 with spring, there is only one context. Why does spring mvc need two? Is it possible to use only one context when using spring mvc?
thanks!
Having a root web application context plus a child servlet context is just an option. If you know that your application won't have a second servlet, it's arguably simpler to have one single Spring context for the whole web application.
You can achieve that setup by simply removing the ContextLoaderListener (and the accompanying contextConfigLocation context-param) from your web.xml and moving all bean definitions into the xml defining the servlet context ([servlet-name]-servlet.xml).
This is possible, because the FrameworkServlet (super-class of DispatcherServlet) doesn't care if there is a root application context when creating the servlet context. It just relays the root context as the parent if available. See related code here.
Imagine you had two separate Dispatchers, each serving a different purpose, and each having its own dependencies. You would configure those independently using separate contexts.
If there is any shared configuration, this can go in the 'global' context.
I don't think it's possible to have only one context using DispatcherServlet, as it creates its own context and links it to the parent context (via the FrameworkServlet superclass).
FrameworkServlet.createWebApplicationContext
Check this answer About multiple containers in spring framework
Yes ,you can have one context only.
For code reuse it would be better to isolate services in Application Context rather then WebApplicationContext.but this not compulsion.you can keep only webApplicationcontext only.
I need to get the servlet application context in the business layer of an spring mvc application.
I've tried implementing ApplicationContextAware interface, autowiring a WebApplicationContext field, and even implementing ServletContextAware and getting the application context with WebApplicationContextUtils, but none of this works.
Is there any other way to get it? I want to avoid having to pass an HttpServletRequest parameter from the controller to get the application context in the business object.
If it helps for something, I'm running on a WebSphere 6.1 server, and I think it has the servlet 2.4 api.
Implementing ApplicationContextAware and injecting ApplicationContext work. So that's the way to go. You must find what other problem stops it from working (how does it not work, actually?)
For example make sure the service class is not instantiated by you using the new operator.
By the way, you cannot and should not get the child application context (defined by dispatcher-servlet) in the service layer. This means that parent would know about child contexts - and it does not. You are thus breaking the layer boundaries. Think of another way of handling this task - for example have the context injected in a controller (it should work there), and then pass the desired arguments to a service.
Is there a way to expose my Spring applicationContext via a servlet or webapp so that I can manipulate and inspect the beans in the appcontext.
You may want to have a look at the Spring Inspector a plug-gable component that provides programmatic access to any Spring based application at run-time. You can use Javascript to change configurations or manage the application behavior at run-time.
Not aware of a special tool/plug-in. Maybe this would do:
How can I determine Objects in application context?
Spring Insight might do the trick.