chemistry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Florian Müller <florian.muel...@alfresco.com>
Subject Re: Retrieve Relationship Issue with AtomPub Binding
Date Mon, 11 Apr 2011 16:35:53 GMT
Hi Randy,

That is alright. The getObjectInternal() call just resolves the relationship link. It does
not fetch the relationships and does not use the operation context.
The next call is the interesting one. Does the URL contain a value for relationshipDirection?
The calls after that fetch relationship details if necessary. They are using the operation
context.

In a nutshell, ignore the first getObject() call on the server side. It just warms up the
cache. All calls after that should either have a valid includeRelationships or relationshipDirection
parameter.


- Florian


On 11/04/2011 16:31, Speakman, Randy wrote:
> Hi Florian,
> 
> Thanks for responding to my question. I have resolved parts of my issue by cleaning all
references to the 0.1.0Incubating release in my project for both my repository connector and
for my client test harness. I replaced the references with the 0.3.0 release. This resolved
most of my issues but I am still having one problem that I cannot resolve. If I call the session.getRelationships(...).iterator().next();
method with an AtomPub binding after setting the OperationContext to IncludeRelationship.SOURCE,
I am still finding that in the repository connector the includeRelationships parameter is
null when it reaches the overridden getObject(...) method. I have set the DEBUG parameter
value in Log4J and I see that the includeRelationships value is being passed as null. Here
is the line from my log files
> 
> " 2011-04-11 11:16:10,662 [main] [HttpUtils.invoke:85] GET http://localhost:9080/CmisServerConnector/atom/cmisdev1/id?id=0901e19680002873&filter=&includeAllowableActions=&includeACL=&includePolicyIds=&includeRelationships=&renditionFilter="
> 
> 
> 
> I have traced through the client api call and believe that I have located the problem.
The loadLink method of the RelationshipServiceImpl.java method invokes the getObjectInternal
method of the AbstractAtomPubService.java file. On line 160 of the getObjectInternal method,
the includeRelationships parameter is being passed as null. Please let me know if you also
find the same issue.
> 
> ------------------------------------------------------------
>  From org.apache.chemistry.opencmis.client.bindings.spi.atompub. RelationshipServiceImpl.java.
On line 58 and line 59
> 
> // find the link
> String link = loadLink(repositoryId, objectId, Constants.REL_RELATIONSHIPS, Constants.MEDIATYPE_FEED);
> 
> ------------------------------------------------------------
> 
> This calls the getObjectInternal method of AbstractAtomPubService.java (lines 160 and
161)
> ------------------------------------------------------------
> org.apache.chemistry.opencmis.client.bindings.spi.atompub. AbstractAtomPubService.java
> 
> getObjectInternal(repositoryId, IdentifierType.ID, id, ReturnVersion.THIS, null, null,
null, null, null,
>                      null, null);
> 
> 
> -----------------------------------------------------------
> -- Client test driver snippet
> -----------------------------------------------------------
> OperationContext context = session.createOperationContext();
> context.setIncludeRelationships(IncludeRelationships.SOURCE);
> ObjectType peer = session.getTypeDefinition("peer");
> session.getRelationships(session.createObjectId("0901e19680002873"), false, RelationshipDirection.SOURCE,
peer, context).iterator().next();
> 
> 
> 
> 
> Thanks,
> 
> Randy
> 
> -----Original Message-----
> From: Florian Müller [mailto:florian.mueller@alfresco.com]
> Sent: Friday, April 08, 2011 11:35 AM
> To: dev@chemistry.apache.org; Speakman, Randy
> Subject: Re: Retrieve Relationship Issue with AtomPub Binding
> 
> Hi Randy,
> 
> I have tried to reproduce your tests with a 0.4.0 client and a 0.4.0 server. (They are
pretty close to 0.3.0. The difference is negligible.).
> It is working for me. includeRelationships and relationshipDirection are always set correctly.
> 
> The method CmisObject.getRelationships(...) doesn't exist anymore in 0.3.0. CmisObject.getRelationships()
return the relationships that were fetched with the object. Make sure the object is actually
retrieved from the repository and not served from the cache. Try CmisObject.refresh().
> 
> If your breakpoint is never hit, make sure that you actually pull the relationships.
> For example, this code doesn't contact the repository:
> session.getRelationships(obj, true, RelationshipDirection.TARGET, null, session.getDefaultContext());
> This code does:
> session.getRelationships(obj, true, RelationshipDirection.TARGET, null, session.getDefaultContext()).iterator().next();
> 
> I've also checked the change logs if a bug in this area has been fixed between 0.1.0
and 0.3.0 but I couldn't find anything that matches.
> 
> 
> Could you please increase the log level to DEBUG [1]. You should see the URLs that are
called. They should include the two parameters in question. If they are wrong it's a client
problem. If they are right it's a server problem.
> 
> 
> Regards,
> 
> Florian
> 
> 
> [1] http://chemistry.apache.org/java/developing/dev-logging.html
> 
> 
> 
> On 08/04/2011 14:50, Speakman, Randy wrote:
>> Hi,
>>
>> I am in the process of adding relationship functionality to my repository connector
and am running into an issue while trying to retrieve relationships with my OpenCMIS client
using the AtomPub binding. If I use the Webservice binding, everything is working correctly.
I was initially using the 0.1.0-incubating release of OpenCMIS, but have also repeated the
tests using the 0.3.0 release.
>>
>> On the server side repository connector I have overridden the getObjectRelationships
method and the getObject method and have setup DEBUG breakpoints at the start of each method
so that I can inspect the data being passed. I have two different client test cases, the first
one invokes the getObject method on the server and the second one should invoke the getObjectRelationships
method on the server. I have found that when I run Test #1 with an AtomPub binding that the
includeRelationships parameter is null when it hits my breakpoint. If I switch to a Webservice
binding, the includeRelationships parameter is set correctly. If I run Test #2 with an AtomPub
binding the breakpoint on getObjectRelationships is never hit. If I switch to a Webservice
binding, the breakpoint is reached and the relationshipDirection parameter is set correctly.
>>
>> I am thinking that there may be an issue in the OpenCMIS client code with the AtomPub
binding when retrieving relationships. However I wanted to pass on snippets of my client side
tests in case the issue may be with my client side setup. In the code snippets below, the
CmisUtils reference is a simple class I wrote that handles the boilerplate setup of a session.
>>
>>
>> /*
>> Client Side Test Case #1
>>    Expect that the getObject method should be invoked and
>>    the includeRelationships parameter should be set to SOURCE
>> */
>>
>> Session session = CmisUtils.getSession(restUrl, repository, username, password);
>> OperationContext context = session.getDefaultContext();
>> context.setIncludeRelationships(IncludeRelationships.SOURCE);
>> ObjectType peerRelation = session.getTypeDefinition("peer");
>> CmisObject baseDoc = session.getObject(new ObjectIdImpl("0901e19680002873"),context);
>> ItemIterable<Relationship>   relatedItems =
>>    baseDoc.getRelationships(false,RelationshipDirection.SOURCE, peerRelation,context);
>>
>>
>>
>> /*
>> Client Test Case #2
>> Expect that the getObjectRelationships method should be invoked
>> and the relationshipDirection parameter should be set to SOURCE
>> */
>> Session session = CmisUtils.getSession(restUrl, repository, username, password);
>> RelationshipService rService = session.getBinding().getRelationshipService();
>> ObjectList objList = rService.getObjectRelationships(repository, "0901e19680002873",
false, RelationshipDirection.SOURCE, "peer", null, false, null, null, null);
>>
>>
>>
>>
>>
>> Thanks,
>>
>> Randy
>>
>>
> 


Mime
View raw message