felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Felix Meschberger (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (FELIX-3607) ThreadIO doesn't utilize changed system streams after bundle activation
Date Mon, 31 Dec 2012 20:06:12 GMT

     [ https://issues.apache.org/jira/browse/FELIX-3607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Felix Meschberger updated FELIX-3607:

    Component/s:     (was: Configuration Admin)
> 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
> 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

View raw message