We’ve been using the following construct for a long time in our util classes:
public static <T> List<T> query(SimpleJdbcOperations jdbcOps, String query,
Map<String, Object> paramMap) {
return jdbcOps.query(query,
new ParameterizedRowMapper<T>() {
@SuppressWarnings("unchecked")
public T mapRow(ResultSet rs, int rowNum)
throws SQLException {
return (T)rs.getObject(1);
}
},
paramMap);
}
If you call this method with T=Long and the column to retrieve (in the database) is an int, Integer will be put to the list as (Long)Interger cast works. So you end up in a List filled with Integer. With that list, a list.remove(new Long(1)) does not remove.
The secure installation of amtu on Debian has some pitfalls. The problem is that amtu uses java.util.prefs.Preferences#systemNodeForPackage instead of java.util.prefs.Preferences#userNodeForPackage (com.amazon.merchants.transport.preferences.UserAccountPreferences). This leads to the problem that the configuration is not stored as non-root user or even more unpredictable: It is stored if you do the configuration as root and cannot be read or updated with another user. The fact that the configuration is stored in the directory /usr/lib/jvm/java-6-sun/.systemPrefs -> /etc/.java/.systemPrefs, which I have never used before, doesn’t make the thing easier. So heres a quick guide for setting up amtu on Debian:
sudo useradd -d /var/lib/amtu -s /bin/bash amtu
sudo mkdir /usr/local/share/amtu /var/lib/amtu /var/log/amtu
cd /usr/local/share/amtu
sudo tar xzvf .../amtu-linux-1.0.9.tar.gz
sudo -s
export JAVA_HOME=/usr/lib/jvm/java-6-sun
./install.sh
exit
sudo /etc/init.d/amt stop; sudo /etc/init.d/amt_monitor stop
cd /usr/local/share/amtu/service/bin
sudo mv data /var/lib/amtu/
sudo ln -s /var/lib/amtu/data .
cd /var/lib/amtu
sudo rm -rf logs
sudo ln -s /var/log/amtu logs
sudo chown -R amtu:amtu data
sudo chown -R amtu:amtu -R /etc/.java /var/lib/amtu /var/log/amtu
Next we change the user the service runs as:
* PIDDIR=”/var/lib/amtu”
* RUN_AS_USER=amtu
sudo vi /etc/init.d/amt
sudo vi /etc/init.d/amt_monitor
Now we change the logging:
* wrapper.java.command=/usr/lib/jvm/java-6-sun/bin/java
* wrapper.logfile=/var/log/amtu/-wrapper.log
* wrapper.logfile.maxsize=1m
* wrapper.logfile.maxfiles=2
sudo vi /usr/local/share/amtu/service/conf/amt.conf
sudo vi /usr/local/share/amtu/service/conf/monitor.conf
Cleanup & start
sudo chsh -s /bin/false amtu
sudo /etc/init.d/amt start; sudo /etc/init.d/amt_monitor start
Debugging:
The wrapper around amtu swallows exceptions. So running within the wrapper I have never seen an error, I have to call the Service on its own via:
amtu@sten:/usr/local/share/amtu/service/bin$ /usr/lib/jvm/java-6-sun/bin/java \
-Dlog4j.configuration=/usr/local/share/amtu/service/conf/log4j.properties \
-Djavax.management.builder.initial=mx4j.server.MX4JMBeanServerBuilder \
-Djava.library.path=../lib -classpath \ ../../lib/mx4j.jar:../../lib/mx4j-impl.jar:../../lib/mx4j-jmx.jar:../../lib/commons-lang-2.0.jar:../../lib/commons-logging.jar:../../lib/log4j-1.2.8.jar:../../lib/hsqldb.jar:../../lib/activation.jar:../../lib/mailapi.jar:../../lib/saaj.jar:../../lib/commons-discovery.jar:../../lib/jaxrpc.jar:../../lib/wsdl4j.jar:../../lib/jakarta-commons-io-SNAPSHOT.jar:../../lib/amtu.jar:../../lib/axis.jar:../../lib/mx4j-remote.jar:../../lib/mx4j-rimpl.jar:../../lib/mx4j-rmjx.jar:../../lib/mx4j-tools.jar \
com.amazon.merchants.transport.TransportMain transport
The intervals when amtu connects to amazon are quiet long for debugging, you can change them here: /etc/.java/.systemPrefs/com/amazon/merchants/transport/preferences/prefs.xml
Zum heutigen Tag löst Redmine den bisherigen Issue Tracker Mantis (1.1.x) ab. Hauptgrund für den Wechsel war das unschöne Interface, was dazu führte, dass die Nutzung für manche mehr eine Strafe als eine Hilfe war. Zudem lösen wir gerade intern CVS mit Git ab und damit können wir das SCM direkt in den Issue Tracker integrieren (Trac, “die Mutter” von Redmine, unterstützt “nur” SVN).
Die alte Mantis-Installation ist noch über “it-old” erreichbar und wird vermutlich in den nächsten Wochen abgeschaltet.
Details zur Migration s. Migrating from Mantis to Redmine
Today we migrated from our old Mantis 1.1.x Installation to Redmine 0.9 (Debian package). Using the migration-script redmine:migrate_from_mantis made great work after some minor traps.
First there was a bug in /usr/share/redmine/lib/tasks/migrate_from_mantis.rake:287. Replaced :role by :roles and added proper [] this was fixed fast. Thereby we’ve changed the default password ‘mantis’ for all users to a generated one (/usr/share/redmine/lib/tasks/migrate_from_mantis.rake:257). After that the import stoped with
rake aborted!
Validation failed: Login has already been taken
Easy reason, 1 hour of debug: User admin was already in the "clean" database of Redmine, so the Mantis user admin has to be renamed.
The most time consuming issue was the encoding. The Mantis database has had the character set latin1 and redmine utf8. This made the import stop when having categories with german umlauts in them (SQL-errors) or cut the complete text before the first umlaut. Having that mastered here is the final mini-script we use to migrate:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
| # prepare mantis database (copy from another host, encoding)
ssh mantishost "mysqldump --add-drop-table mantisdb | gzip - -c" | gunzip - -c \
> ~/bugtracker.mysql
# we don't need to recode
# recode ISO-8859-1..UTF-8 < db-latin1.mysql > db-utf8.mysql
# replace charset table definition
sed -i 's/CHARSET=latin1/CHARSET=utf8/g' ~/bugtracker.mysql
echo "drop database bugtracker"|mysql
echo "CREATE DATABASE bugtracker DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci"|mysql
mysql bugtracker < ~/bugtracker.mysql
echo "UPDATE mantis_user_table SET username='adminMantis' WHERE id=1"|mysql bugtracker
# cleanup redmine
echo "drop database mit_redmine" | mysql
echo "CREATE DATABASE mit_redmine DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci"|mysql
# remove attachements
sudo sh -c "rm /var/lib/redmine/default/files/*"
cd /usr/share/redmine
# prepare redmine
sudo RAILS_ENV=production rake db:migrate
sudo RAILS_ENV=production rake redmine:load_default_data
# finally run the migrate script
sudo rake redmine:migrate_from_mantis RAILS_ENV="production" |
Running it (notice the latin1 instead of UTF-8 encoding):
> sudo rake redmine:migrate_from_mantis RAILS_ENV="production"
(in /usr/share/redmine)
WARNING: Your Redmine data will be deleted during this process.
Are you sure you want to continue ? [y/N] y
Please enter settings for your Mantis database
adapter [mysql]:
host [localhost]:
database [bugtracker]:
username [root]:
password []: xxx
encoding [UTF-8]: latin1
Migrating users..............................
Migrating projects.....................
Migrating bugs...[cut many dots and some warnings]
Migrating news.
Migrating custom fields.....
Users: 30/30
Projects: 21/21
Memberships: 69/69
Versions: 15/15
Categories: 213/213
Bugs: 2726/2726
Bug notes: 3774/3795
Bug files: 349/349
Bug relations: 1054/1064
Bug monitors: 47/53
News: 1/1
Custom fields: 5/5
We here at MIT receive a big productivity boost by using the Pomodoro Technique (works great with GTD).
Die erste iPhone Applikation der meissner.IT kommt in die Beta-Phase, d.h. einige Tester nehmen sie sich vor.
Pünktlich zur Europawahl am 07.06.2009 war die Umsetzung der barrierefreien Präsentation der Wahlergebnisse auf Basis von PC-Wahl fertig und auf den Seiten der Stadt Monheim am Rhein online.
Mit Hilfe des erstellten Programms können nun alle vorherigen und zukünftigen Wahlen im Internet dargestellt werden. Die Wahldaten werden einmalig (oder am Wahltag auch jede Minute) importiert und dann in einer ansprechenden Form dargestellt.
Wie so oft möchten wir uns noch einmal herzlich für die gute Zusammenarbeit mit den Bediensteten der Stadt Monheim bedanken!
Presenting today: One of “took me two hours” issues. This codes seems to be ok:
1
2
3
| Object[] strArr = new String[] { "whatever" };
Object[] newArr = ArrayUtils. addAll(strArr, null);
ArrayUtils. addAll(newArr, new Object[] { Boolean. TRUE }); |
But executing it leads to the following exception:
Exception in thread "main" java.lang.ArrayStoreException
at java.lang.System.arraycopy(Native Method)
at org.apache.commons.lang.ArrayUtils.addAll(ArrayUtils.java:2972)
This is because ArrayUtils.addAll takes as type for the returned array the componentType of the first array. Although strArr is defined as Object[], strArr.getClass().getComponentType() returns String, resulting in a String-array.
Today I was fighting against logback and its configuration option -Dlogback.configurationFile. Logback has simply ignored this option, no matter what I have tried. Simple solution: Upgrade from logback v0.9.9 to logback v0.9.15 and everything works as expected.
Cookies sollten Subdomain übergreifend (www.xai.com -> blog.xai.com) funktionieren. Hierzu hat Tomcat leider keinen Konfigurationsparamter, dafür gab es auch schon mehrere Lösungsansätze:
http://www.esus.be/blog/?p=3
http://thread.gmane.org/gmane.comp.jakarta.tomcat.user/165272
Beide (nacheinander) getestet, Valve Konfiguration in der server.xml an mehrere Stellen ausprobiert, nie hat es geklappt. Anscheinend wird bei tomcat 5.5.17 und 5.5.20 die Session immer vor dem Valve erzeugt und als Cookie geschrieben, ist aber weder über org.apache.catalina.connector.Response.getCookies noch über die MimeHeaders wie im zweiten Link erreichbar.
Zwischendurch noch probiert, Request über einen RequestWrapper im Valve zu verändern und in RequestWrapper#configureSessionCookie die entsprechende Änderung zu machen, auch das war nicht erfolgreich (die Session wird noch vor dem Aufruf des Valve erzeugt).
Somit blieb als einzige Lösung das Patchen von Tomcats org.apache.catalina.connector.Request, darin dann auch #configureSessionCookie. Dies auf der Basis von jeweils 5.5.17 (Entwicklersystem) und 5.5.20 (etch) durchgeführt, Änderungen im CVS (apache-tomcat-5.5) gesichert und online genommen (s. Issue #1778).