Mailing-List: contact dev-help@felix.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@felix.apache.org
Date: Mon, 31 Dec 2012 20:06:12 +0000 (UTC)
From: "Felix Meschberger (JIRA)" <jira@apache.org>
To: dev@felix.apache.org
Message-ID: <JIRA.12599975.1343125887130.66508.1356984372295@arcas>
In-Reply-To: <JIRA.12599975.1343125887130@arcas>
References: <JIRA.12599975.1343125887130@arcas>
Subject: [jira] [Updated] (FELIX-3607) ThreadIO doesn't utilize changed
 system streams after bundle activation
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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