I'm trying to deploy a web service onto WebSphere using a WAR file, which I have been told directly is completely possible and has been done many times before. WebSphere allows me to upload the file, specify the context root, and even start the application. However, when I try to access it by specifying my underlying URIs, WebSphere 404s on me. The relatively useless error message displayed is:
Error 404: SRVE0202E: Servlet [Jersey REST Service]: com.sun.jersey.spi.container.servlet.ServletContainer was found, but is corrupt: SRVE0227I: 1. Check that the class resides in the proper package directory. SRVE0228I: 2. Check that the classname has been defined in the server using the proper case and fully qualified package. SRVE0229I: 3. Check that the class was transferred to the filesystem using a binary transfer mode. SRVE0230I: 4. Check that the class was compiled using the proper case (as defined in the class definition). SRVE0231E: 5. Check that the class file was not renamed after it was compiled.
I have checked my naming conventions, modified my web.xml according to this blog post, attempted packaging it into an ear file (which threw out its own errors when I tried to upload it), and am trying to figure out what configurations I might have wrong. Any ideas of what I could change to make this work?
Edit
Here is the relevant part of my web.xml file:
<?xml version="1.0" encoding="UTF-8"?>
<web-app version="2.4"
id="WebAppId"
xmlns="http://java.sun.com/xml/ns/j2ee"
xsi="http://www.w3.org/2001/XMLSchema-instance"
schemalocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd">
<display-name>MYPROJECT'SDISPLAYNAME</display-name>
<servlet>
<servlet-name>Jersey REST Service</servlet-name>
<servlet-class>com.sun.jersey.spi.container.servlet.ServletContainer</servlet-class>
<init-param>
<param-name>com.sun.jersey.config.property.packages</param-name>
<param-value>MYPROJECTNAME</param-value>
</init-param>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>Jersey REST Service</servlet-name>
<url-pattern>/*</url-pattern>
</servlet-mapping>
</web-app>
Another Edit
I'm using the newest release of Jersey- is that part of the problem?
Yet Another Edit
I'm pretty sure that's the entire problem. WebSphere 6.1 runs jdk1.5, and Jersey stopped supporting that after Jersey 1.2...
As you suspect your problem is lack for WebSphere support for Jersey (or rather JAX-RS).
I don't see JAX-RS in the list of supported APIs by WAS.
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.help.ic.WS.doc/info_sching.html
WAS 6.1 runs on J2SE 1.5 (as seen in the URL above)
Specification or API Version 6.1
Java 2 Standard Edition (J2SE) specification J2SE 5
These probably are the reasons behind the errors that you get to see in your WAS 6.1
HTH
Manglu
Related
I have the following problem:
In my web.xml I define how to serve pictures like so:
<servlet-mapping>
<servlet-name>default</servlet-name>
<url-pattern>*.css</url-pattern>
<url-pattern>*.png</url-pattern>
<url-pattern>*.jpg</url-pattern>
</servlet-mapping>
On Tomcat this works fine but on IBM Websphere 8.5.5.9 I get the following error:
"SRVE0303E: Servlet name for the servlet mapping *.css could not be found."
On another site I already found a solution for this issue (https://www.ibm.com/developerworks/community/forums/html/topic?id=5f4420ba-0754-43fe-8c87-91acc588d9fc) so I also created the ibm-web-ext.xml exactly the same as in their solution but the error still persists.
Does anyone know what I could do differently?
I found the answer to my problem, thanks to #MigratedPigeon because he got me thinking about the class of my default servlet.
A tomcat server has a default servlet, the class for tomcats default servlet is
org.apache.catalina.servlets.DefaultServlet
Websphere on the other hand does not have a default servlet, thats why I get the error "Servlet Name could not be found".
As in the answer I linked in the original question, static file serving can be activated by websphere by using the web-ext.xml file but that still did not solve the issue of my web.xml file having a "default" servlet.
In our application we use spring, so in the end I replaced the default servlet in web.xml with springs dispatcher servlet and now my web.xml file is valid for both, tomcat and websphere.
you should also mention this in your web.xml
<servlet>
<servlet-name>default</servlet-name>
<servlet-class>your servlet class</servlet-class>
</servlet>
Servlet mapping is done based on the value mentioned in the "" tags and respective servlet will be called.
We run an application written with "jspx" (Java Server Page with XML I guess), it runs on web-logic but the web-logic is down currently.
I wish to know if I could copy the files and put it under Apache tomcat.
I have actually tried that but I got some errors which makes me feel Apache tomcat is strictly for "jsp" and not "jspx".
If my assuption is right then what else can I use to compile a ".jspx" program aside from weblogic?
As far as I know, jspx are simply jsp files with well-formed XML instead of "just any html".
Try editing your tomcat/conf/web.xml and add another mapping for the jsp-servlet:
<!-- Existing mapping -->
<servlet-mapping>
<servlet-name>jsp</servlet-name>
<url-pattern>*.jsp</url-pattern>
</servlet-mapping>
<!-- New mapping -->
<servlet-mapping>
<servlet-name>jsp</servlet-name>
<url-pattern>*.jspx</url-pattern>
</servlet-mapping>
But... for Tomcat 8 this is already in place. Can you share the error messages you got?
I am using spring-ws and I have the below configuration in my web.xml
<servlet>
<servlet-name>spring-ws</servlet-name>
<servlet-class>org.springframework.ws.transport.http.MessageDispatcherServlet</servlet-class>
<init-param>
<param-name>**transformWsdlLocations**</param-name>
<param-value>true</param-value>
</init-param>
</servlet>
<servlet-mapping>
<servlet-name>spring-ws</servlet-name>
<url-pattern>/*</url-pattern>
</servlet-mapping>
Here I have transformWsdlLocations configured. Please explain me the use of transformWsdlLocations here. I am using the dynamic WSDL generation concept.
Is transformWsdlLocations really required for dynamic WSDL generation?
Thanks!
Given that it only takes a couple of minutes to remove the value and redeploy your application, I would advise you to do that and see what happens. Just try accessing the WSDL through "localhost" and through "127.0.0.1", and see what differences there are.
However I'll explain what you should see here...
When you read the WSDL that is generated, you should find that there are URLs in there.
i.e. From the local machine you might use:
http://localhost:8080/myservice.wsdl
But when you go live, your service might be:
http://www.<yourdomain>.com/myservice.wsdl
You don't want someone downloading the WSDL from your production domain to have those values populated with "localhost:8080". Likewise, you can't test your service properly if the URL being returned in the WSDL is for your production server. Or you might have multiple production services with different URLs.
transformWsdlLocations ensures that this is generated dynamically based on whatever URL is being used to access the service.
It is not needed for dynamic WSDL generation, but I have always found it very useful to have it. However, it is not enabled by default, so if you do want those URLs to be generated dynamically then it's best to include it.
I have a WAR file with a web application that has been deployed to a weblogic stream.
The JSP part works fine, but it can't find the servlets. Possible due to the lack of mapping in my web.xml file.
I was working fine on Tomcat 6, but can't seem to find using weblogic.
I used annotation #WebServlet("/actionOne") but this doens't seem to work.
I am a little confused about how to map these correctly via the web.xml file.
the servlets are .java files and located at WEB-INF/classes/com/foo/bar/
So far I have added the following the web.xml file but the servlet-mapping section has me confused.
<servlet>
<servlet-name>actionOne</servlet-name>
<servlet-class>com.foo.bar.actionOne</servlet-class>
</servlet>
<servlet>
<servlet-name>actionTwo</servlet-name>
<servlet-class>com.foo.bar</servlet-class>
</servlet>
Hopefully the above is correct, the next section I'm not sure how to use and would appreciate some help.
<servlet-mapping>
<servlet-name>actionOne</servlet-name>
<url-pattern>/actionOne</url-pattern>
</servlet-mapping>
The servlets are being called from the jsp via a Form action="actionOne"
My mapping was correct, it seems the issue was related to a different version of servlet.api in the weblogic modules folder. 2.5 instead of 3.0. This resolved the issue.
I have Weblogic 10.3.5 installed. I deployed the JSF 2.0 war on the server. In my WebContent folder, I have *.xhtml and *.jsp files, which contain JSF2.0 xhtml and pure JSP code, respectively. When I navigate to http://localhost:7001/MyApp/NewFile123.xhtml, I get a 404 Not found error page. (Nothing informative on the Eclipse console). But http://localhost:7001/MyApp/NewFile.jsp works well and does what it's supposed to do.
I am not mixing JSF and JSP but just wanted to see if JSP is gonna work. I have the appropriate servlet-mapping for the XHTML files.
I also have these on my classpath:
glassfish.el_1.0.0.0_2-2.jar
glassfish.jsf_1.0.0.0_2-1-5.jar
glassfish.jstl_1.2.0.2.jar
javax.servlet_1.0.0.0_2-5.jar
Another interesting thing, when I try to edit the *.xhtml files, the auto-complete doesn't work. (i.e it won't autocomplete <h:outp. It used to when I was using Weblogic 12.1 which has JSF2.0 out of the box.
Edit: Here is the relevant part of web.xml
<servlet>
<servlet-name>Faces Servlet</servlet-name>
<servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>Faces Servlet</servlet-name>
<url-pattern>*.xhtml</url-pattern>
</servlet-mapping>
So why do I get a 404 when I try to navigate to a JSF page? Any suggestions?
I also have these on my classpath:
glassfish.el_1.0.0.0_2-2.jar
glassfish.jsf_1.0.0.0_2-1-5.jar
glassfish.jstl_1.2.0.2.jar
javax.servlet_1.0.0.0_2-5.jar
Remove all those container-specific libraries from your /WEB-INF/lib. They do not belong there at all, the container already ships with them. Your /WEB-INF/lib should contain only the webapp-specific libraries which are not shipped with the container.
Your problem is most likely caused by the fact that Weblogic 1.0.3.5 is a Servlet 2.5 container which already ships with JSF 2.0, but that you're supplying a JSF 2.1 library which requires Servlet 3.0. I don't use Weblogic, but I've read that 1.0.3.x requires some specific steps to get JSF 2.0 to work, see also this blog. Here's an extract of relevance:
Download and install one of the latest Oracle WebLogic Server 11g Rel 1 (10.3.3) Installers from OTN. (Give the ZIP Installer a try. Aweseome lightweight!)
Create a new sample domain (call it whatever you want) and start the admin server
Open the administration console (http://localhost:7001/console/)
deploy the JSF 2.0 library (Deployments - Install - wlserver_10.3\common\deployable-libraries\jsf-2.0.war
Find your favorite JSF 2.0 sample (I'll take the guessNumber thing from the mojarra-2.0.2 distribution)
Add a weblogic.xml file to the WEB-INF/ folder with the following content:
<?xml version="1.0" encoding="UTF-8"?>
<weblogic-web-app>
<library-ref>
<library-name>jsf</library-name>
<specification-version>2.0</specification-version>
<implementation-version>1.0.0.0_2-0-2</implementation-version>
<exact-match>true</exact-match>
</library-ref>
</weblogic-web-app>
Update as per the comments:
I now suspect that it may be because of the project settings. I created a Dynamic Web Project and chose JSF 1.2. On the next step, where it asked me for the JSF specification and implementation, I pointed him to those glassfish jsf2 jars. The default was 1.2. Maybe I shouldn't have done that?
That might have generated a JSF 1.2 compliant faces-config.xml which would force JSF 2.0 to run in JSF 1.2 modus. You need to redeclare the <faces-config> root declaration to comply JSF 2.0.
<faces-config
xmlns="http://java.sun.com/xml/ns/javaee"
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-facesconfig_2_0.xsd"
version="2.0">