Disable JSP extension processing - java

I have a JavaEE 1.4 web application running on WebSphere Application Server 6.0. In web.xml, there is a servlet configured to intercept all server requests:
<servlet-mapping>
<servlet-name>name</servlet-name>
<url-pattern>/*</url-pattern>
</servlet-mapping>
This works fine until I try to request something ending with *.jsp. In this case, server tries to find JSP with this name and fails with the error:
java.io.FileNotFoundException: JSPG0036E: Failed to find resource /cfvct/search_criteria.jsp
at com.ibm.ws.jsp.webcontainerext.JSPExtensionProcessor.findWrapper(JSPExtensionProcessor.java:279)
at com.ibm.ws.jsp.webcontainerext.JSPExtensionProcessor.handleRequest(JSPExtensionProcessor.java:261)
at com.ibm.ws.webcontainer.webapp.WebApp.handleRequest(WebApp.java:3226)
at com.ibm.ws.webcontainer.webapp.WebGroup.handleRequest(WebGroup.java:253)
at com.ibm.ws.webcontainer.VirtualHost.handleRequest(VirtualHost.java:229)
at com.ibm.ws.webcontainer.WebContainer.handleRequest(WebContainer.java:1970)
at com.ibm.ws.webcontainer.channel.WCChannelLink.ready(WCChannelLink.java:120)
at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleDiscrimination(HttpInboundLink.java:434)
at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleNewInformation(HttpInboundLink.java:373)
at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.ready(HttpInboundLink.java:253)
at com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.sendToDiscriminaters(NewConnectionInitialReadCallback.java:207)
at com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.complete(NewConnectionInitialReadCallback.java:109)
at com.ibm.ws.tcp.channel.impl.WorkQueueManager.requestComplete(WorkQueueManager.java:566)
at com.ibm.ws.tcp.channel.impl.WorkQueueManager.attemptIO(WorkQueueManager.java:619)
at com.ibm.ws.tcp.channel.impl.WorkQueueManager.workerRun(WorkQueueManager.java:952)
at com.ibm.ws.tcp.channel.impl.WorkQueueManager$Worker.run(WorkQueueManager.java:1039)
at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1475)
I need to have this request processed by the servlet, but seems server uses some JSPExtensionProcessor to process all paths ending with .jsp. Is there any way to change this behaviour?

Yes, you'll need to map your servlet to *.jsp in order to get *.jsp support redirected to your servlet.
<servlet-mapping>
<servlet-name>name</servlet-name>
<url-pattern>*.jsp</url-pattern>
</servlet-mapping>
It is normally a bad idea to have jsps accessible directly, however. Placing them in WEB-INF in some directory, then mapping an appropriate url (.do, .action, etc) to a servlet that then redirects internally to that JSP is the better practice.
So instead of typing thisUrl.jsp, the user would type thisUrl.do or thisUrl.action, and it would then get hit by the servlet to redirect to thisUrl.jsp.

Related

Why I am getting 404 error while hiding .jsp extension in web.xml file?

I configured all my JSP page in web.xml file to hide .jsp extension and I created custom URL in web.xml file corresponding to each JSP page due to SEO point of view but when I deployed this application at server tomcat which is running under Apache web server so my server team replies me like this but I am not getting what does they mean.
Please note that you are running in a server where apache is the web
server and Tomcat is a servlet container. This way all static requests
such as images, CSS, js, HTML are handled by apache and jsp, servlets
are handled by Tomcat. This means Apache will forward any request that
you send with the following extension to tomcat
.jsp
/servlet
.do
This means in order for Tomcat to execute your code you need to send a
request to apache as .jsp, /servlet and .do. Once you send this way,
it will automatically send to tomcat to running there. In your case
/hosting will be executed by apache only and that's why you get this
error of 404.
web.xml
<servlet>
<servlet-name>domain</servlet-name>
<jsp-file>/domain-registration.jsp</jsp-file>
</servlet>
<servlet-mapping>
<servlet-name>domain</servlet-name>
<url-pattern>/domain-registration</url-pattern>
</servlet-mapping>
Do give the proper error, on which url you are getting 404?
Try any other url-pattern you have already specified in the web.xml, check if it works properly or not. I think there is some syntax mistake in your web.xml file other wise it should work.

WAS 8.5.5.9 cannot start webapplication because of SRVE0303E

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.

making the welcome page of a website to be a servlet

Can I make the welcome-file of the website to be a servlet ? If yes , how ? I was trying something like :
<welcome-file-list>
<welcome-file>FilterForwarded</welcome-file>
</welcome-file-list>
<!-- FilterForwarded is a servlet -->
While deploying I do not see any error but when I try to open the website abc.com I get a message from the browser that it is unable to connect to this website.Why is it so ?
I want when anyone visits the website,I should be able to store the client's public IP. To do this I wrote a Filter which after taking the IP , passed it to the servlet (from there I could update the logs). After storing the IP , client be automatically redirected to index.jsp. Is there any way to achieve this ?
EDIT :
<servlet-mapping>
<servlet-name>FilterForwarded</servlet-name>
<url-pattern>/FilterForwarded</url-pattern>
</servlet-mapping>
This is the mapping defined in web.xml . When I use /FilterForwarded in welcome-file I get this message when I try to deploy : Bad configuration: Welcome files must be relative paths: /FilterForwarded
From the logs :
com.google.apphosting.utils.config.AppEngineConfigException: Welcome files must be relative paths: /FilterForwarded
at com.google.apphosting.utils.config.WebXml.validate(WebXml.java:125)
at com.google.appengine.tools.admin.Application.<init>(Application.java:150)
at com.google.appengine.tools.admin.Application.readApplication(Application.java:225)
at com.google.appengine.tools.admin.AppCfg.<init>(AppCfg.java:145)
at com.google.appengine.tools.admin.AppCfg.<init>(AppCfg.java:69)
at com.google.appengine.tools.admin.AppCfg.main(AppCfg.java:65)
If you map the filter to /* you should be able to intercept all requests and then log the IP from there.
Or is your requirement to only log Client IP for the landing page?
If so, you could change the default servlet for the Servlet container, but bear in mind this will change the default servlet for all requests that do not match mappings in your web.xml.
<servlet-mapping>
<servlet-name>FilterForwarded</servlet-name>
<url-pattern>/</url-pattern>
</servlet-mapping>
A more complex, but potentially better solution, is to front your Java web container with a web server and use rewrite rules to proxy to your backend Servlets. This way will mean that you can control the Servlet that is accessed for your landing page without overriding the default servlet for all non-matching requests. This might be overkill for your problem though.

redirecting requests based on the body tomcat

I have a tomcat 7 application which I can get requests from external sources.
Most of them call my request like this:
http://localhost:8080/MyWeb/exRequest
and I build servlet with URL pattern inside MyWeb app.
However, one external source must send the request like this:
http://localhost:8080/
and in the body:
<xml name="test" />
Since I don't want to declare a general servlel (like tomcat default) since it means that any request will need to go through my servlet, I thought to change index.jsp of ROOT to redirect to my servlet.
Is it the best option?
Is there an option to create a default servlet that will be invoked only if there is a special parameter in the body?
EDITED
Please note that I get the requests to localhost:8080 and not localhost:8080/MyWeb - it's general to tomcat and not to a specific web app
You can't choose a servlet to invoke based on the request body, but you can set a servlet as the "welcome-file" in your web.xml.
<servlet>
<servlet-name>index</servlet-name>
<servlet-class>com.y.MyWelcomeServlet</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>index</servlet-name>
<url-pattern>/index</url-pattern>
</servlet-mapping>
<welcome-file-list>
<welcome-file>index</welcome-file>
</welcome-file-list>
If you want to preserve the "welcome" function of some existing index.jsp, your servlet could forward requests without the correct XML in the body to an index.jsp file located under the WEB-INF directory.
No, but you can create a Filter and forward/redirect to a specific servlet whenever the request meets certain conditions.
If using servlet 3.0 map it with #WebFilter, otherwise use web.xml and <filter> + <filter-mapping>. You should map it be executed before the default servlet.

Servlet filter url mapping

How can a filter be mapped to the root of a URL? I'm using Tomcat 7.0.2 and deploying an application as ROOT.war. The welcome page is sign_in.xhtml. I would like to run a filter whenever the client sends a request for the root of the site (i.e. the domain name only), or when the the client requests sign_in.xhtml. Here is what I have so far:
<filter>
<filter-name>My filter</filter-name>
<filter-class>com.myApp.myFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>My filter</filter-name>
<url-pattern>/sign_in.xhtml</url-pattern>
</filter-mapping>
Requests for sign_in.xhtml directly, successfully invoke the filter, but I'm not sure how to get requests for the root to invoke the filter. According to the Servlet spec (version 3.0)
<url-pattern>/</url-pattern>
maps to the default servlet, and an empty string maps to the root. Here's the relevant section from the spec:
"The empty string ("") is a special URL pattern that exactly maps to the
application's context root, i.e., requests of the form http://host:port//. In this case the path info is ’/’ and the servlet path and context path is
empty string (““)."
However, both of the following url patterns cause Tomcat to throw an exception.
<url-pattern></url-pattern>
<url-pattern>""</url-pattern>
I would really appreciate it if someone could shed some light on this. Thank You.
Andrew
The <url-pattern>/</url-pattern> should work for requests on the root. Did you try it?
If your intent is more to filter all requests, then you should use <url-pattern>/*</url-pattern>.
Update: To exclude one and other, I tested the url-pattern of / at Tomcat 7 (using both web.xml and #WebFilter(urlPatterns={"/"})) and it indeed didn't work as expected. The url-pattern of / however works as expected on Tomcat 6 (Servlet 2.5) and also on Glassfish v3 (Servlet 3.0). I suspect a bug in Tomcat 7, so I've reported issue 49914 about this.

Categories