I have a simple Jersey jax rs hello world application that I am trying to deploy to my tomcat server so i can call the resource url and check and see if it gives me the required output but when i set the context path in the web.xml it doesnt deploy to the server it does however when i take the servlet information out and just leave a blank web.xml meaning this must be my problem. Here is the contents of my web.xml.
`<!DOCTYPE web-app PUBLIC
"-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
"http://java.sun.com/dtd/web-app_2_3.dtd" >
<web-app>
<display-name>Web App</display-name>
<servlet-name>ServletContainer</servlet-name>
<servlet-class>com.sun.jersey.spi.container.servlet.ServletContainer</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>ServletContainer</servlet-name>
<url-pattern>/resources/*</url-pattern>
</servlet-mapping>
</web-app>
As requested here is the stacktrace of the error
[INFO] [war:war {execution: default-war}]
[INFO] Packaging webapp
[INFO] Assembling webapp[app1] in [C:\Users\leo\4thYearUni\Project\app1\target\app1]
[INFO] Processing war project
[INFO] Copying webapp resources[C:\Users\leo\4thYearUni\Project\app1\src\main\webapp]
[INFO] Webapp assembled in[170 msecs]
[INFO] Building war: C:\Users\leo\4thYearUni\Project\app1\target\app1.war
[INFO] [tomcat:redeploy {execution: default-cli}]
[INFO] Deploying war to http://localhost:8080/app1
[INFO] OK - Undeployed application at context path /app1
[INFO] FAIL - Failed to deploy application at context path /app1
If anyone has any ideas or workarounds this would be much appreciated
Thank you
Chris
First of all, if something is failing deployment, the first hint at a solution is to look at the logs of the application server to answer the question "Why is this failing?"
Things don't just "fail", they will give error messages and exceptions and stacktraces and information about what is actually occurring. Attempting to guess why something fails with none of this knowledge amounts to just guesswork.
As a guess, make sure that the class com.sun.jersey.spi.container.servlet.ServletContainer is on the classpath of the web application (i.e. in the WEB-INF/lib directory).
Kind of drive-by answering here, but I note a hanging end tag in the middle of your web.xml:
</servlet>
this would stop it parsing....
Turns out there was some confusion about the web.xml files i was editing , and when found the correct web.xml and sorted the hanging servlet tag this sorted the problem . Thank you everyone for all your help and patience as I am completely new to maven.
One of the possible reasons for this is this sort of entry in ant
<zipfileset dir="./mywebcontent/" prefix="/" />
remove prefix="/", it spoils your archive
In my case, it was because when working on https://netbeans.org/kb/docs/web/ajax-quickstart.html tutorial, I didn't tick "add information to the deployment descriptor (web.xml)" during the create new servlet wizard.
Although I deleted that servlet and created the servlet again, this time ticking the checkbox, I think this is what caused my 'context.xml' to contain <Context antiJARLocking="true" path="/MyAjaxApp"/> which caused the error.
So when I changed the line to <Context antiJARLocking="true" path="/AutoCompleteServlet"/>, everything worked fine.
Related
I have a weblogic server with a cluster of two SOA servers.
I am deploying a servlet to this server with a SOAP servlet created with the JDeveloper wizard (Create Java Web Service from WSDL -> Java EE 1.5, with support for JAX-WS Annotations)
It is deployed as a standalone application.
During the development of the application I have changed the WSDL in various ways including changing the port name.
I have gone into the weblogic interface, deleted the previous instalisation and re-deployed through JDeveloper. I get the following error message:
[08:44:59 PM] weblogic.management.DeploymentException: Error encountered during prepare phase of deploying WebService module 'RJMTestBannerAdapter.war'. Two port in the callBannerService(WebserviceDescriptionBean) has the same name {http://ic.ac.uk/AIAMetaData/AIAComponents/ApplicationObjectLibrary/Banner/V1/APIJavaAdapter/BannerAPIJavaAdapterWsdl}callBanner.
It is complaining that there is two ports in the application with the same name. But there isn't.
I have inspected the .war file that JDeveloper produces
The WEB-INF/web.xml has a single entry for the service
The WEB-INF/weblogic.xml is also correct and just specifies the context-root.
I have determined that somewhere in the weblogic servers there must be something with the end point that is not being cleared away when I delete the application.
I have checked the weblogic console user interface, gone through the list of web applications and services and confirmed it is not there.
Does the weblogic server have a deployment plan file or something simular it is picking up while deploying? If so where would this deployment plan be?
I don't think it is important but here is my web.xml:
<?xml version = '1.0' encoding = 'UTF-8'?>
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd" version="2.5"
xmlns="http://java.sun.com/xml/ns/javaee">
<servlet>
<servlet-name>callBanner</servlet-name>
<servlet-class>ic.ac.uk.ic.rjmtest.banner.adapter.gen.main.Main_ptImpl12</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>callBanner</servlet-name>
<url-pattern>/callBanner</url-pattern>
</servlet-mapping>
</web-app>
Also this is the weblogic.xml that appears in the war file. (It is not in my project but JDeveloper must generate it)
<?xml version = '1.0' encoding = 'UTF-8'?>
<weblogic-web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.bea.com/ns/weblogic/weblogic-web-app http://www.bea.com/ns/weblogic/weblogic-web-app/1.0/weblogic-web-app.xsd" xmlns="http://www.bea.com/ns/weblogic/weblogic-web-app">
<context-root>RJMTestBannerAdapter</context-root>
</weblogic-web-app>
I have also inspected the WSDL and there is only a single port.
I finally found the answer.
When I used JDeveloper to regenerate the classes for the service I must have changed the name somehow. This resulted in new java being built.
As I didn't delete the classes or deploy directory the old ones were still there in my war file. So I was trying to deploy two even though my .java files didn't reflect this.
Deleting the classes and deploy directories then recompiling resolved the issue.
This post might be useful for anyone else who hits this error!
This may be an incredibly stupid question, but I have a web application that relies heavily on jQuery for many various widgets and aesthetic utilities that I'm trying to migrate into using Vaadin. For starters, I'm attempting to just create your run-of-the-mill "Hello World" application -- built with Maven and deployed to Tomcat -- with Vaadin, and I'm having a problem deploying it. I've been following the turtorial posted here ( https://vaadin.com/book/-/page/intro.walkthrough.html ). Here's my file structure thus far:
HelloWorld
src
main
java
com
business
helloworld
HelloWorld.java
resources
webapp
WEB-INF
web.xml
test
target
pom.xml
I'm guessing that my problem lies somewhere in my web.xml that follows:
web.xml
<?xml version="1.0"?>
<!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN" "http://java.sun.com/dtd/web-app_2_3.dtd">
<web-app>
<display-name>HelloWorld</display-name>
<servlet>
<servlet-name>HelloWorld</servlet-name>
<servlet-class>com.vaadin.terminal.gwt.server.ApplicationServlet</servlet-class>
<init-param>
<param-name>application</param-name>
<param-value>HelloWorld</param-value>
</init-param>
</servlet>
<servlet-mapping>
<servlet-name>HelloWorld</servlet-name>
<url-pattern>/*</url-pattern>
</servlet-mapping>
</web-app>
I've tried my best to follow the examples I've seen, but I have a feeling I'm making a stupid mistake. When I run the project as a Maven Build (tomcat:redeploy), it doesn't appear in my Tomcat Manager. Any ideas? If you need any more information (like what's in my pom.xml), just let me know...
EDIT: Is it better to create a Vaadin Project and convert it to Maven, or vis versa?
MyApplicationClass in application param-value should be the whole qualified class name, like
com.business.helloworld.HelloWorld
(I'm on a mobile phone so I didn't check the syntax, but that should be it.)
Edit: To the second question, there's an Maven archetype that creates an Maven Vaadin project. By using that you won't have to convert either way.
I have what I think is the simplest possible
hello world example (see below). But when asking for
"http://localhost:8080/hello" thru firefox,
it gives me the
"The requested resource (/hello/) is not available"
error.
Environment: newly installed tomcat 6.0.32 on Windows 7.
Other information:
1. None of the "similar questions" provides any clues.
From experimentation, it appears that tomcat is not
doing the mapping from localhost:8080/hello to my servlet.
I set "<load-on-startup>"
which showed me that the servlet's init entry was being
called, but doGet() is never called.
The log files show no errors.
I have tried both starting tomcat with the hello
directory already in webapps, with hello.war in
webapps, and deploying using the manager application.
All act the same way.
Some possibilities I have considered:
According to the documentation, I should
not need to use a context.xml file, and my experiments
with a context.xml produced the same resource not found
error.
localhost:8080/hello should instead be
localhost:8080/.../hello, but if so, then what is
the ... supposed to be?
Trailing / (e.g. /hello versus /hello/). I changed
the url-pattern to "/hello/*", but it fails the same
way.
I assume the problem is something simple, but I cannot
see it.
[Added 8/8/2011]
The answers about using context.xml were correct; thanks.
In looking around, it appears that an alternate way
to achieve the same effect is to put this
into my web.xml file.
<context-param>
<param-name>ContextPath</param-name>
<param-value>/dts</param-value>
</context-param>
web.xml:
<web-app xmlns="http://java.sun.com/xml/ns/j2ee" version="2.4"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http:/java.sun.com/dtd/web-app_2_3.dtd">
<servlet>
<servlet-name>hello</servlet-name>
<servlet-class>test.HelloServlet</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>hello</servlet-name>
<url-pattern>/hello</url-pattern>
</servlet-mapping>
</web-app>
HelloServlet.java:
package test;
import java.io.*;
import javax.servlet.http.*;
import javax.servlet.*;
public class HelloServlet extends HttpServlet {
public void init()
{
System.out.println("\nHelloServlet.init");
}
public void doGet (HttpServletRequest req,
HttpServletResponse res)
throws ServletException, IOException
{
System.out.println("\nHelloServlet.doGet");
PrintWriter out = res.getWriter();
out.println("Hello, world!");
out.close();
}
}
With a Java Servlet Application (part of, but not the total sum of Java EE - Java Enterprise Edition), applications have servlets under what is called a "context path". This "context path" has to be specified in order to map any request to the application.
Apache Tomcat makes this context path pretty easy to configure, either via server.xml (not recommended) or individual context files (recommended). Both ways specify where to find your web application directory (an unpacked web application archive, or WAR file) and where to place it on the server at a context path.
As Vlad has already said, if you deploy your war file into Tomcat's webapps directory and have automatic installation on (I believe it is on by default), Tomcat will unpack the .war into a directory under that location and use the war's name as its context path. His example war file is named "helloapp.war", so, with the default settings, it would receive any request to http://localhost:8080/helloapp because its context path becomes helloapp.
Of course, once the request is sent to the context path, something needs to match against it. That's where the web.xml comes in to play. While it is possible to use the root as a matcher (every request to the context path gets handled by the same process), typically a pattern is used (such as *.do, *.action, etc), so that individual requests to the helloapp are easily distinguishable (it's easier to read and debug http://localhost:8080/helloapp/login.action and http://localhost:8080/helloapp/doSomethingElse.action than both being recognized via some parameters and the same path of http://localhost:8080/helloapp in my opinion)
So, the context path gets to your application, then your application has to do a lookup on the web.xml to see where to send the actual request. In your example, if your webapp was deployed at the context path of helloapp, to access it with the proper mapping, you would simply append /hello, so the request becomes http://localhost:8080/helloapp/hello
You are deploying your hello servlet in a webapp. Assuming the webapp is in a folder helloapp or in an archive helloapp.war in Tomcat's webapps directory then your sevlet would be accessible at http://localhost:8080/helloapp/hello
You will either need to rename the package to ROOT.war (or the ROOT directory) or modify the ROOT.xml context.xml file to point to the hello folder.
If you go to /hello/hello I bet you'll see your app. If you're using tomcat, use context.xml.
You may not need to use it for a webapp to work, but if you deploy under tomcat, things just work more coherently when you have a context.xml file.
In /yourtomcatinstall/webapps/hello/META-INF/ create a context.xml file with this information"
<?xml version="1.0" encoding="UTF-8"?>
<Context path="/hello">
</Context>
And change the url mapping of your servlet in web.xml to / and/or /* you can have more than one url mapping for a servlet.
I need to create a startup class in Websphere. This class is present in abc.jar. And also abc.jar requires log4j.jar at startup of server.
For above scenario, i have created the startup class with abc.jar in classpath in websphere console and I kept log4j.jar in ext folder of WAS. This works for me.
But problem is that the other profiles share same ext folder of WAS and does not able to start up due to Log4j.jar.
If I keep Log4j.jar in other place and keep that location in classpath. Startup class will not fails.Please help me.
If your application uses EJBs, then you can use a peculiar feature of WAS with the ibm-ejb-jar-ext.xml descriptor, which includes a start-at-app-start element:
<?xml version="1.0" encoding="UTF-8"?>
<ejb-jar-ext
xmlns="http://websphere.ibm.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://websphere.ibm.com/xml/ns/javaee http://websphere.ibm.com/xml/ns/javaee/ibm-ejb-jar-ext_1_1.xsd"
version="1.1">
<session name="TestBean">
<start-at-app-start value="true"/>
</session>
</ejb-jar-ext>
I'm not very familiar with WebSphere and maybe I do not fully understand your problem - but how about deploying a webapp with a startup servlet defined in web.xml?
Here's what I mean:
create a abc.war with abc.jar and log4j.jar copied to abc.war/WEB-INF/lib
define your startup class in abc.war/WEB-INF/web.xml as follows:
<web-app id="WebApp">
<display-name>abc.war</display-name>
<servlet>
<servlet-name>ABCStartupServlet</servlet-name>
<display-name>ABCStartupServlet</display-name>
<servlet-class>abc.ABCStartupServlet</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
...
That way you have log4j.jar and abc.jar together in one place, you can use the WebSphere classloader settings if another log4j version causes problems and your class is called during the startup of the server.
I have problems getting two different struts2 webapps to start together in tomcat. But each of the webapps start correctly when placed independently inside webapps folder of tomcat.
I get the following in catalina.out logs-
SEVERE: Error filterStart
Aug 13, 2009 3:17:45 PM org.apache.catalina.core.StandardContext start
SEVERE: Context [/admin] startup failed due to previous errors
Environment- Java1.6, Tomcat6, Struts2.1.6, FC10
The webapps are "admin" and "user". Both of these webapps contain struts2 jars inside their WEB-INF/lib directory respectively.
web.xml contains the following in both the webapps-
<filter>
<filter-name>struts2</filter-name>
<filter-class>org.apache.struts2.dispatcher.FilterDispatcher</filter-class>
</filter>
<filter-mapping>
<filter-name>struts2</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
A point to note that always the "admin" webapp fails to load with the above error. If I remove the "user" webapp from webapps folder, "admin" webapp comes up just fine.
I have also observed one more thing w.r.t struts2 filter in web.xml- If I remove the struts2 filter from web.xml in one of the webapps, BOTH the webapps start without any errors in the logs (but of course I won't be able to use struts in the webapp where the filter is removed).
I have also tried moving the struts2 jar to tomcat lib and removing them from individual webapps, but same problem exists..
Any ideas what is causing this problem?
Updates: This strangely works fine on Ubuntu OS. But the problem persists on FC10 and OpenSolaris.
I had a similar problem using Spring and using this listener class in web.xml:
org.springframework.web.util.Log4jConfigListener
See the documentation of the Spring Log4jWebConfigurer, which says you need unique "web app root" properties defined per web-app, so I had to have a section like this in each web.xml:
<!-- used by Log4jConfigListener -->
<context-param>
<param-name>webAppRootKey</param-name>
<param-value>myappname.root</param-value>
</context-param>
Are you using Spring ? If not hope this gives you some clues, I don't know much about Struts2 maybe it does something similar. Do let me know how it goes !
We had the same problem while launching two struts2 Maven apps on the same server. The xerces lib was the problem so we did add xalan in the pom.xml dependencies and everything worked fine:
<dependency>
<groupId>xalan</groupId>
<artifactId>xalan</artifactId>
<version>2.7.1</version>
<type>jar</type>
<scope>compile</scope>
</dependency>
Thanks alzoid, extraneon and Peter.
I had overlooked an exception coming up on localhost..log file. I thought I had redirected all the struts log to a different log file but had overlooked mentioning the opensymphony package in the log4j properties file.
Coming to original problem- there was a class loader issue with xerces-impl jar and some other jar file belonging to struts2. So when I removed the xerces-impl jar from the WEB-INF/lib directories in both apps, it started worked fine!