You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by Owain McGuire <ow...@integration.technology> on 2016/09/16 11:19:26 UTC
org.osgi.service.blueprint.container.ComponentDefinitionException: Unable
to validate xml
Hi,
I have a simple wire-tap root and I am unit testing it using
CamelBlueprintTestSupport. I can run the test and it passes but in the log I
get:
2016-09-15 11:10:40,542 [int Extender: 2] ERROR BlueprintContainerImpl
\- Unable to start blueprint container for bundle i4ip-order/1.0.0.SNAPSHOT
org.osgi.service.blueprint.container.ComponentDefinitionException: Unable to
validate xml
at org.apache.aries.blueprint.parser.Parser.validate(Parser.java:317)[org.apac
he.aries.blueprint.core-1.4.4.jar:1.4.4]
at org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(Blueprint
ContainerImpl.java:321)[org.apache.aries.blueprint.core-1.4.4.jar:1.4.4]
at org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintCo
ntainerImpl.java:269)[org.apache.aries.blueprint.core-1.4.4.jar:1.4.4]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)[:1.
8.0_77]
at java.util.concurrent.FutureTask.run(FutureTask.java:266)[:1.8.0_77]
at org.apache.aries.blueprint.container.ExecutorServiceWrapper.run(ExecutorSer
viceWrapper.java:106)[org.apache.aries.blueprint.core-1.4.4.jar:1.4.4]
at org.apache.aries.blueprint.utils.threading.impl.DiscardableRunnable.run(Dis
cardableRunnable.java:48)[org.apache.aries.blueprint.core-1.4.4.jar:1.4.4]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)[:1.
8.0_77]
at java.util.concurrent.FutureTask.run(FutureTask.java:266)[:1.8.0_77]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access
$201(ScheduledThreadPoolExecutor.java:180)[:1.8.0_77]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Sc
heduledThreadPoolExecutor.java:293)[:1.8.0_77]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1
142)[:1.8.0_77]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:
617)[:1.8.0_77]
at java.lang.Thread.run(Thread.java:745)[:1.8.0_77]
Full log here:
https://gist.github.com/owain68/ea09215d7120dd8dc616e237a158a0f8
I cannot for the life of me see what the problem is. The route runs, the test
passes. Is it some sort of timing issue on starting the container, route or
context.
Any ideas where I should start looking for some more information?
Thanks.
O.
Re: org.osgi.service.blueprint.container.ComponentDefinitionException:
Unable to validate xml
Posted by Brad Johnson <br...@mediadriver.com>.
I have to wonder if this is related to the problem you're seeing with the
CBTS using weaving. It just popped up. Since I've never used that
mechanism I don't know. I usually just add my test endpoint definitions in
the test-blueprint-proerties.xml and then have a different default and cfg
production.
http://camel.465427.n5.nabble.com/weaveAddFirst-doesn-t-work-correctly-with-route-level-onException-td5787900.html
On Wed, Sep 21, 2016 at 4:30 AM, owain <ow...@integration.technology> wrote:
> Brad,
>
>
>
> Thanks I will give it a go.
>
>
>
> O.
>
> 
>
>
> On Sep 21 2016, at 12:01 am, Ranx [via Camel] <ml-
> node+s465427n5787793h37@n5.nabble.com> wrote:
>
> > One part of this that's been bothering mainly due to my ignorance of not
> having used in my testing is the adviceWith. And the weaveById. Route
> definitions throw the generic big E exception. I wonder if you'd see
> anyting in there if you did something like this. At least that could
> identify whether there was a problem there or not. By the way I'm
> freehanding my try/catches there so the may not be aligned correctly.
>
> @Test
> public void testMessageReceived() throws Exception {
> try{
>
> context.getRouteDefinition("i4ip-order-publish-route").adviceWith(context,
> new AdviceWithRouteBuilder() {
> @Override
> public void configure() throws Exception {
> *try{*
> replaceFromWith("direct:in");
> weaveById("publishedMessage").after().to("mock:increment");
> *} catch(Exception e) {*
> *System.out.println("We threw an exception in the weaving".*
> * }*
> *} catch(Excepion e)*
> *System.out.println("We caught an error in the route builder."*
> *}*
> });
>
> On Tue, Sep 20, 2016 at 12:15 PM, Brad Johnson <[[hidden
> email]](/user/SendEma
> il.jtp?type=node&node=5787793&i=0&r=bWwtbm9kZStzNDY1NDI3bjU3ODc3OT
> NoMzdAbjUubm
> FiYmxlLmNvbQ==)
> > wrote:
>
> >
>
> >
> > Too bootstrap a route from the Java DSL you only need to do something
> like
> > this:
> >
> > <camelContext xmlns="[http://camel.apache.org/schema/blueprint](http://
> camel
> .apache.org/schema/blueprint&r=bWwtbm9kZStzNDY1NDI3bjU3ODc3OT
> NoMzdAbjUubmFiYmx
> lLmNvbQ==)">
> >
> > <package>my.routes.internal</package>
> >
> > </camelContext>
> >
> > And in the my.routes.internal package (or whatever you want to call it)
> you
> would have route builder. You could put mock:out instead of direct:out.
> You'll still use blueprint to export or import OSGi services if you are
> using
> them but that's a trivial matter and I wouldn't worry about it just yet.
> While
> those routes are hard coded in here you'll later replace them with
> substitution variable names that you can change from the properties. Use
> the
> default properties first and then you can override them in you cfg file for
> production.
> >
> > public class ARouteBuilder extends RouteBuilder {
> >
> > public void configure() {
> >
> > from("direct:in")
> > .log("${body}")
> > .to("direct:out");
> >
> > }
> >
> > }
> >
> > Also, I'm not sure how IDEA works but I'm sure there's something
> > equivalent to what one would do in Eclipse to start a project with a
> Maven
> > archetype. Just type in:
> >
> > camel-archetypes-
> >
> > and it should give you a list of sample archetypes to use to start a
> > project. Also, since you are using Fuse there's a selection of projects
> > under the "quickstarts" directory in there.
> >
> > Brad
> >
> >
> >
> >
> > On Tue, Sep 20, 2016 at 6:27 AM, owain <[[hidden
> email]](/user/SendEmail.jtp
> ?type=node&node=5787793&i=1&r=bWwtbm9kZStzNDY1NDI3bjU3ODc3OT
> NoMzdAbjUubmFiYmxl
> LmNvbQ==)>
> > wrote:
> >
> >> Brad,
> >>
> >> I am using <camel-version>2.15.6</camel-version> since this is the
> >> closest
> >> to Fuse-6.2.1. I have just tried the test with CBTS 2.17.0. Is there a
> >> higher version?
> >>
> >> I add mock:increment (now refactored to mock:out) and replace the "from"
> >> with direct:in in.
> >>
> >>
> >> context.getRouteDefinition("i4ip-order-publish-route").advic
> >> eWith(context,
> >> new AdviceWithRouteBuilder() {
> >> @Override
> >> public void configure() throws Exception {
> >> replaceFromWith("direct:in");
> >> weaveById("publishedMessage").after().to("mock:out");
> >> }
> >> });
> >>
> >> Also I am drawing the same conclusion about the XML only approach.
> Could
> >> you kind enough to post and example to how to bootstrap the Java DSL
> from
> >> the Blueprint XML.
> >>
> >> Thanks for your help. I will try putting it in a new project and see if
> >> that
> >> was the problem. In a single xml file.
> >>
> >> O.
> >>
> >>
> >>
> >> \--
> >> View this message in context: [http://camel.465427.n5.nabble](
> http://camel.
> 465427.n5.nabble&r=bWwtbm9kZStzNDY1NDI3bjU3ODc3OT
> NoMzdAbjUubmFiYmxlLmNvbQ==).
> >> com/org-osgi-service-blueprint-container-ComponentDefinition
> >> Exception-Unable-to-validate-xml-tp5787642p5787758.html
> >> Sent from the Camel - Users mailing list archive at Nabble.com.
> >>
> >
> >
>
> >
>
> >
>
>
> >
>
> > * * *
>
> >
>
> > If you reply to this email, your message will be added to the discussion
> below:
>
> >
>
> > [http://camel.465427.n5.nabble.com/org-osgi-service-blueprint-container-
> ComponentDefinitionException-Unable-to-validate-xml-
> tp5787642p5787793.html](http://camel.465427.n5.nabble.com/
> org-osgi-service-
> blueprint-container-ComponentDefinitionException-
> Unable-to-validate-xml-tp5787
> 642p5787793.html&r=bWwtbm9kZStzNDY1NDI3bjU3ODc3OT
> NoMzdAbjUubmFiYmxlLmNvbQ==)
>
> >
>
> > To unsubscribe from
> org.osgi.service.blueprint.container.ComponentDefinitionException: Unable
> to
> validate xml, [click here](http://camel.465427.n5.
> nabble.com/template/NamlServ
> let.jtp?macro=unsubscribe_by_code&node=5787642&code=
> b3dhaW5AaW50ZWdyYXRpb24udG
> VjaG5vbG9neXw1Nzg3NjQyfC0xMjIxNzE3NTgw&r=bWwtbm9kZStzNDY1NDI3bjU3ODc3OT
> NoMzdAb
> jUubmFiYmxlLmNvbQ==).
> [NAML](http://camel.465427.n5.nabble.com/template/
> NamlServlet.jtp?macro=macro_
> viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces
> .BasicNamespace-nabble.view.web.template.NabbleNamespace-
> nabble.view.web.templ
> ate.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-
> instant_emails%21nabble%3Aemail.naml-send_instant_
> email%21nabble%3Aemail.naml&
> r=bWwtbm9kZStzNDY1NDI3bjU3ODc3OTNoMzdAbjUubmFiYmxlLmNvbQ==)
>
>
>
>
>
> --
> View this message in context: http://camel.465427.n5.nabble.
> com/org-osgi-service-blueprint-container-ComponentDefinitionException-
> Unable-to-validate-xml-tp5787642p5787865.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
Re:
org.osgi.service.blueprint.container.ComponentDefinitionException: Unable
to validate xml
Posted by owain <ow...@integration.technology>.
Brad,
Thanks I will give it a go.
O.
On Sep 21 2016, at 12:01 am, Ranx [via Camel] <ml-
node+s465427n5787793h37@n5.nabble.com> wrote:
> One part of this that's been bothering mainly due to my ignorance of not
having used in my testing is the adviceWith. And the weaveById. Route
definitions throw the generic big E exception. I wonder if you'd see
anyting in there if you did something like this. At least that could
identify whether there was a problem there or not. By the way I'm
freehanding my try/catches there so the may not be aligned correctly.
@Test
public void testMessageReceived() throws Exception {
try{
context.getRouteDefinition("i4ip-order-publish-route").adviceWith(context,
new AdviceWithRouteBuilder() {
@Override
public void configure() throws Exception {
*try{*
replaceFromWith("direct:in");
weaveById("publishedMessage").after().to("mock:increment");
*} catch(Exception e) {*
*System.out.println("We threw an exception in the weaving".*
* }*
*} catch(Excepion e)*
*System.out.println("We caught an error in the route builder."*
*}*
});
On Tue, Sep 20, 2016 at 12:15 PM, Brad Johnson <[[hidden email]](/user/SendEma
il.jtp?type=node&node=5787793&i=0&r=bWwtbm9kZStzNDY1NDI3bjU3ODc3OTNoMzdAbjUubm
FiYmxlLmNvbQ==)
> wrote:
>
>
> Too bootstrap a route from the Java DSL you only need to do something like
> this:
>
> <camelContext xmlns="[http://camel.apache.org/schema/blueprint](http://camel
.apache.org/schema/blueprint&r=bWwtbm9kZStzNDY1NDI3bjU3ODc3OTNoMzdAbjUubmFiYmx
lLmNvbQ==)">
>
> <package>my.routes.internal</package>
>
> </camelContext>
>
> And in the my.routes.internal package (or whatever you want to call it) you
would have route builder. You could put mock:out instead of direct:out.
You'll still use blueprint to export or import OSGi services if you are using
them but that's a trivial matter and I wouldn't worry about it just yet. While
those routes are hard coded in here you'll later replace them with
substitution variable names that you can change from the properties. Use the
default properties first and then you can override them in you cfg file for
production.
>
> public class ARouteBuilder extends RouteBuilder {
>
> public void configure() {
>
> from("direct:in")
> .log("${body}")
> .to("direct:out");
>
> }
>
> }
>
> Also, I'm not sure how IDEA works but I'm sure there's something
> equivalent to what one would do in Eclipse to start a project with a Maven
> archetype. Just type in:
>
> camel-archetypes-
>
> and it should give you a list of sample archetypes to use to start a
> project. Also, since you are using Fuse there's a selection of projects
> under the "quickstarts" directory in there.
>
> Brad
>
>
>
>
> On Tue, Sep 20, 2016 at 6:27 AM, owain <[[hidden email]](/user/SendEmail.jtp
?type=node&node=5787793&i=1&r=bWwtbm9kZStzNDY1NDI3bjU3ODc3OTNoMzdAbjUubmFiYmxl
LmNvbQ==)>
> wrote:
>
>> Brad,
>>
>> I am using <camel-version>2.15.6</camel-version> since this is the
>> closest
>> to Fuse-6.2.1. I have just tried the test with CBTS 2.17.0. Is there a
>> higher version?
>>
>> I add mock:increment (now refactored to mock:out) and replace the "from"
>> with direct:in in.
>>
>>
>> context.getRouteDefinition("i4ip-order-publish-route").advic
>> eWith(context,
>> new AdviceWithRouteBuilder() {
>> @Override
>> public void configure() throws Exception {
>> replaceFromWith("direct:in");
>> weaveById("publishedMessage").after().to("mock:out");
>> }
>> });
>>
>> Also I am drawing the same conclusion about the XML only approach. Could
>> you kind enough to post and example to how to bootstrap the Java DSL from
>> the Blueprint XML.
>>
>> Thanks for your help. I will try putting it in a new project and see if
>> that
>> was the problem. In a single xml file.
>>
>> O.
>>
>>
>>
>> \--
>> View this message in context: [http://camel.465427.n5.nabble](http://camel.
465427.n5.nabble&r=bWwtbm9kZStzNDY1NDI3bjU3ODc3OTNoMzdAbjUubmFiYmxlLmNvbQ==).
>> com/org-osgi-service-blueprint-container-ComponentDefinition
>> Exception-Unable-to-validate-xml-tp5787642p5787758.html
>> Sent from the Camel - Users mailing list archive at Nabble.com.
>>
>
>
>
>
>
> * * *
>
> If you reply to this email, your message will be added to the discussion
below:
>
> [http://camel.465427.n5.nabble.com/org-osgi-service-blueprint-container-
ComponentDefinitionException-Unable-to-validate-xml-
tp5787642p5787793.html](http://camel.465427.n5.nabble.com/org-osgi-service-
blueprint-container-ComponentDefinitionException-Unable-to-validate-xml-tp5787
642p5787793.html&r=bWwtbm9kZStzNDY1NDI3bjU3ODc3OTNoMzdAbjUubmFiYmxlLmNvbQ==)
>
> To unsubscribe from
org.osgi.service.blueprint.container.ComponentDefinitionException: Unable to
validate xml, [click here](http://camel.465427.n5.nabble.com/template/NamlServ
let.jtp?macro=unsubscribe_by_code&node=5787642&code=b3dhaW5AaW50ZWdyYXRpb24udG
VjaG5vbG9neXw1Nzg3NjQyfC0xMjIxNzE3NTgw&r=bWwtbm9kZStzNDY1NDI3bjU3ODc3OTNoMzdAb
jUubmFiYmxlLmNvbQ==).
[NAML](http://camel.465427.n5.nabble.com/template/NamlServlet.jtp?macro=macro_
viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces
.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.templ
ate.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-
instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml&
r=bWwtbm9kZStzNDY1NDI3bjU3ODc3OTNoMzdAbjUubmFiYmxlLmNvbQ==)
--
View this message in context: http://camel.465427.n5.nabble.com/org-osgi-service-blueprint-container-ComponentDefinitionException-Unable-to-validate-xml-tp5787642p5787865.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: org.osgi.service.blueprint.container.ComponentDefinitionException:
Unable to validate xml
Posted by Brad Johnson <br...@mediadriver.com>.
One part of this that's been bothering mainly due to my ignorance of not
having used in my testing is the adviceWith. And the weaveById. Route
definitions throw the generic big E exception. I wonder if you'd see
anyting in there if you did something like this. At least that could
identify whether there was a problem there or not. By the way I'm
freehanding my try/catches there so the may not be aligned correctly.
@Test
public void testMessageReceived() throws Exception {
try{
context.getRouteDefinition("i4ip-order-publish-route").adviceWith(context,
new AdviceWithRouteBuilder() {
@Override
public void configure() throws Exception {
*try{*
replaceFromWith("direct:in");
weaveById("publishedMessage").after().to("mock:increment");
*} catch(Exception e) {*
*System.out.println("We threw an exception in the weaving".*
* }*
*} catch(Excepion e)*
*System.out.println("We caught an error in the route builder."*
*}*
});
On Tue, Sep 20, 2016 at 12:15 PM, Brad Johnson <brad.johnson@mediadriver.com
> wrote:
> Too bootstrap a route from the Java DSL you only need to do something like
> this:
>
> <camelContext xmlns="http://camel.apache.org/schema/blueprint">
>
> <package>my.routes.internal</package>
>
> </camelContext>
>
> And in the my.routes.internal package (or whatever you want to call it) you would have route builder. You could put mock:out instead of direct:out. You'll still use blueprint to export or import OSGi services if you are using them but that's a trivial matter and I wouldn't worry about it just yet. While those routes are hard coded in here you'll later replace them with substitution variable names that you can change from the properties. Use the default properties first and then you can override them in you cfg file for production.
>
> public class ARouteBuilder extends RouteBuilder {
>
> public void configure() {
>
> from("direct:in")
> .log("${body}")
> .to("direct:out");
>
> }
>
> }
>
> Also, I'm not sure how IDEA works but I'm sure there's something
> equivalent to what one would do in Eclipse to start a project with a Maven
> archetype. Just type in:
>
> camel-archetypes-
>
> and it should give you a list of sample archetypes to use to start a
> project. Also, since you are using Fuse there's a selection of projects
> under the "quickstarts" directory in there.
>
> Brad
>
>
>
>
> On Tue, Sep 20, 2016 at 6:27 AM, owain <ow...@integration.technology>
> wrote:
>
>> Brad,
>>
>> I am using <camel-version>2.15.6</camel-version> since this is the
>> closest
>> to Fuse-6.2.1. I have just tried the test with CBTS 2.17.0. Is there a
>> higher version?
>>
>> I add mock:increment (now refactored to mock:out) and replace the "from"
>> with direct:in in.
>>
>>
>> context.getRouteDefinition("i4ip-order-publish-route").advic
>> eWith(context,
>> new AdviceWithRouteBuilder() {
>> @Override
>> public void configure() throws Exception {
>> replaceFromWith("direct:in");
>> weaveById("publishedMessage").after().to("mock:out");
>> }
>> });
>>
>> Also I am drawing the same conclusion about the XML only approach. Could
>> you kind enough to post and example to how to bootstrap the Java DSL from
>> the Blueprint XML.
>>
>> Thanks for your help. I will try putting it in a new project and see if
>> that
>> was the problem. In a single xml file.
>>
>> O.
>>
>>
>>
>> --
>> View this message in context: http://camel.465427.n5.nabble.
>> com/org-osgi-service-blueprint-container-ComponentDefinition
>> Exception-Unable-to-validate-xml-tp5787642p5787758.html
>> Sent from the Camel - Users mailing list archive at Nabble.com.
>>
>
>
Re: org.osgi.service.blueprint.container.ComponentDefinitionException:
Unable to validate xml
Posted by Brad Johnson <br...@mediadriver.com>.
Too bootstrap a route from the Java DSL you only need to do something like
this:
<camelContext xmlns="http://camel.apache.org/schema/blueprint">
<package>my.routes.internal</package>
</camelContext>
And in the my.routes.internal package (or whatever you want to call
it) you would have route builder. You could put mock:out instead of
direct:out. You'll still use blueprint to export or import OSGi
services if you are using them but that's a trivial matter and I
wouldn't worry about it just yet. While those routes are hard coded in
here you'll later replace them with substitution variable names that
you can change from the properties. Use the default properties first
and then you can override them in you cfg file for production.
public class ARouteBuilder extends RouteBuilder {
public void configure() {
from("direct:in")
.log("${body}")
.to("direct:out");
}
}
Also, I'm not sure how IDEA works but I'm sure there's something equivalent
to what one would do in Eclipse to start a project with a Maven archetype.
Just type in:
camel-archetypes-
and it should give you a list of sample archetypes to use to start a
project. Also, since you are using Fuse there's a selection of projects
under the "quickstarts" directory in there.
Brad
On Tue, Sep 20, 2016 at 6:27 AM, owain <ow...@integration.technology> wrote:
> Brad,
>
> I am using <camel-version>2.15.6</camel-version> since this is the closest
> to Fuse-6.2.1. I have just tried the test with CBTS 2.17.0. Is there a
> higher version?
>
> I add mock:increment (now refactored to mock:out) and replace the "from"
> with direct:in in.
>
>
> context.getRouteDefinition("i4ip-order-publish-route").adviceWith(context,
> new AdviceWithRouteBuilder() {
> @Override
> public void configure() throws Exception {
> replaceFromWith("direct:in");
> weaveById("publishedMessage").after().to("mock:out");
> }
> });
>
> Also I am drawing the same conclusion about the XML only approach. Could
> you kind enough to post and example to how to bootstrap the Java DSL from
> the Blueprint XML.
>
> Thanks for your help. I will try putting it in a new project and see if
> that
> was the problem. In a single xml file.
>
> O.
>
>
>
> --
> View this message in context: http://camel.465427.n5.nabble.
> com/org-osgi-service-blueprint-container-ComponentDefinitionException-
> Unable-to-validate-xml-tp5787642p5787758.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
Re:
org.osgi.service.blueprint.container.ComponentDefinitionException: Unable
to validate xml
Posted by owain <ow...@integration.technology>.
Brad,
I am using <camel-version>2.15.6</camel-version> since this is the closest
to Fuse-6.2.1. I have just tried the test with CBTS 2.17.0. Is there a
higher version?
I add mock:increment (now refactored to mock:out) and replace the "from"
with direct:in in.
context.getRouteDefinition("i4ip-order-publish-route").adviceWith(context,
new AdviceWithRouteBuilder() {
@Override
public void configure() throws Exception {
replaceFromWith("direct:in");
weaveById("publishedMessage").after().to("mock:out");
}
});
Also I am drawing the same conclusion about the XML only approach. Could
you kind enough to post and example to how to bootstrap the Java DSL from
the Blueprint XML.
Thanks for your help. I will try putting it in a new project and see if that
was the problem. In a single xml file.
O.
--
View this message in context: http://camel.465427.n5.nabble.com/org-osgi-service-blueprint-container-ComponentDefinitionException-Unable-to-validate-xml-tp5787642p5787758.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: org.osgi.service.blueprint.container.ComponentDefinitionException:
Unable to validate xml
Posted by Brad Johnson <br...@mediadriver.com>.
PS I've likely missed something in that XML sample because I don't see a
direct:in nor the increment route. It's more just how I end up backing out
until I can figure out the source of my problems - other than visiting a
shrink.
On Mon, Sep 19, 2016 at 1:21 PM, Brad Johnson <br...@mediadriver.com>
wrote:
> That's one of the downsides to using the blueprint XML. I used to use it
> exclusively but have started the change to using the Java DSL and route
> builders and using blueprint just to bootstrap it. That keeps the
> blueprint headers very clean then - just blueprint itself and the cm for
> properties loading.
>
> At least by going to the straight XML you've eliminated the properties
> loading as the source of the problem. Irritating I know. All I can say is
> been there, done that. I guess my next step if I were debugging this is to
> put all the XML in a single file and load it and see if you get the same
> problem.
>
> By the way, you may have already mentioned this but what version of CBTS
> are you using. I've started using the 2.17 version even with older
> versions of Camel. It is backwardly compatible and isn't compiled or used
> as part of the installation. But in earlier versions I found myself
> debugging the test and test framework itself as much as debugging the
> code. Earlier versions had race conditions (which you don't seem to be
> getting) and some other issues. Each subsequent version just got better and
> more stable.
>
> If you are just putting CBTS your POM with a test scope you should be able
> to run the 2.17 version and see if that helps. Perhaps not but at least
> you can eliminate that from the equation. Unfortunately I use Eclipse so
> don't know much about how IDEA works. Not that that should make much of a
> difference.
>
> Unless you have some old blueprint in your bundles in the headers I don't
> see why you would be running into that problem. I don't recall but what
> version of Camel did you say you are using? Then in your test you
> shouldn't need to load properties, only load the one blueprint file.
>
> No, you shouldn't have to do that but it if that doesn't work at least
> you'd there's something else wrong. When I get where I'm backed against
> the wall I'll commonly create dummy project using one of the archetypes and
> see if there's something fundamentally different about it.
>
> Wish I could be of more help.
>
> Brad
>
> <blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"
> xmlns:cm="http://aries.apache.org/blueprint/xmlns/
> blueprint-cm/v1.1.0"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="
> http://www.osgi.org/xmlns/blueprint/v1.0.0
> http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd
> http://aries.apache.org/blueprint/xmlns/blueprint-cm/v1.1.0
> http://aries.apache.org/schemas/blueprint-cm/blueprint-cm-1.1.0.xsd
> ">
> //You'd have add defaults for any properties required.
> <cm:property-placeholder persistent-id="technology.integration.i4ip.order"
> update-strategy="reload">
> <cm:default-properties>
> <cm:property name="foo" value="manchu"></cm:property>
> </cm:default-properties>
> </cm:property-placeholder>
>
> <camelContext id="i4ip-order-publish-test-context" xmlns="
> http://camel.apache.org/schema/blueprint">
> <route id="i4ip-order-publish-route">
> <from uri="direct:i4ip-order-tap"/>
>
> <log loggingLevel="INFO" message="publishedMessage:${body}"
> id="publishedMessage"/>
> </route>
> </camelContext>
>
>
> </blueprint>
>
>
> @Override
> protected String getBlueprintDescriptor() {
>
> return "OSGI-INF/blueprint/i4ip-order-publish-route.xml";
> }
>
> ///I haven't used isUsedAdviceWith in my tests so will refrain from any
> comment.
> @Override
> public boolean isUseAdviceWith() {
> return true;
> }
>
> @Test
> public void testMessageReceived() throws Exception {
>
> context.getRouteDefinition("i4ip-order-publish-route").adviceWith(context,
> new AdviceWithRouteBuilder() {
> @Override
> public void configure() throws Exception {
> replaceFromWith("direct:in");
> weaveById("publishedMessage").after().to("mock:increment");
> }
> });
>
> final String BODY = "Hello";
> MockEndpoint mockOut = getMockEndpoint("mock:increment");
> mockOut.setExpectedMessageCount(1);
>
> context.start();
> template.sendBody("direct:in", BODY);
>
> assertMockEndpointsSatisfied();
> assertEquals(BODY, mockOut.getExchanges().get(0).getIn().getBody());
>
> }
>
> On Mon, Sep 19, 2016 at 5:31 AM, owain <ow...@integration.technology>
> wrote:
>
>> Brad,
>>
>> Thank you for your response. Yes the default property in
>> cm:default-properties is over-ridden in the .cfg loaded in
>> loadConfigAdminConfigurationFile(). I was then logging {{foo}} in the
>> route.
>>
>> All of this appears to be working correctly.
>>
>> I took your advice and ripped out everything to do with properties and I
>> still get an "unable to validate xml" and test still passing.
>>
>> It is a bit infuriating since the route is now so simple and one would
>> have
>> hoped the xml validation would have chucked out some more info on the
>> error.
>>
>> The xml validates correctly in IntelliJ IDEA.
>>
>> Progress of some sort: https://issues.apache.org/jira/browse/CAMEL-9923
>> Not sure what I need to do or just leave it. I am running the test in
>> IDEA
>> and not Karaf/Fuse.
>>
>>
>> But even with all the properties ripped out I am still getting this
>> problem.
>> Sounds like some old XML is lurking somewhere!
>>
>>
>>
>>
>>
>> --
>> View this message in context: http://camel.465427.n5.nabble.
>> com/org-osgi-service-blueprint-container-ComponentDefinition
>> Exception-Unable-to-validate-xml-tp5787642p5787724.html
>> Sent from the Camel - Users mailing list archive at Nabble.com.
>>
>
>
Re: org.osgi.service.blueprint.container.ComponentDefinitionException:
Unable to validate xml
Posted by Brad Johnson <br...@mediadriver.com>.
That's one of the downsides to using the blueprint XML. I used to use it
exclusively but have started the change to using the Java DSL and route
builders and using blueprint just to bootstrap it. That keeps the
blueprint headers very clean then - just blueprint itself and the cm for
properties loading.
At least by going to the straight XML you've eliminated the properties
loading as the source of the problem. Irritating I know. All I can say is
been there, done that. I guess my next step if I were debugging this is to
put all the XML in a single file and load it and see if you get the same
problem.
By the way, you may have already mentioned this but what version of CBTS
are you using. I've started using the 2.17 version even with older
versions of Camel. It is backwardly compatible and isn't compiled or used
as part of the installation. But in earlier versions I found myself
debugging the test and test framework itself as much as debugging the
code. Earlier versions had race conditions (which you don't seem to be
getting) and some other issues. Each subsequent version just got better and
more stable.
If you are just putting CBTS your POM with a test scope you should be able
to run the 2.17 version and see if that helps. Perhaps not but at least
you can eliminate that from the equation. Unfortunately I use Eclipse so
don't know much about how IDEA works. Not that that should make much of a
difference.
Unless you have some old blueprint in your bundles in the headers I don't
see why you would be running into that problem. I don't recall but what
version of Camel did you say you are using? Then in your test you
shouldn't need to load properties, only load the one blueprint file.
No, you shouldn't have to do that but it if that doesn't work at least
you'd there's something else wrong. When I get where I'm backed against
the wall I'll commonly create dummy project using one of the archetypes and
see if there's something fundamentally different about it.
Wish I could be of more help.
Brad
<blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"
xmlns:cm="
http://aries.apache.org/blueprint/xmlns/blueprint-cm/v1.1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="
http://www.osgi.org/xmlns/blueprint/v1.0.0
http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd
http://aries.apache.org/blueprint/xmlns/blueprint-cm/v1.1.0
http://aries.apache.org/schemas/blueprint-cm/blueprint-cm-1.1.0.xsd
">
//You'd have add defaults for any properties required.
<cm:property-placeholder
persistent-id="technology.integration.i4ip.order" update-strategy="reload">
<cm:default-properties>
<cm:property name="foo" value="manchu"></cm:property>
</cm:default-properties>
</cm:property-placeholder>
<camelContext id="i4ip-order-publish-test-context" xmlns="
http://camel.apache.org/schema/blueprint">
<route id="i4ip-order-publish-route">
<from uri="direct:i4ip-order-tap"/>
<log loggingLevel="INFO" message="publishedMessage:${body}"
id="publishedMessage"/>
</route>
</camelContext>
</blueprint>
@Override
protected String getBlueprintDescriptor() {
return "OSGI-INF/blueprint/i4ip-order-publish-route.xml";
}
///I haven't used isUsedAdviceWith in my tests so will refrain from any
comment.
@Override
public boolean isUseAdviceWith() {
return true;
}
@Test
public void testMessageReceived() throws Exception {
context.getRouteDefinition("i4ip-order-publish-route").adviceWith(context,
new AdviceWithRouteBuilder() {
@Override
public void configure() throws Exception {
replaceFromWith("direct:in");
weaveById("publishedMessage").after().to("mock:increment");
}
});
final String BODY = "Hello";
MockEndpoint mockOut = getMockEndpoint("mock:increment");
mockOut.setExpectedMessageCount(1);
context.start();
template.sendBody("direct:in", BODY);
assertMockEndpointsSatisfied();
assertEquals(BODY, mockOut.getExchanges().get(0).getIn().getBody());
}
On Mon, Sep 19, 2016 at 5:31 AM, owain <ow...@integration.technology> wrote:
> Brad,
>
> Thank you for your response. Yes the default property in
> cm:default-properties is over-ridden in the .cfg loaded in
> loadConfigAdminConfigurationFile(). I was then logging {{foo}} in the
> route.
>
> All of this appears to be working correctly.
>
> I took your advice and ripped out everything to do with properties and I
> still get an "unable to validate xml" and test still passing.
>
> It is a bit infuriating since the route is now so simple and one would have
> hoped the xml validation would have chucked out some more info on the
> error.
>
> The xml validates correctly in IntelliJ IDEA.
>
> Progress of some sort: https://issues.apache.org/jira/browse/CAMEL-9923
> Not sure what I need to do or just leave it. I am running the test in IDEA
> and not Karaf/Fuse.
>
>
> But even with all the properties ripped out I am still getting this
> problem.
> Sounds like some old XML is lurking somewhere!
>
>
>
>
>
> --
> View this message in context: http://camel.465427.n5.nabble.
> com/org-osgi-service-blueprint-container-ComponentDefinitionException-
> Unable-to-validate-xml-tp5787642p5787724.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
Re:
org.osgi.service.blueprint.container.ComponentDefinitionException: Unable
to validate xml
Posted by owain <ow...@integration.technology>.
Brad,
Thank you for your response. Yes the default property in
cm:default-properties is over-ridden in the .cfg loaded in
loadConfigAdminConfigurationFile(). I was then logging {{foo}} in the
route.
All of this appears to be working correctly.
I took your advice and ripped out everything to do with properties and I
still get an "unable to validate xml" and test still passing.
It is a bit infuriating since the route is now so simple and one would have
hoped the xml validation would have chucked out some more info on the error.
The xml validates correctly in IntelliJ IDEA.
Progress of some sort: https://issues.apache.org/jira/browse/CAMEL-9923
Not sure what I need to do or just leave it. I am running the test in IDEA
and not Karaf/Fuse.
But even with all the properties ripped out I am still getting this problem.
Sounds like some old XML is lurking somewhere!
--
View this message in context: http://camel.465427.n5.nabble.com/org-osgi-service-blueprint-container-ComponentDefinitionException-Unable-to-validate-xml-tp5787642p5787724.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: org.osgi.service.blueprint.container.ComponentDefinitionException:
Unable to validate xml
Posted by Brad Johnson <br...@mediadriver.com>.
By the way, if your XML for the properties has default values for all the
required properties then even an error in loading the properties file will
mean the test will run fine (which is what you seem to be seeing.) One way
to check that is to temporarily comment out one of the default properties
in the XML required for your test to run. If it then throws the same
exception your seeing and another one about not finding the property that
you commented out you'll know that your properties aren't loading correctly
or getting set on the test container (for whatever reason.)
You may have already done this but I'd take an incremental approach. Try
commenting out the loading of the properties loading and make sure you have
all the default properties necessary. Then run your test with just the XML
and make sure you don't get a validation error in the loading of the XML.
If you don't see that error you'll know that the problem is related to the
properties file. But the error specifically says it is associated with the
XML. So personally I'd make sure all the XML is ironed out first. Then
attempt the properties.
If you're just trying to verify the override on the properties I'm fairly
certain that the mechanism used by CBTS is not the same as the one used
karaf/felix.
Brad
On Fri, Sep 16, 2016 at 1:00 PM, Brad Johnson <br...@mediadriver.com>
wrote:
> Yeah those kinds of errors are an irritation. One of the downsides to
> Blueprint and I think OSGi in general is the somewhat obscure error
> messages.
>
> I haven't written my CBTS in quite the way you have it so there may be
> things I'm missing. But if you have the properties for testing already
> defined in the i4ip-order-publish-test-properties.xml is it necessary to
> use the properties file and cfg? Or are you simply trying to verify that
> the properties override works? Also, I noticed that the properties file has
> the full path name of src/test/resources which for the XML at least is not
> required. I'm not sure if it is necessary for loading properties. You
> might want to put in a System.out.println or log statement in your setup to
> see if it is coming in successfully. I'm also unsure of how your
> properties are getting associated with your contexts. I suspect what you
> want instead of in the @Befor setup is:
>
> @Override
> protected Properties useOverridePropertiesWithPropertiesComponent() {
> Properties props = new Properties();
> props.put("demo.sync", Boolean.TRUE.toString());
> return props;
> }
>
> As far as I know you could then load your cfg file in at that point.
>
> Have you tried running it in a full OSGi implementation? CBTS uses PojoSR
> which usually works fine but has some limitations. It can't run multiple
> contexts for example (although that doesn't appear to be the problem.)
>
>
> Brad
>
> On Fri, Sep 16, 2016 at 6:19 AM, Owain McGuire <
> owain@integration.technology> wrote:
>
>> Hi,
>>
>> I have a simple wire-tap root and I am unit testing it using
>> CamelBlueprintTestSupport. I can run the test and it passes but in the log
>> I get:
>>
>> 2016-09-15 11:10:40,542 [int Extender: 2] ERROR BlueprintContainerImpl
>> - Unable to start blueprint container for bundle
>> i4ip-order/1.0.0.SNAPSHOT
>> org.osgi.service.blueprint.container.ComponentDefinitionException:
>> Unable to validate xml
>> at org.apache.aries.blueprint.parser.Parser.validate(Parser.jav
>> a:317)[org.apache.aries.blueprint.core-1.4.4.jar:1.4.4]
>> at org.apache.aries.blueprint.container.BlueprintContainerImpl.
>> doRun(BlueprintContainerImpl.java:321)[org.apache.aries.blu
>> eprint.core-1.4.4.jar:1.4.4]
>> at org.apache.aries.blueprint.container.BlueprintContainerImpl.
>> run(BlueprintContainerImpl.java:269)[org.apache.aries.blu
>> eprint.core-1.4.4.jar:1.4.4]
>> at java.util.concurrent.Executors$RunnableAdapter.call(
>> Executors.java:511)[:1.8.0_77]
>> at java.util.concurrent.FutureTask.run(FutureTask.java:266)[:1.8.0_77]
>> at org.apache.aries.blueprint.container.ExecutorServiceWrapper.
>> run(ExecutorServiceWrapper.java:106)[org.apache.aries.blu
>> eprint.core-1.4.4.jar:1.4.4]
>> at org.apache.aries.blueprint.utils.threading.impl.DiscardableR
>> unnable.run(DiscardableRunnable.java:48)[org.apache.aries.
>> blueprint.core-1.4.4.jar:1.4.4]
>> at java.util.concurrent.Executors$RunnableAdapter.call(
>> Executors.java:511)[:1.8.0_77]
>> at java.util.concurrent.FutureTask.run(FutureTask.java:266)[:1.8.0_77]
>> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFu
>> tureTask.access$201(ScheduledThreadPoolExecutor.java:180)[:1.8.0_77]
>> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFu
>> tureTask.run(ScheduledThreadPoolExecutor.java:293)[:1.8.0_77]
>> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPool
>> Executor.java:1142)[:1.8.0_77]
>> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoo
>> lExecutor.java:617)[:1.8.0_77]
>> at java.lang.Thread.run(Thread.java:745)[:1.8.0_77]
>>
>> Full log here: https://gist.github.com/owain68/ea09215d7120dd8dc616e2
>> 37a158a0f8
>>
>> I cannot for the life of me see what the problem is. The route runs, the
>> test passes. Is it some sort of timing issue on starting the container,
>> route or context.
>>
>> Any ideas where I should start looking for some more information?
>>
>> Thanks.
>>
>> O.
>>
>>
>>
>
Re: org.osgi.service.blueprint.container.ComponentDefinitionException:
Unable to validate xml
Posted by Brad Johnson <br...@mediadriver.com>.
Yeah those kinds of errors are an irritation. One of the downsides to
Blueprint and I think OSGi in general is the somewhat obscure error
messages.
I haven't written my CBTS in quite the way you have it so there may be
things I'm missing. But if you have the properties for testing already
defined in the i4ip-order-publish-test-properties.xml is it necessary to
use the properties file and cfg? Or are you simply trying to verify that
the properties override works? Also, I noticed that the properties file has
the full path name of src/test/resources which for the XML at least is not
required. I'm not sure if it is necessary for loading properties. You
might want to put in a System.out.println or log statement in your setup to
see if it is coming in successfully. I'm also unsure of how your
properties are getting associated with your contexts. I suspect what you
want instead of in the @Befor setup is:
@Override
protected Properties useOverridePropertiesWithPropertiesComponent() {
Properties props = new Properties();
props.put("demo.sync", Boolean.TRUE.toString());
return props;
}
As far as I know you could then load your cfg file in at that point.
Have you tried running it in a full OSGi implementation? CBTS uses PojoSR
which usually works fine but has some limitations. It can't run multiple
contexts for example (although that doesn't appear to be the problem.)
Brad
On Fri, Sep 16, 2016 at 6:19 AM, Owain McGuire <owain@integration.technology
> wrote:
> Hi,
>
> I have a simple wire-tap root and I am unit testing it using
> CamelBlueprintTestSupport. I can run the test and it passes but in the log
> I get:
>
> 2016-09-15 11:10:40,542 [int Extender: 2] ERROR BlueprintContainerImpl
> - Unable to start blueprint container for bundle
> i4ip-order/1.0.0.SNAPSHOT
> org.osgi.service.blueprint.container.ComponentDefinitionException: Unable
> to validate xml
> at org.apache.aries.blueprint.parser.Parser.validate(Parser.
> java:317)[org.apache.aries.blueprint.core-1.4.4.jar:1.4.4]
> at org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(
> BlueprintContainerImpl.java:321)[org.apache.aries.
> blueprint.core-1.4.4.jar:1.4.4]
> at org.apache.aries.blueprint.container.BlueprintContainerImpl.run(
> BlueprintContainerImpl.java:269)[org.apache.aries.
> blueprint.core-1.4.4.jar:1.4.4]
> at java.util.concurrent.Executors$RunnableAdapter.
> call(Executors.java:511)[:1.8.0_77]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)[:1.8.0_77]
> at org.apache.aries.blueprint.container.ExecutorServiceWrapper.run(
> ExecutorServiceWrapper.java:106)[org.apache.aries.
> blueprint.core-1.4.4.jar:1.4.4]
> at org.apache.aries.blueprint.utils.threading.impl.
> DiscardableRunnable.run(DiscardableRunnable.java:48)[
> org.apache.aries.blueprint.core-1.4.4.jar:1.4.4]
> at java.util.concurrent.Executors$RunnableAdapter.
> call(Executors.java:511)[:1.8.0_77]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)[:1.8.0_77]
> at java.util.concurrent.ScheduledThreadPoolExecutor$
> ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.
> java:180)[:1.8.0_77]
> at java.util.concurrent.ScheduledThreadPoolExecutor$
> ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)[:1.8.0_77]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(
> ThreadPoolExecutor.java:1142)[:1.8.0_77]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(
> ThreadPoolExecutor.java:617)[:1.8.0_77]
> at java.lang.Thread.run(Thread.java:745)[:1.8.0_77]
>
> Full log here: https://gist.github.com/owain68/
> ea09215d7120dd8dc616e237a158a0f8
>
> I cannot for the life of me see what the problem is. The route runs, the
> test passes. Is it some sort of timing issue on starting the container,
> route or context.
>
> Any ideas where I should start looking for some more information?
>
> Thanks.
>
> O.
>
>
>