Hi all,
I'm trying to do something similar but am still having difficulties
(pax exam 1.2.0 & tiny bundles 1.2.0).
I'm setting up my configuration as suggested by Clement above. Then in
my test I do this:
@Test
public void testFoo() throws Exception {
InputStream x = TinyBundles.newBundle()
.add(TestActivator.class) // trivial activator
.set(Constants.BUNDLE_SYMBOLICNAME, "foo")
.set(Constants.IMPORT_PACKAGE, "org.osgi.framework")
.set(Constants.BUNDLE_ACTIVATOR, TestActivator.class.getName())
.build();
Bundle b = bundleContext.installBundle("http://localhost";, x);
b.start();
}
Tiny Bundles does create the bundle and the bundle does get installed,
but when I try to call b.start()
I get an exception from Felix [1].
I would also be happy to construct my test Foo bundle in the configure
method and then start it in the test itself later if that is a better
approach. Anyone an idea how to do this?
Thanks,
David
[1]
org.osgi.framework.BundleException: Activator start error in bundle foo [12].
at org.apache.felix.framework.Felix.activateBundle(Felix.java:1751)
at org.apache.felix.framework.Felix.startBundle(Felix.java:1622)
at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:915)
at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:902)
at
org.apache.cxf.dosgi.systests2.common.TestImportService.testClientConsumer(TestImportService.java:58)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.ops4j.pax.exam.junit.extender.impl.internal.CallableTestMethodImpl.injectContextAndInvoke(CallableTestMethodImpl.java:134)
at
org.ops4j.pax.exam.junit.extender.impl.internal.CallableTestMethodImpl.call(CallableTestMethodImpl.java:101)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.ops4j.pax.exam.rbc.internal.RemoteBundleContextImpl.remoteCall(RemoteBundleContextImpl.java:80)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:305)
at sun.rmi.transport.Transport$1.run(Transport.java:159)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Transport.java:155)
at
sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:535)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:790)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:649)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)
2009/12/21 Todor Boev <rinsv...@gmail.com>:
> Btw this method might be useful:
>
>
> public TinyBundle remove(Class<?> c) {
> return removeResource(c.getName().replace(".", "/") + ".class");
> }
>
> Toni Menzel wrote:
>> On Mon, Dec 21, 2009 at 4:10 PM, Toni Menzel <t...@okidokiteam.com> wrote:
>>
>>>
>>> On Mon, Dec 21, 2009 at 4:07 PM, Todor Boev <rinsv...@gmail.com> wrote:
>>>
>>>> On Mon, Dec 21, 2009 at 4:18 PM, Toni Menzel <t...@okidokiteam.com>wrote:
>>>>
>>>>> well, thats possible but not too simple.
>>>>> There are different approaches:
>>>>> - give the auxiliary and test code different source folders. (exam just
>>>>> packs the one where the test sits in)
>>>>>
>>>> How can I do that with maven? Or you mean I can make a separate maven
>>>> project where all the tiny bundle code will live?
>>>>
>>> yes.. Tinybundles loads from classpath.. so it does not care where the
>>> stuff comes from physically.
>>>
>> http://issues.ops4j.org/browse/PAXSB-32
>> So, once we support that, you lose that "feature".
>>
>>>
>>>> - remove the unwanted classes using
>>>>> http://paxexam.ops4j.org/display/paxexam/How+to+customize+the+test+environment(see
>>>>> customizeTestProbe)
>>>>>
>>>> Yup this worked :) However for some reason ".build(withBnd())" did not
>>>> work. The plan was to remove the BND generated Export-Packages header and
>>>> just add a Private-Packages header for the single package where the JUnit
>>>> code is. In the end I used the brute force approach :P
>>>>
>>>> new Customizer() {
>>>> @Override
>>>> public InputStream customizeTestProbe(InputStream probe) throws
>>>> IOException {
>>>> return modifyBundle(probe)
>>>> .removeHeader(EXPORT_PACKAGE)
>>>> .removeHeader(DYNAMICIMPORT_PACKAGE)
>>>> .set(IMPORT_PACKAGE,
>>>> "org.ops4j.peaberry.activation.invocations, " +
>>>> "org.ops4j.peaberry.activation.examples.export, " +
>>>> "org.ops4j.peaberry.activation.examples.singleton, " +
>>>> "com.google.inject; resolution:=optional, " +
>>>> "com.google.inject.binder; resolution:=optional, " +
>>>> "com.google.inject.matcher; resolution:=optional, " +
>>>> "org.aopalliance.intercept; resolution:=optional, " +
>>>> "junit.framework; resolution:=optional, " +
>>>> "org.junit; resolution:=optional, " +
>>>> "org.junit.runner; resolution:=optional, " +
>>>> "org.ops4j.pax.exam; resolution:=optional, " +
>>>> "org.ops4j.pax.exam.junit; resolution:=optional, " +
>>>> "org.ops4j.pax.exam.options; resolution:=optional, " +
>>>> "org.ops4j.pax.swissbox.tinybundles.core;
>>>> resolution:=optional, " +
>>>> "org.ops4j.peaberry; resolution:=optional, " +
>>>> "org.ops4j.peaberry.activation; resolution:=optional, " +
>>>> "org.ops4j.peaberry.builders; resolution:=optional, " +
>>>> "org.ops4j.peaberry.util; resolution:=optional, " +
>>>> "org.osgi.framework")
>>>>
>>>>
>>>> .removeResource("org/ops4j/peaberry/activation/invocations/InvocationLog.class")
>>>>
>>>> .removeResource("org/ops4j/peaberry/activation/invocations/InvocationLogModule.class")
>>>>
>>>> .removeResource("org/ops4j/peaberry/activation/invocations/internal/Activator.class")
>>>>
>>>> .removeResource("org/ops4j/peaberry/activation/invocations/internal/InvocationLogImpl.class")
>>>>
>>>> .removeResource("org/ops4j/peaberry/activation/invocations/internal/LoggingInterceptor.class")
>>>>
>>>>
>>>> .removeResource("org/ops4j/peaberry/activation/examples/singleton/Config.class")
>>>>
>>>> .removeResource("org/ops4j/peaberry/activation/examples/singleton/SingletonRoot.class")
>>>>
>>>>
>>>> .removeResource("org/ops4j/peaberry/activation/examples/export/Config.class")
>>>>
>>>> .removeResource("org/ops4j/peaberry/activation/examples/export/Hello.class")
>>>>
>>>> .removeResource("org/ops4j/peaberry/activation/examples/export/HelloImpl.class")
>>>>
>>>> .build();
>>>> }
>>>>
>>> Uppss.. yes, guess a filter support ("*") would be good, he ?
>>>
>>>>
>>>> - wait for 2.0 release (scheduled for 1Q 2010 but.. maybe you dont wait
>>>>> ;))
>>>>>
>>>> Is there a design document or something I can check out to see what's
>>>> coming? :)
>>>>
>>> mmhh.. mostly in my head, but probably its good to share thoughts on
>>> christmas..
>>>
>>>
>>>>
>>>>> Toni
>>>>>
>>>> Cheers,
>>>> Todor
>>>>
>>>> --
>>>> Go on! Destroy the fabric of the universe! See if I care!
>>>>
>>>
>>>
>>> --
>>> Toni Menzel
>>> Independent Software Developer
>>> Professional Profile: http://okidokiteam.com
>>> t...@okidokiteam.com
>>> http://www.ops4j.org - New Energy for OSS Communities - Open
>>> Participation Software.
>>>
>>>
>>
>>
>
>
> _______________________________________________
> general mailing list
> general@lists.ops4j.org
> http://lists.ops4j.org/mailman/listinfo/general
>
_______________________________________________
general mailing list
general@lists.ops4j.org
http://lists.ops4j.org/mailman/listinfo/general
