Possibly, though I may have to go back to A for some strange cases, which
would rule that out. I also wasn't aware that you could override XSL
templates / imports / etc, so that does make a case for doing it in pure
XSL. That said, how do I reference a template that's in another OSGi
bundle? Do I just add the requisite Import-Package statement for the
package the resource is in?
The other possibility, which *almost* worked, was creating a bean in Camel,
then passing that in as an XSL parameter and calling instance methods on
it, which would have given me full access to Camel/OSGi/etc, which would've
been perfect. Unfortunately, Xalan isn't OSGi friendly, and since it wants
to lookup the Class I'm calling methods on (frankly, it doesn't need to),
it explodes because it can't find it. I can probably work around that, but
it's less than ideal.
So yeah, either injecting a bean into my template (with some effort to hack
around class loader limitations), or see if I can do it all in XSL.
Thanks,
- Andrew
On 21/11/2013 9:58 PM, "Walzer, Thomas" <thomas.wal...@integratix.net>
wrote:
> Not sure if I got your requirements right.
>
> How about going a plain XSL way (no java mapping)? Doing everything in XSL
> and using a generic template for address mapping. You could import it as
> needed and overide as needed.
>
> Cheers, Thomas.
>
> Am 21.11.2013 um 03:13 schrieb Andrew Thorburn <nzi...@gmail.com>:
>
> > 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
> > want.
> >
> > 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
> > well.
> >
> > 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
> > qualification!).
> >
> > 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(...); ... }
> >
> > Thanks,
> >
> > - Andrew Thorburn
>
>
