[Wrapper-user] Console hiding & java.lang.Process suggestion

[Rich T. <arm...@ho...>]

To Wrapper Devs,

In the documentation for the property "wrapper.ntservice.hide_console" it 
says:
"In order to capture the console output of a Java application the Wrapper 
must create a console for the JVM to use."
, and:
"In order to be able to display the Java GUI with older JVMs, the console 
can not be hidden by default."

Can it not employ a Java-based solution and use the Runtime and Process 
classes in the java.lang package?
I do not know whether you have considered this already, but their docs say 
that they have both existed since JDK1.0, for benefit of older code.
You can start processes using the Runtime object to spawn Process objects.
For a Java app you then specify "javaw xyz" as the process : this does not 
use a console at all, but being created with the Process object, it will 
still have InputStream/OutputStream objects that you can link to.

Then setup stream copying threads to capture the process output invisibly 
and direct it where you want, to an AWT/Swing console, other program, log 
file or even real console.
If the app requires input from its System.in stream then you would need some 
sort of console for the user to type into to pass onto the process, 
otherwise, it need not be displayed (probably not for a background 
service?).
The Process object can spawn and operate in its own thread so that when it 
ends/quits/exits (use "waitfor()") it can notify an attached listener in 
your main wrapper program.
Note that the Process streams are inverted because you are communicating 
inwards (for example, getOutputStream() returns what the Process considers 
to be its System.in).

The disadvantage is that each new JVM process requires its own block of 
memory to run in (do not know how much JDK1.5 sharing saves, though).

Also, so that the integration methods still work across the process 
boundary, you would need to make sure that you have a small helper class on 
the other side that you call as the process.
OS API -> JNI -> WrapperMain -> WrapperHelperProcessApp -> User's App
So then the WrapperStartStopApp "start()"/"stop()" methods can be activated 
by using some escape sequences or mini-protocol passed through the Process 
streams that is handled by your helper on the other side to manipulate the 
user's wrapped JAR/class.
Requires at most 2 JVMs, as if more Java-wrapped services are needed then a 
loop in the wrapper helper can thread them in parallel and try-catch each on 
exception/error (including setting the security manager to catch inner 
System.exit() calls).

Neat program anyway,
See Ya,
Rich Townsend.

_________________________________________________________________
Don’t just search. Find. Check out the new MSN Search! 
http://search.msn.click-url.com/go/onm00200636ave/direct/01/