Okay...just so that I get this straight... You're saying that because I don't load any bundles into the framework (in the configure() method), I just have an empty framework and thus my service won't be found. Makes sense. I thought that might be it.
But are you saying that there's no way that I can test ExampleService from within the ExampleService project? Must I create another project to own my Drone test cases and have those test cases pull their bundles from an already-built ExampleService bundle in Maven? That also makes sense...I just didn't understand it that way to begin with. So, in addition to my example service bundle project, I should create another project under the top-level project to house my integration tests? No problem...just wanting to confirm. And yes...that would be a nice addition to Pax Construct: To set up a Pax Drone project with stubs to get you started. Toni Menzel wrote: > 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 > _______________________________________________ general mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/general
