Deploy your app to the root context
This is an easy trick which I am sure most of you already know.
Let’s take a Java application called MyAddressBook. Its generated war file could be called myaddressbook.war.
By default, when you deploy this web application to Tomcat, the URL to access it will be http://localhost:8080/myaddressbook/. And if you point a domain name such as ‘addressbook.com’ to this server, the URL would be http://addressbook.com/myaddressbook/.
I don’t know for you but I don’t like to systematically have the subfolder ‘myaddressbook’ after my domain. But maybe I am too picky! 😉
The idea is to deploy our application in the Tomcat root context.
You have two ways of doing this:
- Define a
ROOT.xmlfile in yourconf/Catalina/localhostfolder, or; - Rename your war file to
ROOT.war.
Note that the case is important, it has to be ROOT in UPPERCASE! 🙂
Once this is done, you will be able to call your application via the URL http://localhost:8080/
or http://addressbook.com/. Way better! 😎
How to monitor your Java application
It is very good to have your application and your database running on a Linux or Windows server, but who will tell you if your website is down? Who said “the users”? 😯 No, you won’t look very professional if you wait for a user complaint.
What you need to do is to monitor your server. But which tools to use? There are so many on the market… 🙁
I tested a few of them (Hyperic, Nagios, Zenoss, Cacti, Monitis) but the one I choose is Zabbix. What I like with Zabbix is its price (free 😎 ) and the fact that it is easy to configure and very flexible. Indeed, you can monitor anything you want on the machine (CPU, network, disk space, services, etc)! 🙂
However, if you also want to monitor your Tomcat application server or even Hibernate Java library, you need some more work.
To monitor Tomcat, you first need to enable JMX Remote. To do so, you can have a look at the official documentation or simply add the following parameters to your Tomcat startup script:
export CATALINA_OPTS='-Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=8999 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false'
Then, I will recommend you to deploy Zapcat JMX Zabbix Bridge in your Tomcat web server. This tool has been developed to simplify the communication between the JMX management API inside Java applications and the Zabbix monitoring tool.
To read the installation instructions for Tomcat, please click on the following link:
http://www.kjkoster.org/zapcat/Tomcat_How_To.html
Finally, if you are using Hibernate in your Java application and would like to monitor it, you have to instantiate and configure a Hibernate MBean (org.jboss.hibernate.jmx.Hibernate) that will be responsible for constructing a Hibernate SessionFactory and exposing it to your application through JNDI.
Here are the lines you need to add to your context XML file:
<bean id="mbeanExporter" class="org.springframework.jmx.export.MBeanExporter" lazy-init="false">
<property name="server" ref="mbeanServerFactory"/>
<property name="beans">
<map>
<entry key="org.hibernate:type=statistics" value-ref="hibernateMBean"/>
</map>
</property>
</bean>
<bean id="mbeanServerFactory" class="org.springframework.jmx.support.MBeanServerFactoryBean">
<property name="locateExistingServerIfPossible" value="true"/>
</bean>
<bean id="hibernateMBean" class="org.hibernate.jmx.StatisticsService">
<property name="sessionFactory" ref="sessionFactory"/>
<property name="statisticsEnabled" value="true"/>
</bean>
Onclick event is not fired on IE
I am pretty sure everybody knows that Internet Explorer has “a few” bugs… 🙄
You didn’t? 😯 Alright, better to stay on your little cloud and leave this blog right away!
For the others, I will talk about the JavaScript event onclick which is not fired when the following requirements are matched:
- In a form;
- There is only ONE input text element;
- There is one button which has an
onclickevent assigned; - You press the ‘Enter’ button inside the input text element.
For a better understanding, let’s now take the following example:
<html>
<head><title>Test</title><head>
<body>
<form>
<input type="text" id="t1"/>
<input type="submit" onclick="alert('onclick fired!'); return true;"/>
</form>
</body>
</html>
As you can see, there is nothing difficult in this code.
Well, that doesn’t mean Internet Explorer can handle it… 😆
The bug occurs if you press the ‘Enter’ button inside the input text element using Internet Explorer. Indeed, the onclick event is not fired and the text ‘onclick fired!’ is not display to the user! However, it works perfectly fine on Firefox and Safari.
The funny thing is this code works on Internet Explorer if you add another input text, even if it is hidden!
Why? Don’t ask me! 😐
Anyway, the following example works on IE:
<html>
<head><title>Test</title><head>
<body>
<form>
<input type="text" id="t1"/>
<input type="text" style="display:none"/>
<input type="submit" onclick="alert('onclick fired!'); return true;"/>
</form>
</body>
</html>
Why are we assigning an onclick event to the submit button?
It could be for a lot of reasons, but the main one is probably to validate the form before submitting the data.
By the way, RichFaces is very often using this event on the submit buttons.
So remember to add a hidden input text to your form if you want to allow users to use the ‘Return’ key. 🙂
No saved view state
How many of you did already get the following error when working with JSF?
I would be surprised if none of you got it at least once! 😉
HTTP ERROR: 500
/web/home.htmlNo saved view state could be found for the view identifier: /web/home.html
RequestURI=/web/home.html
Caused by:
javax.faces.application.ViewExpiredException: /web/home.htmlNo saved view state could be found for the view identifier: /web/home.html
at org.apache.myfaces.lifecycle.RestoreViewExecutor.execute(RestoreViewExecutor.java:88)
at org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:103)
at org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:76)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:151)
at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1093)
at org.apache.myfaces.webapp.filter.ExtensionsFilter.doFilter(ExtensionsFilter.java:341)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)
at org.springframework.web.filter.RequestContextFilter.doFilterInternal(RequestContextFilter.java:83)
at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:76)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)
at org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:178)
at org.ajax4jsf.webapp.BaseFilter.handleRequest(BaseFilter.java:290)
at org.ajax4jsf.webapp.BaseFilter.processUploadsAndHandleRequest(BaseFilter.java:368)
at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:495)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)
...
This very common error happens because your session has timed out. As you probably already know, JSF is storing the view state of your page in session. Obviously, when the session has timed out, it can’t restore the view state and so throws a ViewExpiredException.
The solution for this problem is to add the following lines in your web.xml file:
<context-param>
<param-name>facelets.BUILD_BEFORE_RESTORE</param-name>
<param-value>true</param-value>
</context-param>
When this initialization parameter is turned on, it changes ViewHandler.restoreView() to build the view before asking the StateManager for help.
However, if you are using RichFaces, for some reason this is breaking a few Ajax components! 🙁
To be honest with you, I didn’t investigate in depth why these components don’t work with this parameter set to true.
What I did instead is to make sure the session actually never times out! 😉
To do that, I am polling the server every 29 minutes (as my session time out is set to 30 minutes). Obviously, you can poll the server only every 59 minutes if you set your session time out to 60 minutes.
Here is the code I used to poll the server every 29 minutes:
<h:form>
<a4j:poll id="poll" interval="1740000" limitToList="true" />
</h:form>
Note that the interval attribute is in milliseconds (29 minutes x 60 x 1000 = 1,740,000 milliseconds).
This solution is far from being perfect! Indeed, if, for example, a user doesn’t close his browser during the night, it means that we will have to keep the session opened during hours! 😐
But, as far as I am concerned, it is still better than to throw an exception at the user face. 😉
WWF – Help us
Be careful of SKIP_COMMENTS
Posted by smoreau in Tricks on 01 Dec 2009
In the early days, we used to hide JavaScript code from old browsers that do not support JavaScript.
The way of doing this was to put a one-line HTML-style comment without the closing characters immediately after the opening
<script>tag and put//-->at the end of the script.For example:
<script type="text/javascript"> <!-- alert('Test'); //--> </script>However if you are using this trick with the initialization parameter
facelets.SKIP_COMMENTSset to true, the code between<!--and//-->won’t even be sent to the client!It simply means that the code above won’t open an alert window because it has been skipped during the page rendering.
Here is what the client will receive:
You have two solutions to avoid this situation:
SKIP_COMMENTSparameter to false (the default is true). This can’t really hurt, your page will just be heavier depending on how much HTML comments you put on your page;For information, below is the code to put in your web.xml file to set the
SKIP_COMMENTSparameter to false:<context-param> <param-name>facelets.SKIP_COMMENTS</param-name> <param-value>false</param-value> </context-param>Facelets, JavaScript, old browsers, SKIP_COMMENTS
No Comments