Tuomas Kiviaho created FELIX-3607:
-------------------------------------
Summary: ThreadIO doesn't utilize changed system streams after
bundle activation
Key: FELIX-3607
URL: https://issues.apache.org/jira/browse/FELIX-3607
Project: Felix
Issue Type: Bug
Components: Configuration Admin, Gogo Runtime
Affects Versions: gogo.runtime-0.12.0
Reporter: Tuomas Kiviaho
Priority: Minor
I use maven failsafe to run integration test fragments inside external osgi
framework and remote gogo is used to bridge forked failsafe execution with a
bundled failsafe junit provider. Everything has worked fine until I noticed
that once executing thread changes. Then I seem to start receiving
surefire/failsafe directives along with whatever is printed to system streams.
When thread execution stays the same there is no problem
'Hello World' -> server[failsafe] ->
'3,0001,Hello World' -> server[telnetconsole] ->
'3,0001,Hello World' -> client[telnetconsole] ->
'3,0001,Hello World' -> client[failsafe] ->
'Hello World'
but thread changes due to using log service for instance then the message isn't
coming back (which is perfectly normal) but instead is poured over to System.out
'Hello World' -> server[logservice] ->
'Hello World' -> server[loglistener] -> // here we have a different thread
'Hello World' -> server[failsafe] ->
'3,0001,Hello World' -> server[telnetconsole] ->
'3,0001,Hello World' -> System.out // and here thread local can't be found so
System.out is used as fallback mechanism
or that's what I think was meant to be. Actually the printing is done to some
ancient System.out that was set during the bundle got active. Failsafe infact
pushes and pops the System.out in between without Gogo noticing it.
This kind of possiblility could be taken into account by wrapping the system
in, out and error to a dedicated FilteredStreams that use the previously
obtained streams in case system streams do not point to ThreadIOImpl's err,out
and in anymore. The close() method already contains similar logic.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
