You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@camel.apache.org by Christian Müller <ch...@gmail.com> on 2011/11/12 07:02:56 UTC

[DISCUSS] Extract camel-validator from camel-core

Hello all!

With [1], we add the functionality to Camel to validate XML files against
nested schema files with the camel validator component. So far so good...

We couldn't do this in the best possible way without to introduce an
additional dependency to xml-resolver. The current implementation doesn't
have this dependency but requires a lot more work to the user than it
should be. IMO the way to provide the best solution for our users is to
extract the Camel validator component into it's own project. There we can
have a dependency to xml-resolver and we can provide a good default
ResourceResolver implementation.

What do you think?

[1] https://issues.apache.org/jira/browse/CAMEL-4666

Best,
Christian

Re: [DISCUSS] Extract camel-validator from camel-core

Posted by Christian Müller <ch...@gmail.com>.
Hello Dave!

Sorry for the late response. The issue is solved. You can find some unit
test for it in [1] and [2].

[1]
https://svn.apache.org/repos/asf/camel/trunk/camel-core/src/test/java/org/apache/camel/component/validator/ValidatorIncludeRouteTest.java
[2]
https://svn.apache.org/repos/asf/camel/trunk/camel-core/src/test/java/org/apache/camel/component/validator/ValidatorWithResourceResolverRouteTest.java

Best,
Christian

On Thu, Feb 16, 2012 at 4:58 PM, hoyski <ho...@gmail.com> wrote:

> Hello -
>
> Can someone please tell me where this landed and/or point me to
> documentation?
>
> This discussion appears to be at the heart of a problem I'm working
> through.
> My situation is that I have all of my XSDs in one OSGi bundle. I'd like to
> reference an XSD in that bundle from a validator in a Camel route in a
> different bundle.
>
> I'm using Camel 2.8.2. Any help would be greatly appreciated.
>
> Thanks,
> Dave
>
>
> --
> View this message in context:
> http://camel.465427.n5.nabble.com/DISCUSS-Extract-camel-validator-from-camel-core-tp4986357p5489891.html
> Sent from the Camel Development mailing list archive at Nabble.com.
>

Re: [DISCUSS] Extract camel-validator from camel-core

Posted by hoyski <ho...@gmail.com>.
Hello -

Can someone please tell me where this landed and/or point me to
documentation?

This discussion appears to be at the heart of a problem I'm working through.
My situation is that I have all of my XSDs in one OSGi bundle. I'd like to
reference an XSD in that bundle from a validator in a Camel route in a
different bundle. 

I'm using Camel 2.8.2. Any help would be greatly appreciated.

Thanks,
Dave


--
View this message in context: http://camel.465427.n5.nabble.com/DISCUSS-Extract-camel-validator-from-camel-core-tp4986357p5489891.html
Sent from the Camel Development mailing list archive at Nabble.com.

Re: [DISCUSS] Extract camel-validator from camel-core

Posted by Björn Bength <bj...@gmail.com>.
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 <fr...@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"
>> <ch...@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
>
>
>
>
>
>
>
>
>
>

Re: [DISCUSS] Extract camel-validator from camel-core

Posted by Freeman Fang <fr...@gmail.com>.
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"
> <ch...@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










Re: [DISCUSS] Extract camel-validator from camel-core

Posted by Raul Kripalani <ra...@fusesource.com>.
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"
<ch...@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

Re: [DISCUSS] Extract camel-validator from camel-core

Posted by Christian Müller <ch...@gmail.com>.
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

Re: [DISCUSS] Extract camel-validator from camel-core

Posted by Christian Müller <ch...@gmail.com>.
Let's discuss this later by having breakfest together and afterwards we
will share our opinions here...

Sent from a mobile device

Re: [DISCUSS] Extract camel-validator from camel-core

Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi Christian,

it sounds good, but the question is: how to load/look up the XSD in the 
validator component ?

I mean, in Karaf, to validate a feature XML, we use the following code:

         SchemaFactory factory = 
SchemaFactory.newInstance(XMLConstants.W3C_XML_SCHEMA_NS_URI);
         // root element has namespace - we can use schema validation
         Schema schema = factory.newSchema(new 
StreamSource(FeatureValidationUtil.class
 
.getResourceAsStream("/org/apache/karaf/features/karaf-features-1.0.0.xsd")));

So we get the XSD for the bundle class loader. No problem so far.

The question is how the user can provide *efficiently* a XSD from 
outside the bundle.

I will get back to you with some solution that we can provide, which 
should work in both OSGi or non-OSGi worls :)

Regards
JB

On 11/12/2011 07:02 AM, Christian Müller wrote:
> Hello all!
>
> With [1], we add the functionality to Camel to validate XML files against
> nested schema files with the camel validator component. So far so good...
>
> We couldn't do this in the best possible way without to introduce an
> additional dependency to xml-resolver. The current implementation doesn't
> have this dependency but requires a lot more work to the user than it
> should be. IMO the way to provide the best solution for our users is to
> extract the Camel validator component into it's own project. There we can
> have a dependency to xml-resolver and we can provide a good default
> ResourceResolver implementation.
>
> What do you think?
>
> [1] https://issues.apache.org/jira/browse/CAMEL-4666
>
> Best,
> Christian
>

-- 
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: [DISCUSS] Extract camel-validator from camel-core

Posted by Claus Ibsen <cl...@gmail.com>.
Does Apache XML Resolver work with OSGi ?
But seems like a good idea so a +1 from me.


On Sat, Nov 12, 2011 at 7:02 AM, Christian Müller
<ch...@gmail.com> wrote:
> Hello all!
>
> With [1], we add the functionality to Camel to validate XML files against
> nested schema files with the camel validator component. So far so good...
>
> We couldn't do this in the best possible way without to introduce an
> additional dependency to xml-resolver. The current implementation doesn't
> have this dependency but requires a lot more work to the user than it
> should be. IMO the way to provide the best solution for our users is to
> extract the Camel validator component into it's own project. There we can
> have a dependency to xml-resolver and we can provide a good default
> ResourceResolver implementation.
>
> What do you think?
>
> [1] https://issues.apache.org/jira/browse/CAMEL-4666
>
> Best,
> Christian
>



-- 
Claus Ibsen
-----------------
FuseSource
Email: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/