Hi, 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 configuration". 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 et.al. 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 this 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. Regards Björn On Mon, Nov 14, 2011 at 7:17 AM, Freeman Fang <freeman.f...@gmail.com> 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" >> <christian.muel...@gmail.com> 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 > Email:ff...@fusesource.com > Web: fusesource.com > Twitter: freemanfang > Blog: http://freemanfang.blogspot.com > > > > > > > > > >
