Liking the File language in Camel 1.5.0

Claus has a great write up on the new File language feature in Camel 1.5.0 - cool stuff! I'm really looking forward to the next release!

A favorite feature of mine in the next Apache Camel is a new feature to use file name patterns in the file component. What we have introduced is a new language, the file language, so you can leverage this feature anywhere in Camel where it uses Expressions, Languages etc. The file language currently support both the file and the FTP component as well.

As a lot of integrations is file based you need to be able to read (consume) or write (produce) files. Then you need to be able to specify file names. What's new in Camel 1.5.0 is that you can express this using patterns, for instance directly in the configuration of your endpoints. Prior you had to do this in Java code.

Simple example
Lets image you need to move consumed files into a backup folder after processing.

Now you can express this using the pattern: backup/${file:name}
Well then you need to use .bak as extension, and the pattern is:backup/${file:name}.bak

Okay next issue is that the backup folder should be grouped by dates using the yyyyMMdd pattern. Well the expression support thejava.text.SimpleDateFormat patterns also.
The pattern is:backup/${date:now:yyyyMMdd}/${file:name}.bak wherenow means current date. You can substitute this with different commands such as file for using the timestamp on the file instead.

Advanced example
In this sample you need to produce files (save) and you need to save the file using a generate unique filename. We use the divide and conquer pattern for this so you create a POJO class that generates the unique filename, then you as the developer have the full power how to do this. And then its very easy to unit test as its plain POJO that can be tested very easily with JUnit. Next step is to express this as a file pattern. As your POJO is a bean we use the bean langauge to invoke your pojo.

So the pattern is: myfile-${bean:myguidgenerator.generateid}.txt
Where myguidgenerator is the bean id of your POJO and generateidis the method name. You can omit the method name if there is no ambiguity which method Camel should invoke.

Camel routes
This feature is configurable directly in camel routing on your endpoints. So what we can do now is:

from("file://inbox?expression=backup/${date:now:yyyyMMdd}/${file:name}.bak").to("bean:processFile");

The route will consume files and process the files in the processFile bean, that is a plain POJO class. After processing the files is moved (renamed) using the pattern in the expression. So the file is moved to the backup subfolder, for example: backup/20081014/report-october-2008.bak

More to come
Well there is a ton of new features and improvements in Camel 1.5.0. Check out the current release note.

Using Guice as a JNDI provider

In many ways a Dependency Injection framework is a replacement for looking things up in a registry like JNDI; but sometimes having some kind of registry or JNDI provider can be useful such as if you want to work with JSR250/EJB3 or some legacy code which expects JNDI to be used - or you want to use JNDI as a kinda loosely coupled registry between completely different modules of your system.

I've hacked up a simple JNDI provider which just uses Guice to create all the objects; so you stick to pure Java code for writing your Guice Modules to depenency inject your objects together then have a little properties file to enable/disable/tweak things.

When looking at Guice through spring-tinted glasses the most glaring difference (apart from the lack of XML) tends to be the absence of the ApplicationContext and a registry where you can look things up by name. This JNDI provider provides a more standard alternative to the ApplicationContext, as JNDI is in the JDK and it kinda gives you that crutch to lean on until you figure out the guicier way of doing your dependency injection :). 

One neat thing is it combines JNDI naming with the @Named injection points in Guice and allows @Resource from JSR250/EJB3 all configured via the same jndi.properties file 

Adding support for @PostConstruct, @PreDestroy and @Resource to Guice

I do like guice as a Dependency Injection engine; I think it has a lot of promise; particularly if 2.0 is released soon :)

I still struggle sometimes, coming from a spring framework mindset, figuring out how to do some stuff. Though I love the @Provides support in trunk of Guice. Here's hoping 2.0 is out soon! :)

I've experimented recently adding support for ConstructorInterceptors into guice so you can add custom lifecycles like @PostContruct from JSR250/EJB3 or Spring's InitializingBean etc. 

I've also created a patch to support closing of singletons such as via @PreDestroy or spring's DisposableBean.

Slightly more wacky is a patch adding support for custom injection point annotations which allows you to easily support things like 

• @Resource from JSR 250/EJB3
• @PersistenceContext from JPA
  
• the various JAX-RS annotations like @Context, @PathParam etc
• WebBeans @In
• Spring's @Autowire
• Apache Camel's injection annotations like @EndpointInject or @Produce

Feedback greatly appreciated!

Enterprise Integration Designer preview

From Oisin's blog.

Thanks to Enterprise Integration Patterns, architects have a clear and succinct way to describe integration within complex systems. It certainly beats a lot of MS-Word documents and monster integration architecture diagrams. And, with Apache Camel, we’ve got an open source runtime that allows us to create routes by chaining EIPs together, using Spring XML or Java fluent builders. That’s fantastic, but EIPs are as much about sharing pictures as creating message routing graphs, and where are the pictures?  

We’ve made some tools that will allow you to load up Camel Spring XML files into Eclipse for visual inspection and editing. You can also create EIP diagrams in your Workbench and save them as Camel configurations. Finally, we’ve put in some debugging capabilities to allow you trace through the paths a message will take through your EIP graph.  

We are earnestly seeking feedback - check out the FUSE Integration Designer Preview page to download the Eclipse plugins, or check out the video links under the Training Videos at the bottom of the page.

Looks great! Feedback greatly appreciated