Okay...I *finally* figured out what was going on with my Pax Drone test
case. I won't give line-by-line details, but I'll share enough details
to give someone to work with if they encounter the same problem...
* First, I am running my tests against Equinox (by calling
setPlatform() and passing in Platforms.EQUINOX). One error that I
was frequently getting was that my test class could not be found.
I couldn't imagine why this was the case, but I suspected that it
was a deeper dependency problem.
* On a whim, I switched to Felix. Felix complained loudly with a
NoClassDefFoundError on one of the classes in Compass (this bundle
uses Compass for searching and indexing objects).
* It so happens that Compass uses class.forName() extensively to
load classes. At very least, this creates a problem for BND when
creating the manifest. By manually adding the various compass
packages to Import-Package, I made the NoClassDefFoundError go
away for the Compass dependencies.
* But I was still getting a NCDFF for my test class itself...which
seemed weird to me since it is the test class that kicked off
everything.
* Then it occurred to me that my test class is in the same package
as the service interface. Since the service interface was being
exported from the service bundle and since my test was getting
bundled up on the fly, this created a split package scenario.
* My bar went green as soon as I moved the test class to a different
package other than one being exported from another service in the
framework.
The class.forName() stuff in Compass still bugs me...I'm concerned that
I may run into other weirdness later. To be honest, I'm almost ready to
ditch Compass and just use raw Lucene. Compass has been a pain for OSGi
in several way:
* The Compass JAR file comes as an OSGi bundle (it has a
Bundle-SymbolicName: header in its MANIFEST.MF. But that's about
it. There are no package exports (or package imports for that
matter). Consequently, even though it's a bundle, it's a rather
useless bundle, requiring some BND goodness to expose its contents.
* Compass extends Lucene with some classes that are in
"org.apache.lucene.*" packages. Compass also depends on Lucene,
which itself offers stuff in "org.apache.lucene.*" packages. Two
word: Split packages. I got around this by embedding Lucene within
Compass.
* Now this class.forName() thing has me wondering if the
object-to-search-index mapping benefits of Compass are worth all
of these hassles.
Anyway, I just wanted to say thanks to all who helped me try to figure
this out...and to leave a marker behind in case anyone else runs into
the same or similar problems.
Craig Walls wrote:
> 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
