[jira] [Created] (FELIX-3607) ThreadIO doesn't utilize changed system streams after bundle activation

["Tuomas Kiviaho (JIRA)" <ji...@apache.org>]

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

        

[jira] [Updated] (FELIX-3607) ThreadIO doesn't utilize changed system streams after bundle activation

["Tuomas Kiviaho (JIRA)" <ji...@apache.org>]

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

Tuomas Kiviaho updated FELIX-3607:
----------------------------------

    Attachment: gogo-runtime.patch

Here's a patch for the issue which uses always the latest System.in/out/err and not the one that was present at the time the bundle activator got started. This way for instance sysout-over-slf4j can be registered after gogo runtime. 

ThreadIO has to be now aware of the possibility wind up in indefinite loop so if printing is already in progress which might happen inside of gogo session if somebody registers temporary System.in/out/err wrappers. 
                
> 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
>         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: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira