In short: I don't know which folder to place the "spring-context.xml" file in a WebApp when I'm doing this:
ApplicationContext context = new ClassPathXmlApplicationContext("spring-context.xml");
In Long: I know what a classpath is basically. It used to be an environment variable that told the Java project where to look for jars and other resources. It doesn't seem to be used much. But in Eclipse, it talks about setting your classpath by going into your Java Build Path.
What I don't understand it when I want to find a Spring "spring-context.xml" file using the classpath (above) what that has to do with the Eclipse Java Build Path, if anything! What folders does a WebApp look in when I use the above statement? I usually hear people say, "In the classpath" but that doesn't tell me much since I don't want to use an environment variable and the Eclipse Java Build Path seems to have little to do with finding the spring-context.xml file.
More Detail
Initially I was afraid that more details would confuse the situation, but maybe they hold a key.
I am using Vaadin to create a web app. I'm following their direction for how to get a Spring context into Vaadin. I've created a Spring Helper class:
public SpringContextHelper(Application application) {
ServletContext servletContext = ((WebApplicationContext) application.getContext()).getHttpSession().getServletContext();
context = WebApplicationContextUtils.getRequiredWebApplicationContext(servletContext);
}
In the web.xml I have these sections:
<listener>
<listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>
<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>classpath*:spring-context.xml</param-value>
</context-param>
I'm getting the error in the first line of SpringContextHelper(). I've broken the line down so I know it is this logic that is failing:
WebApplicationContext wac = (WebApplicationContext) application.getContext();
wac comes back null, presumably because is can't find the spring-context.xml file.
Essentially, the "Java Build path" you specify for a project is the CLASSPATH.
And files you put in the "src" root of your "Java Resources" project folder will automatically go in your web app's "classes" subdirectory (i.e will automatically be available as in the runtime CLASSPATH).
For example, if you have a custom log4j.properties file, then it can and should go in your Eclipse project's "src/" root.
As far as "where does spring-context.xml go?", I don't know. This link suggests it should go under META-INF/jsca (at least for WebLogic):
http://docs.oracle.com/cd/E15315_09/help/oracle.eclipse.tools.weblogic.doc/html/sca.html
Related
When I run my application on tomcat the spring-context.xml file is located at
/WEB-inf/spring-context.xml
This is ok. But running a junit test I have to supply it with the location of my spring-test-context.xml like this:
#ContextConfiguration(locations={"classpath:/spring-test-context.xml"})
The only way this works is if the file is located in
/src/spring-context.xml
How can I get my application to find my spring-context files in the same location? So that it works with junit testes and deployed on tomcat?
I tried this and it gave me alot of errors about not finding any beans, but it didn't say it couldn't find the file..
classpath:/WEB-INF/spring-test-context.xml
As duffymo hinted at, the Spring TestContext Framework (TCF) assumes that string locations are in the classpath by default. For details, see the JavaDoc for ContextConfiguration.
Note, however, that you can also specify resources in the file system with either an absolute or relative path using Spring's resource abstraction (i.e., by using the "file:" prefix). You can find details on that in the JavaDoc for the modifyLocations() method in Spring's AbstractContextLoader.
So for example, if your XML configuration file is located in "src/main/webapp/WEB-INF/spring-config.xml" in your project folder, you could specify the location as a relative file system path as follows:
#ContextConfiguration("file:src/main/webapp/WEB-INF/spring-config.xml")
As an alternative, you could store your Spring configuration files in the classpath (e.g., src/main/resources) and then reference them via the classpath in your Spring MVC configuration -- for example:
<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>classpath:/spring-config.xml</param-value>
</context-param>
<listener>
<listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>
With this approach, your test configuration would simply look like this (note the leading slash that denotes that the resource is in the root of the classpath):
#ContextConfiguration("/spring-config.xml")
You might also find the Context configuration with XML resources section of the reference manual useful.
Regards,
Sam
(author of the Spring TestContext Framework)
The problem is that /WEB-INF is not in the CLASSPATH for a web app. However, /WEB-INF/classes is.
Your problem with testing is that you aren't running in an app server, so WEB-INF/classes isn't part of the CLASSPATH by default. I'd recommend setting up your tests so that either WEB-INF/classes is in the test CLASSPATH or use a relative or absolute file path to find them.
I basically need to pass an argument to the WAR file that contains the path to my config.json.
I want to achieve it in such a way so that once the project has been exported as a WAR file, I should be able to change the argument without opening the WAR file and having to export it again.
I understand I can pass arguments in the web.xml which can be obtained in the servlet but wouldn't changing the web.xml require me to open the WAR file?
I am using jetty-runner.jar to deploy my webapp.
When you run jetty-runner.jar, you may pass a proprty to jvm like this
java -jar jetty-runner.jar my.war -Dproperty.name=value
In your web.xml you may use following syntax
<context-param>
<param-name>property.name</param-name>
<param-value>${property.name}</param-value>
</context-param>
See an example here: http://www.xinotes.net/notes/note/1611/
I can see 2 solution to you problem:
1) You define an environment variable that specifies the path to your config.json on the server that hosts you jetty instance
2) You add to the class path the folder that contains the config.json and access it from your web application.
Is there a way to place applicationContext.xml into WEB-INF folder? I am specific to WEB-INF folder because I know that it can be placed into WEB-INF\classes folder.
As per the requirement, Clients should be able to configure applicationContext.xml according to their setup.
There is another option I thought of importing xml configuration files from WEB-INF folder to applicationContext.xml. But I didn't tried it yet and not sure how feasible it is.
From your requirement point of view, there is absolutely no difference between putting it in the WEB-INF or in WEB-INF/classes directory: Either way it needs to be accessed from the exploded WAR/EAR after deployment, which may not be possible if your app server don't explode it (ie, JBoss can work directly with the WAR).
IMO, the solution for you is to stop using the WebApplicationContext implementation. Use DefaultListableBeanFactory which should be initialized in a ServletContextListener, reading the configuration file manually. That way you can obtain the path to the applicationContextFile from the ApplicationServer environment (using JNDI or whatever method suits you), so it can be places anywhere in the machine where the Application Server resides.
At least that's what we did, for the very same reason you have.
Yes, you can do this, but the classpath is a pretty logical place to put them.
In your web.xml, in the definition for "contextConfigLocation", just add /WEB-INF/applicationContext.xml to the section.
If you add this in the web.xml then you can access the applicationContext
<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>
/WEB-INF/applicationContext.xml
</param-value>
</context-param>
I am trying to make servlet.
I have installed tomcat6 on ubuntu with admin examples and docs. I am able to run the examples provided. But when i try to make my own servlet it doesnt work.
I did following steps
Under the ROOT i create folder with
-ROOT
----myapp
------WEB-INF
---------classes
I made two files one is index.html which have a button and action on form to call the servlet. Second is .java file. I compiled the .java file and .class is done. So now tree look like
-ROOT
----myapp
------index.html
------WEB-INF
---------classes
-----------TestServ.java
-----------TestServ.class
Now i open this in browser using http://localhost:8080/myapp
It shows up with index.html page with button. But when i click on the button it says
Error 404:
http://localhost:8080/myapp/TestServ not found !!
I dont know where m going wrong. I have set the CATALINA_HOME too. But still this problem continue.
You need to create a web.xml in the WEB-INF directory, and define the servlet mapping in web.xml, so that the myapp/TestServ URL is forwarded to the TestServ servlet class.
Here is a page describing web.xml, and has the example and elements you need to set up. For your class, these elements will probably look something like this:
<servlet>
<servlet-name>testServ</servlet-name>
<servlet-class>TestServ</servlet-class>
</servlet>
<servlet-mapping>
<!-- For any URL starting with /content/, the rewriter servlet will be called -->
<servlet-name>testServ</servlet-name>
<url-pattern>/TestServ</url-pattern>
</servlet-mapping>
You shouldn't be deploying any of your code under ROOT.
You shouldn't have any Java class in the default package. Try putting your TestServ.java in a package.
Your deployment should NOT include any .java files.
You've got to register your servlet properly in web.xml. Include a mapping to a particular URL.
Your best best is to create a WAR file named myapp.war, which includes WEB-INF/classes and WEB-INF/lib and a web.xml for your situation. Put that in the Tomcat /webapps and start the container. If you've registered your servlet properly you should be able to access it via http://localhost:8080/myapp/TestServ.
I'd read the deployment docs carefully.
How do I move my spring xml configuration outside of my java web application?
I'd like to store my spring.xml outside of my web application so I don't have to create a new build of my application to change the configuration.
What is the best way to do this?
As Rod Johnson explains it in this thread:
You can use the classpath: prefix to load from the classpath, with the normal Spring listener or startup servlet. This is made possible by Spring's Resource abstraction. You can freely mix and match resources from WEB-INF and classpath.
So, put the configuration files somewhere in the classpath outside the webapp and declare the following in the web.xml:
<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>classpath:springContext*.xml</param-value>
</context-param>
I think that relying on the classpath is more portable than using an absolute file path.
You can move it to some folder (outside of webapp structure) and explicitly specify context location to point to context in that folder in your web.xml:
<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>file:/full/path/to/context.xml</param-value>
</context-param>
That said, the best way to do this may be to not do it at all :-) and instead reconsider how you deploy your application (e.g. you can create a "patch" or "upgrade" deployment unit that contains changes rather then full blown WAR). Specifying absolute paths tends to be more hassle than it's worth.
Why complicate you build for this, when it's a deployment problem. Most containers deploy WARs in an "exploded" form, which means that somewhere on you file system is the spring.xml file.
If you'd like to update that, you can simply locate the actual location and then copy your new spring.xml over the old one. Yet, at the same time, your WAR remains the de riguer "source of truth".
WARs tend to be very simple to use and deploy, so there's a benefit to bundling your configuration as best you can in the WAR.
So, you can update the spring.xml by going behind the back of the container, and editing it (or copying over) it directly.
Finally, having the spring.xml outside of your WAR means that's it's available to ALL of your WARs, and if you decide later to add another WAR to your system, you will likely have difficulty segregating the two files as they are no long anchored to a specific WAR.