0

I need to package an app that can be invoked either double-click, or on the command line. Jwrapper, however, runs the app in the background, dumps a bunch of log info into the terminal, and sends stdout to a log file, making it unusable on the command line.

Is there any way to control this? Perhaps in a particular virtual app?

Update:

The jar supports a number of command-line switches, including --help, and --version, which output to console, and directives that communicate with the app over a socket (e.g. "tell the running app to load the file at the following path"). These are for scripting and debugging, so not necessarily the same audience as the 'double-click-to-run' users. So a fall-back is to require such users to manually install jvm + jar.

Could one install a lighter-weight wrapper that doesn't fork, output to console, or direct output to a file? E.g. just run the bundled jvm, passing in the jar and main class?

Update2:

Or better would be a command-line switch to prevent forking, console output from the wrapper, and redirecting output.

user1009908
  • 1,390
  • 13
  • 22

1 Answers1

0

Are you looking to be able to communicate with the app over the terminal (like type stuff in and get responses etc) or just to see the output of the app in the terminal?

The way things work at the moment JWrapper is set up to allow headless installation (although we haven't tested it) but as you say it dumps logging output. We could have a switch to prevent that in a future version but I'm not sure if we could easily pipe input to the app since it potentially goes through more than one process change during the launch.

AntonyM
  • 1,602
  • 12
  • 12