felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tuomas Kiviaho (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (FELIX-3607) ThreadIO doesn't utilize changed system streams after bundle activation
Date Thu, 16 Aug 2012 07:47:37 GMT

     [ 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
> 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


View raw message