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

[Leif M. <le...@ta...>]

Rich,
It looks like you have given this some thought, so sorry if I am missing
your
point. The wrapper.ntservice.hide-console and wrapper.ntservice.console
properties are used to control how the native Wrapper process creates or
hides
its own Console window. This is all outside of the scope of the Java process
so the methods that you pointed out are unfortunately not applicable to the
problem.

The native Wrapper process launches and then controls a single Java process.
The console is needed by several functions within the Wrapper process. It is
possible to pipe Java output from to the Wrapper process even if a console
window has not been registered.

There are problems with some system signals as well as the ability to
display
a Swing GUI with some Java versions however if a console has not been
registered.

Cheers,
Leif

Rich Townsend wrote:

> 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.