[
https://issues.apache.org/jira/browse/FELIX-3607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13541481#comment-13541481
]
Felix Meschberger commented on FELIX-3607:
------------------------------------------
The patch looks good to me.
Could someone else knowledgeable with the ThreadIO stuff have a look, too ?
Thanks.
(Removed the config admin component, because this looks like unrelated)
> 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: Gogo Runtime
> Affects Versions: gogo.runtime-0.12.0
> Reporter: Tuomas Kiviaho
> Priority: Minor
> Attachments: gogo-runtime.patch
>
>
> 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
For more information on JIRA, see: http://www.atlassian.com/software/jira
