how to get Process object from a thread (Runnable)
Marteno Rodia
this question follows a similar question I've already asked before,
but now it will bo more specyfic. Let's imagine I have some code (a
part of a bigger program) for which I want to redirect output and
error streams into a log file. I can do this using
Process.getErrorStream() and Process.getInputStream() functions. I can
also put the appropriate part of my code (which in fact has not been
written by me) into the run() method of an anonymous class
implementing the Runnable interface, but... there is one problem:
How to get a Process object out of the Runnable object? Is it possible
by any means?
MR
Nigel Wade
> Hello,
> this question follows a similar question I've already asked before,
> but now it will bo more specyfic. Let's imagine I have some code (a
> part of a bigger program) for which I want to redirect output and
> error streams into a log file. I can do this using
> Process.getErrorStream() and Process.getInputStream() functions.
A Process object refers to an external executing process with its own
input/output streams. Process's getErrorStream/getInputStream allows the JVM to
read the external Process's output and error streams. It doesn't allow you to
redirect the JVM's output and error streams.
I believe you may be able to do this by opening a file and then using
System.setErr/setOut, but you'd need to check that. However, I'm sure you'd be
better off investigating the use of a Logger.
> I can
> also put the appropriate part of my code (which in fact has not been
> written by me) into the run() method of an anonymous class
> implementing the Runnable interface, but... there is one problem:
>
> How to get a Process object out of the Runnable object? Is it possible
> by any means?
>
A Runnable is code to be executed on a thread within the JVM process. If you
could get a Process associated with a Runnable it would be the JVM process. If
you redirect the output for your Runnable code you also redirect it for all
other threads in the JVM because all threads are executed by the JVM and share
the same input/output/error streams.
--
Nigel Wade
Matt Humphrey
"Marteno Rodia" <marten...@o2.pl> wrote in message
news:aaaa4f84-4ffe-4ba5...@n4g2000vba.googlegroups.com...
Runnables are Processes are not related. A Runnable is a fragment of code
within the local JVM that can be executed in a thread. A Process is a
separate application outside of the JVM. Processes have input / output
streams but no access to the JVM memory. Runnables can access all of
memory, but do not have independent streams.
There's no way you can redirect output from only a part of your program,
unless you have some control over the stream for that part of the program
itself.
It is possible, however, for you to launch your code fragment into a
separate application. Just write a main for it (although that could be
tricky.) Launch it as a Process and connect the streams. If you can make
the program read from a file and write to a file, the job will be much
easier--check out the well-documented gotchas on launching processes that
produce output.
Matt Humphrey http://www.iviz.com/
Eric Sosman
No, because Runnable has nothing to do with Process:
they are unrelated. You can use Runnable without Process,
and you can use Process without Runnable. The only methods
a Runnable class is guaranteed to have are run() and the
methods common to every Object.
If you have a class of your own that implements Runnable
and manages a Process object, you can write your own method
to retrieve the Process from it. If your class extends
Process it's even easier :-)
Daniel
Please clarify:
- you got some functionality
- you want it multithreaded or to run in a separate thread
- you want your threads to share an object of class Process that will
serve the purpose you mentioned.
Is this correct?
Daniel
Daniel
<marten...@o2.pl> wrote:
I apologise, was a misunderstanding.
You can use log4j to operate the logging from your threads and will
work very well
or
do you have your own logging infrastructure?
- Create your custom logging context (an object of a class you
implemented that has two methods one for regular logging, the other
for error logging)
- Instead of having an anonymous runnable implementations, create a
class that extends Thread and has an additional attribute - your
logging object. In the run - place the functionality you menttioned.
- Create first the logging object
- Then create your threads, and pass the reference to the logging
object to them
- Start the threads.
Of course, the access to the logging object should be somehow synched
Daniel
Matt Humphrey
"Matt Humphrey" <ma...@iviz.com> wrote in message
news:fdadnQJjeP1...@giganews.com...
> Runnables are Processes are not related. A Runnable is a fragment of code
John B. Matthews
"Matt Humphrey" <ma...@iviz.com> wrote:
The typo was easy to figure out, but I was less sanguine about the
notion of "fragment of code". If I may amplify: A class that implements
the Runnable interface "must define a method of no arguments called
run." [1] If a Thread is constructed with an instance of a Runnable
class, the run() method is invoked when the Thread is started. [2, 3]
Of course, as you helpfully observed, the OP can execute arbitray Java
code in a separate virtual machine, if desired:
Process p = Runtime.getRuntime().exec("java MyRunnable"); [4]
[1]<http://java.sun.com/javase/6/docs/api/java/lang/Runnable.html>
[2]<http://java.sun.com/javase/6/docs/api/java/lang/Thread.html>
[3]<http://java.sun.com/docs/books/tutorial/essential/concurrency/runthread.html>
[4]<http://groups.google.com/group/comp.lang.java.programmer/msg/3a52ecfb9ab8fc1f>
--
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>
Lew
> do you have your own logging infrastructure?
> Of course, the access to the logging object should be somehow synched
An advantage of both log4j and the inbuilt java.util.logging framework is that
they do the synching for us.
--
Lew
Daniel
I fully concur and I use log4j in my applications 100% for this reason
and many others (it is already done with various appender types etc),
however the gentleman wanted to operate with his own logger probably
to address a specific requirement...
Regards,
Daniel
Marteno Rodia
> Please clarify:
> - you got some functionality
yes, definately
> - you want it multithreaded or to run in a separate thread
To be precise, I have a multi-threaded application, and I want to
supress messages just for a part of one thread. The code which is
executed here hasn't been written by me.
> - you want your threads to share an object of class Process that will
> serve the purpose you mentioned.
I want to get a Process object just for this part of one of my
threads. I could launch another Thread for it, but the problem is
still I cannot get the Process object.
***
The trick with loggers is also not a good idea, because I don't want
to/can't modify not my own code.
MR
Nigel Wade
> On May 26, 6:51 pm, Daniel <dan...@proghowto.com> wrote:
>> Please clarify:
>> - you got some functionality
>
> yes, definately
>
>> - you want it multithreaded or to run in a separate thread
>
> To be precise, I have a multi-threaded application, and I want to
> supress messages just for a part of one thread. The code which is
> executed here hasn't been written by me.
>
>> - you want your threads to share an object of class Process that will
>> serve the purpose you mentioned.
>
> I want to get a Process object just for this part of one of my
> threads. I could launch another Thread for it, but the problem is
> still I cannot get the Process object.
>
As has already been pointed out to you the process associated with each thread
within the JVM is the JVM itself. Since you already have direct access to the
input/output streams of the JVM via System.out/System.in/System.err you don't
need a Process to get these Streams. However, those System streams are shared
between all threads, so you can't redirect them just for some code executed by
a thread, they will be redirected for all threads for the duration of the
redirect.
> ***
> The trick with loggers is also not a good idea, because I don't want
> to/can't modify not my own code.
>
Then I'm pretty sure you can't do what you are attempting to do by any simple
means.
You may be able to implement your own class to handle the output by extending
PrintStream so it could replace System.out/err. You would need to devise your
own mechanism within that class for redirecting only the output generated by
the code you haven't written. But don't ask me how...
--
Nigel Wade
Marteno Rodia
> Then I'm pretty sure you can't do what you are attempting to do by any simple
> means.
The only way to do that I can think about has been already mentioned
in the thread. It involves making from "the part of the code" an
external application and invoking it as a Process object. It is
possible, however, I don't like it, because I must export the project
into JAR file, and then invoke the JVM to execute this JAR, and what
if a user of the application moves or deletes the external JAR? How
can I ensure in another way MyClass to be visible in the working
directory?
Anyway, thanks for all your responses up tu now and later :))
MR
Matt Humphrey
Presuming you were originally expecting to execute the code within the main
application, there's no need for a separate or external jars. You simply
launch a new JVM with the all the same jars and classpath as the original
application, but with a different main class. If you don't need all the
same jars, feel free to omit them. And (of course) the user could move any
of your files and jars at any time just like they could for any other
deployed application--they'll just get what they deserve.
Matt Humphrey http://www.iviz.com/