Am 06.12.14 09:18 schrieb "Babak Vahdat" unter <babak.vah...@swissonline.ch>:
>Hi, > >quick update about this thread: > >#1 The upgrade to Pax Exam 4.3 is done now (CAMEL-8111). > >#2 Regarding the failing test BlueprintTracerTest. It¹s now fixed and >enabled however using the Tracer#destinationUri property instead of the >combination of the Tracer#destination property together with the ><endpoint> >XML element inside <camelContext>. Just found a way about how to still make this work properly when using the <endpoint> DSL together with the Tracer#destination property, and committed BlueprintTracerRefTest for this purpose. The bottom line of what I've learned about this is that if you depend on your Camel Context to be published as an OSGi service into the container and you make use of the <endpoint> DSL element, then set the "registerBlueprintCamelContextEager" system property to "true" (See BlueprintCamelContext for the details). If not then the notification about the event of ³Camel Context is started" happens *before* OsgiCamelContextPublisher gets added to the list of ManagementStrategy#eventNotifiers. Probably there's room for improvement about this inside the code base which I didn't dig into. Babak > >I could track down the issue a bit further to the following which shows >what >the problem is: > >I installed the distro example camel-example-servlet-rest-blueprint >following the steps inside README: >https://github.com/apache/camel/blob/master/examples/camel-example-servlet >-rest-blueprint/README.txt > >Then checked the OSGi services this bundle exposes, which was: > >karaf@root> osgi:ls >... >camel-example-servlet-rest-blueprint (114) provides: >---------------------------------------------------- >[javax.servlet.ServletContext] >[org.osgi.service.blueprint.container.BlueprintListener] >[org.apache.camel.CamelContext] >[org.osgi.service.blueprint.container.BlueprintContainer] > >Note the CamelContext being exposed as an OSGi service above. Then made >the >required changes causing BlueprintTracerTest to fail (see the gist below). >Installed the example again inside a clean Karaf instance. And as you see >below the CamelContext is not exposed as a OSGi service anymore: > >karaf@root> osgi:ls >... >camel-example-servlet-rest-blueprint (114) provides: >---------------------------------------------------- >[org.osgi.service.blueprint.container.BlueprintListener] >[javax.servlet.ServletContext] >[org.osgi.service.blueprint.container.BlueprintContainer] > >And this is exactly the reason why BlueprintTracerTest used to fail, as >the >CamelContext did not get exposed as an OSGi service: >https://github.com/apache/camel/blob/master/tests/camel-itest-osgi/src/tes >t/java/org/apache/camel/itest/osgi/blueprint/BlueprintTracerTest.java#L44 > >The following is the trivial change I made locally to this example to >verify >the effect being explained above: >https://gist.github.com/bvahdat/45f9f2d47d86889abe7c > >Note that adding the Tracer to this example works perfectly and you can >see >the trace logs (e.g. using the log:tail Karaf command) as you invoke the >routes using your browser or the curl command. > >Babak > >Babak Vahdat wrote >> Hi >> >> I was looking into one of the OSGi tests being recently added into the >> codebase: >> >>https://github.com/apache/camel/blob/master/tests/camel-itest-osgi/src/te >>st/java/org/apache/camel/itest/osgi/blueprint/BlueprintTracerTest.java >> >> Which is disabled from very first day inside the corresponding POM as >>it¹s >> failing: >> <exclude> >> **/BlueprintTracerTest.* >> </exclude> >> > >> >> It's the *only* OSGi test about the Camel Tracer we've got inside our >> whole codebase so why I think it's a good/important one. I've already >>got >> a fix in place for it which I will commit shortly. However to make the >> test work I make use of Tracer#destinationUri instead of >> Tracer#destination property inside the blueprint XML. The wired thing is >> that using Tracer#destination you get *no* exception or the likes, >>simply >> nothing... but you just end up with the following line on the console, >> which BTW is very famous on Google :) >> >>https://github.com/apache/camel/blob/master/tests/camel-itest-osgi/src/te >>st/java/org/apache/camel/itest/osgi/blueprint/AbstractIntegrationTest.jav >>a#L87 >> >> So if any OSGi / Pax Exam expert out there has got an idea what the >> problem could be, then that would be cool. I suspect the problem is with >> PAX Exam itself rather than Camel as I tried out the same test setup >>using >> camel-test-blueprint module which passed properly! Well behind the scene >> that guy uses PojoSR and not a real OSGi runtime as PAX Exam does, but >> even then. >> >> Also my intention by the next days on the master branch is to upgrade to >> Pax Exam 4.3 so please keep your fingers crossed :) >> >> Side note: The test behaviour using Pax Exam 4.3 is exactly the same. >> >> Babak > > > > > >-- >View this message in context: >http://camel.465427.n5.nabble.com/About-an-OSGi-test-failing-by-our-codeba >se-tp5759911p5760235.html >Sent from the Camel Development mailing list archive at Nabble.com.
