[
https://issues.apache.org/jira/browse/CONNECTORS-578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13530412#comment-13530412
]
Karl Wright commented on CONNECTORS-578:
----------------------------------------
I think it's getting an exception from LAPI, throwing an exception, and
retrying.
I'm putting in code to dump what that exception is. Please synch up and
rebuild, and when you start ManifoldCF it should start spewing errors to
standard out if I am correct. Please send me one of the traces.
> Livelink connector needs access to general metadata
> ---------------------------------------------------
>
> Key: CONNECTORS-578
> URL: https://issues.apache.org/jira/browse/CONNECTORS-578
> Project: ManifoldCF
> Issue Type: New Feature
> Components: LiveLink connector
> Affects Versions: ManifoldCF 1.1
> Reporter: Karl Wright
> Assignee: Karl Wright
> Fix For: ManifoldCF 1.1
>
> Attachments: procmon.xlsx, stacktrace-startup.txt, stacktrace.txt
>
>
> General metadata access requested for the livelink connector.
> >>>>>>
> All you have to do is call GetObjectInfo with the volumeID (use zero), the
> docID, and a LLVALUE objectInfo (which is just for the returned data; it's
> one of those god awful OpenText rec arrays IIRC)
> On second thought: let me verify this with a code example; but I'm 90% sure
> this should work.
>
> GetObjectInfo should return (in objectInfo) all the data in dtree but I only
> need a subset of that.
> UI display name -> prefix + dtree name
> Name -> ot_name
> Description -> ot_dcomment
> Owner -> ot_userid
> Creation Date -> ot_createdate
> Creator -> ot_createdby
> Modified -> ot_modifydate
> Modified By -> ot_modifiedby
>
> For example, to get the dcomment out of the LLValue
> You would have to do this:
> LLValue elem = ( new LLValue() ).setAssocNotSet();
> String dcomment = elem.toString(“DCOMMENT”);
>
> And that’s how you extract the data out of the opentext structure. It’s kinda
> crappy, you have to know the OT db schema in advance.
>
> Now since owner and creator are sometimes different you would have to make at
> most 2 additional calls to GetObjectInfo to find out the OpenText user name
> (because all you’ll have is a number). So I would check to see if the owner
> and the creator are the same then I only have to make one call.
>
> Listing the general attributes: I would suggest prefixing them with ot_ (for
> OpenText) so the values don't interfere with the general data on the document
> itself. Attached is a picture of the general tab in OpenText. The data itself
> resides in the dtree table.
> And just append it to the array or map that the LivelinkConnector.java
> returns.
> IIRC, you can insert the code around line 1055-1160 after you get the cats
> and atts.
>
> Attached is the GetObjectInfo description from the documentation:
> GetObjectInfo
>
> This function returns an Assoc value object containing information about the
> specified object.
>
> C++ Function Prototype
>
> LLSTATUS LL_GetObjectInfo(
> LLSESSION session,
> LLLONG volumeID,
> LLLONG objectID,
> LLVALUE objectInfo );
>
> Java/.NET Method Declaration
>
> public int GetObjectInfo(
> int volumeID,
> int objectID,
> LLValue objectInfo )
> Input Parameters
> session the session handle as returned by the SessionAllocEx
> function
> volumeID the volume ID of the object. Specify 0 to identify the
> object using only the objectID value.
> objectID the object ID of the object
>
> Output Parameters
> objectInfo a value object of type Assoc, initialized using the
> Value API, containing the attributes for the new object. For more
> information, see ObjectInfo Attributes.
>
> Remarks
>
> For Livelink servers using complex attributes, the category field of the
> objectInfo Assoc is undefined. This function does not retrieve attribute
> definitions.
>
> Any LLVALUE initialized using the Value API can be passed as the objectInfo
> output parameter. GetObjectInfo assigns the appropriate type and value to it.
>
> This function can be performed on any type of object.
>
> <<<<<<
> Followup questions/answers:
> >>>>>>
> To make sure I understand this:
> (1) There is no way to determine through LAPI the names of all
> available general attributes without having a specific item’s
> ObjectInfo object except by describing the dtree table – via something
> like JDBC? (If this is in fact true then I’d prefer to just allow the
> user to enter names of the columns by hand.)
> (2) The general attribute info is found, for any specific object, in
> its associated ObjectInfo structure, and can be retrieved by name.
> (3) SOME general attribute data will require additional processing
> (e.g. lookup of the actual user name given the user id).
> Please correct me if I'm incorrect in any way.
> Is there any different kind of additional processing you can envision?
> Or is lookup of a user name pretty much it?
> <<<<<<
> >>>>>>
> (1) Correct. You could also cheat and just look at the returned LLValue in
> the debugger and see all the dtree column values.
> (2) Correct.
> (3) Correct. Name should be sufficient for the user (it will be the OT
> username)
> <<<<<<
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
