camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Thorburn <>
Subject Access Camel Context or OSGi Context from XSL Extension method?
Date Thu, 21 Nov 2013 02:13:40 GMT
I am currently in the process of building a "simple" proof of concept
using Camel and ServiceMix, and mostly it's been going fine - it so
far has done exactly what I want, if not necessarily always how I

However, I'm coming up a bit short on how to achieve what I want right now.

The scenario is fairly simple:

SMX is acting as a layer between my Application, A, and a remote
application, R. To try and centralise a bunch of the logic, we are
planning to have A transform a (non-trivial) graph of domain objects
to XML and send them over to SMX. SMX will then take this set of XML,
transform it into some different XML via XSL, transform that into a
POJO, then transform the POJO into the flat file required by R.

The problem I'm running into is that I need to combine some of the
data in non-trivial ways. e.g. The domain objects I'm sending have
address data like unitNo, streetNo, streetName, streetType, suburb,
country, etc. Whereas R requires address line 1, 2, 3, 4, etc. So I
need to turn our separate address fields into combined fields, based
on various rules around shortening them if they're too long, etc.

On top of that, some values also need to be mapped, as the value of
the field in the domain object may be different to the value that R
expects (e.g. A may have a street type of ST, but R may expect
STREET). This occurs in the addresses, and also in other fields as

This one ESB will handle multiple different interfaces on R, and I
imagine that while most will share the same requirements as far as
mapping and address formatting goes, I worry that some might not, so I
would like to come up with a solution that makes it easy to have one
generic implementation that can be overridden on a case-by-case basis,
or be able to be exposed as a web service, etc.

It's possible I'm overthinking this, but I'm not happy with my current solution:

Camel Route is Web Service -> XSL -> XML -> ..., where the XSL calls
out to a static Java method for transforming the address and
translating codes. Note that there could be 5 - 10 different addresses
in a single request, and 30+ elements that need a mapping, out of a
much larger set of elements.

My problem is that, while this seems fairly simple, it means I lose
access to everything Camel-, Spring- and OSGi-related. Mostly, it
means I'd have strong coupling between all my dependencies, no way to
access any properties apart from System properties, no way to call
Camel routes, etc, etc, which makes me very nervous, and just doesn't
*feel* right (I know, I know - that's a terribly subjective

Does anyone see a better solution, or have any advice about things I
should have a look at which could help? Can I, for example, gain
access to the current CamelContext so I can call out to a camel route
for address formatting or other such things?

Or am I really just stuck going with this:

public static NodeList formatAddress(NodeList address) { String unitNo
= address.item(0).getChildNodes().item(0).getTextContent(); ... }

public static String translate(String type, String val) { InputStream
is = XSLUtil.class.getResourceAsStream(...); ... }


- Andrew Thorburn

View raw message