A few tips on getting an adapter running:
Verify the connection information. Usually before i try to set up an adapter, i try connecting to the resource from the machine where the adapter will be. So, for example, i will use SQLPLUS to access a database. This ensures that the resource can be contacted from your potential adapter location, as well as verifying that you have the proper environment setup and login credentials. Once i have successfully connected using resource client connection methods, then i move to the adapter.
If your adapter does not start, try starting it in debug mode from the adapter_config tool. The adapter process will generally not run as “you”, it will run as whichever user the adapter monitor process starts the adapter as (the default for NT is System Account, the default for Unix is bin*). The exception to this rule is when the adapter is running in debug mode (sic. from within the adapter_config tool, that is). When in debug mode, the adapter process runs as the user that started the process. So, if your adapter does not run in regular mode, but will start in debug mode, there is an environment discrepancy between the user that kicked off the process in debug, and the user that normally runs the adapter process.
2a) Typical discrepancies are: environment variables (e.g. Paths, Libs), and permissions (in Unix, mostly).
2b) Sometimes adapters need special paths to work correctly (particularly the MQ Series adapter, and the Database adapters), make sure you read the user guide for your adapter carefully, it may contain specific instructions such as environment variables to set, or additional packages needed to function properly.
- If your adapter will not start and the error message doesn’t really help you, disable the adapter (checkbox on the adapter’s properties) and save it (also note the name you gave this adapter instance). Then start the adapter from the command line with something similar to:
beans_adapter AdapterName Broker@client:port AdapterName debug=1 alert=1 warning=1 info=1
Sometimes this gives better debug output than the debug tool. Also, that way you can shunt it to a file if it is very verbose.
- If it is a custom adapter, and your adapter isn’t showing up in the adapter_config list of installed adapters, you can choose File - Show Installed Adapters to see what is wrong with your adapter (it will have a red dot next to it). Or you can execute the command:
beans_adapter -check com.package.MyClassName
to run a check on your main adapter class. The command returns the error it finds, or if everything is ok, it just returns with no output.
*bin is used because it is granted automatic nohup privileges, which is a little less work for wM than if the default is not used (if you change the user, the processes that get kicked off become automatically preceded by a nohup command)