One of the primary benefits of BOF is hot deployment of updates. But do you get hot deployment for all BOF elements? The answer is no, and you need to understand when you do and when you don’t.
If you look at the BOF class loaders you will see that all module-specific loaders share a common parent – the BOF shared loader. The shared loader is primarily intended to contain module interfaces. There is a second supported case though – non-sandboxed Java libraries. These are used to share implementation jars across modules. This is not a recommended practice, but it does avoid potential duplication of class files in memory (the only reason that it is supported).
It is fatal to update interfaces in a running VM in many cases and ill advised in others, so the expectation is that classes in the shared loader are not dynamic. Anything that is loaded by a module-specific loader is subject to hot deployment, but anything loaded by the shared loader does not enjoy hot deployment. The main reason for this is that invalidating this class loader would mean invalidating all existing module-specific class loaders, possibly resulting in duplicates for some time as modules are garbage collected which could be a significant memory cost. Regardless of the reason, it is a fact.
The take home lesson is that if you use non-sandboxed Java libraries you will not get hot deployment for those libraries. At the cost of some class file duplication you can get all the BOF benefits including hot deployment if you sandbox your Java libraries, and we strongly recommend this. Note that an update to a sandboxed Java library is propagated to all consuming modules via hot deployment.
As an aside, be careful to avoid caching module instances because these instances are immune to hot deployment.
2 responses so far ↓
Frank Weyhers // April 28, 2009 at 11:25 pm
Hi Don,
i have a little problem with class loader effects in my bof modules. Let me explain:
we use documentum 6.5 and have created some workflow methods, which we deploy as modules. Some of these workflow-methods should call webservices (third party applications). We have created (generated by wsdl2java) the client stub for these webservice.
What are your recommendations about the deployment of the necessary java libs (i.e. jaxb…) and the handling of classloading in this situation.
Kind regards
Frank
donr7n // April 29, 2009 at 9:45 am
Hi Frank. I’m not a web service guy, but I’ll do my best with some recommendations. In the method server there should not be any versions of jaxb or jaxws visible to BOF by default (until Java 6). Put the versions you choose in a sandboxed java library. Put your code generated stubs in a sandboxed java library or implementation jars. Most importantly, you will need to set up your thread context class loader appropriately within your module to give jaxb visibility to your client stubs (the advice is appropriate for jaxb clients in general – not just DFS clients).