Re: Using JNI to determine whether an object implements an
interface
On Sun, 21 Nov 2010, Steve Sobol wrote:
On Sun, 21 Nov 2010 21:52:24 +0000 (UTC)
Martin Gregorie <martin@address-in-sig.invalid> wrote:
On Sun, 21 Nov 2010 11:58:40 -0800, Steve Sobol wrote:
Yes. Really, my goals are (a) tight integration with the OS and (b)
convenience. I mean, sure, you could use JMX to control your app. But
how are you going to launch that app? I'm not all that familiar with
JMX/RMI/CORBA, but my impression is that you still need some mechanism
to instantiate and control Java objects.
In a *nix environment all you need do is "java progname args &" and its
off and running as a background task, or you can use the 'daemon' shell
script function.
Agreed, although as mentioned, part of the problem with "java progname
args &" is what shows up when you do a 'ps' -- I want to be able to see
my app's name, not "java" followed by a long list of arguments.
This seems to be a fairly big driver for what you're doing; it may well be
that there are no good existing solutions for this, because i suspect
that, like me, most people aren't bothered about this. I'm used to doing
ps -f and looking deep into the command line to see what a process is
really doing. It's also easy enough to knock up scripts to help with this
- we have one that lists all the running JBoss instances by looking for
/usr/bin/java processes running org.jboss.Main or whatever with a -c
argument somewhere down the line.
Still, on the unix side, you may find that
exec -a myappsname java -long -list -of -arguments
does what you need. Doesn't help with windows, of course.
Oh, and if you're going to use &, you probably want to use disown too,
otherwise when the terminal that started the process exits (eg the user
logs out), the process will get killed.
Anything else is done by sending signals to the service, not something
Java can easily handle
Martin, you are a genius. :) I'd completely forgotten about using
signals... probably because it's been a LONG time since the last time I
did any serious *ix programming.
And didn't read my earlier post carefully enough either!
Say I have a program written in Java - let's call it
com.lobosstudios.MyService I use LaunchJVM to create a native launcher,
let's call it linux-native-service If you send a signal to such a
program, you'll be sending the signal to my C++ stub
(linux-native-service), which can trap the signal and take the
appropriate action (i.e., call one of the methods exposed by
com.lobosstudios.MyService).
Hopefully. As has been pointed out, the JVM will be doing some signal
handling. If it's well-behaved, it won't interfere with handling of any
signals it isn't interested in; you will probably need to use a process of
trial, error, and crossed fingers to find those. Off the top of my head, i
think it does listen for both SIGUSRs, and definitely SIGQUIT, but not
SIGHUP. I doubt it listens for any of the high-numbered SIGRTetc signals
on linux.
Still, i think i'd go for a named pipe: after the launcher writes its PID
to a file, it can open a named pipe somewhere and then read from it; the
control tool can write to it to send commands. It's not vulnerable to
interference from the JVM, it has a simple and familiar programming model
(no need to think about what functions are safe to use in signal handlers,
or implement some sort of internal message queue), it allows much richer
communication than signals, it's easy on the sending side, and it allows
feedback. You could also look at unix domain sockets, but i like the fact
that named pipes exist as objects in the filesystem.
ssh uses named pipes in this way in its 'control master' mechanism, if you
want to see an example of this.
tom
--
VENN DIAGRAM THAT LOOK LIKE TWO BIG CIRCLES EQUAL BAD PUBLIC POLICY.