The Software Chef

Most Java standards are implemented using an api jar and an concrete implementation jar. The API constists maninly of interfaces but a class that looks up the default implementation. This lookup normally happens by trying to load a specific resource bundle which is located in the implementation jar. This can lead to “interesting” classloader problems when used with OSGi and Spring DM specifically
Read more »

Eclipse Galileo is out a while and it ships with TMF XText 0.7 (formerly openArchitectureWare XText). Amongst other things it contains scoping of references, which I really like and especially the ability to serialize your model back to its text representation without comments being lost.

This is especially convenient if you are currently using some other means of generating code, for example hibernate tools. The serialization feature gives you an easy possibility to transform your existing model to an xtext model from within java code. Even better create updatable models, where you can manually edit the Xtext representation and keep the model up to date from an external source.

Example for loading and saving an XText model:

public static void main(String[] args) {
    DomainModelStandaloneSetup.doSetup();
    ResourceSet resourceSet = new ResourceSetImpl();
    URI uri = URI.createFileURI("myapplication.domainmodel");
    Resource resource = resourceSet.getResource(uri, true);
    Model model = (Model) resource.getContents().get(0);
    
    Entity entity = DomainModelFactory.eINSTANCE.createEntity();
    entity.setName("Customer");
    
    model.getElements().add(entity);
    
    HashMap saveOptions = new HashMap();
    saveOptions.put(XtextResource.OPTION_FORMAT, Boolean.TRUE);
    resource.save(new FileOutputStream("myapplication.domainmodel"), saveOptions);
}

The classes in bold face are generated from your Xtext grammar.

In a typical spring based server application there is a service layer responsible for infrastructure tasks and communication with the clients. Service methods can be long running and execution would normally block the user-interface. Putting the client side end of the call in a thread solves the blocking but leaves the network connection open while the server side of the call is active. This can lead to all sorts of time-out issues and seems to be the wrong end to fix the problem .

Using spring AOP it is remarkably easy to declaratively enable service methods to execute detached from the regular call context.

The Goal

@DeferredExecution
public myServiceMethod() throws DeferredExecutionException {
}

This method would execute with the following sematics:

1. The regular method call is wrapped in a thread
2. The thread is executed
3. If the thread does not finish within x seconds, raise a checked exception
4. If it does finish in time, return the result of the method

This way clients of this method are forced to handle detached execution (i.e. show a progress dialog querying the server) and the client side of the call not langer lasts longer than a set time.
Read more »