No that class is the actual code for the check_http plugin itself. But it looks like the plugin code is being bundled up with the web application code as well. I can't really see a reason for this to be so (other than it's easier for our build process to include everything that way) so I'll open up a low priority feature request to get this ironed out for the next release.
The code that you are interested in running is the blue-check-http.jar that resides in the $BLUE_HOME directory. Essentially this acts as a wrapper for the check_http.class so when you run java -jar blue-check-http.jar from within Blue, its actually calling the check_http.class. The version of the check_http.class that is executed is contained within the blue-plugins.jar (hence me wondering why there is a need for us to bundle the plugin code with the webapp other than for ease of build) in the ~lib directory of your Blue installation. The blue-check-http.jar version does a few house keeping tasks such as setting the correct classpath for the check_http.class. The check_http plugin makes use of the commons-httpclient libraries from Apache and these need to be on the classpath of the plugin at runtime.
Thanks for the testing offer. Any feedback is appreciated. I'll try and set aside some time for finishing off the check_http plugin shortly.
cheers
Rob
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think I'm calling the plugin incorrectly.
I have a similar plugin working in nagios:
./check_http -H some.website.com -p 80 -u /index.html
Here's what I have setup in Blue:
Macro ID:
1 /opt/blue/webapps/blue/WEB-INF/classes/org/blue/plugins
Command (check_http):
java $USER1$/check_http -H $ARG1$ -p $ARG2$ -u $ARG3$
Service:
check_http !some.website.com!8890!/index.html
Log:
[1177077953] SERVICE ALERT: some.website.com;website_http;WARNING;HARD;5;libgcj-java-placeholder.sh
Thanks,
Rob
Rob,
Yeah it does look like you are calling the plugin incorrectly.
To get it working, your $USER1$ macro should be pointing to the install location of your Blue directory i.e. /opt/blue
The command to get it working will be:
java -jar $USER1$/blue-check-http.jar -H $ARG1$ -p $ARG2$ -u $ARG3$
If I remember rightly the check_http.java plugin isn't quite finished yet. Hopefully I'll have some spare time shortly to get it completed.
cheers
Rob
Let me know if I can help with testing. So the following java class has to do with the admin/config app server rather than the http service check?
/opt/blue/webapps/blue/WEB-INF/classes/org/blue/plugins/check_http.class
Thanks,
Rob
Rob,
No that class is the actual code for the check_http plugin itself. But it looks like the plugin code is being bundled up with the web application code as well. I can't really see a reason for this to be so (other than it's easier for our build process to include everything that way) so I'll open up a low priority feature request to get this ironed out for the next release.
The code that you are interested in running is the blue-check-http.jar that resides in the $BLUE_HOME directory. Essentially this acts as a wrapper for the check_http.class so when you run java -jar blue-check-http.jar from within Blue, its actually calling the check_http.class. The version of the check_http.class that is executed is contained within the blue-plugins.jar (hence me wondering why there is a need for us to bundle the plugin code with the webapp other than for ease of build) in the ~lib directory of your Blue installation. The blue-check-http.jar version does a few house keeping tasks such as setting the correct classpath for the check_http.class. The check_http plugin makes use of the commons-httpclient libraries from Apache and these need to be on the classpath of the plugin at runtime.
Thanks for the testing offer. Any feedback is appreciated. I'll try and set aside some time for finishing off the check_http plugin shortly.
cheers
Rob