Java Customization: File Entity Generates Read Only Elements

[ptc-1894556]

Hi - we have a weird problem when using file entity within a document. We edit a document that includes another document via a file entity (like . Both the containing and included are read/write on the file system.

However when the customization goes to update an element in the doc it gets a read only exception :-

org.w3c.dom.DOMException: [A30111] DOM exception: attempt to modify a read only object
at com.arbortext.epic.internal.aom.ElementImpl.setAttribute(Native Method)
at com.arbortext.epic.internal.aom.ElementImpl.setAttribute(ElementImpl.java:50)

Interesting thing is that as soon as an edit is made to the document (manually via the editor) the customization can then always update document elements 100% successfully. This 'feels' like some sort of initialization bug but I'm not sure.. The document DOM tree appears to be seeing child elements as read only until the user makes a document change via the editor.


Can anyone provide any insight into what is going on or possible work arounds?

Thanks in advance..David

[ClayHelberg]

Hi David--

This is known as "locking"--Arbortext won't let you edit a child document (entity) in the context of its parent until you lock it (to prevent multiple people from trying to update the same chunk at the same time--similar to locking a database record). When you edit the file in an edit window, it automatically locks whatever chunk you're editing. That's when the little file cabinet icon turns into a little key icon.

I'm not sure of the AOM way to do this programmatically. It looks like you might be able to get the entity content as a CMSObject and then call its checkout() method, but I haven't tried that so I can't say for sure if it's the right way to do it. Or, you could "cheat" and use Acl.eval("oid_entity_lock(" + entityRefNode.aclId + ")"). (Note that there are single quotes inside the double quotes next to the parens there.)

HTH.

--Clay

[ptc-1894556]

Clay - great, thanks for this invaluable info. I will try some of the approaches you mentioned.

Digging further it looks like this locking behavior would only interface with the Arbortext's proprietary CMS system whereas we are using Subversion source control. Perhaps we should be using that..

If not, I'm wondering if there is a way to disable the locking behaviour. I will keep digging..

Thanks again..

[jdreystadt]

You probably want to look at the ACL function called oid_entity_lock. As
I remember it, Subversion does not have the idea of checkout. So you
really just need to tell the Editor that you want to request a file
system level lock on this entity or XML inclusion. You don't want to
disable locking behavior, you want the entities / inclusions to be
opened with a lock asserted so that you can write to them and other
users or processes cannot. Then the DOM would see the entities /
inclusions as being writeable.

Normally, the UI of the Editor takes care of this for you. When the
Editor opens an entity or inclusion, it only opens it for read only,
which means that the operating system does not see the file as locked.
Then as the author goes around typing in the document, the Editor
automagically notices if the author is trying to type in an entity or
inclusion that is not yet locked. If so, it asks the operating system
for read/write on the underlying file, causing an operating system lock.
But you are working at the Java level, you don't get the same automagic.
So you have to see if you are trying to write to an entity / inclusion
that is not yet locked at the operating system level and ask for a lock
if needed.


John Dreystadt
Software Development Director
Arbortext - PTC
734-327-6079
-