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?
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.
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'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
I used to build my projects with maven. Now I want to do it 'manually'. But I struggle a little bit with directory order and other stuff. I first just created a new dynamic web project in eclipse and added JSF libraries. Now I tried to deploy a hello world page onto a tomcat 7. But jsf-tags are not getting rendered.
Here is my directory structure:
Anybody has an idea where the mistake is? Am I missing a library or is my structure wrong?
cheers
It finally works! thank's to balusc
But jsf-tags are not getting rendered.
This means that the FacesServlet isn't mapped in web.xml or you didn't make the URL in browser address bar to match the url-pattern of the FacesServlet. The FacesServlet is the one responsible for parsing JSF tags and doing all the JSF works.
Assuming that the url-pattern of the FacesServlet as definied in web.xml is *.jsf, then you need to open the start.xhtml by http://localhost:8080/fitnessverwaltung/start.jsf instead of http://localhost:8080/fitnessverwaltung/start.xhtml.
You can also change the url-pattern to *.xhtml, then you don't need to worry about this.
<servlet>
<servlet-name>facesServlet</servlet-name>
<servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>facesServlet</servlet-name>
<url-pattern>*.xhtml</url-pattern>
</servlet-mapping>
I'm trying to write a web application using SpringMVC. Normally I'd just map some made-up file extension to Spring's front controller and live happily, but this time I'm going for REST-like URLs, with no file-name extensions.
Mapping everything under my context path to the front controller (let's call it "app") means I should take care of static files also, something I'd rather not do (why reinvent yet another weel?), so some combination with tomcat's default servlet (let's call it "tomcat") appears to be the way to go.
I got the thing to work doing something like
<servlet-mapping>
<servlet-name>app</servlet-name>
<url-pattern>/</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>tomcat</servlet-name>
<url-pattern>*.ext</url-pattern>
</servlet-mapping>
and repeating the latter for each one of the file extensions of my static content. I'm just wondering why the following setups, which to me are equivalent to the one above, don't work.
<!-- failed attempt #1 -->
<servlet-mapping>
<servlet-name>app</servlet-name>
<url-pattern>/*</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>tomcat</servlet-name>
<url-pattern>*.ext</url-pattern>
</servlet-mapping>
<!-- failed attempt #2 -->
<servlet-mapping>
<servlet-name>app</servlet-name>
<url-pattern>/</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>tomcat</servlet-name>
<url-pattern>/some-static-content-folder/*</url-pattern>
</servlet-mapping>
Can anyone shed some light?
I think I may know what is going on.
In your working web.xml you have set your servlet to be the default servlet (/ by itself is the default servlet called if there are no other matches), it will answer any request that doesn't match another mapping.
In Failed 1 your /* mapping does appear to be a valid path mapping. With the /* mapping in web.xml it answers all requests except other path mappings. According to the specification extension mappings are implicit mappings that are overwritten by explicit mappings. That's why the extension mapping failed. Everything was explicitly mapped to app.
In Failed 2, App is responsible for everything, except content that matches the static content mapping. To show what is happening in the quick test I set up. Here is an example. /some-static-content-folder/ contains test.png
Trying to access test.png I tried:
/some-static-content-folder/test.png
and the file was not found. However trying
/some-static-content-folder/some-static-content-folder/test.png
it comes up. So it seems that the Tomcat default servlet (6.0.16 at least) drops the servlet mapping and will try to find the file by using the remaining path. According to this post Servlet for serving static content Jetty gives the behavior you and I were expecting.
Is there some reason you can't do something like map a root directory for your rest calls. Something like app mapped to /rest_root/* than you are responsible for anything that goes on in the rest_root folder, but anywhere else should be handled by Tomcat, unless you make another explicit mapping. I suggest setting your rest servlet to a path mapping, because it declares the intent better. Using / or /* don't seem appropriate, since you have to map out the exceptions. Using SO as an example, my rest mappings would be something like
/users/* for the user servlet
/posts/* for the posts servlet
Mapping order
Explicit (Path mappings)
Implicit (Extension mappings)
Default (/)
Please correct anything that I got wrong.
For reference, the "failed attempt #2" is perfectly correct in version of Tomcat >= to 6.0.29.
It was the result of a Tomcat bug that get fixed in version 6.0.29:
https://issues.apache.org/bugzilla/show_bug.cgi?id=50026
<!-- Correct for Tomcat >= 6.0.29 or other Servlet containers -->
<servlet-mapping>
<servlet-name>app</servlet-name>
<url-pattern>/</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>default</servlet-name>
<url-pattern>/some-static-content-folder/*</url-pattern>
</servlet-mapping>
I've never tried to map a servlet like this, but I would argue that /* does technically both start with / and end with /*, even though the same character is used for both matches.