Skip to content

Économiser le pétrôle maintenant !

La pénurie s’annonce, aucun nouveau gisement de pétrôle conventionnel n’a été découvert sur la dernière décennie, les resources disponibles aujourd’hui demande de plus en plus d’efforts pour en assurer l’extraction – en moyenne la consommation d’un baril est nécessaire pour en extraire 18. Le pic de production est déjà bien derrière nous: c’était en 2006 !

L’humanité doit se résoudre à économiser cette source irremplaçable pour certains usages avant d’avoir siphoné la dernière goutte pour refroidir une piste de ski en plein désert ou faire tourner une formule 1 sur un circuit.

Pour imposer l’usage d’alternatives au pétrôle là où cela est possible sans impacter trop fort les utilisations légitimes, on peut imaginer la mise en place d’une taxation graduée du pétrôle en fonction de l’usage qui en est fait… Idée complexe à mettre en oeuvre et uniquement pertinente si elle est appliquée de manière internationale avec des moyens de contrôle strict, mais à mon avis indispensable.

Le pétrôle bon marché n’est plus, tentons au moins de préserver aussi longtemps que possible une partie des réserves pour les générations futures.

Icescrum setup on Debian Squeeze

As official Icescrum documentation is too short for a non Java expert to setup this product on a Debian system, this page details required tricks and also propose advice for a production environment.

Do not (re)start Tomcat before having raised the point where I tell you can start it.

Packages

First, required Debian packages (and dependencies) to install with aptitude or apt-get:
sun-java6-bin
sun-java6-jre
sun-java6-fonts
tomcat6
mysql-server

I do not recommend the use of openjdk-6 packages.

Database

Create your MySQL database and user for icescrum:
$ mysql -u root -p
mysql> create database icescrum character set utf8;
Query OK, 1 row affected (0.00 sec)

mysql> grant all privileges on icescrum.* to 'icescrum'@'localhost' identified by 'icescrumpswd';
Query OK, 0 rows affected (0.00 sec)

Of course, please use complex root and icescrum MySQL passwords.

Application

Download the icescrum_R4.x_WAR.zip file and extract it to get the WAR file itself, which is a zip file too after all. I decided to place it in /opt.

cd /tmp
unzip icescrum_R4_3.1_war.zip
mv icescrum.war /opt/icescrum-4.3.1.war
ln -s /opt/icescrum-4.3.1.war /opt/icescrum.war
chmod g+r-wx,o-rwx /opt/icescrum-4.3.1.war

Application work files

Icescrum is built with Grails and LiquidBase which both write files – I consider as temporary files. By default, it also stores users’ avatars and its application log icescrum.log in the current Java process working directory. The following command prepares a directory to get all that stuff but divert logs files to relevant location.

mkdir -p /var/local/icescrum/lbdsl
chown -R tomcat6.tomcat6 /var/local/icescrum
ln -s /var/log/tomcat6 /var/local/icescrum/logs

Application configuration

Extract the template configuration file with the following commands

cd /tmp
unzip /opt/icescrum.war WEB-INF/classes/config.properties
mv WEB-INF/classes/config.properties /etc/tomcat6/icescrum-config.properties

Edit that file with your database settings, MTA information – I suppose you have a satellite available on localhost – and browser’s URL required by Grails:

dataSource.driverClassName=org.gjt.mm.mysql.Driver
dataSource.dialect=org.hibernate.dialect.MySQLInnoDBDialect
dataSource.url=jdbc:mysql://localhost:3306/icescrum?useUnicode=true&characterEncoding=utf8&autoReconnect=true
dataSource.username=icescrum
dataSource.password=icescrumpswd
dataSource.dbCreate=update

grails.mail.host = localhost
grails.mail.port = 25
grails.mail.username = icescrum@localhost
grails.mail.password =

grails.serverURL=http://localhost:8080/icescrum

Tomcat configuration

Create a Tomcat context file at location /etc/tomcat6/Catalina/localhost/icescrum.xml with the content:

<Context
path="/icescrum"
docBase="/opt/icescrum.war"
debug="0"
reloadable="false"
unpackWAR="true"
swallowOutput="true"
/>

Edit /etc/default/tomcat6 to set various parameters on Java command line:

JAVA_HOME=/usr/lib/jvm/java-6-sun

JAVA_OPTS="-Djava.awt.headless=true -XX:MaxPermSize=256m -Xmx512m -XX:+UseConcMarkSweepGC"
JAVA_OPTS="$JAVA_OPTS -Dicescrum_config_location=/etc/tomcat6/icescrum-config.properties"
JAVA_OPTS="$JAVA_OPTS -Dlbdsl.home=/var/local/icescrum/lbdsl/"
JAVA_OPTS="$JAVA_OPTS -Duser.home=/var/local/icescrum/"

Notice I had to disassemble liquibase/dsl/properties/LbdslProperties.class to discover the lbdsl.home property which enables to avoid the default location to /usr/share/tomcat6/.lbdsl !

Now you can restart Tomcat, wait for a while looking at /var/log/tomcat6/catalina.out and then connect to http://localhost:8080/icescrum/

But then change grails.serverURL in /etc/tomcat6/icescrum-config.properties to match your definite users’ URL access.

HTTPS configuration

Until I add more details to this section, please refer to http://tomcat.apache.org/tomcat-6.0-doc/ssl-howto.html

I recommend to place the server key store in /etc/tomcat6/

Adapt grails.serverURL for https now and restart Tomcat.

Network configuration

To keep Tomcat running as standard user without changing ports to standard privileged 80 and/or 443, here are two iptables rules:

iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-ports 8080
iptables -t nat -A PREROUTING -p tcp --dport 443 -j REDIRECT --to-ports 8443

Please refer to http://wiki.debian.org/iptables to persist them in your Debian system.

Conclusion

This setup is designed for a productive environment. The original application release is kept unmodified to ease upgrades and all settings are placed in Unix standard locations.

There are still many details you may need to tune Icescrum for your specific platform, like memory settings (-Xmx in JAVA_OPTS) and database pooling. But this document is written as a start point. Do not hesitate to post comments if anything is unclear, wrong or requires improvements.

Get GWT working in WebSphere with details

I had to deploy a GWT application (2.x) based on GWT-platform into IBM WebSphere (6.1 and 7) and that was not piece-of-cake at all. It has been tested on JBoss (4.x) first without any issue. So what is wrong with WebSphere (or GWT) ?

Available information in forums sounds more like magic than engineering: one thread about Guice, another about GWT Dispatch.

As I am not satisfied when something falls into function [hum, my favorite expression in french: "tomber en marche"] without deep understanding, I have investigated why GWT/Guice does not work out-of-the-box on WebSphere and how it should work.

  • First, WebSphere does not trigger your Guice ServletContextListener at application initialization without additional Web Container Custom Properties. Here it is:
    com.ibm.ws.webcontainer.invokeFiltersCompatibility = true
    from WebSphere v7 InfoCenter
  • Second, WebSphere only triggers the listener at first request on a Servlet only, but not for resources like generated GWT html/javascript content. With a GWT application, you get the initial content from a JSP and then a RPC call to /dispatch. I have not checked if the ServletContextListener is already called because of the request to the JSP, which is a specific kind of Servlet. The call just fails with 404, as if the listener has not been triggered.
  • Conclusion part 1: even if your application does not require any JavaEE Servlet, you have to register one, with the option load-on-startup to enforce the listener to be really called at application deployment.

But it is not enough. When a new servlet mapping is added with the Servlet API, WebSphere does not honor it. It still answers 404 about /dispatch.

So the fake servlet you have to use to initiate the context and trigger the listener at application deployment MUST be mapped to /dispatch to reserve the servlet mapping in WebSphere. Then the DispatchServletModule will replace the fake servlet by the real DispatchServiceImpl when invoking the method serve on /dispatch.

Next trouble: the gwtapplication.jsp page is registered as a welcome file list in web.xml. So when you use /myappcontext/ in your browser, you get the gwtapplication.jsp content. Great it works ! Until a RPC call to a SecuredAction is invoked. It fails with a security failure because of the lack of the security cookie at client side. Why ? The Guice filter is not invoked, the pattern *.jsp has not been matched. To ease diagnostic, the DispatchService answers a blank page with status code 200. Thank you guys for the non-ending wait progress in the browser, why not return a 403 status ? Here is the bug report.

Now how to get WebSphere to behaves like others, I mean Tomcat the reference implementation ? Just add the following custom property to the Web Container:
com.ibm.ws.webcontainer.mapFiltersToAsterisk = true

In case of doubt or failure, just directly browse /myappcontext/gwtapplication.jsp to get your security cookie set.

Here I am. All that work to get a GWT/Guice/gwt-platform application just work in WebSphere. Hope it may save you some hours.

Bonus: during my tests, I have made a mistake in servlet name reference for servlet-mapping tag. Guess what: you just get a NullPointerException in SystemOut with any obvious cause in stack trace. The IBM guy has forgotten to handle human failure in its web.xml configuration parsing ! I would expect a clean error message like the servlet name « foobar » referred in servlet-mapping at line X is unknown. It may help.