Re: Gogo output not always showing
OK, so one fix would be to run my command in a new thread created from within the gogo command and thus inheriting its ThreadLocals. I can't use ExecutorService, but that's not a big blocker. Will try that... Regards Philipp On 21.01.2015 13:35, Derek Baum wrote: I’ve thought more about this. The gogo telnet daemon creates a new CommandSession, using the IO streams to the telnet client, which has the expected result of re-directing IO to the telnet client. gogo’s ThreadIO uses InheritableThreadLocal to manage the per-thread IO, so that any new thread that inherits from the initial gogo thread will also have its IO redirected to the telnet client. However, in your case, the command that writes to System.out is NOT run in a thread inherited from gogo, and thus appears on the default JVM console. A possible solution is to change the signature of your command to include CommandSession as the first argument, you can then use session.getConsole() to get the output stream used to create the session i.e. the telnet client. However, doing this will mean that you can’t pipe the output of your command, as it will always write to the console. — Derek On 21 Jan 2015, at 11:42, Bulu wrote: 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 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=INTERFACElisten interface (default=127.0.0.1) -p --port=PORT listen port (default=2019) -? --helpshow 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 ---
Re: Gogo output not always showing
I’ve thought more about this. The gogo telnet daemon creates a new CommandSession, using the IO streams to the telnet client, which has the expected result of re-directing IO to the telnet client. gogo’s ThreadIO uses InheritableThreadLocal to manage the per-thread IO, so that any new thread that inherits from the initial gogo thread will also have its IO redirected to the telnet client. However, in your case, the command that writes to System.out is NOT run in a thread inherited from gogo, and thus appears on the default JVM console. A possible solution is to change the signature of your command to include CommandSession as the first argument, you can then use session.getConsole() to get the output stream used to create the session i.e. the telnet client. However, doing this will mean that you can’t pipe the output of your command, as it will always write to the console. — Derek > On 21 Jan 2015, at 11:42, Bulu wrote: > > 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 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=INTERFACElisten interface (default=127.0.0.1) > -p --port=PORT listen port (default=2019) > -? --helpshow 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 >>> >>> --
Re: Gogo output not always showing
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 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=INTERFACElisten interface (default=127.0.0.1) -p --port=PORT listen port (default=2019) -? --helpshow 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
Re: Gogo output not always showing
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 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=INTERFACElisten interface (default=127.0.0.1) >>> -p --port=PORT listen port (default=2019) >>> -? --helpshow 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 >
Re: Gogo output not always showing
just add the command to start telnet to gosh.args: java -Dgosh.args='--nointeractive -c telnetd start' -jar bin/felix.jar Note: if you are using Java 8, you need gogo.shell (0.12.0) to fix FELIX-4425 — Derek > On 21 Jan 2015, at 08: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=INTERFACElisten interface (default=127.0.0.1) >> -p --port=PORT listen port (default=2019) >> -? --helpshow 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
Re: Gogo output not always showing
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=INTERFACElisten interface (default=127.0.0.1) -p --port=PORT listen port (default=2019) -? --helpshow 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
Re: Gogo output not always showing
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=INTERFACElisten interface (default=127.0.0.1) -p --port=PORT listen port (default=2019) -? --helpshow 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
Re: Gogo output not always showing
> On 20 Jan 2015, at 15:24, Bulu wrote: > > Hello > > In my gogo commands, I use simple System.println(...) calls to output things > to the gogo shell. (is that the correct way?) Yes, goo is designed so commands can simply use System.out.println(…) > > 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=INTERFACElisten interface (default=127.0.0.1) -p --port=PORT listen port (default=2019) -? --helpshow help g! telnetd start telnetd is running on 127.0.0.1:2019 g! — Derek
Gogo output not always showing
Hello In my gogo commands, I use simple System.println(...) calls to output things to the gogo shell. (is that the correct way?) 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. Stopping and restarting the bundle which exports those commands does not fix the problem. What could cause this behavior and how should I fix it? Thanks & regards Philipp Versions: 0|Active |0|System Bundle (4.2.1) 1|Active |1|Apache Felix Gogo Command (0.14.0) 2|Active |1|Apache Felix Gogo Runtime (0.12.1) 3|Active |1|Apache Felix Gogo Shell (0.10.0) 4|Active |1|Apache Felix Remote Shell (1.1.2) - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
