Hi Randy, You might want to have a look at CmisServiceWrapper in the chemistry-opencmis-server-support package. It can save you a lot of hassle like that. It sets unset parameter values to the default values defined in the CMIS spec. It also automatically rejects invalid parameter combination.
- Florian On 11/04/2011 19:53, Speakman, Randy wrote: > Hi Florian, > > I am all set now. I had an issue in my overridden getObject(...) method that > was very hard to track down. Essentially the first call to getObject(...) > with the null Boolean values passed in from the getObjectInternal(...) client > call was the culprit. Inside my getObject(...) method it calls another > private method to compile the objectType data. This method took primitive > boolean values. So when I passed along the null Boolean objects for > includeAllowableActions and includeAcl, the getObject method was throwing an > NPE (auto-unboxing I assume?). Changing my custom method to accept Boolean > parameters and appropriate checks for null values has resolved this problem > for me. I wasn't seeing the second call to getObject(...) on the server like > you explained earlier, so I knew something else was wrong on my server. > > Thanks for your time on leading me in the right direction on this issue. Also > thank you, and the other contributors, for creating OpenCMIS. I have found > this software very useful and have leveraged both the client and server > components in several projects so far. > > Thanks, > > Randy > > -----Original Message----- > From: Florian Müller [mailto:[email protected]] > Sent: Monday, April 11, 2011 12:36 PM > To: Speakman, Randy > Cc: [email protected] > Subject: Re: Retrieve Relationship Issue with AtomPub Binding > > 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:[email protected]] >> Sent: Friday, April 08, 2011 11:35 AM >> To: [email protected]; 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 >>> >>> >> >
