Non-Modeled Classes

Some components contain non-modeled classes. For these classes, the usage of each External interface or class is described in the Javadoc for the class.

Some non-modeled classes come with Eclipse access restrictions in place to provide customers with guidance in relation to which APIs they can and cannot call or customize. Certain classes and packages are marked as restricted; these classes must not be used as they are internal classes that can change over time. Access restrictions should not be removed from the Eclipse.classpath file as this may result in the consumption of restricted classes which can cause problems during upgrades.

Some non-modeled components contain package protected classes; these classes should not be used in custom code. Customers must not place any custom code in the same package structure in order to call or reference package protected classes.

Many non-modeled APIs are not directly customizable. Only interfaces/classes tagged with the @Implementable annotation can be extended or implemented. Such classes will have JavaDoc detailing how to customize or implement them. Non-modeled classes that are not tagged with the @Implementable annotation must not be extended or implemented as new operations may be added overtime which may cause upgrade impact.

For classes tagged with the @Implementable annotation, the typical customization mechanisms for these types of class are events and strategies.

Events allow customers to add custom logic at various points in the application. For details on how to add event listeners, please refer to the Persistence Cookbook. Event classes are typically named ‘xxxEvent', so they can be easily identified.

Strategy patterns allow customers to change the default behavior of certain functions within the application. Each strategy class has a default implementation provided; however customers can choose to override the default implementation of any of the strategy operations through the use of Guice bindings. The further details on using Guice bindings, please refer to the Persistence Cookbook. Strategy classes are typically named ‘xxxStrategy', so they can be easily identified.

Note: For further compliance details on a per-component basis, please refer to Component Compliance Details.