[
http://issues.ops4j.org/browse/PAXEXAM-175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13353#action_13353
]
Toni Menzel commented on PAXEXAM-175:
-------------------------------------
2)
yes but of cause requires exam to do the matching on its own.
It is a little bit harder than it might seem in first place because (at least
when using 1.2.x or the paxrunner container in 2.0) those urls (mavenBundle and
all that produce urls for a certain url handler) are processed by Pax Runner,
actually Exam never sees them.
Matching the bundles by symbolicname however should work in most cases.
It just gets hard when profiles fall into place, as they are definitely not
resolved upfront as its a core piece of pax runner.
So, yes, in the end it should look like that. How we can archive that, we'll
see.
I am strongly target that for the 2.0 branch and do it there with possibly
necessary infrastructure changes in place rather than "hacking" it together for
1.x line.
> PaxLogginApi bundle's BundleContext is no longer valid in PaxExam tests
> -----------------------------------------------------------------------
>
> Key: PAXEXAM-175
> URL: http://issues.ops4j.org/browse/PAXEXAM-175
> Project: Pax Exam
> Issue Type: Bug
> Affects Versions: 1.2.0
> Environment: Linux OS & Windows, Java 1.6
> Reporter: Bartosz Kowalewski
> Assignee: Toni Menzel
>
> From time to time I observe the following error in Pax Exam based tests.
> {code}
> java.lang.ExceptionInInitializerError
> at blah.createCamelContext(AbstractOSGiFlowTest.java:81)
> at blah.AbstractOSGiFlowTest.setUp(AbstractOSGiFlowTest.java:100)
> 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.runBefores(CallableTestMethodImpl.java:172)
> at
> org.ops4j.pax.exam.junit.extender.impl.internal.CallableTestMethodImpl.injectContextAndInvoke(CallableTestMethodImpl.java:124)
> 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)
> Caused by: java.lang.IllegalStateException: BundleContext is no longer valid
> at
> org.eclipse.osgi.framework.internal.core.BundleContextImpl.checkValid(BundleContextImpl.java:1003)
> at
> org.eclipse.osgi.framework.internal.core.BundleContextImpl.getBundle(BundleContextImpl.java:151)
> at
> org.ops4j.pax.logging.OSGIPaxLoggingManager.getLogger(OSGIPaxLoggingManager.java:94)
> at
> org.apache.commons.logging.LogFactory.getInstance(LogFactory.java:269)
> at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:164)
> at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:146)
> at
> org.apache.camel.impl.DefaultCamelContext.<clinit>(DefaultCamelContext.java:106)
> ... 28 more
> {code}
> As I said it happens from time to time. I thought that it is because the Pax
> Logging bundle hasn't been started yet, while the client app already uses
> logging API. Nevertheless, I got 'IllegalStateException: BundleContext is no
> longer valid' and not NPE, so I'm puzzled.
> I thought that adding a wait (wait for state) for Pax Logging bundles would
> solve this issue. This could (probably) be incorporated into the logProfile.
> I think that currently the only bundle for which the pax container waits
> before starting the test method is the system bundle. It does not wait for
> other bundles. However, as I wrote above, I'm worried that I'm getting
> IllegalStateException instead of NPE - I'm not sure if adding additional
> waits would help.
> Oh, one more thing. Of course the brute force workaround that I used in
> PAXEXAM-174 also got rid of the 'IllegalStateException: BundleContext is no
> longer valid' error ]:->.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.ops4j.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
_______________________________________________
general mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/general
