I also found an infinite loop if a component loads an XSL stylesheet
which has an invalid XPath function (e.g. <xsl:value-of
select="ext:format($a 'b')" /> - there should be a comma between $a
and b: "($a, 'b')"), which didn't seem to stop when I shutdown the
route (I don't recall seeing anything in the log suggesting it was
being shut down, but there were a lot of errors scrolling by very
fast). I had to head into the cache and nuke the bundle after
force-quitting SMX to get it to work properly, which was quite
awkward. I will raise a full bug report for that when I can.
- Andrew
On Fri, Nov 22, 2013 at 7:31 PM, Andrew Thorburn <nzi...@gmail.com> wrote:
> 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
>>
>
