I've been using some scripts to quickly redeploy snapins (basically a wrapper around scp and executing deploy_service on Breeze) but noticed sometimes the deploy_service reports errors redeploying but they are really false positives or some other times SMGR seems to push a redeploy of the last version "properly deployed" through SMGR into Breeze, which overwrites my newly deployed version.

In summary, what is the recommended way to quickly redeploy snapins into Breeze for development?

We encourage you to use the Eclipse plugin that can be installed with the Avaya Breeze SDK. It offers single click access to the steps you are currently manually running. What makes this work quickly, and not get in the way of the normal Breeze service audit, is that it bypasses System Manager (when it can) by installing the svar directly on the Breeze node and directly into the JEE container. The heart of this process is the deploy_service script that you've discovered.

However, deploy_service is pretty simplistic when it comes to error reporting. All it does is tail the alog (i.e. the JEE container info/error log) and if it sees anything happening at all, assumes it's an error and lists out the nearly coincident messages. If other things are going on in WebSphere it may dump those entries too, and deploy_service thinks those are errors. The standard install run from System Manager uses deploy_service too, but instead of looking at those log entries it waits to see if the service actually starts (deploy_service -lv will show this), and declares success if it does. This is a relatively slow process, and humans (really just software developers) normally don't want to wait that long.

So, you have a choice: ignore the "errors" and assume everything worked (true 99.9% of the time) or manually run deploy_service -lv and notice that your snap-in is running, before you test. The "errors" are only a problem if your snap-in fails to start running. And, all "running" means is that your snap-in's init() method has been called and did not return an error. There still could be all kinds of problems with your snap-in's code, but that's for you to fix (and the logs displayed by deploy_service might help diagnose, though the other logs described in the troubleshooting guide are a better bet).

If you make any changes to the properties.xml file, then you must load the snap-in through the System Manager at least once. After that, as long as you confine your changes to code, you can use the faster technique described here. The Eclipse plugin checks this, and will automatically do this for you.

great, thanks Kurt.

H

Thank you!