Problem updating r_policy_id and r_version_label on a dm_document

Hans Henrik · 2023-10-06T12:49:11+00:00

There was an error rendering this rich post.

Hi,

We are upgrading our Documentum installation and need to create new services which import documents into Documentum and add the lifecycle (policy) to the documents during import.

Normally I would use the attach method to attach the policy but because we relocate documents during the policy attachment in the lifecycle actions I need to apply the lifecycle manually as the documents needs to be located in a separate folder structure until a user pick up the imported document and correct whatever in the metadata.

The below code is just sample code but it will throw an except also below:

public static voidUpdatePolicyID(String strRObjectId, String strRPolicyID) {

   try {

      IDfSysObject dctmSysObject = (IDfSysObject) dctmIDfSession.getObjectByQualification("dm_document (all) where r_object_id = '"+ strRObjectId + "'");

     dctmSysObject.setString("r_policy_id", strRPolicyID);

     dctmSysObject.save();

   }

   catch (DfException ex) {

      System.out.println("Failed to update Policy ID!\n" + ex.getStackTraceAsString());

   }

   catch (Exception ex) {

      System.out.println("Failed to update Policy ID!\n" + ex.getMessage());

   }

}


14:01:42,863 ERROR [main] com.documentum.fc.client.security.impl.util.ClassContextFetcher - Static initialization for determining class call context failed

java.lang.reflect.InaccessibleObjectException: Unable to make protected native java.lang.Class[] java.lang.SecurityManager.getClassContext() accessible: module java.base does not "opens java.lang" to unnamed module @6ad82709

at java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:354) ~[?:?]

at java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297) ~[?:?]

at java.lang.reflect.Method.checkCanSetAccessible(Method.java:199) ~[?:?]

at java.lang.reflect.Method.setAccessible(Method.java:193) ~[?:?]

at com.documentum.fc.client.security.impl.util.ClassContextFetcher.(ClassContextFetcher.java:63) [dfc.jar:?]

at com.documentum.fc.client.DfTypedObject.getCallStackStartingAtTopOfStack(DfTypedObject.java:1075) [dfc.jar:?]

at com.documentum.fc.client.DfTypedObject.isCalledByTrustedCaller(DfTypedObject.java:1042) [dfc.jar:?]

at com.documentum.fc.client.DfTypedObject.verifyInternalAttributeAccessRights(DfTypedObject.java:1016) [dfc.jar:?]

at com.documentum.fc.client.DfTypedObject.setStringRaw(DfTypedObject.java:1462) [dfc.jar:?]

at com.documentum.fc.client.DfTypedObject.doSetString(DfTypedObject.java:1445) [dfc.jar:?]

at com.documentum.fc.client.DfTypedObject.setString(DfTypedObject.java:1418) [dfc.jar:?]

at com.tieto.flsdoc.tbo.FlsEnterpriseImpl___PROXY.setString(FlsEnterpriseImpl___PROXY.java) [dfc.jar:?]

at Main.UpdatePolicyID(Main.java:190) [bin/:?]

at Main.main(Main.java:137) [bin/:?]

I'm no Java expert as I just started learning the language about a year ago.

There is no problem updating other "normal" attributes like "object_name".
So to me it seems like some kind of security issue as I don't have this problem in Documentum 7.3 and prior.

I have tried to add this: -Djava.locale.providers=COMPAT,SPI --add-opens=java.base/java.lang=ALL-UNNAMED --add-opens=java.base/java.lang.invoke=ALL-UNNAMED
to the command line but same result.

Inside dfc.jar there is a file called dfc.example.java.policy but it's written in Klingon (for a Java beginner) (file is attached). But I think it's something like that I need to implement.

Product information:
Documentum 21.04
DFC 21.04
JDK 17 (have also tried with JDK 11, same issue)

Please, any help will be appreciated.

Best regards,
Hans Henrik

dfc.example.java.policy.txt

Find more posts tagged with

Documentum

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

Hans Henrik

Problem solved, add: -Djava.locale.providers=COMPAT,SPI --add-opens=java.base/java.lang=ALL-UNNAMED --add-opens=java.base/java.lang.invoke=ALL-UNNAMED
to the execution environment works if I do it the right way :)

All comments

Hicham Bahi

I don't understand your use case but you're not supposed to set r_ attributes manually. The r_ prefix stands for "read-only", which means that they can only be updated by the Documentum Server as a response to an API call (such as attach for example).

Francois Dauberlieu

the attributes with the r_ prefix means read only therefore, you can't update them.

However, you could probably 'cheat' the system with the API execsql (refer to the API doc for that) that would allow to modify the values directly in the RDBMS (if you do so, you'll have to re-fetch the object though)

NOTE: using execsql can be risky, make sure you know what you're doing because if you mess around in the RDBMS, you won't get support…

Hans Henrik

Thanks,

Yes, I know what I'm doing. I have over 20 years with Documentum database and know it as my own pocket but I dont' understand these restriction added to the later java API.

To me is seems strange to limit the access as it should be handled by ACL's. If you are docbase owner it's your docbase and you should be able to do whatever you want.

Also, Documentum have never been very stable when it comes to attaching lifecycles. For many years I had my own tool to repair failed lifecycle attachment due to problems in data communication.

And, yes, I can just use DQL/SQL to do my thing but to me it's not the right way to do it as I have to save the object before I can attach the life cycle. This will make the object stored in the repository with missing data in case of failure later in the creation/update process instead of I just could have done revert on the object.

I know the work around but I would prefer to do it the right way.

Br Hans Henrik

Hans Henrik

Francois Dauberlieu

Good one. But still, officially r_* attributes are not supposed to be updated manually by your app. However, if it works for you, well done…😉