[Heads Up] added an OSGi system test for running Camel in Felix & Equinox

[James.Strachan]

Just as a simple integration test to check our OSGi metadata is OK,
I've created a little integration test case here...
http://svn.apache.org/repos/asf/camel/trunk/tests/camel-itest-osgi/
http://svn.apache.org/repos/asf/camel/trunk/tests/camel-itest-osgi/src/test/java/org/apache/camel/itest/osgi/OSGiIntegrationTest.java

for this issue
https://issues.apache.org/activemq/browse/CAMEL-1536

using Pax Exam
http://wiki.ops4j.org/display/paxexam/Pax+Exam

I made a minimal test (so not using Spring and so forth). We should
add another test using Spring I guess too.

I found quite a lot of stuff was mandatory rather than optional (e.g.
JMX stuff and JAXB stuff) so I tweaked the metadata for camel-core a
little to make more imports optional. I hope that doesn't break
anything :). We could always make those imports mandatory in
camel-spring maybe? (Though even with camel-spring you might wanna use
JavaConfig)

So far Pax Exam seems pretty good - the only missing feature is being
able to use the project's pom to figure out what versions of things to
use (like ServiceMix Kernel integration tests do).
--
James
-------
http://macstrac.blogspot.com/

Open Source Integration
http://fusesource.com/

[Claus Ibsen-2]

Hi

This is really great new.
The OSGi world is not as trivial as at first sight.


On Thu, Apr 16, 2009 at 5:47 PM, James Strachan
<james.strachan@...> wrote:

> Just as a simple integration test to check our OSGi metadata is OK,
> I've created a little integration test case here...
> http://svn.apache.org/repos/asf/camel/trunk/tests/camel-itest-osgi/
> http://svn.apache.org/repos/asf/camel/trunk/tests/camel-itest-osgi/src/test/java/org/apache/camel/itest/osgi/OSGiIntegrationTest.java
>
> for this issue
> https://issues.apache.org/activemq/browse/CAMEL-1536
>
> using Pax Exam
> http://wiki.ops4j.org/display/paxexam/Pax+Exam
>
> I made a minimal test (so not using Spring and so forth). We should
> add another test using Spring I guess too.
>
> I found quite a lot of stuff was mandatory rather than optional (e.g.
> JMX stuff and JAXB stuff) so I tweaked the metadata for camel-core a
> little to make more imports optional. I hope that doesn't break
> anything :). We could always make those imports mandatory in
> camel-spring maybe? (Though even with camel-spring you might wanna use
> JavaConfig)
>
> So far Pax Exam seems pretty good - the only missing feature is being
> able to use the project's pom to figure out what versions of things to
> use (like ServiceMix Kernel integration tests do).
> --
> James
> -------
> http://macstrac.blogspot.com/
>
> Open Source Integration
> http://fusesource.com/
>

--
Claus Ibsen
Apache Camel Committer

Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus
Apache Camel Reference Card:
http://refcardz.dzone.com/refcardz/enterprise-integration

[willem.jiang]

Yeah, it's definitely a good new for me.
It took me hours to test a little change of camel-osgi in ServiceMix.
(Downloading kit, hacking the meta-info, running the servicemix start up
script, checking the log file ...)

I will see if I can add more tests into camel-itest-osgi :)

Willem


Claus Ibsen wrote:

> Hi
>
> This is really great new.
> The OSGi world is not as trivial as at first sight.
>
>
> On Thu, Apr 16, 2009 at 5:47 PM, James Strachan
> <james.strachan@...> wrote:
>> Just as a simple integration test to check our OSGi metadata is OK,
>> I've created a little integration test case here...
>> http://svn.apache.org/repos/asf/camel/trunk/tests/camel-itest-osgi/
>> http://svn.apache.org/repos/asf/camel/trunk/tests/camel-itest-osgi/src/test/java/org/apache/camel/itest/osgi/OSGiIntegrationTest.java
>>
>> for this issue
>> https://issues.apache.org/activemq/browse/CAMEL-1536
>>
>> using Pax Exam
>> http://wiki.ops4j.org/display/paxexam/Pax+Exam
>>
>> I made a minimal test (so not using Spring and so forth). We should
>> add another test using Spring I guess too.
>>
>> I found quite a lot of stuff was mandatory rather than optional (e.g.
>> JMX stuff and JAXB stuff) so I tweaked the metadata for camel-core a
>> little to make more imports optional. I hope that doesn't break
>> anything :). We could always make those imports mandatory in
>> camel-spring maybe? (Though even with camel-spring you might wanna use
>> JavaConfig)
>>
>> So far Pax Exam seems pretty good - the only missing feature is being
>> able to use the project's pom to figure out what versions of things to
>> use (like ServiceMix Kernel integration tests do).
>> --
>> James
>> -------
>> http://macstrac.blogspot.com/
>>
>> Open Source Integration
>> http://fusesource.com/
>>
>
>
>

[James.Strachan]

2009/4/17 Willem Jiang <willem.jiang@...>:
> Yeah, it's definitely a good new for me.
> It took me hours to test a little change of camel-osgi in ServiceMix.
> (Downloading kit, hacking the meta-info, running the servicemix start up
> script, checking the log file ...)
>
> I will see if I can add more tests into camel-itest-osgi :)

Great stuff! :)

I wonder if it'd make sense to have a parent pom.xml file for all OSGI
tests which has all the Pax Exam dependencies in it - and the
depends-maven-plugin stuff; then we can spin up lots of little
integration tests using different sets of bundles (e.g. just
camel-core which is what I did - then camel-spring, or camel-spring +
ActiveMQ or whatever).

we might wanna have a directory structure more like this?

tests/osgi/
  camel-itest-osgi-core/
  camel-itest-osgi-spring/
  camel-itest-osgi-jms/

etc

--
James
-------
http://macstrac.blogspot.com/

Open Source Integration
http://fusesource.com/

[cmoulliard]

Otherwise an interesting alternative could be to use the features.xml file
where the list of the bundles to be used for testing purpose is defined.
Alin has added an interesting option in pax-runner to scan for features :
scan-features:mvn:org.apache.servicemix/apache-servicemix/4.0.0/xml/features!/cxf
Regards,

Charles

On Fri, Apr 17, 2009 at 12:49 PM, James Strachan
<james.strachan@...>wrote:

> 2009/4/17 Willem Jiang <willem.jiang@...>:
> > Yeah, it's definitely a good new for me.
> > It took me hours to test a little change of camel-osgi in ServiceMix.
> > (Downloading kit, hacking the meta-info, running the servicemix start up
> > script, checking the log file ...)
> >
> > I will see if I can add more tests into camel-itest-osgi :)
>
> Great stuff! :)
>
> I wonder if it'd make sense to have a parent pom.xml file for all OSGI
> tests which has all the Pax Exam dependencies in it - and the
> depends-maven-plugin stuff; then we can spin up lots of little
> integration tests using different sets of bundles (e.g. just
> camel-core which is what I did - then camel-spring, or camel-spring +
> ActiveMQ or whatever).
>
> we might wanna have a directory structure more like this?
>
> tests/osgi/
>  camel-itest-osgi-core/
>  camel-itest-osgi-spring/
>  camel-itest-osgi-jms/
>
> etc
>
> --
> James
> -------
> http://macstrac.blogspot.com/
>
> Open Source Integration
> http://fusesource.com/
>

[James.Strachan]

2009/4/17 Charles Moulliard <cmoulliard@...>:
> Otherwise an interesting alternative could be to use the features.xml file
> where the list of the bundles to be used for testing purpose is defined.
> Alin has added an interesting option in pax-runner to scan for features :
> scan-features:mvn:org.apache.servicemix/apache-servicemix/4.0.0/xml/features!/cxf
> Regards,

Awesome - thanks Charles! I was wondering how we could move to using
features XML files for testing instead - many thanks!

--
James
-------
http://macstrac.blogspot.com/

Open Source Integration
http://fusesource.com/

[cmoulliard]

I will try to cover this part in my tutorial (part 2) that I write for the
moment (http://cwiki.apache.org/CAMEL/tutorial-osgi-camel-part2.html) .The
material is ready and works top of SMX 4


On Fri, Apr 17, 2009 at 2:00 PM, James Strachan <james.strachan@...>wrote:

> 2009/4/17 Charles Moulliard <cmoulliard@...>:
> > Otherwise an interesting alternative could be to use the features.xml
> file
> > where the list of the bundles to be used for testing purpose is defined.
> > Alin has added an interesting option in pax-runner to scan for features :
> >
> scan-features:mvn:org.apache.servicemix/apache-servicemix/4.0.0/xml/features!/cxf
> > Regards,
>
> Awesome - thanks Charles! I was wondering how we could move to using
> features XML files for testing instead - many thanks!
>
> --
> James
> -------
> http://macstrac.blogspot.com/
>
> Open Source Integration
> http://fusesource.com/
>

[James.Strachan]

2009/4/17 Charles Moulliard <cmoulliard@...>:
> I will try to cover this part in my tutorial (part 2) that I write for the
> moment (http://cwiki.apache.org/CAMEL/tutorial-osgi-camel-part2.html) .The
> material is ready and works top of SMX 4

Great stuff Charles! :)

--
James
-------
http://macstrac.blogspot.com/

Open Source Integration
http://fusesource.com/

[cmoulliard]

Have you look to the picture in my tutorial (new EIP icons relooked) ?

On Fri, Apr 17, 2009 at 2:12 PM, James Strachan <james.strachan@...>wrote:

> 2009/4/17 Charles Moulliard <cmoulliard@...>:
> > I will try to cover this part in my tutorial (part 2) that I write for
> the
> > moment (http://cwiki.apache.org/CAMEL/tutorial-osgi-camel-part2.html)
> .The
> > material is ready and works top of SMX 4
>
> Great stuff Charles! :)
>
> --
> James
> -------
> http://macstrac.blogspot.com/
>
> Open Source Integration
> http://fusesource.com/
>

[James.Strachan]

2009/4/17 Charles Moulliard <cmoulliard@...>:
> Have you look to the picture in my tutorial (new EIP icons relooked) ?

They look great :)

>
> On Fri, Apr 17, 2009 at 2:12 PM, James Strachan <james.strachan@...>wrote:
>
>> 2009/4/17 Charles Moulliard <cmoulliard@...>:
>> > I will try to cover this part in my tutorial (part 2) that I write for
>> the
>> > moment (http://cwiki.apache.org/CAMEL/tutorial-osgi-camel-part2.html)
>> .The
>> > material is ready and works top of SMX 4
>>
>> Great stuff Charles! :)
>>
>> --
>> James
>> -------
>> http://macstrac.blogspot.com/
>>
>> Open Source Integration
>> http://fusesource.com/
>>
>

--
James
-------
http://macstrac.blogspot.com/

Open Source Integration
http://fusesource.com/

[willem.jiang]

Hi James,

Can you run the camel-itest-osgi test successfully ?
I got the below error in my windows box.

org.ops4j.pax.exam.spi.container.TestContainerException: Cannot get the
remote bundle context
        at
org.ops4j.pax.exam.rbc.client.RemoteBundleContextClient.getRemoteBundleContext(RemoteBundleContextClient.java:256)
        at
org.ops4j.pax.exam.rbc.client.RemoteBundleContextClient.stop(RemoteBundleContextClient.java:201)
        at
org.ops4j.pax.exam.container.def.internal.PaxRunnerTestContainer.stop(PaxRunnerTestContainer.java:160)
        at
org.ops4j.pax.exam.junit.internal.JUnit4TestMethod.invoke(JUnit4TestMethod.java:120)
        at
org.junit.internal.runners.MethodRoadie.runTestMethod(MethodRoadie.java:105)
        at org.junit.internal.runners.MethodRoadie$2.run(MethodRoadie.java:86)
        at
org.ops4j.pax.exam.junit.internal.JUnit4MethodRoadie.runBeforesThenTestThenAfters(JUnit4MethodRoadie.java:60)
        at org.junit.internal.runners.MethodRoadie.runTest(MethodRoadie.java:84)
        at org.junit.internal.runners.MethodRoadie.run(MethodRoadie.java:49)
        at
org.ops4j.pax.exam.junit.JUnit4TestRunner.invokeTestMethod(JUnit4TestRunner.java:245)
        at
org.ops4j.pax.exam.junit.JUnit4TestRunner.runMethods(JUnit4TestRunner.java:195)
        at
org.ops4j.pax.exam.junit.JUnit4TestRunner$2.run(JUnit4TestRunner.java:185)
        at
org.junit.internal.runners.ClassRoadie.runUnprotected(ClassRoadie.java:34)
        at org.junit.internal.runners.ClassRoadie.runProtected(ClassRoadie.java:44)
        at org.ops4j.pax.exam.junit.JUnit4TestRunner.run(JUnit4TestRunner.java:181)
        at
org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:45)
        at
org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
        at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
        at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
        at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
        at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)
Caused by: java.rmi.ConnectException: Connection refused to host:
192.168.0.131; nested exception is:
        java.net.ConnectException: Connection refused: connect
        at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:574)
        at sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:185)
        at sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java:171)
        at sun.rmi.server.UnicastRef.newCall(UnicastRef.java:306)
        at sun.rmi.registry.RegistryImpl_Stub.lookup(Unknown Source)
        at
org.ops4j.pax.exam.rbc.client.RemoteBundleContextClient.getRemoteBundleContext(RemoteBundleContextClient.java:234)
        ... 20 more
Caused by: java.net.ConnectException: Connection refused: connect
        at java.net.PlainSocketImpl.socketConnect(Native Method)
        at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:333)
        at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:195)
        at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:182)
        at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366)
        at java.net.Socket.connect(Socket.java:520)
        at java.net.Socket.connect(Socket.java:470)
        at java.net.Socket.<init>(Socket.java:367)
        at java.net.Socket.<init>(Socket.java:180)
        at
sun.rmi.transport.proxy.RMIDirectSocketFactory.createSocket(RMIDirectSocketFactory.java:22)
        at
sun.rmi.transport.proxy.RMIMasterSocketFactory.createSocket(RMIMasterSocketFactory.java:128)
        at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:569)
        ... 25 more


Willem

James Strachan wrote:

> 2009/4/17 Willem Jiang <willem.jiang@...>:
>> Yeah, it's definitely a good new for me.
>> It took me hours to test a little change of camel-osgi in ServiceMix.
>> (Downloading kit, hacking the meta-info, running the servicemix start up
>> script, checking the log file ...)
>>
>> I will see if I can add more tests into camel-itest-osgi :)
>
> Great stuff! :)
>
> I wonder if it'd make sense to have a parent pom.xml file for all OSGI
> tests which has all the Pax Exam dependencies in it - and the
> depends-maven-plugin stuff; then we can spin up lots of little
> integration tests using different sets of bundles (e.g. just
> camel-core which is what I did - then camel-spring, or camel-spring +
> ActiveMQ or whatever).
>
> we might wanna have a directory structure more like this?
>
> tests/osgi/
>   camel-itest-osgi-core/
>   camel-itest-osgi-spring/
>   camel-itest-osgi-jms/
>
> etc
>

[willem.jiang]

Just a quick update of what I found with Pax Exam in my windows box.
It looks like test only can run successfully with knopflerfish in my
windows box.
I always get the "java.rmi.ConnectException: Connection refused to host"
with felix, equinox whether enable or disable the firewall.

Now, I'm downloading the Pax Exam and Runner code to find more about it.

Willem

Willem Jiang wrote:

> Hi James,
>
> Can you run the camel-itest-osgi test successfully ?
> I got the below error in my windows box.
>
> org.ops4j.pax.exam.spi.container.TestContainerException: Cannot get the
> remote bundle context
> at
> org.ops4j.pax.exam.rbc.client.RemoteBundleContextClient.getRemoteBundleContext(RemoteBundleContextClient.java:256)
> at
> org.ops4j.pax.exam.rbc.client.RemoteBundleContextClient.stop(RemoteBundleContextClient.java:201)
> at
> org.ops4j.pax.exam.container.def.internal.PaxRunnerTestContainer.stop(PaxRunnerTestContainer.java:160)
> at
> org.ops4j.pax.exam.junit.internal.JUnit4TestMethod.invoke(JUnit4TestMethod.java:120)
> at
> org.junit.internal.runners.MethodRoadie.runTestMethod(MethodRoadie.java:105)
> at org.junit.internal.runners.MethodRoadie$2.run(MethodRoadie.java:86)
> at
> org.ops4j.pax.exam.junit.internal.JUnit4MethodRoadie.runBeforesThenTestThenAfters(JUnit4MethodRoadie.java:60)
> at org.junit.internal.runners.MethodRoadie.runTest(MethodRoadie.java:84)
> at org.junit.internal.runners.MethodRoadie.run(MethodRoadie.java:49)
> at
> org.ops4j.pax.exam.junit.JUnit4TestRunner.invokeTestMethod(JUnit4TestRunner.java:245)
> at
> org.ops4j.pax.exam.junit.JUnit4TestRunner.runMethods(JUnit4TestRunner.java:195)
> at
> org.ops4j.pax.exam.junit.JUnit4TestRunner$2.run(JUnit4TestRunner.java:185)
> at
> org.junit.internal.runners.ClassRoadie.runUnprotected(ClassRoadie.java:34)
> at org.junit.internal.runners.ClassRoadie.runProtected(ClassRoadie.java:44)
> at org.ops4j.pax.exam.junit.JUnit4TestRunner.run(JUnit4TestRunner.java:181)
> at
> org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:45)
> at
> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)
> Caused by: java.rmi.ConnectException: Connection refused to host:
> 192.168.0.131; nested exception is:
> java.net.ConnectException: Connection refused: connect
> at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:574)
> at sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:185)
> at sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java:171)
> at sun.rmi.server.UnicastRef.newCall(UnicastRef.java:306)
> at sun.rmi.registry.RegistryImpl_Stub.lookup(Unknown Source)
> at
> org.ops4j.pax.exam.rbc.client.RemoteBundleContextClient.getRemoteBundleContext(RemoteBundleContextClient.java:234)
> ... 20 more
> Caused by: java.net.ConnectException: Connection refused: connect
> at java.net.PlainSocketImpl.socketConnect(Native Method)
> at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:333)
> at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:195)
> at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:182)
> at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366)
> at java.net.Socket.connect(Socket.java:520)
> at java.net.Socket.connect(Socket.java:470)
> at java.net.Socket.<init>(Socket.java:367)
> at java.net.Socket.<init>(Socket.java:180)
> at
> sun.rmi.transport.proxy.RMIDirectSocketFactory.createSocket(RMIDirectSocketFactory.java:22)
> at
> sun.rmi.transport.proxy.RMIMasterSocketFactory.createSocket(RMIMasterSocketFactory.java:128)
> at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:569)
> ... 25 more
>
>
> Willem
>
> James Strachan wrote:
>> 2009/4/17 Willem Jiang <willem.jiang@...>:
>>> Yeah, it's definitely a good new for me.
>>> It took me hours to test a little change of camel-osgi in ServiceMix.
>>> (Downloading kit, hacking the meta-info, running the servicemix start up
>>> script, checking the log file ...)
>>>
>>> I will see if I can add more tests into camel-itest-osgi :)
>> Great stuff! :)
>>
>> I wonder if it'd make sense to have a parent pom.xml file for all OSGI
>> tests which has all the Pax Exam dependencies in it - and the
>> depends-maven-plugin stuff; then we can spin up lots of little
>> integration tests using different sets of bundles (e.g. just
>> camel-core which is what I did - then camel-spring, or camel-spring +
>> ActiveMQ or whatever).
>>
>> we might wanna have a directory structure more like this?
>>
>> tests/osgi/
>>   camel-itest-osgi-core/
>>   camel-itest-osgi-spring/
>>   camel-itest-osgi-jms/
>>
>> etc
>>
>
>