ok, i already checked you laboratory. well, the problem is by design: you just load an empty osgi framework. Thus, you service (ExampleService) will not be found. Short answer to "your manifest": No, it does not recognize your manifest.
The faq ansers this like so: By design the drone will be built using the wrap approach solely on classes found inside the current project. Every dependency will be declared as an optional import-package. This constrains the usage of the drone. But by intention. The drone contains just the recipe host and its direct dependencies (like helper classes just for testing purpose). Everything you want to test should be build by someone who really knows about it: maven-bundle-plugin or similar. This way you orchestrate the final artifacts and no hybrid bundles that blur the test outcome. --- PaxDrone just takes complete bundles and provides a method to quickly set them and write some test code (called recipes) against this. So, its a decision that might lead to unexpected results (like your case) but should be clear once you know about this. There are some things that might help here in future: - support paxdrone somehow in a paxconstruct setup directly in a way that those "integration test projects" you need for paxdrone are automatically pre-build (stubs) if wanted. Will keep you in touch. Toni -------- Original-Nachricht -------- > Datum: Mon, 28 Jul 2008 08:31:41 -0500 > Von: Craig Walls <[EMAIL PROTECTED]> > An: General OPS4J <[email protected]> > Betreff: Re: Pax Drone > > Okay...here's what I did: > > 1. Used pax-create-project to create a project > 2. Used pax-create-bundle to create the bundle subproject > 3. Manually added Pax Drone dependencies to the top-level project's > pom.xml > 4. Added a Drone test case for the ExampleService > > When I run "mvn test", the test fails for the same reason it fails in my > much more interesting project...that is, because it can't seem to find > the service. The good news (sorta) is that the test runs in Eclipse...it > still fails for the same reason that it fails in Maven, but it runs fine > otherwise. > > The two places where I may've screwed up (and I am looking for feedback) > are: > > * Did I correctly add Pax Drone to the project? I did it manually > (instead of using something like pax-import-bundle) because I > didn't want Pax Drone to be provisioned at runtime. Is there a > better way than to add it manually in the POM? > * Is my test case written correctly? Am I trying to get the service > correctly? (I looked for examples in SVN, but all of the Drone > examples that I found in SVN stopped short of retrieving a service > and testing it. If I'm missing something, please point me in the > right direction.) > > I checked all of what I did into SVN at > https://scm.ops4j.org/repos/ops4j/laboratory/users/habuma/pax-construct-drone. > > BTW, side question: How does Pax Drone know to create a bundle for my > project that publishes the service? Does it find a MANIFEST.MF somewhere > and use that? Does it find an activator class and assume that it should > be the activator? How does that magic work? > > > > > Craig Walls wrote: > > Absolutely. I'll try to cook one up. > > > > As I mentioned, I'm not 100% convinced that it's a Pax Drone/Pax > > Construct mismatch--that was just the pattern that I had observed. > > > > I'll need to cook up an example where it fails. I am not prepared to > > share the code that I discovered this in, but I'll try to come up with > > something similar. > > > > > > Stuart McCulloch wrote: > > > >> 2008/7/28 Toni Menzel <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> > >> > >> Will definitely have a look at that asap. @craig: can you provide > >> a ready to go Sample of the Problem in your laboratory? > >> Toni > >> > >> > >> yep, I think we'll need an example - I tried to create one using > >> pax-construct 1.3 and pax-drone 1.3-SNAPSHOT, but wasn't > >> able to recreate the error > >> > >> Sent from my iPhone > >> > >> On 28.07.2008, at 10:38, "Stuart McCulloch" > >> <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> > >> wrote: > >> > >> > >>> 2008/7/28 Toni Menzel <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> > >>> > >>> hex craig, > >>> thanks for digging into the problems yourself and sorry about > >>> me not > >>> jumping in this weekend. > >>> first about the Manifest itself: (though it doesn't look to > >>> be our > >>> Problem today) its by design to ensure conistency within the > >>> dronebundle as well as (More important) to really force the > >>> testcode > >>> not containing real code. Its different from unittesting. The > >>> drone is > >>> just an extra module (bundle) solely to orchestrate the other > >>> bundles. > >>> The wiki contains a faq entry about this. > >>> About paxconstruct: will try to catch up with stuart whats > >>> wrong here. > >>> > >>> > >>> interesting... pax-construct generated projects are still normal > >>> Maven projects that someone could create by hand, given time > >>> - so it's odd they cause problems in pax-drone > >>> > >>> initial thought is possibly a dependency/plugin conflict... but > how? > >>> > >>> Stay there! ;-) > >>> Cheers, > >>> Toni > >>> > >>> > >>> > >>> On 28.07.2008, at 06:13, Craig Walls <[EMAIL PROTECTED] > >>> <mailto:[EMAIL PROTECTED]>> wrote: > >>> > >>> > > >>> > Following up to my earlier e-mail... > >>> > > >>> > I now believe that my previous supposition was false. At > >>> that point I > >>> > was thinking that my service wasn't being published because > >>> Pax Drone > >>> > didn't know about my activator. But now I have a much > >>> simpler bundle > >>> > project and have no trouble writing Pax Drone tests in it > >>> and against > >>> > the service that its activator publishes. So that blows my > >>> original > >>> > theory. > >>> > > >>> > So, I've tried Pax Drone in a few more bundle projects and > >>> have had a > >>> > mixed bag of results. So far, the pattern seems to be that > >>> it works > >>> > fine > >>> > in projects that I create by hand, but doesn't work well in > >>> projects > >>> > that I created with Pax Construct. I suspect that I'll > >>> prove that > >>> > wrong, > >>> > but that's the current pattern. > >>> > > >>> > For what it's worth, in Pax Construct projects, I am seeing > two > >>> > problems > >>> > (but they might be related). First, when I try to run the > >>> test from > >>> > Eclipse, I get the following exception/stack-trace: > >>> > > >>> > java.lang.SecurityException: class > >>> > "org.apache.commons.logging.LogLevel"'s signer information > >>> does not > >>> > match signer information of other classes in the same > package > >>> > at java.lang.ClassLoader.checkCerts(ClassLoader.java:775) > >>> > at > >>> java.lang.ClassLoader.preDefineClass(ClassLoader.java:487) > >>> > at > java.lang.ClassLoader.defineClass(ClassLoader.java:614) > >>> > at > >>> > > >>> > java.security.SecureClassLoader.defineClass(SecureClassLoader.java: > >>> > 124) > >>> > at > >>> java.net.URLClassLoader.defineClass(URLClassLoader.java:260) > >>> > at > >>> java.net.URLClassLoader.access$100(URLClassLoader.java:56) > >>> > at java.net.URLClassLoader$1.run(URLClassLoader.java:195) > >>> > at java.security.AccessController.doPrivileged(Native > >>> Method) > >>> > at > >>> java.net.URLClassLoader.findClass(URLClassLoader.java:188) > >>> > at java.lang.ClassLoader.loadClass(ClassLoader.java:306) > >>> > at > >>> sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268) > >>> > at java.lang.ClassLoader.loadClass(ClassLoader.java:251) > >>> > at > >>> java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) > >>> > at org.ops4j.pax.runner.Run.<init>(Run.java:86) > >>> > at > >>> > org. > >>> > ops4j. > >>> > pax. > >>> > drone. > >>> > connector. > >>> > paxrunner. > >>> > > >>> > intern.PaxRunnerInstanceImpl.startup(PaxRunnerInstanceImpl.java:75) > >>> > at > >>> > org. > >>> > ops4j. > >>> > pax. > >>> > drone. > >>> > connector. > >>> > > >>> > paxrunner.intern.PaxRunnerConnector.execute(PaxRunnerConnector.java: > >>> > 63) > >>> > at > >>> org.ops4j.pax.drone.spi.DroneRunner.run(DroneRunner.java:76) > >>> > at > >>> > org. > >>> > > >>> > ops4j.pax.drone.spi.junit.DroneTestCase.runBare(DroneTestCase.java:60) > >>> > at > junit.framework.TestResult$1.protect(TestResult.java:110) > >>> > at > >>> junit.framework.TestResult.runProtected(TestResult.java:128) > >>> > at junit.framework.TestResult.run(TestResult.java:113) > >>> > at junit.framework.TestCase.run(TestCase.java:124) > >>> > at junit.framework.TestSuite.runTest(TestSuite.java:232) > >>> > at junit.framework.TestSuite.run(TestSuite.java:227) > >>> > at > >>> > org. > >>> > junit. > >>> > > >>> > internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:81) > >>> > at > >>> > org. > >>> > eclipse. > >>> > jdt. > >>> > internal. > >>> > > >>> > junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:38) > >>> > 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) > >>> > > >>> > When I run the tests at build time using Maven, the test > >>> fails with a > >>> > NPE when it tries to use the null ServiceReference received > >>> from the > >>> > BundleContext. > >>> > > >>> > For non-Pax Construct projects, it works fine in both > >>> Eclipse and > >>> > Maven. > >>> > > >>> > Again, any clues would be greatly appreciated. In the > >>> meantime, I'll > >>> > be > >>> > digging around in the Pax Drone source code. > >>> > > >>> > > >>> > > >>> > Craig Walls wrote: > >>> >> Imagine that I have created a bundle that publishes a > >>> HelloService to > >>> >> the OSGi service registry. Now I want to test that service, > >>> >> integrated > >>> >> with all of the stuff (in other bundles) that it works > >>> with. So I > >>> >> write > >>> >> a Pax Drone test, adding all of the required bundles. > >>> >> > >>> >> I run the test...it looks a little something like this: > >>> >> > >>> >> public class HelloServiceBundleTest extends DroneTestCase { > >>> >> > >>> >> @Override > >>> >> protected ConnectorConfiguration configure() { > >>> >> return > >>> ConnectorConfigurationFactory.create(this).setPlatform( > >>> >> Platforms.EQUINOX).addBundle("...") > >>> >> .addBundle("..."); // bundle names left > >>> out for > >>> >> brevity's sake > >>> >> } > >>> >> > >>> >> public void testBundleContextExists() { > >>> >> assertNotNull(droneContext.getBundleContext()); > >>> >> } > >>> >> > >>> >> public void testHelloServiceShouldExist() { > >>> >> BundleContext bundleContext = > >>> droneContext.getBundleContext(); > >>> >> ServiceReference serviceRef = bundleContext > >>> >> > >>> >> > >>> .getServiceReference("com.habuma.hello.HelloService"); > >>> >> HelloService helloService = (HelloService) > bundleContext > >>> >> .getService(serviceRef); > >>> >> assertNotNull(helloService); > >>> >> } > >>> >> } > >>> >> > >>> >> But it doesn't work. The testBundleContextExists() test > >>> works. But > >>> >> testHelloServiceShouldExist() fails. It tries to find the > >>> >> HelloService, > >>> >> but it can't be found. I'm pretty sure that it's because... > >>> >> > >>> >> * I'm not adding the hello service bundle to the > >>> >> ConnectorConfiguration...and... > >>> >> * I'm letting the test case automatically generate the > >>> bundle for > >>> >> the hello service...and... > >>> >> * The generated bundle doesn't know about the > >>> >> activator...therefore... > >>> >> * The service isn't be published. > >>> >> > >>> >> My question: How can I test the index service (in an > >>> integration test > >>> >> along with all of the stuff that it depends on) using Pax > >>> Drone? > >>> >> Like I > >>> >> said, it seems that the crux of the problem is that the > >>> service is > >>> >> never > >>> >> published because the activator is never executed because > >>> I don't > >>> >> know > >>> >> how to tell Pax Drone about the activator. > >>> >> > >>> >> Any clues? The only thing that I can think of is to test > >>> the hello > >>> >> service in a separate project, including the hello service > >>> bundle > >>> >> in the > >>> >> set of bundles added to the ConnectorConfiguration and > >>> ensure that > >>> >> the > >>> >> hello service bundle has been created before I run the > >>> integration > >>> >> test. > >>> >> But I'd really prefer to test the hello service bundle > >>> within the > >>> >> hello > >>> >> service bundle project. > >>> >> > >>> >> > >>> >> > >>> >> _______________________________________________ > >>> >> general mailing list > >>> >> [email protected] <mailto:[email protected]> > >>> >> http://lists.ops4j.org/mailman/listinfo/general > >>> >> > >>> > > >>> > > >>> > _______________________________________________ > >>> > general mailing list > >>> > [email protected] <mailto:[email protected]> > >>> > http://lists.ops4j.org/mailman/listinfo/general > >>> > >>> _______________________________________________ > >>> general mailing list > >>> [email protected] <mailto:[email protected]> > >>> http://lists.ops4j.org/mailman/listinfo/general > >>> > >>> > >>> > >>> > >>> -- > >>> Cheers, Stuart > >>> _______________________________________________ > >>> general mailing list > >>> [email protected] <mailto:[email protected]> > >>> http://lists.ops4j.org/mailman/listinfo/general > >>> > >> _______________________________________________ > >> general mailing list > >> [email protected] <mailto:[email protected]> > >> http://lists.ops4j.org/mailman/listinfo/general > >> > >> > >> > >> > >> -- > >> Cheers, Stuart > >> > ------------------------------------------------------------------------ > >> > >> _______________________________________________ > >> general mailing list > >> [email protected] > >> http://lists.ops4j.org/mailman/listinfo/general > >> > >> > > > > > > _______________________________________________ > > general mailing list > > [email protected] > > http://lists.ops4j.org/mailman/listinfo/general > > > > > _______________________________________________ > general mailing list > [email protected] > http://lists.ops4j.org/mailman/listinfo/general _______________________________________________ general mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/general
