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