But there are few problems which I experienced:

1. The most frustrating is in fact described in the Hibernate docs. An object returned by session.load() isn’t necessarily an object of the expected class:

   Cat cat = (Cat) session.load(Cat.class, id);  // instantiate a proxy (does not hit the db)
   if (cat.isDomesticCat()) {                  // hit the db to initialize the proxy
       DomesticCat dc = (DomesticCat) cat;       // Error!
       ....
   }

2. No inheritance mapping for value objects: here is the JIRA issue that never gets fixed, and a workaround.
3. The strong suggestion in the Hibernate documentation to use a join table for every unidirectional one-to-many association (in the section 2.2.5.3.2.2. “Unidirectional”). Another suggestion is discussed here.
4. 2nd level caching should be used with caution: after deleting an object the stale version can still stay in cache which can lead to an ObjectNotFoundException. I found no other solution except disabling the 2nd level cache for the class.

The most impressive part of the talk was when Armin demonstrated the “online” debugging feature on a standard error page generated by Werkzeug. Upon each error the context in which it happens is stored on the server (only if the app is in the debug mode). Thus on the error page itself you can directly interact with the Python interpreter which is “frozen” in the very state in which the error happened. So you can use the full power of the interactive Python interpreter directly on the standard error page. That’s awesome.

${node.title}
<div class="children">
<c:forEach var="node" items="${node.children}">
	<c:set var="node" value="${node}" scope="request"/>
	<jsp:include page="node.jsp"/>
</c:forEach>
</div>

The tricky thing is that when you use jsp:include (and for recursion you have to use the dynamic inclusion), normally, you loose all the variables defined in the parent JSP. But if you redefine the variables you need in the “request” scope, then they will be visible in the included JSP too. I assumed that this very JSP is named “node.jsp” and omitted the declarations. Surprisingly, I found neither this nor any other solution on the Web, so I had to invent one.

tie(@lines, "Tie::File", $fname, mode => 0) or die "Can't tie $fname: $!";
$max_lines = $#lines;
for ($i = $max_lines; $i; $i--) {
	if (not &$apply($lines[$i])) {
		return 0;
	}
}

The second approach is faster but requires at least as much available memory as the size of the log file, in fact more than twice as much when processing several files one by one (in my case, 1:02 min and up to 150Mb RAM):

open(LOG, $fname) or die "Can't open $fname: $!";;
@lines = reverse <LOG>;
foreach $line (@lines) {
	chomp $line;
	if (not &$apply($line)) {
		close(LOG);
		return 0;
	}
}
close(LOG);

So I chose the first approach, because I thought that stable memory footprint on the server is more important than the time the script takes to complete. Here is the full code for the package I wrote that provides handy functions for scanning rolling logfiles forwards and backwards: logscan_pl.txt

And here is a usage sample:

require 'logscan.pl';
$errors = 0;
logscan::scan("Joanna", sub {
	$_ = shift;
	if (/(.*) INFO.*Returning error by [([^]]*)].*user=[([^]]*)].*roles=[([^]]*)]/) {
		my ($time, $uri, $user, $role) = ($1, $2, $3);
		$errors++;
		print "$time $uri $user $rolen";
	}
	return 1;
});
print "\\n\\nTotal errors: $errors\\n";