Year: 2009

RichFaces provides some nice AJAX-components for Java Server Faces but the documentation and examples could be better. RichFaces has great documentation compared to some other frameworks but it could be better with adding a little bit of real world and down to earth examples. So here is one example of using RichFaces dataScroller and dataTable -components with custom CSS-styling, backingBean and JSF-page snippets using Richfaces 3.3.2.SR1 and JSF 1.2_12.

Using RichFaces dataScroller and dataTable components has a big negative property: they work nicely if the amount of data is small but when the row count reaches to thousands they become sluggish or stop working. The rich:dataScroller needs the complete datamodel being loaded into memory and only displays a part of it. Not very efficient if the rowcount exceeds 1000 or so.

Anyways here is some real world example. The icons used in the examples for dataScroller are from Crystal Project Icons.

Eclipse is nice IDE but it has it’s own problems. This time the Java Search and Open Type -search produced an error saying “Class file name must end with .class”. Very helpfull. Fortunately almost all the answers in the world can be found in the Internet and so with a quick googling the solution to this annoying problem was found on Stack Overflow.

I had already tried Project -> Clean… and closing Eclipse, deleting all the built class files and restarting Eclipse to no avail as was the original question author. The right answer lies in deleting the corrupted search index which is explained in Eclipse bug’s #269820 comment.

Apache Tomcat likes with default settings to listen to requests on 8080 and 8443 ports but it is more enjoyable to use the more common 80 and 443 ports for HTTP and HTTPS traffic. This way the user don’t have to put those pesky port numbers after the address. Of course you could just tell Tomcat to listen to those ports but it has some negative sides: hassle with the startup and running Tomcat as root.

Luckily it is easy to tell the system to redirect the traffic from some port to other. Just define some new xinetd services in /etc/xinetd.d/tomcat.

Xinetd puts a connection limit per source IP, by default and this causes the service to become unresponsive when there are dozens of queries a second. You see the following kind of line in your messages log file: “xinetd[2049]: FAIL: tomcat-https per_source_limit from=123.456.789.123”. To correct this, uncomment the per_source and instances lines in your xinet.d file and restart it.

If you are using this redirection of all traffic to HTTPS with JIRA and want to attachments working also with Internet Explorer then you must add the following to your jira.xml (f. ex. /opt/tomcat/conf/Catalina/localhost/jira.xml). This is a Internet Explorer bug, for more information see http://jira.atlassian.com/browse/JRA-8179.