Romain thanks for the documentation as well. I polished it a bit.

We should look into adding some DSL sugar for XML DSL so you can define <stax handler="com.foo.Record"/> or whatever for the expression. A bit like we have <tokenize> for the splitting using tokenizer

Thanks for the patch. Committed to trunk. I polished the patch a bit. Also we have already the converters in camel-core. I added a few extras from this patch. As well as some other polished/improved.

Romain do you mind helping with documentation of this new component?

We need a basic components wiki page for stax component.

As well we need to add details to the Splitter EIP page how you can use stax to parse XML files.
http://camel.apache.org/splitter

And what it requires, such as a JAXB class etc.

removing spring dependency

the spring needed classes are this hierarchy: http://grepcode.com/file/repo1.maven.org/maven2/org.springframework/spring-core/3.0.6.RELEASE/org/springframework/util/xml/StaxStreamXMLReader.java#StaxStreamXMLReader (all other dependencies can easily be removed)

what is the best in your opinion: to simply copy these classes or something else?

the needed spring code is simply 2 or 3 files under apache licence so it can be copied/pasted. It was just to avoid to rewrite some conversion...

Hmm this code has Spring Framework dependency. Would be lovely without this dependency so people can use it in non Spring environments.

removing camel-jaxb and camel-spring dependencies

camel-spring should not be a dependency.

And would it be possible to create an unit test that does not use JAXBDataFormat. As you should be able to use the component without any other components.

And the converters is already in camel-core, so they are not needed.

updating the patch to remove @author tags and to merge every main classes in stax package

I would suggest use the package name org.apache.camel.component.stax and have all the logic in there. This is how the other components is.
Also at Apache we discourage having @author tags in the source, so they should be removed in the patch.
Also consider if you have sufficient unit tests. Also for inputs that are not a file etc. And if there is an empty XML document, etc.

a first patch version created from camel trunk

i'll be happy to do it, any tip on what you meant by "polishing the code"?

Looks interesting and would require JAXB model classes to work.

You may want to polish the code a bit and attach it as a patch to this JIRA, as this is how ASF can accept patches.