Is there a specific reason you are not using the latest version of Felix? I
know we had some problems on jamvm and getting security to work there might
be tricky - anyways, it would be worthwhile to test with Felix 4.6.0 if
possible.
regards,
Karl
On Wed, Jan 21, 2015 at 9:29 AM, Jerry Wang
When using felix 4.2 in java SE in ubuntu, it works. Is it meaning that
the felix is OK?
On 2015-1-21 23:48, Karl Pauls wrote:
Is there a specific reason you are not using the latest version of Felix? I
know we had some problems on jamvm and getting security to work there might
be tricky -
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?
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 b...@romandie.com wrote:
Hello Derek
I then
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
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).
Hi Bernd,
Thank you for your answer.
In the regular SE, I did the test. The command line is java
-Dorg.osgi.framework.security=osgi
-Dpolicy.provider=gnu.java.security.policyFile
-Djava.security.policy=all.policy -cp
Hi,
Sorry, the command line i used is jamvm
-Dorg.osgi.framework.security=osgi -Dpolicy.provider=gnu.java.
security.PolicyFile -Djava.security.policy=file:///data/osgi/all.policy
-cp bin
/felix.jar:/usr/local/classpath/lib/classpath:/usr/local/classpath/share/classpa
th:/lib -Xms4M
It looks like it is not caused by the policy file but by the felix security
manager. It looks like you unpacked the framework JAR? That might be the
problem. (No codesource)
(other possibilities might be a different file path normalisation. Did you
try the same setup with a regular SE?)
Bernd
Am
The security manager of Java SE is debugged with those properties:
http://docs.oracle.com/javase/7/docs/technotes/guides/security/troubleshooting-security.html
But I dont know if this also applies to GNU CP (in fact a quick glimpse
over the source only shows a few JUL logger entries. So maybe it
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
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
12 matches
Mail list logo