Deploying SBOs to global repository (only)

I can’t seem to figure out how to organize my Documentum projects in composer so that it does not require me to install my SBOs to every content server. If I understand correctly, only the global repository needs the SBOs and they will only ever be deployed from the global repository.

However, If I create a project that contains a TBO and that TBO requires the use of an SBO then I must reference the project that contains the SBO and in doing so commit to installing both projects into every content repository that needs the application.

Is there an authoritative answer to this problem or has anyone figured out a workaround?

I’m trying to structure my projects so I can teach others and I can hardly teach them if I don’t know how and why it works myself. It is also very inefficient since I now must deploy my changes to multiple locations. I’ve tried the forums before but got no response.

Thanks,

-Mark

Find more posts tagged with

Note:

If there are Accepted Answers, those will be shown by default. You can switch to 'All Replies' by selecting the tab below.

Accepted answers

fainemr

Okay, the problem from my previous post turns out to be my fault. My ant build script was referencing the "src" directory so it built the common jar file with the source files included but not the class files. You can see it right there in my listing of the contents of the jar file. Somehow, I didn't even notice that the files all end in .java. After correcting this issue and retesting the entire process I can say that this is the correct answer.

Just to sum up:

Do not reference the SBO in the "Required Modules" section of the General Tab. Instead, add the SBO interface jar file to the "Interface JARs" section on the general tab.

Thanks goes to Siddhartha Chakraborty at EMC for helping me with this. He was really on the ball.

All comments

DCTM_Guru

"...If I create a project that contains a TBO and that TBO requires the use of an SBO then I must reference the project that contains the SBO"

- Cant you just reference the SBO jar file in your TBO project? This sounds like more of a compile issue than deployment issue. You shouldnt have to deploy SBO in order for your project to compile. It just may need a reference in order to compile correctly.

fainemr

That is what I thought too but it won't even deploy if the dependent project hasn't already been installed.

Just to clarify:

The problem is that the project contains a TBO that references an SBO in the Required Modules section of the TBO. The SBO is not local but a reference to an SBO in another project that contains SBOs.

My idea so far is to have two generic projects:

common

global_registry

and other projects for specific projects

project1, project2, etc

The common project is installed to every content repository, it contains our basic object model and just generally anything that belongs in every content repository.

The global registry project contains mostly just SBOs and instended to be installed to only the global registry repository.

However, I find that if one of the other projects (project1, project2, etc) references an SBO from global_registry in Required Modules then, in order to deploy the project, I must first install the global_registry project to the content repository first.

DCTM_Guru

Have you contacted EMC support about this? This sounds like a limitation/bug for Composer.

fainemr

Yes, just today. I am curious what they will say. If it is a bug it is a big oversight since it kind of defeats the purpose of a global registry.

fainemr

I received a reply from EMC:

Q1. If I understand correctly, only the global repository needs the SBOs and they will only ever be deployed from the global repository.

EMC. Yes. SBOs should be deployed in the global repository and there is no need to deploy the SBO in other repositories.

Q2. If I create a project that contains a TBO and that TBO requires the use of an SBO then I must reference the project that contains the SBO.

EMC. No. It is not required for you to reference the project that contains the SBO. If your TBO code is invoking the SBO then it requires the SBO interface jars as a reference to its implementation class. So you need to just add the SBO interface jar as a reference jar in your TBO definition.

---

This seems to work but I have some code in a Jar file that is made up of mostly non-DFC static methods. This Jar file is referenced within a Java Library I call “common”. It is a part of an overall project of common artifacts which is also called “common”. The common Java library is shared with modules in multiple projects by adding it to the Java Libraries for the given module under the deployment tab. However, when configured as described above the common Java library is deployed but for some reason I still get a NoClassDefFoundError when my SBO tries to call the code in the library.

java.lang.NoClassDefFoundError: gov/nasa/msfc/repository/utility/objects/dctm/DQLQuery

at gov.nasa.msfc.repository.sbo.impl.DocumentSBOImpl.getNextReferenceNumber(DocumentSBOImpl.java:154)

at gov.nasa.msfc.repository.tbo.NtDocument.init(NtDocument.java:240)

However, the BOF cache does contain the jar file, it is being deployed, but maybe not loaded with the correct class loader?

-rw-r--r-- 1 tomcat tomcat 23K Jun 6 15:32 09024d0880045feb_common.jar

-rw-r--r-- 1 tomcat tomcat 1.6K Jun 6 15:32 09024d0880045fed_IDocumentSBO.jar

-rw-r--r-- 1 tomcat tomcat 13K Jun 6 15:32 09024d0880045ffb_NtDocumentTBO.jar

$ unzip –l 09024d0880045feb_common.jar

…

17043 03-20-12 15:36 gov/nasa/msfc/repository/utility/objects/StringUtil.java

3479 03-20-12 15:36 gov/nasa/msfc/repository/utility/objects/dctm/DQLQuery.java

2076 03-20-12 15:36 gov/nasa/msfc/repository/utility/objects/dctm/DocumentUtil.java

…

I'll keep working this with EMC and post back what I find out.

fainemr

Just to sum up:

Do not reference the SBO in the "Required Modules" section of the General Tab. Instead, add the SBO interface jar file to the "Interface JARs" section on the general tab.

Thanks goes to Siddhartha Chakraborty at EMC for helping me with this. He was really on the ball.