Mailing-List: contact dev-help@camel.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@camel.apache.org
Received-SPF: pass (nike.apache.org: domain of bjorn.bength@gmail.com
 designates 74.125.82.173 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <A54FBF4E-3161-4099-A3E6-718F179E2148@gmail.com>
References: 
 <CALvzYd9firh_GhOC-5SLf5QgYDP0uFp=ACb3QgsHZM1G3wfk1g@mail.gmail.com>
	<4EBE8A99.2050106@nanthrax.net>
	<CALvzYd94BKj0=m_2LH6sok6KEr4i09sFtTzK8PA08TXJgyGi1w@mail.gmail.com>
	<CALvzYd-9RgAKood=eV2k=0jpxVS3gG1NWyu=HGv_iJLehDh_YQ@mail.gmail.com>
	<-6082237572495826356@unknownmsgid>
	<A54FBF4E-3161-4099-A3E6-718F179E2148@gmail.com>
Date: Mon, 14 Nov 2011 10:46:43 +0100
Message-ID: 
 <CAPee5JEZ=9Xas5GcxcwNi_e7Ar6GCesNKO-Mu8NtAhOLPhsu-A@mail.gmail.com>
Subject: Re: [DISCUSS] Extract camel-validator from camel-core
From: =?ISO-8859-1?Q?Bj=F6rn_Bength?= <bjorn.bength@gmail.com>
To: dev@camel.apache.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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=C3=B6rn


On Mon, Nov 14, 2011 at 7:17 AM, Freeman Fang <freeman.fang@gmail.com> wrot=
e:
> Yeah, pax-url absolutely is appropriate here.
>
> Freeman
> On 2011-11-13, at =E4=B8=8A=E5=8D=8810: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=C3=BCller"
>> <christian.mueller@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:ffang@fusesource.com
> Web: fusesource.com
> Twitter: freemanfang
> Blog: http://freemanfang.blogspot.com
>
>
>
>
>
>
>
>
>
>