camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Björn Bength <>
Subject Re: [DISCUSS] Extract camel-validator from camel-core
Date Mon, 14 Nov 2011 09:46:43 GMT

the more I think of this, the more I prefer a simple solution with
just a catalog resource resolver (through xml-resolver).
That's because it's (to my knowledge) a de facto standard to map
public and system ids and in this case it would be a perfect
opportunity to follow the principle of "convention over
However, resolution of the possible (resolved) URIs in the system ids
mapping might need something like pax-url or classpath lookup
depending on case, if not xml-resolver handles that.

Compare with projects like XJC or maven-jaxb2-plugin where
setting a catalog file and optionally a class name of a specialized
catalog resolver is common.
That would easily be done in camel too, as in my first patch.
At least camel should offer such a configuration bean to configure all
this and then set this bean as a resourceResolver on the endpoint, but
is overly complex in my opinion.
At least one thing or another should be extracted to another
camel-component if camel-core is not allowed more dependencies.


On Mon, Nov 14, 2011 at 7:17 AM, Freeman Fang <> wrote:
> Yeah, pax-url absolutely is appropriate here.
> Freeman
> On 2011-11-13, at 上午10:07, Raul Kripalani wrote:
>> Hi,
>> Since we are talking OSGi, this looks like an appropriate use case for
>> the PAX URL classpath protocol. It provides means to lookup resources
>> in any other deployed bundle, either by specifying its symbolic name
>> or by performing a container-wide search.
>> It worked like a charm for me with a use case that involved Facelets
>> and loading taglibs from other bundles under Karaf.
>> -- Raul.
>> On 13 Nov 2011, at 00:02, "Christian Müller"
>> <> wrote:
>>> We found another library/dependency which JB can bundle... :-) I will
>>> provide a patch for it later...
>>> I discussed this with JB that this should of cure also work in OSGI in
>>> different scenarios:
>>> 1) the XSD is packaged together with the route in an OSGI bundle
>>> 2) the XSD is packages in another OSGI bundle (because it is used in
>>> multiple different OSGI bundles)
>>> 3) the XSD is located somewhere in the file system
>>> 4) the XSD is available somewhere over http
>>> All this should be possible. For 2), the user may have to use fragment
>>> bundles or "require bundle". I will work on it later...
>>> Best,
>>> Christian
> ---------------------------------------------
> Freeman Fang
> FuseSource
> Web:
> Twitter: freemanfang
> Blog:

View raw message