Remove Foobar.xhtml from URL with JSF - java

I have written a facelets web application using tomcat as a application server. My program has a foobar.xhtml and the URL to it is:
http://localhost:8080/Myapplication/foobar.faces
Can I change something in my application so that a link to:
http://localhost:8080/Myapplication/
..will actually render my application on http://localhost:8080/Myapplication/foobar.faces ?
Alternatively, could the http://localhost:8080/Myapplication/ be redirected to http://localhost:8080/Myapplication/foobar.faces ?

You would normally use the <welcome-file> entry in the web.xml for this. But unfortunately this doesn't work as expected on at least Tomcat when using fictive URL's which are to be passed through a servlet like a FacesServlet. Tomcat will scan for the physical file on the disk matching the exact name before forwarding. If it isn't present, then you will just face a default 404 error page.
Using /foobar.xhtml as <welcome-file> is also not going to work since that page requires to be parsed by the FacesServlet to get all the JSF stuff to work.
One of the ways to fix this is to place another real /foobar.faces file there next to the real /foobar.xhtml file. It doesn't need to be filled with code, it can be left empty. Just the presence of the physical file is enough for Tomcat to open the desired page as welcome page.

web.xml has a
<welcome-file-list>
<welcome-file>foobar.faces</welcome-file>
</welcome-file-list>
element where you can define the page to be opened.

Related

Java Servlet-2.3 not working in Websphere Liberty Profile 8.5.5.6

We have a Java Web application running in IBM Websphere Liberty profile server. We have recently developed a Java Servlet which is responsible to generate JFreeCharts using Java library.
Code in web.xml
<servlet>
<servlet-name>GraphicServlet</servlet-name>
<servlet-class>com.test.GraphicServlet</servlet-class>
<load-on-startup>10</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>GraphicServlet</servlet-name>
<url-pattern>*.img</url-pattern>
</servlet-mapping>
Code in index.html file
<img src="summary/chart.img" height="100" width="100" />
Code in GraphicsServlet.java
This Servlet has doGet method implemented and the business logic in the method generates a chart image file(.png) using JFreeCharts and this image is returned as response in form of stream.
Application flow:
When application is accessed, index.html file is displayed by default and this page has a section where chart generated by JFreeChart needs to be displayed.
Scenario Description:
The Image file is not getting displayed when application is accessed. Using the browser's developer tools, I have found that 404 error is printed when a request is sent to *.img Url. Next, I tried to find out if that Servlet is really deployed on to the server or missed in the .war file by any chance, and I checked the deployment folder in websphere and found the Servlet deployed. Next, I tried to check if Servlet is up and running. From a new browser, I sent a test request like http://localhost:9080/myapp/summary/chart.img, it returned 404 error on to the screen.
I wanted to know why servlet is not getting up. So, I implemented the init() method of HttpServlet in my GraphicsServlet and written a print statement. I didnot get that print when the application finished loading. Finally, I tried with commenting out every line of doGet method, even then I received
404 Error on the screen.
Problem Description: I want to know why the GraphicsServlet is not getting up. Please let me know if there are any techniques to know the reason behind the failure of GraphicServlet.
Update 1:
I tried removing the configuration in web.xml and annotated the GraphicServlet with #WebServlet annotation. Now, I am able to see those print statements and it is now confirmed that GraphicServlet is up and running when annotation is used. So, I started looking at web.xml DOCTYPE tag. The version of Web app DTD was very old. It was 2.3 version, and the Java version we installed is 1.8. Can anyone here let me know whats the problem with WebApp-2.3 ?
Update 2:
I removed the #WebServlet annotation from GraphicServlet and again I tried with xml configuration and also changing the Web-app version from 2.3 to 3.1 (also 3.0) in web.xml file. The GraphicServlet is still not up and running.
Update 3:
I have noticed that javaee-7.0 feature is being used in the Websphere server.xml file.
Thanks for your patience.
Maybe you should change your servlet mapping in web.xml to be like this:
/summary/*.img

How to put jsp in ROOT folder of tomcat so that the jsp is picked by all web apps

I have multiple web applications defined in my tomcat. In case of any exception, I want to throw one jsp (done using SimpleMappingExceptionResolver tag of spring). When I put the jsps in the web-inf folder of the web applications, it works fine which is obvious.
But I want to put this jsp at a common place in tomcat such as ROOT library. But if I do this, tomcat is not able to find my jsp. Can somebody tell me if any changes in web.xml is required to make this happen or I should put this jsp somewhere else.
Thanks in advance.
What do you mean by 'picked up' or 'access'? You can put a jsp file on the tomcat ROOT application, and do a 302 redirect into it everytime you encounter exception.
For example place you all-apps generic exception page on webapps/ROOT/generic_exception.jsp, then on each of your apps, add this to the web.xml
<error-page>
<exception-type>java.lang.Throwable</exception-type>
<location>/myapp_error.jsp</location>
</error-page>
That should redirect request into myapp_error.jsp (inside myapp) if any uncaught exception surfaces. Then inside myapp_error.jsp, just perform html meta redirect to /generic_exception.jsp
However the drawback of this approach is you are redirected into different web-app, it's difficult / require extra work if you want to pass session attributes

How to specify html page globally in Jboss?

We have a filter that redirects user to error.html, if the user is not authorized. Right now, we are keeping error.html page inside the WAR, but is there any way to make the html file public so that every war file can access this error page? It would be still better, if we make this html page as a jar and keep it in server/default/lib.
Here is the sample that is used in filter.
`reqDespacher = request.getRequestDispatcher("error.html")`
and the accessing url is
http://localhost/Context_root/error.html
Any help would be appreciated.
In JBoss5 or JBoss6, you can copy and then define this custom error.html inside the /deployer/jbossweb.deployer/web.xml of the server instance that you are running. This will require a reboot of the JBoss instance. Example for error code 404:
<error-page>
<error-code>404</error-code>
<location><relative_path_to_error_html_file_under_jbossweb.deployer_folder></location>
</error-page>
Secondly, instead of re-directing request by specifying a page manually like you are doing currently, you should use the <error-page> and <error-code> deployment directive to define custom error pages. See specify-the-default-error-page-in-web-xml-in-servlet for a detailed example on how to add error-code directives on web.xml.
For JBoss AS7 global error page configuration take a look at how-to-customize-jboss-as7-404-page .

Make Localhost/projectName homepage url

I'm not sure how to start on this, but I currently have a simple application that has a home page url of
localhost:8080/projectName/homePage.jsp
However, I'd like it so that
localhost:8080/projectName/
OR
localhost:8080/projectName
sends me to the homePage.jsp.
I've read about an index.jsp that was created by eclipse in other projects, but it seems like that hasn't been done for me - do I need to create this? I'm not using a web.xml, and am instead relying on #WebServlet to do wiring.
2 ways to do this.
1. Add an entry in web.xml as follows
<welcome-file-list>
<welcome-file>homepage.jsp</welcome-file>
</welcome-file-list>
2. create an index.jsp file in your WebContent folder and forward the request to homePage.jsp
According to the following post there is no such way possible with annotation:
Servlet 3.0 annotations <welcome-file>

Jnlp-Prevent downloading of the jars that i referenced

I have been developed a jnlp file, and it is working properly when client downloads it from his/her browser. No problem up to here, but client can also access to the jar files that my jnlp is referencing, and eventually download them.
I don't want my jars to be downloaded by others by writing the path from browser. I just want to make the jnlp is directly accessible from browser.
How can I fix this situation ?
There is no 'fix' for it. If the Jars are accessible to the JWS client that launches the app., they are also available by direct fetch.
You can use the provided JnlpDownloadServlet as a way to block access. The JnlpDownloadServlet (look for it in the samples provided with the JDK) will handle requests for Jar files and do a diff on them. If you setup your web.xml file like
<servlet>
<servlet-name>JnlpDownloadServlet</servlet-name>
<servlet-class>com.sun.javaws.servlet.JnlpDownloadServlet</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>JnlpDownloadServlet</servlet-name>
<url-pattern>/app/*</url-pattern>
</servlet-mapping>
then all requests for the files in /app will go through this servlet. This will prevent users from doing a simple browse to see the available files, but if they know the file name they can still create a get request to fetch it through the servlet.
If that is a problem, then you can also put security on access to this servlet (as you would any other servlet) using the security-constraint settings in the web.xml. If you add that, then the javaws launcher will require the user to provide valid credentials before it will download the files. I used BASIC as the auth-method because I wasn't sure if the javaws client would honor any others.
What if you generate the jnlp dynamically via a JSP or servlet (see here an example)?
In this case you can write a filter that can implement a policy(based on a cookie?) for retrieving files. If the cookie is not set you can disable the download of jars.
See the following article: http://lopica.sourceforge.net/faq.html#cookies

Categories