Best practices to avoid OID conflicts

The runtime annotations provided by the rhino-ra module are the easiest way to assign OIDs. These annotations keep the statistic metadata and code together. You can use runtime annotations for parameter set interfaces and counter statistics.

The compile-time annotations provided by the slee-annotations module and the stats-annotations module overlap significantly. Don’t combine these annotations within an application.

Don’t combine multiple OID assignment methods within a product. For example, if you use compile-time annotations to assign OIDs, avoid using manually written deployment descriptors.

Parameter set types shared between different components need different OID suffixes. Assign OID suffixes for such parameter set types with compile-time annotations or in deployment descriptors. Don’t assign with annotations that are introspected at runtime as that may lead to OID conflicts.

Allocate separate blocks of numbers for each usage parameters interface in an inheritance hierarchy. For example, a base usage parameters interface would have OID suffix values ranging from "2" to "99" while an extension of that interface would have OID suffix values ranging from "100 to 199", "200 to 299", and so on. This is to avoid an OID clash with interfaces extending the base usage parameters interface if the base interface is expanded with more parameters.

Avoid hard-coding OID parts within annotations or deployment descriptors, as it’s difficult to see what OIDs are assigned before compiling and deploying the application. Instead, store the OIDs for the application in a file that has the same version used by all releases and development branches. This provides a clear view of the OID coverage for different components and parameter set types.