Programming Guides › Connector Programming Guide › Testing with JMeter › Debugging Tips

Debugging Tips

The following are suggested breakpoint locations for debugging custom connectors. These breakpoints are listed in order, starting with locations that are nearest your custom connector to locations deepest within the ApacheDS runtime stack:

• Methods in one of your connector's processing styles (for example, SDKAttributeStyleOpProcessor.doAdd()) which are called after the framework has performed all validations and conversions as specified by your configuration metadata. You can check arguments here in the debugger before your connector-specific code uses them.
• LDAP methods within MetaConnector, for instance MetaConnector.add(). Although the arguments to these methods have been normalized, they are still in LDAP terminology and can provide clues if you are having problems during the name mapping, validation, and conversion phases.
• The ApacheDS SchemaService does lookup() calls on your connector to sanity test MODIFY and other operations. Therefore, if you see an operation make it to the expected method call on PartititionLoaderService (say modify()), but it does not make it to the corresponding call on MetaConnector (say modify()) then put a breakpoint in your connector’s attribute-style processor’s doLookUp() method, to see if a problem is occurring here (or MetaConnector.lookup() / MetaConnector.search() if execution is not reaching doLookUp())
• The search() method returns NamingEnumerations. Some streaming varieties mean that results are not retrieved at the time that the search() method returns. Instead they are retireved some later time when the ApacheDS framework steps through the entries in the returned enumeration. When problems occur while stepping through search results, the most interesting breakpoint candidate is at the start of MapSearchResultsFromConnectorEnum.processNext() where you can see each result prior to it being converted from connector terminology to LDAP.
• LDAP methods within the SOAFilteringInterceptor (like add()), which are called as soon as a new LDAP request is submitted to the ApacheDS interceptor chain. These may be useful to look at requests before ApacheDS processes them. This class acts as the front end to CA IAM CS. If methods in MetaConnector are not being called, then this is the next layer down in the CA IAM CS architecture.
• org.apache.directory.server.ldap.LDapProtocolProvider.messageReceived(). This is the deepest point in the ApacheDS stack handling LDAP requests and should only be useful if requests or responses are failing to be encoded or decoded according to the LDAP protocol for some reason.
• When porting a C++ connector to CA IAM CS, you can compare the objects and attributes found in each. To do compare the objects, explore the same endpoint in each connector, and then connect to the ETADB. Delete everything under the connector level in ETADB and restart your Provisioning Server. Also, remove systemdb in CA IAM CS before starting it.
• If you want to clean up 'systemdb' on a regular basis, during development, use the secret C++ Connector password in both the Provisioning Manager and CA IAM CS. Using the password saves time in resetting the password. To reset the password manually, bind to a running CA IAM CS with the secret password and set the userPassword on the uid=admin,ou=system object, where it is saved to systemdb.
• For scripted connectors methods invokeFunction and invokeScript are places suitable for debugging execution of scripts and serve as the Java to script language boundary. The exception message generated by Rhino usually includes the file and the line number where the problem occurred.
• Setting exception breakpoint org.mozilla.javascript.JavaScriptException for debugging scripted connectors is a useful way to catch Rhino script execution failures.