API Management 10.4 | CentraSite for Developers | Customizing CentraSite | Customization of CentraSite Control | Special and Advanced Topics
 
Special and Advanced Topics
Icons
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
Class Loading
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:
WEB-INF/classes WEB-INF/lib/*.jar
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:
plugInDir/classes plugInDir/lib/*.jar
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.
Multithreading and Synchronization
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.
Avoid usage of global variables, which might lead to the following issues:
*Synchronization is required otherwise non-reproducible race conditions occur.
*Memory leakages if global collections that grow for each session are used.
*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:
*If the connection is still open, credentials of another user is used, thus causing a security hole.
*If the connection is no longer open, a corresponding exception occurs (trying to use a closed connection).
Nested Layouts
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:
*com.softwareag.cis.plugin.adapter.util.CommonAdapter - for a plug-in that does not depend on CentraSite Control
*com.centrasite.control.adapters.BaseAdapter - for a plug-in that depends on CentraSite Control
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:
*call super.endProcess()
*call CommonAdapter.removeKnownAdapter (subPageAdapter) for each subPageAdapter

Copyright © 2015- 2019 | Software AG, Darmstadt, Germany and/or Software AG USA, Inc., Reston, VA, USA, and/or its subsidiaries and/or its affiliates and/or their licensors.
Innovation Release