This may be a silly question but I've found no answer when googling this.
Currently, I map the requests from someFileName.html to a servlet which then forwards to someFileName.jsp using servlet mappings in web.xml. I would like to avoid that and just configure my application server so that html files are parsed and executed as if they were JSPs (so that custom tags and EL could be used from within the HTML). Bonus to answers that allow any extensions to be mapped to the JSP processor.
I use Tomcat but I'd like the solution to be portable to other containers such as Glassfish.
With 2 simple steps you can achieve this:
Add this servletmapping for the JSP servlet:
<servlet-mapping>
<servlet-name>jsp</servlet-name>
<url-pattern>*.html</url-pattern>
</servlet-mapping>
This tells the application container to use the the JSP servlet when serving html files.
Comment out the <mime-mapping> for text/html mime type (*.html) files so that the container won't handle HTML files as static content.
Hope this helps.
Related
So I have files such as index.jsp and download.jsp in my web application widget.war and am using Tomcat 7. I would like these files to be accessible from the internet as html files i.e
http:/www.mycompany.com/widget/index.html
http:/www.mycompany.com/widget/download.html
Questions:
How do I do this, I know it can be done as I did it about 5 years ago but cannot remember how.
Is it a good idea, it seems like a good idea as users are familar with html but jsps, and returning as jsps shows an implementation detail, but does it matter ?
You can map *.html through your application's web.xml to the jsp servlet defined in tomcat_path/conf/web.xml.
<servlet-mapping>
<servlet-name>jsp</servlet-name>
<url-pattern>*.html</url-pattern>
</servlet-mapping>
However, extensions in general are an implementation detail, so it makes no big difference to your users if the URL ends with .html or .jsp. Most won't probably care anyway.
I'm new to Tomcat, and understand servlet-mapping, but was hoping I could do some mapping to a html file residing in the webapp/ folder.
I have a simple javascript web application that resides as webapp/index.html. Since I'm messing with the url in javascript, I want to make it possible to map /console/* to hit webapp/index.html. For example /console/hi and /console/bye should both load up webapp/index.html.
Is this possible? If so, how?
You can change your index.html file to same index.jsp file
and then use this mapping in web.xml
<servlet>
<servlet-name>index</servlet-name>
<jsp-file>index.jsp</jsp-file>
</servlet>
<servlet-mapping>
<servlet-name>index</servlet-name>
<url-pattern>/console/*</url-pattern>
</servlet-mapping>
I think it is the easiest way.
Like #Pointy said, you'll need a filter, that will receive all requests and redirect to the .hmtl page you want...
Here is a link with a simple filter implementation.
Hope it helps
I've published a Java servlet filter implementation that does what you need to Github. The code is pretty simple, and I expect you might want to customize it to your own needs.
https://github.com/lookfirst/history-api-fallback
I have always wondered why so many Java developers use ".do" as the extension for their web controller (MVC) resources. Example: http://example.com/register.do
It doesn't even seem to be framework specific as I have seen it in Spring MVC and Struts projects.
Where did this ".do" extension practice come from. Why was this done instead of no extension?
I feel like I missed the Java world memo on this.
Personally I prefer no extension.
To my knowledge, this convention has been spread by Struts1. The user guide puts it like this:
5.4.2 Configure the ActionServlet Mapping
Note: The material in this section is not specific to Struts. The
configuration of servlet mappings is
defined in the Java Servlet
Specification. This section describes
the most common means of configuring a
application.
There are two common approaches to
defining the URLs that will be
processed by the controller servlet --
prefix matching and extension
matching. An appropriate mapping entry
for each approach will be described
below.
Prefix matching means that you want
all URLs that start (after the context
path part) with a particular value to
be passed to this servlet. Such an
entry might look like this:
<servlet-mapping>
<servlet-name>action</servlet-name>
<url-pattern>/do/*</url-pattern>
</servlet-mapping>
which means that a request URI to
match the /logon path described
earlier might look like this:
http://www.mycompany.com/myapplication/do/logon
where /myapplication is the context
path under which your application is
deployed.
Extension mapping, on the other hand,
matches request URIs to the action
servlet based on the fact that the URI
ends with a period followed by a
defined set of characters. For
example, the JSP processing servlet is
mapped to the *.jsp pattern so that
it is called to process every JSP page
that is requested. To use the *.do
extension (which implies "do
something"), the mapping entry would
look like this:
<servlet-mapping>
<servlet-name>action</servlet-name>
<url-pattern>*.do</url-pattern>
</servlet-mapping>
and a request URI to match the
/logon path described earlier might
look like this:
http://www.mycompany.com/myapplication/logon.do
WARNING - The framework will not operate correctly if you define more
than one <servlet-mapping> element
for the controller servlet.
WARNING - If you are using the new module support since version 1.1, you
should be aware that only extension
mapping is supported.
And I think this convention has been kept (sometimes to not change URLs even after replacing Struts1, sometimes just because people were happy with it).
It was common practice to map your struts servlet to *.do in web.xml to pass URLs to the struts servlet. For example:
<!-- Standard Action Servlet Mapping -->
<servlet-mapping>
<servlet-name>action</servlet-name>
<url-pattern>*.do</url-pattern>
</servlet-mapping>
There is really no reason except convention for this. If you use no extension you need to do some magic to handle images and other static content in a way that doesn't send them to your sevlet. Often this gets done at a load balancer of a fronting web server.
I am developing a java project.
I want to display an extention of any webpage as '.jsf' evenif it is 'jsp' or 'xhtml'.
What should I do?
Then just configure the FacesServlet accordingly?
<servlet-mapping>
<servlet-name>facesServlet</servlet-name>
<url-pattern>*.jsf</url-pattern>
</servlet-mapping>
If you actually meant "I want to block direct access to *.jsp and *.xhtml so that the visitor is forced to invoke them by *.jsf", then add a security constraint to web.xml on the desired url-patterns and an empty auth-constraint:
<security-constraint>
<display-name>Restrict direct access to JSP and XHTML files</display-name>
<web-resource-collection>
<web-resource-name>JSP and XHTML files</web-resource-name>
<url-pattern>*.jsp</url-pattern>
<url-pattern>*.xhtml</url-pattern>
</web-resource-collection>
<auth-constraint />
</security-constraint>
Redirect all request to to the servlet that needs to handle the jsf requests
<servlet-mapping>
<servlet-name>MyServlet</servlet-name>
<url-pattern>*</url-pattern>
</servlet-mapping>
STEPS (For new jsp project) :
In web.xml, change to *.jsf
Change to index.jsp
Create new welcome.jsp
In index.jsp page, include :
Run project and see extention in browser.
If this is for using JavaServer Faces, then the configuration of the JSF servlet enables the automatic mapping of .jsf to the underlying .xhtml or .jsp file.
I think you have it the wrong way round.
The user-agent will make requests to your servlet, with a given URI identifying the resource they wish to access. You decide what the correct URI for a given resource is, and how to respond to this request. So it's conceptually not a case of your webpage having an "address" that you want to display differently. Rather, it's a case of what URIs you want to use to map to which resources.
If you don't want to expose the extension, then you don't need URIs to have any extension at all, they're just strings. You will, however, need to think about how to resolve potential name clashes (as djna notes in the comment). I believe that this is configured for you at the Faces level, and actually BalusC's answer should have all the technical information necessary to do this.
I just wanted to point out the backwards nature of your thought processes, clearing this up will hopefully make it easier to grok the process in general. It's better that you understand it, than simply paste something into your web.xml that makes the problem go away (for now).
You should configure your server to process .jsf files as .jsp pages. How to actually do this depends on the server you are using - an information you haven't provided.
Disclaimer: I'm not familiar with either jsf or jsp, so I don't know what consequences this server modification will have on actual jsf pages.
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.