Help

JBlitz Professional offers a simple open API that allows you to customize key aspects of the test environment. With this API, you can write:

• Response Checkers. Simple Java plug-ins that allow you to perform bespoke response checking to verify any given web page download.
• Response Informers. Simple Java plug-ins that allow you to perform bespoke processing on any given web page download.
• URL Assistants. Simple Java plug-ins that allow you to determine the exact form of the URL used to download any given web page.
• Dynamic Substitution Generators. Simple Java plug-ins that can generate arbitrary test data for your URLs.
• Customization Modules. More complex modules that allow you to modify, enhance or replace parts of the JBlitz query engine and / or plug in third party software.

Response checkers, response informers, URL assistants and customization modules allow you to programmatically extend the core functionality of JBlitz with your own Java code. Details about how to implement and install each so that they take part in your test runs are described below.

Response Checker plug-ins are very simple Java classes that implement a single static method and that are invoked by JBlitz whenever the web page they are configured for is downloaded. Their job is to decide whether the download was successful or not (i.e. whether an error has occurred).

The decision about whether an error has occurred is one made entirely by you in your code. Usually, you would want to look at the returned page and see if it contains all the expected information for the request made.

If you determine that the response is in error, return a non null error message to JBlitz and the configured error handling will ensue. Otherwise, return null and JBlitz will process this response as a 'hit'.

Your response checker can be any Java class that implements the following method signature:

/** * Check the response page. Return an error message for failure, null for success */ public static String checkResponsePage( long requestNumber, // Unique request number for this request String testCase, // As entered in the GUI int pageIndex, // Zero based index of the page within the test case String url, // The full URL used to request this page int virtualUserIndex, // Zero based virtual user index within the test case String requestMessage, // Full request message used to issue this request String responseHeaders, // Response headers read byte[] responseBody, // Response body read int httpCode, // Response code from above headers. -1 if none found long timeToConnectMillis, // Connection time long timeToRespondMillis) // Response time

Any class that implements this method can be a response checker. Because the method is static, the class does not even have to be constructible. However, it does need to be a public class and it does need to contain the method signature shown exactly. Note: you don't need to specify any special library settings or link with the file 'jblitz.jar' when building your class.

We recommend that you build your class using the same version of Java as you use to run JBlitz. JBlitz currently supports versions 1.6, 1.5 and 1.4 of the JVM. When run within JBlitz, your response checker will, of course, be running in the same VM that is used by JBlitz itself.

Once you have built your checker, follow these steps to start using it:

1. Decide whether you need a global checker or a page-level checker.
   
   The former is invoked for each and every web page downloaded during any given test run. The latter is invoked only for the pages it is configured against. Use the former where you want to write all the code in one place and have it switch on the test case and web page. Use the latter when you want to write separate checkers for each page.

2. Make your class file available on the JBlitz application classpath. Doing this depends on how you installed JBlitz:
   
   If you installed JBlitz by running the Windows installation program, you'll need to edit the file JBlitz Pro.ini in your installation folder. This file contains the JBlitz application classpath under the entry starting Class Path. Just add the appropriate entry to the classpath and save this file. Remember to separate classpath entries with semi-colons.
   
   If you downloaded and installed JBlitz using either the ZIP or TAR GZIP distributions, you will need to include an entry for your checker class file within the -classpath parameter when running JBlitz. Remember to separate classpath entries with semicolons (Windows) or colons (Linux / Unix). More details on how to configure the classpath for JBlitz are given in the installation instructions.

3. Install your checker within JBlitz. Do this through the GUI.
   
   For global response checkers, go to the 'Error Handling' tab and select the 'Custom Errors' sub-tab. Click on the 'Set...' button to specify the class that implements your checker.
   
   For page-level response checkers, double click on a test case to show the test case settings dialog. Select a web page in the list. Double click on the third 'dash' icon to the right of the entry or use the right mouse popup menu.

When you start a test run, you should see your installed checker being invoked. Problems ? Check here for some hints on trouble-shooting.

An example response checker com.clan.jblitz.custom.samples.ThroughputResponseChecker is contained within the code samples. Download the source code.

Response Informer plug-ins are similar to response checkers being very simple Java classes that implement a single static method and that are invoked by JBlitz whenever the web page they are configured for is downloaded. Their job is to perform any ad-hoc processing as decided by you which may include, but is not limited to, such things as custom logging, integrating with third party software, sending emails, triggering alerts etc.

Your response informer can be any Java class that implements the following method signature:

/** * Invoked when the page for which this informer is registered has been downloaded */ public static void onResponseReceived( long requestNumber, // Unique request number for this request String testCase, // As entered in the GUI int pageIndex, // Zero based index of the page within the test case String url, // The full URL used to request this page int virtualUserIndex, // Zero based virtual user index within the test case String requestMessage, // Full request message used to issue this request String responseHeaders, // Response headers read byte[] responseBody, // Response body read int httpCode, // Response code from above headers. -1 if none found long timeToConnectMillis, // Connection time long timeToRespondMillis, // Response time boolean isError) // True if this response has been deemed an error

Any class that implements this method can be a response informer. Because the method is static, the class does not even have to be constructible. However, it does need to be a public class and it does need to contain the method signature shown exactly. Note: you don't need to specify any special library settings or link with the file 'jblitz.jar' when building your class.

We recommend that you build your class using the same version of Java as you use to run JBlitz. JBlitz currently supports versions 1.6, 1.5 and 1.4 of the JVM. When run within JBlitz, your response informer will, of course, be running in the same VM that is used by JBlitz itself.

Once you have built your informer, follow these steps to start using it:

1. Make your class file available on the JBlitz application classpath. Doing this depends on how you installed JBlitz:
   
   If you installed JBlitz by running the Windows installation program, you'll need to edit the file JBlitz Pro.ini in your installation folder. This file contains the JBlitz application classpath under the entry starting Class Path. Just add the appropriate entry to the classpath and save this file. Remember to separate classpath entries with semi-colons.
   
   If you downloaded and installed JBlitz using either the ZIP or TAR GZIP distributions, you will need to include an entry for your informer class file within the -classpath parameter when running JBlitz. Remember to separate classpath entries with semicolons (Windows) or colons (Linux / Unix). More details on how to configure the classpath for JBlitz are given in the installation instructions.

2. Install your informer within JBlitz. Do this through the GUI. Double click on a test case to show the test case settings dialog. Select a web page in the list. Double click on the fourth 'dash' icon to the right of the entry or use the right mouse popup menu.

When you start a test run, you should see your installed informer being invoked. Problems ? Check here for some hints on trouble-shooting.

An example response informer com.clan.jblitz.custom.samples.StdOutResponseInformer is contained within the code samples. Download the source code.

URL Assistant plug-ins are another type of simple plug-in that can be used with JBlitz. Introduced from v5.1 onwards, they give you control over the exact URL used to request the web page for which they are configured. They are commonly be used to:

• Incorporate arbitrary test data into your URLs.
• Maintain state data in a bespoke way (when your URL contains state information that needs to be transferred from the previous page). In this scenario, you'll probably want to combine a response informer and URL assistant together to keep track.
• Assert any other type of control over your URLs that can only be achieved programmatically.

Because URL assistants have control over the whole URL, they can be used to make connections to alternate hosts / ports as well as just changing the page and query string / entity data that is associated with the request. Note, however, that they cannot be used to alter the request method used. If you need to do this, consider using a customization module.

Your URL assistant can be any Java class that implements the following method signature:

/** * Invoked to query the actual URL to download a page for which this assistant * is registered. The incoming URL param represents the URL that would otherwise * be used by JBlitz to request this web page if no URL assistant was in use. * This method should return the actual URL to be used */ public static String getURL( long requestNumber, // Unique request number for the originating request String testCase, // As entered in the GUI int pageIndex, // Zero based index of the page within the test case int virtualUserIndex, // Zero based virtual user index within the test case String requestMethod, // Request method being used for this web page String candidateURL) // The candidate URL to use as specified in the GUI or // derived according to the navigation mode in force

Any class that implements this method can be a URL assistant. Because the method is static, the class does not even have to be constructible. However, it does need to be a public class and it does need to contain the method signature shown exactly. Note: you don't need to specify any special library settings or link with the file 'jblitz.jar' when building your class.

The candidateURL parameter and the return value follow the standard JBlitz convention used when dealing with POST (or PUT) requests - that is, if this page is being requested using POST or PUT, the entity data should appear at the end of the URL following a question mark as if it were a query string. JBlitz will then automatically trim off the entity data and package it up correctly for transmission.

We recommend that you build your class using the same version of Java as you use to run JBlitz. JBlitz currently supports versions 1.6, 1.5 and 1.4 of the JVM. When run within JBlitz, your URL assistant will, of course, be running in the same VM that is used by JBlitz itself.

Once you have built your assistant, follow these steps to start using it:

1. Make your class file available on the JBlitz application classpath. Doing this depends on how you installed JBlitz:
   
   If you installed JBlitz by running the Windows installation program, you'll need to edit the file JBlitz Pro.ini in your installation folder. This file contains the JBlitz application classpath under the entry starting Class Path. Just add the appropriate entry to the classpath and save this file. Remember to separate classpath entries with semi-colons.
   
   If you downloaded and installed JBlitz using either the ZIP or TAR GZIP distributions, you will need to include an entry for your assistant class file within the -classpath parameter when running JBlitz. Remember to separate classpath entries with semicolons (Windows) or colons (Linux / Unix). More details on how to configure the classpath for JBlitz are given in the installation instructions.

2. Install your URL assistant within JBlitz. Do this through the GUI. Double click on a test case to show the test case settings dialog. Select a web page in the list. Double click on the second 'dash' icon to the right of the entry or use the right mouse popup menu.

When you start a test run, you should see your installed URL assistant being invoked. Problems ? Check here for some hints on trouble-shooting.

An example URL assistant com.clan.jblitz.custom.samples.CatSubcatURLAssistant is contained within the code samples. Download the source code.

Dynamic Substitution Generator plug-ins are the final type of plug-in that can be used with JBlitz. New from v5.1, these generator plug-ins are specifically designed to allow you to take control over test data generation using your own Java code. They work alongside the other types of dynamic substitutions (integer, floating point, choice, document etc) to give you an additional means of generating test data that can be inserted into your URLs. They're most suitable for use when the item(s) of test data need to be programmatically determined.

Your substitution generator can be any Java class that implements the following method signature:

/** * Invoked to obtain a user defined dynamic substitution value * This method should return the text to be used to replace the %u substitution element * This enclosingScope parameter depends on the context in which this substitution * appears. There are 3 possibilities: * the %u substitution element appears directly in a web page URL * the %u substitution element appears in an item of test data that has been * recursively substituted by a %x, %y or %z substitution element * the %u substitution element appears in a request header and substitutions within * request headers have been enabled * In the first case, enclosingScope will be the URL for the originating request * In the second case, enclosingScope will be the the item of test data concerned * In the third case, enclosingScope will be the set of request headers for the * originating request */ public static String getUserDefinedSubstitution( long requestNumber, // Unique request number for the originating request String testCase, // As entered in the GUI int pageIndex, // Zero based index of the page within the test case int virtualUserIndex, // Zero based virtual user index within the test case int substitutionIndex, // A number from 0 to 99 defining which of the // %u00 -> %u99 substitutions this is for String enclosingScope) // The text into which this substitution is to be made // (normally the requesting URL)

Any class that implements this method can be a substitution generator. Because the method is static, the class does not even have to be constructible. However, it does need to be a public class and it does need to contain the method signature shown exactly. Note: you don't need to specify any special library settings or link with the file 'jblitz.jar' when building your class.

We recommend that you build your class using the same version of Java as you use to run JBlitz. JBlitz currently supports versions 1.6, 1.5 and 1.4 of the JVM. When run within JBlitz, your substitution generator will, of course, be running in the same VM that is used by JBlitz itself.

Once you have built your substitution generator, follow these steps to start using it:

1. Make your class file available on the JBlitz application classpath. Doing this depends on how you installed JBlitz:
   
   If you installed JBlitz by running the Windows installation program, you'll need to edit the file JBlitz Pro.ini in your installation folder. This file contains the JBlitz application classpath under the entry starting Class Path. Just add the appropriate entry to the classpath and save this file. Remember to separate classpath entries with semi-colons.
   
   If you downloaded and installed JBlitz using either the ZIP or TAR GZIP distributions, you will need to include an entry for your substitution generator class file within the -classpath parameter when running JBlitz. Remember to separate classpath entries with semicolons (Windows) or colons (Linux / Unix). More details on how to configure the classpath for JBlitz are given in the installation instructions.

2. Install your substitution generator within JBlitz. Do this through the GUI. Select the 'Dynamic Substitutions' tab on the main screen. Click on the '%u00 ... %u99' list item on the left. Click the 'Set...' button to specify the Java class that will act as your dynamic substitution generator.

When you start a test run, your substitution generator will be invoked whenever JBlitz encounters a URL which contains one of the %u substitutions. Your substitution generator must handle all the %u substitutions encountered during a test run. Problems ? Check here for some hints on trouble-shooting.

An example dynamic substitution generator com.clan.jblitz.custom.samples.CurrentTimeGenerator is contained within the code samples. Download the source code.

More complex customization of JBlitz can be achieved by writing a customization module. Customization modules are Java classes that plug in 'under the hood' into the JBlitz query engine. These modules can be used to: Enhance, modify or replace parts of the query engine. This gives you the ability to tailor the test environment to better suit your testing requirements. You get control over what pages are downloaded, how and when they are downloaded, and a load of other details even down to the nuts and bolts of what socket implementation is used. Listen to events from the query engine as they occur. A 'low-level' event registration API gives you a hook into adding features such as logging, alerts, statistical analysis, notifications, integration with third party software etc (similar to response informers, but at a finer level of detail).

Click on one of the following topics to learn more about how to customize JBlitz.

• What is a customization module ?
• How to go about writing a customization module
• How to integrate your customization module into JBlitz
• Sample customization modules
• Where to look for further help

A customization module is a special module containing custom Java software written to the JBlitz customization API. Customization modules are loaded when the application starts and are integrated into the query engine and event management sub-systems. Only one customization module may be loaded at any point in time.

Customization modules allow your software to work with the core JBlitz software components. The API lets you modify the queries made by each virtual user, lets you inspect or modify the replies, gives you control over what order the queries are performed in (and when) and allows you to register for a variety of notification events such as 'connection made' events or 'hit' events.

By writing a customization module, you can:

• Customize the sequence in which web pages are downloaded from the server.
• Use a customized socket for requests.
• Alter the request method, URL and timeout for any given request.
• Customize the request message issued by JBlitz for any given request.
• Raise custom errors on inspection of the response headers or body.
• Perform processing based on the request response.
• Add you own logging, debugging, third party code as you see fit.
• Listen to events as they occur. For example, 'connecting', 'connected', disconnected', 'virtual user starting', 'hit', 'error' etc.

Customization modules are normally packaged as JAR files, but may also just be a collection of Class files. Modules are installed into JBlitz through the GUI (only one module can be loaded at a time). Modules can vary in complexity from just a couple of lines of code to thousands. The sections below explain further how to write your own customization module and integrate it into JBlitz.

NOTE: Customization modules do not replace the use of test configuration files to define what tests to perform. JBlitz still works off test configuration files, but rather allows an installed customization module to modify the testing defined by the configuration. Admittedly, such modification may go as far as using complete different URLs, but some of the configuration parameters are not available for modification (for example: the number of virtual users or the run control options).

Customization modules must be written in Java. The term 'module' is a loose term for a collection of Java classes that are written to the customization API. There are two ways you can go about writing your module:

1. Copy one of the sample modules and adapt it for your own purposes. All the sample modules have very simple implementations contained entirely in a single class. Choose one that's the closest fit. You'll probably want to modify the package name to something more suitable.
2. Write your own module from scratch. Well, it is easy after all!

Make sure you are using JDK version 1.4, 1.5 or 1.6 to build your module. The actual version should correspond to the version of Java you're using to run JBlitz. For most people, this will be version 1.4.2, version 1.5.0 or version 1.6.0. If you are using a later version JRE to run JBlitz, make sure you use the corresponding JDKs to build your module. JDKs are free to download and available from the Sun website.

Note the following:

• You'll need to add the file 'jblitz.jar' to the library settings of your IDE, or make sure its on the classpath if compiling manually with 'javac'. This JAR file is installed as part of your JBlitz evaluation and contains the classes that define the customization API in the package com.clan.jblitz.custom.
• Javadoc for the API is available online and also separately downloadable.
• The source code for the API and sample modules is separately downloadable too.

There are four important interfaces that make up the core of the customization module API. The first, and most important, is the interface com.clan.jblitz.custom.CustomModule. All customization modules must, at the very least, implement this interface. It has three methods and looks like this:

public interface CustomModule { public void initialize(Env env); public void terminate(); public void testConfigurationLoaded(File testConfig, boolean isNew); }

Here, the important method is the first one, initialize(). This is where your module gets loaded into JBlitz. The Env parameter is your handle onto the available functionality. When this method is invoked, you need to use the Env object to either modify the JBlitz query engine or listen to events (or both).

The com.clan.jblitz.custom.Env interface is the second of the main interfaces for the customization API:

public interface Env { public QueryExtension getQueryExtension(); public void setQueryExtension(QueryExtension queryExtension); public EventManager getEventManager(); }

This interface gives your customization module access to functionality within JBlitz. The second method setQueryExtension() allows you to customize the query engine. The QueryExtension parameter represents an extension to the query engine used to make requests and receive responses from the server. A default implementation, DefaultQueryExtension (which is used by JBlitz when no customization module is loaded) is available for subclassing. The last method getEventManager() gives you access to the application event manager through which you can register for various types of download and virtual user related events.

Which brings us on to the third and fourth of the main interfaces. The third interface is com.clan.jblitz.custom.engine.QueryExtension:

public interface QueryExtension { public DownloadSequence getCustomDownloadSequence(int testCaseIndex, String testCaseName); public String getRequestMethod(RequestContext requestContext, String requestMethodFromGUI); public RequestURL getURL(RequestContext requestContext, <more...>); public Socket createSocket(RequestContext requestContext, RequestURL url, <more...>); public StringBuffer formatGetRequest(RequestContext requestContext, <more...>); public StringBuffer formatPostRequest(RequestContext requestContext, <more...>); public OutputStream sendRequest(RequestContext requestContext, <more...>); public CustomError responseHeadersReceived(RequestContext requestContext, <more...>); public CustomError responseBodyReceived(RequestContext requestContext, <more...>); public void disconnect(RequestContext requestContext, RequestURL url, <more...>); }

This interface defines amongst other things:

• The order in which web pages are downloaded within a test case.
• The host, request method, timeout and URL used for each request.
• The socket implementation used for each request.
• The actual message format for both GET and POST requests.
• Whether the response headers or response body indicates that a custom error should be raised and propagated back to the GUI.

All of this behavior is thus available for modification by a customization module that sets a new query extension onto the application environment.

The fourth interface is com.clan.jblitz.custom.engine.EventManager. This interface allows you to listen to various events as they occur whilst testing:

public interface EventManager { public void addTestRunListener(TestRunListener l); public void removeTestRunListener(TestRunListener l); public void addVirtualUserListener(VirtualUserListener l); public void removeVirtualUserListener(VirtualUserListener l); public void addConnectionListener(ConnectionListener l); public void removeConnectionListener(ConnectionListener l); public void addResponseListener(ResponseListener l); public void removeResponseListener(ResponseListener l); }

Test run listeners receive an event whenever a test run begins or ends. Virtual user listeners receive events related to the starting and stopping of each virtual user within each test case. Connection listeners receive connected / disconnected events and response listeners receive an event whenever a response page is received from the server, or when no response is receivable. The response page may be deemed either a hit (success) or an error (bad HTTP response code, error string found or custom error raised).

A couple of simple code snippets illustrating these four interfaces follow. In the first, we set a new query extension onto JBlitz and override the responseHeadersReceived() method to raise an error if they don't begin with some magic string:

public void initialize(Env env) { env.setQueryExtension(new DefaultQueryExtension() { public CustomError responseHeadersReceived(RequestContext context, RequestURL url, String headerFields) { if(!headerFields.startsWith(SOME_STRING) { // Error - raise an error to appear on the GUI return new CustomError("Invalid response headers received"); } // Not an error - perform default functionality return super.responseHeadersReceived(context, url, headerFields); } }); }

In the second, we listen to response events as they're generated by registering a response listener:

public void initialize(Env env) { env.getEventManager().addResponseListener(new ResponseListener() { public void hit(RequestContext requestContext, long requestNumber, RequestURL url, ResponseData responseData); // Process hit event... } public void error(RequestContext requestContext, long requestNumber, int errType, RequestURL url, ResponseData responseData); // Process error event... } public void exceptionError(RequestContext requestContext, long requestNumber, RequestURL url, Exception exception); // Process exception error event... } }); }

Hopefully, this gives you a good start on writing some custom code for JBlitz. Once you've written your code, its a good idea to check that:

• The class that implements com.clan.jblitz.custom.CustomModule is publicly accessible.

• The class that implements com.clan.jblitz.custom.CustomModule declares a public no-arg constructor.

• All the classes and any third party classes that comprise the customization module can be found in the classpath for JBlitz. This is described in more detail below under the integration section.

Remember, more detailed descriptions for all the classes and interfaces in the customization API is available.

Integrating your customization module and running it is a three step process:

1. Package your class files up into a JAR file (optional - you can also run them as class files) - see the note below on how to package Java class files into a JAR file.

2. Make your JAR file (or class files) available on the JBlitz application classpath.

3. Run JBlitz. Select the 'Customize' menu option from the main menu, type the fully qualified class name for the class that implements com.clan.jblitz.custom.CustomModule into the drop-down combo and hit 'Load'.

Step 1 and 2:

If you installed JBlitz by running the Windows installation program, you can save yourself some time and energy by calling your JAR file 'custom.jar' and placing it in the 'lib' sub-folder of your installation folder. That way it gets automatically included in the application classpath! Move straight on to step 3.

Otherwise, you'll need to edit the file JBlitz Pro.ini in your installation folder. This file contains the JBlitz application classpath under the entry starting Class Path. Just add the appropriate entry to the classpath and save this file. Remember to separate classpath entries with semi-colons.

If you downloaded and installed JBlitz using either the ZIP or TAR GZIP distributions, you will need to specify your customization module JAR file (or class files) as part of the -classpath parameter when running JBlitz. Remember to separate classpath entries with semicolons (Windows) or colons (Linux / Unix). More details on how to configure the classpath for JBlitz are given in the installation instructions.

Step 3:

Once you have done steps 1 and 2, you'll need to restart JBlitz for changes to the classpath to take effect. Select the 'Customize' option from the main menu and type in the fully qualified name for your customization module class that implements the interface com.clan.jblitz.custom.CustomModule. When you hit the 'Load' button, JBlitz will perform some checks to ensure that your module can be found and is loadable. All things being equal, your module will be loaded and your module's initialize() method will have been invoked. Your module will then participate when you run your test cases.

If you encounter problems with the above, check out the further help section below or contact us at support@clanproductions.com being sure to include as much detail as possible about your test environment and what you're trying to do.

Note on how to create JAR files. Use the utility 'jar.exe' which comes as part of the JDK distribution. A typical command line for running 'jar.exe' is:

jar -cvf <jarfile> <classes>

Some pre-written sample customization modules are available in the JAR file customization_samples.jar in the lib subfolder of your installation. You can try running any of the samples at any time by selecting the 'Customize' menu option from the main menu and then selecting one of the sample modules from the drop-down combo and hitting 'Load'.

Current sample customization modules comprise:

• com.clan.jblitz.custom.samples.DynamicData. Replace portions of each URL with dynamically derived test data. All occurrences of the substitution element '%zz' (arbitrarily chosen) are replaced with test data derived from a sequence of static strings.

• com.clan.jblitz.custom.samples.Logging. Logs messages to a file on each method.

• com.clan.jblitz.custom.samples.OddPagesOnly. Alters the download sequence within each test case to only download every other page.

• com.clan.jblitz.custom.samples.POSTDataPlusQueryString. Allows POST requests to specify a query string aswell as the usual POST data. URLs are entered in the GUI using two question marks. The first marks the boundary between the page and its query string. The second marks the boundary between the query string and the POST data.

• com.clan.jblitz.custom.samples.RaiseCustomError. Raises a custom error to the GUI when any downloaded page is smaller than a certain size (2K).

• com.clan.jblitz.custom.samples.RampUp. Applies a simple ramp up effect where virtual users are only started after successive delay intervals.

• com.clan.jblitz.custom.samples.ReverseOrder. Downloads web pages within each test case in the reverse order.

Source code for all the sample modules is available. Feel free to download and copy any of the samples modules as a basis for your customization module.

If you have read the appropriate sections of this page and are still having problems with your plug-in or customization module, some of the following may be able to provide further help.

Try running JBlitz with custom debug on. Use the command line parameter -debug custom. This parameter makes JBlitz issue customization API related debug information to the standard output stream stdout.

Simplifying your custom code can often be a great strategy for tracking down elusive and mysterious bugs. Paring back to the 'bare bones' and building up slowly from there (with frequent testing) is usually a better approach than writing reams of code and only testing at the end.

Try looking over the general help page for running and testing with JBlitz.

You can browse the API help for programming to the customization API.

You can download and browse the source code for the customization API classes and all the sample modules.

Understanding and coding to a new API can be tricky at the best of times. We've done our best to document everything, but there are bound to be areas that are not explained fully. So feel free to email support@clanproductions.com at any time with your customization question and we should be able to provide an answer for you.