Merry Xmas,
Changing default source of bundles.
===========================
The problem
----------------
I would like to stop the behaviour where Pax and its collaborators suck down
various bundles from the net and would rather provision them manually. This
all happens depending on the "profile" or profiles one selects like "core",
"web" and so on using PaxRunnerOption. This all started when i need to
modify "org.ops4j.pax.exam.rbc_1.2.0.jar" so that it included the Option
class, due to a NoClassDefFoundError occuring.
[java] java.lang.NoClassDefFoundError: [Lorg/ops4j/pax/exam/Option;
[java] at java.lang.Class.getDeclaredMethods0(Native Method)
[java] at java.lang.Class.privateGetDeclaredMethods(Unknown
Source)
[java] at java.lang.Class.getDeclaredMethods(Unknown Source)
[java] at
org.ops4j.pax.exam.junit.extender.impl.internal.CallableTestMethodImpl.getAnnotatedMethods(CallableTestMethodImpl.java:292)
[java] at
org.ops4j.pax.exam.junit.extender.impl.internal.CallableTestMethodImpl.runBefores(CallableTestMethodImpl.java:162)
[java] at
org.ops4j.pax.exam.junit.extender.impl.internal.CallableTestMethodImpl.injectContextAndInvoke(CallableTestMethodImpl.java:124)
[java] at
org.ops4j.pax.exam.junit.extender.impl.internal.CallableTestMethodImpl.call(CallableTestMethodImpl.java:101)
[java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
[java] at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown
Source)
[java] at
sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
[java] at java.lang.reflect.Method.invoke(Unknown Source)
[java] at
org.ops4j.pax.exam.rbc.internal.RemoteBundleContextImpl.remoteCall(RemoteBundleContextImpl.java:80)
[java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
[java] at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown
Source)
[java] at
sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
[java] at java.lang.reflect.Method.invoke(Unknown Source)
[java] at sun.rmi.server.UnicastServerRef.dispatch(Unknown
Source)
[java] at sun.rmi.transport.Transport$1.run(Unknown Source)
[java] at java.security.AccessController.doPrivileged(Native
Method)
[java] at sun.rmi.transport.Transport.serviceCall(Unknown
Source)
[java] at
sun.rmi.transport.tcp.TCPTransport.handleMessages(Unknown Source)
[java] at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(Unknown Source)
[java] at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(Unknown Source)
[java] at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
[java] at
java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
[java] at java.lang.Thread.run(Unknown Source)
[java] Caused by: java.lang.ClassNotFoundException:
org.ops4j.pax.exam.Option
[java] at
org.apache.felix.framework.ModuleImpl.findClassOrResourceByDelegation(ModuleImpl.java:738)
[java] at
org.apache.felix.framework.ModuleImpl.access$100(ModuleImpl.java:60)
[java] at
org.apache.felix.framework.ModuleImpl$ModuleClassLoader.loadClass(ModuleImpl.java:1650)
[java] at java.lang.ClassLoader.loadClass(Unknown Source)
[java] at java.lang.ClassLoader.loadClassInternal(Unknown
Source)
Examining the stacktrace is obvious that the host test runner within the
osgi container is trying to discover various methods, fields to inject and
so on. Unfortunatel if it encounters a method with a type which it cannot
see like Option it falls over.
Why
-----
The source of the problem Option appearing in a method signature other than
configure is because I have an abstract OsgiTestCase. I use an abstract
OsgiTestCase because it contains numerous abstract and overridable protected
methods which sub classes can pick to override to customize that test rather
than one big configure() method.
Some interesting methods include:
- profile - returns a comma separated string which are used to create
many ProfileOption(s).
- requiredBundles - think of TinyBundles like functionality so the test
can build its own bundles from the filesystem. It does a few other things
like validate bundle classpath entries, bundle activators etc.
My Solution
--------------
One solution was to hack the *rbc.jar in my bundles cache and simply add
Option.class to it so that the relfection looping step shown inthe above
stacktrace can do its thing and not blow up. This hack worked but is fragile
because what if this hacked jar disappears then im back to the above
exception. My final solution so far is to simply eliminate Option from
method signatures replacing it with Object and doing casts inside methods.
Not an ideal solution but it works.
How
-----
This has lead to my question regarding how to change the behaviour whereby
the profile sucks the jars from the net, with an ability to simply provision
the files from the file system. I am unsure how to change the default "mvn"
protocol style and have not attempted to really get into the code. Is there
an easy way to do this ?
How to stop Pax test probe class dep scanning
=====================================
I have no need for any attempt to scan the filesystem to include dependent
classes with the TestCase, myOsgiTestCase does all this by itself by simply
including the test class and any inner classes. If your test needs more
classes that are not visible then one simply does a TinyBundle thing and
simply adds classes. I think this approach is great because I know exactly
whats inside my test probe, for the moment i am using the Customizer class
but there is currently no way Option to kill the scanning.
Thats it!
mP
_______________________________________________
general mailing list
general@lists.ops4j.org
http://lists.ops4j.org/mailman/listinfo/general
