Happy New Year, sorry, somehow overlooked that mail. On 27.12.2009, at 11:35, Miroslav Pokorny wrote:
> 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. Sure.. in your setup you might get such problem, however, the method scanning (reflection) inside the target fw should skip those (unrelated) methods. Feel free to submit a simple example/fix /jira issue if it does not. > > 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 ? Well, its a nature of pax runner to be very much online. There are ways to overwrite the platform with static resources (file url). However, there's a native container implementation based on osgi core r4.2 api that gives you pretty much maximum cross fw level control but without the pax runner benefits (of cause). > > 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. This is also part of an internal fork i am doing: provide a raw api to constuct, run and evaluate your test(s) including custom test probes. Its pretty much experimenting with all kinds of ideas that i want to demo (in a brainstorming manner) at OSGi Devcon London (end of february). Though, time is running away like nothing, and there's also the daily business. Will keep the list in touch with things. Toni > > > Thats it! > > mP > _______________________________________________ > 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
