My command is not doing anything fancy with System.out - just calling
println(). Also I couldn't find any call to System.setOut() in my code.
If the System.out is set globally how is it possible that some commands
write to gogo shell while, at the same time, others write to the java
std-out? It should really be the same for all, no?
Also, regarding your grep example: if you execute a command with grep
(lb | grep "foo") but at the same time another thread writes to the
System.out (say some console logging), this will also be "grepped" right?
As System.setOut() is a native call, maybe it's a JVM problem? I'm on
Oracle VM 1.7.0_60 on ARM v7.
Regards Philipp
On 21.01.2015 12:15, Derek Baum wrote:
System.out is global within the JVM.
The ThreadIO classes in gogo manage System.out (and System.in & System.err) on
a per-thread basis using System.setOut(PrintStream out) etc.
This allows commands to simply read and write System.in & System.out and work
accordingly.
For example:
g! lb -s
The lb command write to System.out is actually written to the console
g! lb -s | grep gogo
The lb command write to System.out is actually written to a pipe created by
gogo.
For this to work, no other bundles must be attempting a similar thing.
i.e. if a bundle caches the value of System.out and later uses it in a call to
System.setOut() then it could upset gogo’s ThreadIO mechanism.
I suggest examining your problem command to see exactly how System.out is
obtained and whether there are any calls to System.setOut().
—
Derek
On 21 Jan 2015, at 08:54, Bulu <b...@romandie.com> wrote:
Hello again
Using the internal telnetd does not fix the problem, output of this one command
is still going to the java exe std-out instead of the gogo shell.
But the command giving me problems is maybe not very standard:
For one, it executes in a separate thread (not the shell/gogo thread). This
thread comes from a ExecutorService.newFixedThreadPool(1).
Second, the actual command (and its System.out.println) are implemented in a
separate service (not the bundle which exports the gogo command).
Could any of these create the problem as described?
Regards Philipp
On 21.01.2015 09:12, Bulu wrote:
Hello Derek
I then access gogo through telnet (Felix Remote Shell 1.1.2). Sometimes
(rarely), certain of my commands do no longer output to the shell, instead the
output is really going to the std-out of the java application. Note that at the
same time, other of my own commands in the same bundle still work as expected
and output to the gogo shell.
The Felix remote shell was designed to work before gogo was introduced.
gogo has its own simple telnet daemon:
Welcome to Apache Felix Gogo
g! type telnetd
telnetd is void gogo:telnetd(String[])
true
g! telnetd -?
telnetd - start simple telnet server
Usage: telnetd [-i ip] [-p port] start | stop | status
-i --ip=INTERFACE listen interface (default=127.0.0.1)
-p --port=PORT listen port (default=2019)
-? --help show help
g! telnetd start
telnetd is running on 127.0.0.1:2019
g!
Thanks - I wasn't aware of that internal telnet daemon. I currently start the
framework in non-interactive mode (gosh.args=--nointeractive) and rely on the
telnet daemon to connect to the shell. How can I make gogo's telnetd start by
itself?
Regards Philipp
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
