|
From: Rich T. <arm...@ho...> - 2004-10-07 23:00:46
|
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. _________________________________________________________________ Dont just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/ |