Use ISIG flag for our stty call from jline, in order to translate INT to ^C.
ISIG was added in "Add interrupt and quit keys" (d7292625).

This is related to issue #53.

Reviewed-by: Tomasz Grabiec <tgrabiec@gmail.com>
Signed-off-by: Or Cohen <orc@fewbytes.com>
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>

When using the MultiJarLoader as the main class, it will use a
configuration file for the java loading.  Each line in the file will be
used to start a main, you can use -jar in each line or specify a main
class.

Signed-off-by: Amnon Heiman <amnon@cloudius-systems.com>
Reviewed-by: Tomasz Grabiec <tgrabiec@cloudius-systems.com>
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>

Use four spaces for indentation and use UNIX linefeeds.

Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>

This patch adds to support multiple NIC initialization on loader.cc.

Signed-off-by: Takuya ASADA <syuu@dokukino.com>
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>

Signed-off-by: Tomasz Grabiec <tgrabiec@cloudius-systems.com>

Makes this go away:

  Note: io/osv/OsvSystemClassLoader.java uses unchecked or unsafe
  operations.  Note: Recompile with -Xlint:unchecked for details.

Unfortunately javac does not recognize statement level suppressions
like this:

  //noinspection unchecked
  return (T) method.invoke(target, args);

I need to switch to more coarse grained suppression on method level:

  @SuppressWarnings("unchecked")

Signed-off-by: Tomasz Grabiec <tgrabiec@cloudius-systems.com>

When system classloader is used as a parent some of its protected
methods are called to lookup resources.

This also adds delegation for all remaining protected and public
methods.

Signed-off-by: Tomasz Grabiec <tgrabiec@cloudius-systems.com>

Signed-off-by: Or Cohen <orc@fewbytes.com>

Signed-off-by: Tomasz Grabiec <tgrabiec@cloudius-systems.com>

Related changes previously made in java/build.xml
were reverted and moved to java/runjava/build.xml

Signed-off-by: Tomasz Grabiec <tgrabiec@cloudius-systems.com>

The system classloader should have classes which were
specified in the command line using -cp/-classpath/-jar.
Before this change only runjava.jar was included.

System class loader is queried explicitly by
java.util.logging framework to lookup classes
configred in logging properties file.

To solve this problem a custom system classloader
is set when starting JVM. It delegates to the application
classloader created when java program was started.

It also handles the case when a new java application
is started within the same JVM. Such application
should have its own view of system classes. However
we are able to install only one system classloader
per JVm. To solve this we start each java application
in a separate thread and use InheritableThreadLocal
to hold the application class loader which should be
used as system class loader view for the thread family.

Signed-off-by: Tomasz Grabiec <tgrabiec@cloudius-systems.com>

Building with ant requires no changes in the build scripts
when new classes are added. It is a standrd tool to build
java programs.

Signed-off-by: Tomasz Grabiec <tgrabiec@cloudius-systems.com>

This is patch v2, incorporating most of the comments from the previous round.

Solves issue #47:

elf::program's API - add_object() and remove_object() was problematic in
two respects:

1. It did not do reference-counting on the loaded object, so if add_object()
   was done 5 times, a single remove_object() would unmap the object and
  its 4 other users will crash.

2. It is un-C++-like.

This patch replaces these two functions by a single function get_library():

  std::shared_ptr<elf::object>
   get_library(std::string lib, std::vector<std::string> extra_path = {});

get_library() returns a shared_ptr, which is reference counting and does
proper C++-style RAII. For example in the code:

	auto lib = elf::get_program()->get_library(path);
	auto main = lib->lookup<int (int, char**)>("main");
	int rc = main(argc, argv);

once lib out of scope, the reference count of the elf::object automatically
goes down, and if nobody else holds another shared-pointer to the same
library, the object is destroyed (causing the shared library to be unloaded).

This patch also documents, with Doxygen, all the functions it touches.

IMPORTANT NOTE: This reference count is completely unrelated to the issue
of concurrent use of dlopen()/dlclose()/dl_iterate_phdr(), which is still
buggy and we need to fix (I have a patch for that, but it's too long to fit
in the margin).

Signed-off-by: Nadav Har'El <nyh@cloudius-systems.com>

URLClassLoader determines whether URL denotes a jar or directory
by checking the last character of the path.

Before:

   [/]% java -cp java Hello
   Uncaught Java exception:
   java.lang.ClassNotFoundException: Hello
       at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
       at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
       at java.security.AccessController.doPrivileged(Native Method)
       at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
       at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
       at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
       at io.osv.RunJava.loadClass(RunJava.java:175)
       at io.osv.RunJava.runClass(RunJava.java:115)
       at io.osv.RunJava.parseArgs(RunJava.java:81)
       at io.osv.RunJava.main(RunJava.java:27)

After:

   [/]% java -cp java Hello
   Hello, world.

Signed-off-by: Tomasz Grabiec <tgrabiec@cloudius-systems.com>

Currently we call abort() if something is wrong whith
java.so command. Now that we allow to run processes from
the command line this may not be the best behavior because
a problem with starting a less import program will abort
the system:

  [/]% run java.so -cp java Hello
  run_elf(): running main() in the context of thread 0xffffc0000c30b010
  java.so: Can't create VM.
  Aborted

Instead of that we could just return and the system can
be still usable:

  [/]% run java.so -cp java Hello
  run_elf(): running main() in the context of thread 0xffffc0000c30b010
  java.so: Can't create VM.
  run: finished with exitcode 1

  [/]%

Signed-off-by: Tomasz Grabiec <tgrabiec@cloudius-systems.com>

This is needed to start the JVM with debugger interface.

Signed-off-by: Tomasz Grabiec <tgrabiec@cloudius-systems.com>

We use the RunJava Java class to run Java applications (both java.so
and the "java" CLI command use it). We used to have RunJava.class
uncompressed, in the /java directory, but this caused two problems:

1. Or noticed that having a directory (/java) on the classpath causes
   thousands of stat() calls when Java tries to look for all classes
   in this directory. With a jar, its contents are read only once.

2. The "java" CLI command (java.groovy) didn't work because apparently
   Groovy cannot deal with classes being in the top-level package.

   So this patch moves RunJava into the io.osv package, and put it into a jar
   /java/runjava.jar.

   Note that java.groovy is changed in a separate patch (because it's in
   a different sub-repository....)

Signed-off-by: Nadav Har'El <nyh@cloudius-systems.com>

Add "-version" option to RunJava, and therefore to java.so and the "java"
CLI command.

java -version now shows:

  java version "1.7.0_25"
  OpenJDK Runtime Environment (1.7.0_25-mockbuild_2013_07_27_13_36-b00)
  OpenJDK 64-Bit Server VM (build 23.7-b01, mixed mode)

I can't explain why the version on the second line is different than what
"java -version" on Fedora 18 shows for the same libjvm.so:

  java version "1.7.0_25"
  OpenJDK Runtime Environment (fedora-2.3.10.4.fc18-x86_64)
  OpenJDK 64-Bit Server VM (build 23.7-b01, mixed mode)

Signed-off-by: Nadav Har'El <nyh@cloudius-systems.com>
Signed-off-by: Avi Kivity <avi@cloudius-systems.com>

JavaVMOption has extraInfo member that's not initialized in mkoption().
It only used by few special case options that provide a function pointer
hook to the JVM so it's harmless but fix it anyway.

Spotted by Coverity.

Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>

Add Cloudius copyright statement to files in java/. All of these (one C++
java.cc and the rest Java source code) are our own code.

Pass the "-D" command line options that are used to configure JMX, for
example, to the JVM.

Added a new function, osv::reboot() (declared in <osv/power.hh>)
for rebooting the VM.

Also added a Java interface - com.cloudius.util.Power.reboot().

NOTE: Power.java and/or jni/power.cc also need to be copied into
the mgmt submodule.

In the existing code, each -classpath or -jar paramter replaced the
classpath. This is inconvenient (and unlike the Unix "java" program).
Better just add to the classpath.

For example, now we can run:

  java.so -cp /java/cli.jar -jar /java/web.jar app

  Which runs web.jar's main class, but adds both cli.jar and web.jar
  to the classpath.

This is a fix for the previous commit (717693) that had an implicit
dependency on Ant js.jar

Breaks the build

A straightfoward implementation for SSHD
Supports SCP, SFTP subsystem and a shell through the current JS cli

Broken by 92b6753b.

The test command of the CLI didn't work because Javascript cannot work
with a Java String[] array as if it is a JS array, I was surprised to see
92b6753b and I assumed it works but
apparently the test command got broken.

This patch properly returning a Scriptable object that Javascript
code understands, it acquires a thread specific Rhino Context that
is used to cast the test names to a JS array, and from there the JS
code picks it up.

Pass -X* (and of course also -XX*) options to the JVM.
The -Xmx option is the most useful example.

The JVM options end with the first "-jar" *or* classname, not *and*.
Fix the typo.

Our CLI changes the console's tty mode to raw when doing its line
editing, and back to the original (cooked) mode when running a command.
Obviously, when we're running on a telnet connection we shouldn't touch
the console's mode like the existing code did.

OSV doesn't (at least for now) have ptys, so we can't handle the
telnet connection exactly like we handled the console, and the kernel
can't implement a "cooked" line discipline for us like it implemented on
the console. But we can do a very similar thing in Java instead:

This patch adds a new Java class, "TTY", which has an input and output
stream and an "stty" interface. We have one implementation for the console
(using System.in, System.out and the console's Stty), and a different
implementation, TelnetTTY, for a telnet connection.

This patch does not currently implement a line discipline ("cooked mode")
for this TelnetTTY, so it will always stay in raw mode. This is fine for all
our current uses of the CLI, but if in the future we have commands that read
user input and expect cooked mode (echo, line editing), we'll need to
implement this line discipline.

This patch adds a simple telnet server to OSV, implemented in Java.
One can telnet to the VM's IP address (default port 23) and get a CLI
shell. Multiple concurrent telnet sessions are supported (and the shells
are independent, as expected).

To start the telnet server, simply run the com.cloudius.cli.util.TelnetCLI
class. For example, in the CLI to start a telnet server in the background
use:

	java com.cloudius.cli.util.TelnetCLI &

To start OSV with only a telnet server, try

	sudo scripts/run.py -c1 -nv -m2G -e "java.so -jar
		/java/cli.jar java  com.cloudius.cli.util.TelnetCLI"

(The "cli.jar" in the last example is only needed to set the IP address...)

In the future we can turn the telnet server on by default - but let's
add a password feature first :-) Right now, there's no password requested
when someone telnets in.

The CLI used to assume it was using System.in, System.out (which point
to the console). Now make these parameters. We need this so we can run the
CLI on a telnet connection, and it doesn't send output to the console or try
to read from it.

RhinoCLI relied on a bunch of global Java variables such as _cx and _args.
This was not only ugly, it also prevents us from running multiple instances
of the CLI on the same JVM - e.g., to support multiple telnet connections.

There isn't actually a need for these JVM-wide global variables. At most,
we need to global use variables in the Javascript interpreter (so each
instance of the interpreter would have its own copy).

This patch puts main's arguments in a new global-per-javascript-interpreter
variable "mainargs" instead of the global-for-entire-JVM _args. "_cx" isn't
needed at all: one of uses was to for Java to convert a String[] into the
equivalent Javascript alternative - but Java should just return String[]
and let Javascript worry about handling that (it seems to work just fine
without change). A second use was for returning an exit code, but a more
appropriate methods to do the same thing without global variables exist.