I am new to spring and currently struggling in understanding the settings required for using an existing spring project in my current project
I have a spring project which has all the service for communicating with the database and webservice.
I am writing a new application which neeeds to talk to the database and webservice.
I thought of re-using the existing implementation in the other project.
I included the project in the build path of the current project.
However I am getting dependency injection error.
Now I am kind of stuck to see what all the other files I need to have in my current project settings so that I can re-use the existing project.
Should I need to import the context file of the other project in to my current one? If so can someone point me to the documentation where I can refer for some guidance?
I'll give it a shot. Hope I can bring about clarity to your question... =D
When you say "I included the project in the build path of the current project.", I assumed you added a spring web project as a dependency to another spring web project. In summary, you can't add a spring web project as a dependency of another spring web project. Let's take some time to understand how you wire a bean to do injection in spring container first...
When you use spring framework, you will find a similar code in your web.xml like the following:
<servlet>
<servlet-name>spring</servlet-name>
<servlet-class>
org.springframework.web.servlet.DispatcherServlet
</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>spring</servlet-name>
<url-pattern>*.htm</url-pattern>
</servlet-mapping>
What you have just done is to use spring framework's servlet to handle every request URL that ends with .htm. Of course you may configure it otherwise.
You should also have another xml that contains all your bean tags. By default, it is spring-servlet.xml. In this spring-servlet.xml, you specify which bean shall be injected to which bean if you are going the xml configuration approach. If you are using annotation approach, you should have a tag to scan all your existing #Component (and its derived annotations) annotated classes, then use #Inject or #Autowired annotation to inject the declared instance(bean). For example:
<context:component-scan
base-package="org.companyname.webappname" />
<context:annotation-config />
So far, what I have been explaining is how to declare a bean in a spring container. An "injection" happens only when you declare a bean (to live in spring container when web server starts) in a spring container, and specify which class it should be injected into.
So now that you have two spring web projects (assumption), with two web.xml and two spring container, you will have a problem getting the base-project's spring container to find the dependent spring web project's packages/classes. I suggest you move all the classes in the dependent project into the base-project and only have one spring container (one web.xml).
Another way is to create a Java Library Project, place all your services, DAO and web services classes in it and build it as jar. In your base project, add the jar file (as dependencies) and either do a component-scan on the jar's package or declare it in xml with the jar's package. Either way, you should only have one spring container, one web.xml.
Hope I am not confusing you.
You got to understand how the IoC container work first. Here is where you need to read and digest how spring IoC works: http://docs.spring.io/spring/docs/3.0.x/reference/beans.html
Update: if you are doing a non web spring project, the concept of having only one spring container still stands. The solution of moving dependent project's classes to a jar file is still valid. Except that you don't configure spring via web.xml. =D
You need to import the file containing the bean definitions of the service layer(say, service-context.xml) into the new project.
It can be done as:
<import resource="classpath:service-context.xml"/>
It depends on how you have setup the project.
In general you would need to use
An example of this can be seen here (see the directions on how to include the project in your own application)
Related
I am developing my Spring-based web application using Spring Framework + Spring Security + Hibernate for data access (ORM) + Maven as build manager. All data acces operations must be provided by Hibernate.
My goal is to integrate Spring Security, Spring Framework and Hibernate for work together. I read many corresponding tutorials but what is confusing to me is that there are (in tutorials code) many xml-configuration files that missing in my project. Here is the structure of my project
As you can see there are only two Spring related xml-files and web.xml - they all been automaticaly generated by Spring when I added Spring Framework and Spring Security support to my project.
But in mentioned tutorials there are also files named "spring-database.xml", "spring-security.xml". The first as I think is to configure Spring toget data from database and the second is just basic Spring Security config. file.
Questions:
1) Those two files have not been generated automaticaly, even "spring-security.xml". Is it ok - is it like it must be? Or something wrong with my project settings?
2) If I can name those xml config files as I wish - then how does Spring know about them all and distinguish them? I just have not found anything about config files with such names in official Spring refference docs.
Answering question 2 please give some examples if it is possible.
3) My applicationContext file is empty - is it ok? And what if difference between it and dispatcher-servlet?
Thank you in advance!
1) I general you need just one spring configuration file, which is normally placed in src/main/resources (or elsewhere on the classpath) and after called applicationContext.xml or similar. If you use several Spring modules (such as Spring Data, Spring Security etc) it is common practice to have one separate config file for each module, but its not necessary, you can place all config in the same xml.
2) The naming doesn't matter, Spring looks in the classpath for the files: https://softwareengineering.stackexchange.com/questions/145545/where-to-put-spring-configuration-file
3) Normally the applicationContext.xml contains the definition of your beans and packages to scan for annotation and should be placed in src/main/resources. I guess dispatcher-servlet.xml is for the URI/servlet mapping (spring mvc)
There is no problem with your project structure. It is not mandatory to have the file names as you have in your project. If you want to have your own names for the xml files you have to mention the names of the xmls in the in web.xml. See below
<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>
/WEB-INF/dispatcher-servlet.xml
/WEB-INF/spring-security.xml
</param-value>
</context-param>
Coming to the third question. applicationContext.xml should not be empty. You need to specify the beans of your application (services, dao, etc..) in applicationContext.xml. In dispatcher-servlet.xml you need specify beans (handler mappings, controllers, view resolvers etc..) related to spring mvc.
This is driving me nuts. And this has been probably asked before but....
I've started recently with Tapestry for a Hibernate-Spring-Tapestry project. I used a maven archetype for Hibernate/Tapestry and then added Spring integration but this is giving more problems than I thought.
Currently I'm stuck with this, after adding the right tapestry-spring integration dependency and after changing the filter in /WEB-INF/web.xml I can't get jetty to run. This is because it can't find /WEB-INF/applicationContext.xml, mostly because I don't have that file in my project.
I just want to know what it should contain so I can move on to my next noob error.
EDIT: I've replaced the default Tapestry5 filter with
<filter>
<filter-name>app</filter-name>
<filter-class>org.apache.tapestry5.spring.TapestrySpringFilter</filter-class>
</filter>
Full web.xml -> http://pastebin.com/KgPTDrmC
TapestrySpringFilter works by retrieving the WebApplicationContext created and initialized by Spring's ContextLoaderListener (which you should also have). The applicationContext.xml file is a Spring XML bean declaration file which the ContextLoaderListener can use to create that WebApplicationContext.
The beans that go in it depend on your application.
This question already has answers here:
Difference between applicationContext.xml and spring-servlet.xml in Spring Framework
(6 answers)
Closed 9 years ago.
Why do we need applicationContext.xml in Spring?
In what situation would we use it? Do you have an example?
What is the difference between applicationContext.xml and spring-servlet.xml?
How can we compare applicationContext.xml in Spring with Struts.xml in Struts for easy understanding?
Why do we need applicationContext.xml in Spring?
In the early days of Spring framework, Application context i.e the various weave and settings necessary to bootstrap, coordinate and control all objects, where done using XML file. Although one can break various settings and dependency injection into several context files, this process has been made easier In Spring 2.5 and later by annotation-driven settings.
What is the difference between applicationContext.xml and spring-servlet.xml?
In a MVC based project, again if you're not using annotation-driven weaving mechanism for your project, all your endpoint servlets can be setup in the spring-servlet.xml. Note that the name of the file is always self chosen.
How can we compare applicationContext.xml in Spring with Struts.xml in Struts for easy understanding?
They are both similar in terms of what they're trying to achieve. i.e a central location for the application bootstrap settings. Similarly, all settings can be tiered into different files to make it modular.
applicationContext comes from Spring Framework: it manages the business/DAO beans.
spring-servlet comes from Spring MVC: it manages the web beans.
A Web application can have many servlets running at the same time, therefore:
spring-servlet.xml will hold beans only visible to a particular servlet.
You could have many different servlets running
spring-servlet2.xml
spring-servlet3.xml
messaging-servlet.xml
etc.
applicationContext.xml will hold application wide beans. Therefore all the servlets running will have access to the beans defined in applicationContext.xml. However, this is a one way dependency, your servlets can access you applicationContext.xml beans but your applicationContext cannot access any of your servlet beans.
I am a bit familiar with Spring framework but am still having lots of question concerning use of spring from project architectural view point. Now I am setting up Spring 3 and a Maven web application and am willing to try out all the the fancy component-scan's and autowiring features however this is where I get confused.
I am trying to break the project into sub-modules. And at some point these sub-modules may include something-context.xml in classpath*:resource/META-INF, like for instance when I will want to define a datSource related stuff in a separate module. So that's fine spring let's you load context files from within class-paths of all of the jars.
But here is where it gets vague - say I am using component scan. I am obviously using spring DispatcherServlet and it needs a servlet context to be loaded, and then there is a global application context parameter specified in web.xml contextConfigLocation.
So now servlet context config has a component-scan feature enabled for com.mycom.project.controllers and context loaded in the global contextConfigLocation has a context loaded with component scan feature for package com.mycom.project also searches for classpath*:META-INF/spring/*-context.xml.
So my question is - does this load controller's twice given that component scan is used for a for com.mycom.project.controllers and com.mycom.project? Or is it all loaded into one huge container and the contextConfigLocation parameter for either DispatcherServlet or global declaration is sort of access issue ? As in DispatcherServlet will reach only what's defined in servlet-context.xml but won't be able to use anything else?
And if my assumption is wrong, could I have a suggestion on how to manage multi-module project issues?
Thanks.
Yes, you might run into trouble. See this link for how to solve your problem.
#Service are constructed twice
The way you proceed when creating modules seems valid to me. You have a context.xml file for each module and all will get loaded once you load the application. Your modules are self-contained and can also be used in different environments. That's pretty much the way I'd also do it.
Why do we use dispatcher
servlet.xml?
Is it something like web.xml?
Is application and dispatcher xmls
different from each other, are there
any similar things which both can
do?
I have a value, now i need to send
it to another class? can i do it via
application-context.xml
In addition to Nathans' answer - the dispatcher-servlet.xml defines a child context of the base application context (define in applicationContext.xml)
Child contexts have access to all the beans defined in the parent context, but parents don't have access to beans in the child contexts.
Because people don't want one humongous application-context.xml, they split them up by application layer.
No, it's just a Spring application context file.
They do the same thing.
That's not what it's for, it's for defining what your spring-managed objects get injected with.
Dispatcher servlet.xml is just the convention followed by the Spring front controller for web MVC applications. If you don't use Spring web MVC, you need not have a dispatcher-servlet.xml
web.xml is the configuration file required by a Java web app. You must have a web.xml for a Java web app, but the Spring servlet.xml is only required if you use Spring web MVC.
The Spring servlet XML is just part of a Spring web application configuration. You can put all your Spring configuration in the single XML file if you wish, but usually people have more than one.
Spring's bean factory creates objects and injects their dependencies. Your code does the rest. Define what "send it to another class" means to you.