[
http://issues.ops4j.org/browse/PAXEXAM-175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13350#action_13350
]
Toni Menzel edited comment on PAXEXAM-175 at 3/30/10 5:50 PM:
--------------------------------------------------------------
yep. But i am not sure if waiting for all bundles to be started is not really
always true:
- fragments
- bundles that i want in resolved or installed state only by purpose
So, first thing you should use is startlevels, to structure your own bundles as
well as 3rd party bundles in a way, that things like logging work at the
expected point in time.
Solutions:
What i could think of is to have an interceptor in config method that lets you
determine if the container is ready or not.
Like:
[code]
options(
waitCondition(
new Condiition() {
boolean active(Bundle[] bundles, Integer[] states) {
.. (.implement your condition here.)
}
}
)
)
[code]
the condition will run at there place where your "hack" is currently at, ant
repeated until its either "true" or timed out.
This will be executed in the host jvm (the one your junit runs in), thats why
you don't get a full BundleContext.
That would be the Exam 1.2.x solution i guess which does not change the as-is
strategy.
For 2.0 i have a precondition hook in mind that also runs on the server.
wdyt?
Any ideas?
was (Author: tonit):
yep. But i am not sure if waiting for all bundles to be started is not
really always true:
- fragments
- bundles that i want in resolved or installed state only by purpose
So, first thing you should use is startlevels, to structure your own bundles as
well as 3rd party bundles in a way, that things like logging work at the
expected point in time.
Solutions:
What i could think of is to have an interceptor in config method that lets you
determine if the container is ready or not.
Like:
options(
waitCondition(
new Condiition() {
boolean active(Bundle[] bundles, Integer[] states) {
.. (.implement your condition here.)
}
}
)
)
the condition will run at there place where your "hack" is currently at, ant
repeated until its either "true" or timed out.
This will be executed in the host jvm (the one your junit runs in), thats why
you don't get a full BundleContext.
That would be the Exam 1.2.x solution i guess which does not change the as-is
strategy.
For 2.0 i have a precondition hook in mind that also runs on the server.
wdyt?
Any ideas?
> 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
