Special and Advanced Topics

There are various optional references to icons which may be contributed by a plug-in. Most icons should be transparent GIFs unless stated otherwise in the table below. Here is a set of potential locations for contributing icons:

Context	Recommended Size in Pixels	Remarks
Plug-in icon appearing in the common About dialog	16x16	Transparent GIF
Bitmap for plug-in specific 2nd-level About dialog	None	May be also JPG or PNG file
Perspective icon in Select Perspective dialog	16x16	Transparent GIF
Header icon contributed by perspective	Height: 35. Width: depends on space required for toolbar and view listbox.	May be also JPG or PNG file
Icon representing an item in tree or table	16x16	Transparent GIF
Icon for command for an item (context menu or toolbar in detail view)	16x16	Transparent GIF

The Pluggable UI depends on dedicated class loaders. The code for a normal web application is only loaded through the basic WebappClassLoader provided by the servlet container (for example, Tomcat), this class loader is only used for loading the classes resembling the PluggableUI base with the underlying Application Designer. The respective classes are loaded from the following directories below <RuntimeWebAppsDir>\PluggableUI:

In addition, locations holding common or shared class or jar files are searched by the WebappClassLoader when attempting to resolve references to required classes.

Any code contributed by a plug-in is loaded by a corresponding instance of the PlugInWebappClassLoader from the following directories below <RuntimeWebAppsDir>/PluggableUI:

If resolution fails, the PlugInWebappClassLoader for the current plug-in delegates class loading to the PlugInWebappClassLoaders for other plug-ins in the order listed as <requiredPlugin> in the plugin.xml of the current plug-in recursively. Finally, if resolution through required plug-in fails, the PlugInWebappClassLoader delegates class loading to the WebappClassLoader.

The following picture illustrates the scenario of the LifeCycleManagement plug-in (representing any other third party plug-in) that depends on the CentraSiteControl plug-in and the PluggableUI base infrastructure.

The AdapterPlugInClassLoader is used by Application Designer when resolving references to adapter classes found in layout definitions. The AdapterPlugInClassLoader never loads classes itself. Instead, it asks all known PlugInWebappClassLoaders in an unspecified order to load a required class.

CAUTION:
You must avoid having the same adapter classes in more than one plug-in, else it results in various classloading related issues (ClassCastException, ClassNotFoundException, …). Under normal conditions, fulfilling this restriction should not cause any problems.

In general, you should avoid having multiple locations contributing the same classes within the graph of locations spanned by the required plug-ins.

Normally, when executing the HTTP requests on behalf of a single Application Designer session, there is no parallel execution in multiple threads (unless the code contributed by a plug-in starts a thread on its own). Hence, access to objects or properties having a scope restricted to the session context does not require any synchronization.

However, when using global or static variables, this is no longer true. Multiple active user sessions may be processed in parallel.

Global references to JAXR-based RegistryObjects. A RegistryObject contains a reference to the JAXR-based Connection (including the underlying credentials) that had been used to load it. When resolving a secondary reference either of the following may happen:

All adapter classes of a plug-in should not be just subclasses of com.softwareag.cis.server.Adapter. Instead, they should be derived from one of the following classes:

BaseAdapter is a subclass of CommonAdapter and thus inherits certain properties. Among those is the implicit registration of all adapters as known adapters in the current session context. However, under certain circumstances it may happen that adapters for nested pages displayed using a SUBCISPAGE or ROWTABSUBPAGES control are not automatically deregistered when closing, for example, an activity displayed in the CONTENT frame on the right hand side of the workplace. This may lead to subsequent NullPointerExceptions.

Normally, deregistration is accomplished within the destroy() method in CommonAdapter. Hence, be careful when overriding this method in a subclass to call super.destroy(). In addition, you should override the endProcess() method in the adapter for the container layout, which should perform at least the following actions: