All entries for Monday 27 March 2006
March 27, 2006
The project I am currently working on has an OM which looks like:
page -> content -> contentFetcher
The page typically has 4 contents (links, toolbars, main and rhs) which are sequentially loaded. This seems like a good candidate for threading; there are no dependencies between them and they are each potentially expensive to created (coming from remote servers etc.).
As an experiment I wrapped added the call to retrieve them in it's own thread and deployed. Unfortunately it all went horribly wrong….and (I think) it is because we are using spring OSIV which creates a single session for the entire thread. The stack trace is:
java.util.ConcurrentModificationException at java.util.HashMap$HashIterator.nextEntry(HashMap.java:787) at java.util.HashMap$ValueIterator.next(HashMap.java:817) at org.hibernate.pretty.Printer.toString(Printer.java:90) at org.hibernate.event.def.AbstractFlushingEventListener.flushEverythingToExecutions(AbstractFlushingEventListen er.java:97) at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:26) at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1009) at org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java:356) at org.hibernate.transaction.JDBCTransaction.commit(JDBCTransaction.java:106) at org.springframework.orm.hibernate3.HibernateTransactionManager.doCommit(HibernateTransactionManager.java:584)
which is a shame.
(As an aside, it is OK to create threads within JBoss, or rather to retrieve threads from a custom threadpool; thus allowing JBoss to shut down without your threads holding anything up.)
I am sure I can work around this, and I have only spent 5 minutes on this so far, but I don't think we will be able to use SessionPerView…..
So the project I am working on uses a number of technologies including JSTL and freemarker.
Somebody had entered the following character: "è" which was displaying perfectly in JSP, but freemarker was replacing it with "?".
Of course I thought, it must be freemarkers fault :) I was meticulously careful about never converting a byte into a String using the string constructor unless the charset was specified, but I never realised you had to do it the other way as well :( When calling getBytes(), the encoding of the string is completely ignored and the platform default is used…. Why?
So the following will do bad things:
new String(new String("some string with a funny character è", encoding).getBytes(), encoding);
The problem was also a little bit more interesting because on windows machines the default platform is unicode based, on solaris it isn't, so the problem only exhibited itself on solaris.
I have (I am ashamed to say) never really delved into the joy of charsets and text encoding, instead preferring to stick my head in the sand. Luckily Chris May sits next on the desk next to me :)