This article describes how we used Groovy to create a DSL for the clauses in a rules engine. We have been collaborating in the development of an “expert system” application for KnowledgeBench Ltd. This application uses a forward chaining rules engine to provide a “smart” system capable of creating formulations in domains such as pharmaceutical tablet formulation, inhalers, paints, food & drink and cosmetics. (more…)
Caching pages leads to a speedier browsing experience and so is a good idea. Replacing information within a web page using Ajax similarly improves the user’s experience. The problem comes when the browser caches the information from the Ajax request. It’s a logical thing to do, but it’s not normally what the developer wants.
There are a number of ways round this. (more…)
In addition to having problems with JNDI not working properly, I’ve also been bashing my head against Plesk–that is supposedly “designed to simplify the management and administration of web sites”.
It’s the interaction between Plesk and Tomcat that’s the particular problem and how both of them negotiate dealing with multiple domains (or rather don’t deal with it). (more…)
If you’re writing a JSP using the JSTL tag <c:catch var=”myError”> … </c:catch> then I’m sure that you know that the next thing to do is to check after the closing catch tag to see if myError is empty. If not you can output some useful error message having successfully caught any exception. However, sometimes it’s useful to actually output the stack trace (when debugging a site for example). It turns out not to be difficult to do this. Simply copy in the following:
Subscribe to news from Isocra
<c:if test="${not empty myError}">
<p class="error">An error occured: <c:out value="${myError}"/></p>
<pre>
<c:forEach var="stackTraceElem" items="${myError.stackTrace}">
<c:out value="${stackTraceElem}"/><br/>
</c:forEach>
