[oslc-rm] [OSLC-RM] Troubleshoot : PUT on a DOORS requirement

[Madeuf, Louis]

Never mind, this log entry in the server command prompt helped me find a
non-ascii character in my xml. It works now !

Have a nice day

 

<29-Aug-2012 11:32:14> [http-8080-2] WARN
com.hp.hpl.jena.rdf.model.impl.RDFDefaultErrorHandler  -
file:///C:/Program%20Files/IBM/Rational/DOORS%20Web%20Access

/1.5.0.1/server/bin/(line 9 column 53): {W124} Non-ascii characters in a
namespace URI may not be completely portable:
<http://localhost:8080/dwa/rdm/%3Fversion

%3D2%26prodID%3D0
%26urn%3Durn%3Atelelogic%3A%3A1-4fe839f150a62e6e-M-000000e0/types/>.
Resulting RDF URI references are legal.

 

From: Madeuf, Louis 
Sent: 29 August 2012 11:16
To: 'oslc-rm at open-services.net'
Subject: [OSLC-RM] Troubleshoot : PUT on a DOORS requirement

 

Hello to all the OSLC-RM mailing list,

 

I am facing a strange issue with DOORS 9.4 + DWA 1.5 OSLC-RM
implementation.

According to this link it is possible to do a PUT on a requirement : 

 

http://publib.boulder.ibm.com/infocenter/doorshlp/v9/index.jsp?topic=/co
m.ibm.doors.install.doc/topics/r_oslc_services.html

 

So I did, using this URL :

 

http://localhost:8080/dwa/rm/+URN-OF-A-REQUIREMENT

 

I had to keep track of the versioning with the If-Match header, and
everything seems to work, no errors pop up. But when I look closer to
the XML sent back, the resource is the previous version and not the
updated version I PUT. In DOORS database, the requirement is still the
previous version. I looked at the ETag header, the ETag did not change,
indicating the version is still the same before and after the PUT.

 

Any ideas about what could be going on ?

Thanks a lot for your time,

 

Best Regards,

 

Louis MADEUF

EADS Innovation Works

+44 (0)1633714711

Quadrant Campus, Celtic Springs, Cleppa Park, 

Coedkernew, Newport, NP10 8FZ, United Kingdom.

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-rm_open-services.net/attachments/20120829/6d7a7d2d/attachment-0003.html>