[Wrapper-user] Filters: triggering on things other than strings

[Wrapper U. <wr...@co...>]

As I understand it now, the wrapper can only trigger on an output string.

Is there any way (or near-future plans) to trigger on something other than
output. For example, if the program throws an Exception, or trigger on the
exit code of the application?

In my specific case, I'm having an application "service1" (which I'm under
the assumption can't be changed to display different output) tries to
connect to a (naming) server "service0". Note that service0 will also be
launched by a wrapper. So, basically, service0 should be started before
service1. But I'm starting them with the init.d services in Linux, so that
can't be guaranteed. The way service1 works is that, upon starting up, it
will try to connect to service0. If service0 is not running, service1 will
retry to connect a number of times before giving up and exiting with exit
code 1.

When it can't connect to service0, service1 prints the following:
----------------------------------------------------------
jvm 1    | [ Retrying to connect to 127.0.0.1:1234 ]
...number of times...
jvm 1    | [ Retrying to connect to 127.0.0.1:1234 ]
jvm 1    | [ Retrying to connect to 127.0.0.1:1234 ]
wrapper  | <-- Wrapper Stopped
----------------------------------------------------------

So as you see, there's really no unique string it prints out that I can
trigger on after it failed n times. I found it exits with exit code 1 by
running the wrapper with logging set to debug.
Anyway, in theory, at the same time, a different wrapper instance could (in
my case should) be off starting service0, so I'd like service1's wrapper to
restart service1 with the hope that service0 will eventually be up to
connect to. Allowing the wrapper to trigger on service1's exit code would
help.
As a workaround (kluge?) , I could just trigger on the "Retrying to connect"
string, but that would restart after each failed connect, as opposed to
after the program exits in failure.

Another (totally separate) solution would be (and I'm just brainstorming
here) putting some dependencies on different wrapper applications. Something
like writing a totally separate script that somehow checks if service0 is
running (service0 status) before it launches service1...

Any ideas?

Thanks,
Aiman