This resulted in the following easy to use plugin:

$("#someElement").fromTemplate("templateId", dataset)

Where templateId is the ID of the template element and dataset is a simple Javascript object with data to expose to the template. Because this might help others understand the Micro-Templating code a bit better and might be useful to other jQuery users I have just uploaded the code to github as jQuery-fromTemplate-plugin.

Naast deze aanpassingen zal er in de toekomst nog gekeken worden naar een automatische demo aanvraag en een nieuws onderdeel op de site.

public List<Thing> findRecordsByIds(final List<Integer> ids) {
	return (List<Thing>) getHibernateTemplate().execute(new HibernateCallback() {
		public Object doInHibernate(Session session) throws HibernateException, SQLException {
			return session.createCriteria(Thing.class).add(Restrictions.in("thingId", ids));
		}
	});
}

And it failed with a SQLGrammarException (which should never occur when using the Hibernate Query API). The Hibernate project knows about this as seen in their JIRA, but a fix is not yet delivered. Of course an easy fix to my example is:

public List<Thing> findRecordsByIds(final List<Integer> ids) {
	if(ids.size() == 0) return Collections.emptyList();
	return (List<Thing>) getHibernateTemplate().execute(new HibernateCallback() {
		public Object doInHibernate(Session session) throws HibernateException, SQLException {
			return session.createCriteria(Thing.class).add(Restrictions.in("thingId", ids));
		}
	});
}

Which also uses another function everybody should know about: Collections.emptyList() which in contrary to Collections.EMPTY_LIST uses a simple form of type inference to create a List<Thing> instead of a raw List and avoids a compiler warning.

To save anyone with the same problem a lot of time, a workaround is to add the following line to eclipse.ini:

-XX:CompileCommand=exclude,org/eclipse/core/internal/dtree/DataTreeNode,forwardDeltaWith

That stops Java Hotspot’s JIT compiler from compiling the problem-method and avoids the crash.

new HashMap() {{
	put("name", "Tomas Salfischberger");
	put("phone", "123456789");
	put("room", "11b");
}};

The { } notation is called an “initialization block”. We can also see this notation in action in the following class:

public class Person {
	protected int age;

	// Initialization block
	{
		age = 30;
	}
	public Person() {
		age = 40;
	}
}

And you can feel it coming, the bonus-question here is: After creating a Person object, what is the value of the age field? You can try for yourself, or I can just tell you it will be 40. From that we can conclude that the init-block is executed before the constructor. If you check the documentation from Sun, you’ll find that init-blocks are indeed prepended to every constructor.

A new question arises: How could Tomas have used the put method in an init-block before the constructor of the HashMap has actually run? A more detailed look at the HashMap example reveals that what’s actually happening there, is the creation of a subclass of HashMap. This explains why the init-block runs after the constructor of HashMap: The init-block of the subclass is prepended to the constructor of the subclass, and the constructor of a subclass always runs after the constructor of its superclass.

A practical test confirms the following execution order of init-blocks and constructors:

- superclass init block
- superclass constructor
- your init block
- your constructor

You can also define multiple init-blocks, the runtime system guarantees they execute in the order that they appear in the source code. So all in all the init-blocks are a nice (and widely unknown) language feature which can be used to add general initialization to all constructors or in special cases to replace a no-argument constructor.

{
    "name" => "Tomas Salfischberger",
    "phone" => "123456789",
    "room" => "11b"
}

And for PHP:

array(
    "name" => "Tomas Salfischberger",
    "phone" => "123456789",
    "room" => "11b"
)

Now the problem with a lot of these comments is that most Java-critics can’t actually write proper Java code. There is, for example, the following method to instantiate the same Map in Java:

new HashMap() {{
    put("name", "Tomas Salfischberger");
    put("phone", "123456789");
    put("room", "11b");
}}

It is true that there is a bit more typing involved, but how many seconds does this actually cost you? And what if you look at the extra information we have provided? In Java we have actually expressed that we need a HashMap and not for example a TreeMap. That is not just more typing because Java programmers like typing, it’s actually valuable information.

Another one which might be useful (but more widely known I guess?) is this function to create a List using the Java 5 varargs feature:

Arrays.asList("value1", "value2", "something else")

These are both just simple tricks to make a programmer’s life easier, unfortunately a lot of people don’t know about them. Let’s hope the lost Ruby souls will some day find out about the simple tricks in other languages

Here is an example of the code used to execute a simple script and give it access to part of the service-layer of the application:

Interpreter interpreter = new Interpreter();
interpreter.set("log", log);
interpreter.set("xxxxService", xxxxService);
interpreter.set("yyyyService", yyyyService);
interpreter.set("inputObject", someObject);
interpreter.eval(script);

After which it is possible to write scripts in the BeanShell language (which is very much like Java) to modify the object inputted, or as in my case validate some business-rules by making a few service-calls.

public class UserEditController extends CancellableFormController {
    protected SecurityService securityService;

    protected ModelAndView onSubmit(...) throws Exception {
        User user = (User)command;
        securityService.updateUser(user);

        return getSuccessView();
    }

    @Required
    public void setSecurityService(SecurityService securityService) {
        this.securityService = securityService;
    }
}

At first sight this seems a very common form-controller to edit a User object. The problem lies here in the fact that the User object has a few properties like “expireDate” and “accessLevel”. Experienced Spring users might see the security-problem now, others should check out the documentation for a hint:

Note that there are potential security implications in failing to set an array of allowed fields. In the case of HTTP form POST data for example, malicious clients can attempt to subvert an application by supplying values for fields or properties that do not exist on the form.

If you don’t set the allowedFields or disallowedFields property the DataBinder will bind all HTTP-parameters to the domainobject so a malicious user could post an accessLevel property changing their own accessLevel. Of course setting allowedFields everywhere seems like a lot of work, but Spring has made this quite easy. From the documentation:

Register fields that should be allowed for binding. Default is all fields. Restrict this for example to avoid unwanted modifications by malicious users when binding HTTP request parameters.Supports “xxx*”, “*xxx” and “*xxx*” patterns. More sophisticated matching can be implemented by overriding the isAllowed method.

So with these patterns there is no excuse to not restrict the properties to be bound.

javax.naming.NameNotFoundException: Name jdbc is not bound in this Context

But this DataSource is defined in the src/main/webapp/META-INF/context.xml default context file:

<Context>
        <Resource name="jdbc/dbname" auth="Container" type="javax.sql.DataSource"
                maxActive="100" maxIdle="30" maxWait="10000"
                username="username" password="pass" driverClassName="com.mysql.jdbc.Driver"
                url="jdbc:mysql://localhost/dbname?autoReconnect=true"/>
</Context>

So I searched the web for other people with these kind of issues and found a few mailinglist questions (all unanswered) here and here. And finally found out that it is just not possible to use a context.xml with the tomcat:run goal as it is still an open issue in the codehaus JIRA: #MOJO-594. So I hope this might save someone some time searching for how to get tomcat to pickup the context.

After this rather unsatisfactory search I decided to checkout how hard it would be to integrate Apache XML-RPC with Spring in the way I just described. The target is to be able to write something like the following Spring configuration to be able to export some services:

<bean name="serviceExporter" class="...">
    <property name="services">
        <map>
            <entry key="ExampleService" value-ref="exampleServiceBean" />
        </map>
    </property>
</bean>

Perry Nguyen has written a post about integrating Apache XML-RPC 3 with Spring but he has left some open ends in my opinion. His solution is like mine based on a map of beans to be used in a ProcessorFactoryFactory. The first step in handling an XML-RPC request is mapping the request to a simple controller:

public class XmlRpcController extends AbstractController {
    private XmlRpcServletServer server = new XmlRpcServletServer();

    @Override
    protected ModelAndView handleRequestInternal(HttpServletRequest req, HttpServletResponse res) throws Exception {
        // Delegate the request to the XmlRpcServletServer
        server.execute(req, res);
        // And stop processing of the request
        return null;
    }

    @Required
    public void setMapping(XmlRpcHandlerMapping mapping) {
        server.setHandlerMapping(mapping);
    }
}

As you can see this is just a simple wrapper around the XmlRpcServletServer to pass the request and response to the execute method. Apart from that we have a mapping property to set the handlerMapping property on the server. The next step is to create our own mapping class to be able to map service-names to a class:

public class SimpleHandlerMapping extends AbstractReflectiveHandlerMapping {
    public void setServices(Map<String, Object> services) throws XmlRpcException {
        // Check parameter
        Assert.notNull(services, “Services map should not be null.”);

        // Setup a RequestProcessorFactoryFactory
        SimpleRequestProcessorFactoryFactory factory = new SimpleRequestProcessorFactoryFactory();

        // Register all service beans with the factory
        for (Object serviceBean : services.values()) {
        	factory.registerServiceBean(serviceBean.getClass(), serviceBean);
        }

        // Set the RequestFactoryFactory to be used for mapping
        setRequestProcessorFactoryFactory(factory);

        // Loop through the set
        Iterator<Entry<String, Object>> it = services.entrySet().iterator();
        while (it.hasNext()) {
            // Fetch from the map
            Entry<String, Object> entry = it.next();
            String serviceName = entry.getKey();
            Object serviceBean = entry.getValue();

            // Register service in the handler mapping
            registerPublicMethods(serviceName, serviceBean.getClass());
        }
    }
}

The input of this mapper is a simple Map of Strings and Objects describing the service-names associated with the objects (Spring beans). First we create a RequestProcessorFactoryFactory to be able to map classnames to Spring beans the code for this SimpleRequestProcessorFactoryFactory is given below. Then we register all services in the Map with the factory and set the factory to be used by the methods from our superclass.

The last step is to register all service-names with their respective classes using the registerPublicMethods method from our superclass. This tells Apache XML-RPC to register all public methods and call our SimpleRequestProcessorFactoryFactory to get a Factory returning the servicebean. This SimpleRequestProcessorFactoryFactory is based on a Map of Class and Objects to map the Class Apache XML-RPC asks for to a Spring bean:

public class SimpleRequestProcessorFactoryFactory implements RequestProcessorFactoryFactory {
    private Map<Class, Object> serviceBeans = new HashMap<Class, Object>();

    public RequestProcessorFactory getRequestProcessorFactory(Class pClass) throws XmlRpcException {
        // Get the serviceBean from the map
        final Object serviceBean = serviceBeans.get(pClass);

        // Check if the bean is actually found
        if (serviceBean == null) {
            throw new XmlRpcException(”Handler \”" + pClass.getCanonicalName() + “\” not found.”);
        }

        // Create a factory just returning the lookedup bean
        return new RequestProcessorFactory() {
            public Object getRequestProcessor(XmlRpcRequest pRequest) throws XmlRpcException {
                return serviceBean;
            }
        };
    }

    public void registerServiceBean(Class clazz, Object serviceBean) {
    	serviceBeans.put(clazz, serviceBean);
    }
}

And then just a few lines of XML to wire it all together:

<bean id="xmlRpcHandlerMapping" class="nl.celerity.example.xmlrpc.SimpleHandlerMapping">
    <property name="services">
        <map>
            <entry key="ExampleService" value-ref="exampleService" />
        </map>
    </property>
</bean>

<bean id="xmlRpcController" class="nl.celerity.example.xmlrpc.XmlRpcController">
    <property name="mapping" ref="xmlRpcHandlerMapping" />
</bean>

Where exampleService is of course the name of a Spring bean with some public methods to be exported. With these two simple helper classes and an extremely simple controller we have the ability to export Spring beans as XML-RPC services by just adding a simple line of XML configuration.

Deze verandering werd deels geïnitieerd door het feit dat de H in SHC stond voor Henschen, en John Henschen zich enige tijd geleden vanwegen persoonlijke omstandigheden uit het bedrijf heeft teruggetrokken. De belangrijkste aanzet voor deze verandering was echter het feit dat SHC is gegroeid van hoofdzakelijk een netwerk solutions provider naar een groeiende speler op de markt van softwareontwikkeling.

Een nieuw onderdeel van deze website is onze blog of weblog, vooral bedoeld om een platform te vormen voor publicatie van informatie over de technieken die wij gebruiken en een mogelijkheid om deze informatie te delen met beroepsgenoten. Dit onderdeel zal in het Engels beschikbaar zijn, omdat deze technieken internationaal gebruikt worden en de informatie daarmee universeel is voor het gehele vakgebied.

Arthur zal zich gaan richten op het verbeteren van de gebruiksvriendelijkheid van de geavanceerde functionaliteit van Celerity CRM en het exporteren van data naar Microsoft Office formaten.