OSGi Guidelines

1.Interaction between non-core bundles which can be hot-deployed should be through services (Interfaces).

2.Bundle should Import packages only for utilities, datatypes packages / classes and interfaces.

3.Interface and implementation should be separately bundled. The datatypes associated with service contracts can be bundled along with the interfaces.

4.All third party jars should be converted into bundles. Avoid using "external" in Bundle-classpath.

5.Avoid split package. Proper package structure should be followed. Two bundles should not have same package structure. We can have package structure like -.

6.TC shared classes to be bundled into separate bundles.

7.Avoid static variables and blocks.

8.Avoid Class.forname instead use Classloader.loadclass(). Class.forname may cause issues when bundle is hot deployed as initiating classloader caches the loaded class.

9.Classes present in separate dependent bundles should be loaded using TCCL. For example in jdbcframework all TYPE classes would be bundled with the respective bundle. These classes have to be loaded by jdbcframework bundle. Since classes present in respective bundle will not be visible to jdbcframewok bundle, so jdbcframework bundle has to use TCCL to load these classes.

10.Cyclic dependency should not exist between bundles.

11.Resource clean up - Each bundle / bean should clean up its resources like threads, sockets, cache, file handles, connections etc using its life cycle method (using "destroy" of bean or "stop" of "bundle activator")

12.Use the bean initialization method to initialize the properties and avoid putting initialization logic into constructor.

13.Native library to be loaded once. The code that is loading the native library should be part of core bundle which should not be hot deployed.

14.Prefer composition over inheritance.

15.Use AOP for common concerns - prefer compile time weaving over load-time / runtime weaving.

16.Use DM kernel when web container is not required.

17.Prefer import package over import-bundle.

18.All In-House jars should not have resolution optional for package imports.[Just to ensure that in production enviroment dependencies are resolved at deployment time rather than run time.]

19.All third party converted jars have resolution=optional.Else this pulled a not of other jars which were never used.

20.All log4j imports should have bundle symbolic name for lo4j to resolve properly to log4j instead of slf4j - something like

org.apache.log4j.*;bundle-symbolic-name="com.springsource.org.apache.log4j"

This can be added as part of Bundlor template during building the jar.

21.Manifest is generated at build time based on template(Spring Utility like Bundlor can be used for the same).