2008/7/28 Toni Menzel <[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]> 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]
>> 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
--
Cheers, Stuart
_______________________________________________
general mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/general
