There are a couple of reasons you might want to deploy Java server methods as BOF modules.
- You want to deploy the implementation in the same dar/docapp as the dm_method definition
- You want to avoid jar hell by avoiding the java_methods directory
- You want hot deployment for your method implementation
In order to deploy your method as a module you have to do the following:
- Define a module by subclassing DfSingleDocbaseModule or have your module implement the marker interface IDfModule directly
- Have your module implement IDfMethod – not IDmMethod (no interface jar)
- Put the module name – not the class name – in the command_verb of the dm_method object
- Make your module self-contained. You have no visibility to classes in the java_methods directory so you must be able to find anything you need in one or more BOF modules.
That’s it.
5 responses so far ↓
Rob Audenaerde // December 1, 2008 at 6:26 am
Ok, but suppose I have 20 server methods. Currently they are deployed by one bug jar in the java_methods.
I agree the BOF is a nicer way to deploy methods, but I would need 20 BOF modules, all mapping to the same jar; as it needs to be self contained. I would end up with a lot of code duplication.
It might be possible to pack the ‘general’ part of the modules in a module in Documentum? Did you test this?
donr7n // December 1, 2008 at 8:37 am
Rob
By “self-contained” I meant that you must rely only on BOF modules – the java_methods directory is not visible to a method module. But you have access to any BOF modules that have been deployed so you can distribute logic across BOF modules as needed. I updated the post to make it clearer – thanks.
If you want to share common code across BOF modules you can use a BOF java library. A java library is a collection of one or more jars that can be used by more than one module. If you update a java library then all consuming modules will see the update. In almost all cases I would recommend a sandboxed java library (an option when you define it in Composer).
I would still recommend that you separate the unique parts of the methods into discrete implementation jars (especially the classes that implement IDfMethod) and just share common code.
In Composer the easiest way to do this is to have the method modules and the java library in a single project.
If it suits your purposes better though, you can have more than one project, but just define the java library in one and then have the other projects reference that project. If there is no obvious “home project” for the common code then you can create a project with nothing but the java library in it and have all the consuming projects refer to that one. In all cases be sure that you only define the java library once or you will not get the behavior you want. Remember to deploy the dars in the right order (the one containing the java library first).
Don
Rob // December 22, 2008 at 1:36 am
Thanks for the article,
However, I got a ‘class cast execption’ telling me the ‘test.testmethod.TestMethod’ is incompatible with the com.documentum.fc.client.IDfModule
The fix is to also implement the IDfModule interface in your method. This interface does not enforce any extra contract, but is needed to make the method compatible.
donr7n // December 22, 2008 at 10:14 am
You are absolutely right Rob – thanks. Mea culpa. I have corrected the post to reflect this.
Writing Java server methods that invoke DFS services « Say Scheveningen // May 20, 2009 at 5:01 pm
[...] First you should understand how to implement a method as a BOF module. [...]