[news.eclipse.technology.ohf] Re: ITI-14 - RetrieveDocument URI (Length

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Newsgroup Home]

[news.eclipse.technology.ohf] Re: ITI-14 - RetrieveDocument URI (Length Problem)

From: stefan@xxxxxxxxxxxxx (Stefan S.)
Date: Thu, 21 Aug 2008 18:08:33 +0000 (UTC)
Newsgroups: eclipse.technology.ohf
Organization: Eclipse
User-agent: NewsPortal/0.36 (http://florian-amrhein.de/newsportal)

Hi Sarah!

Thanks for your quick response. Don't worry, I am not sooo fast in posting bugs at "official" places! ;)

I am aware of the fact, that I am posting to the XDS.b registry, but as far as I am informed, the URI attribute is requried attribute for an XDS.b registry and an optional attribute for XDS.b. Please correct me, if I am wrong.

Greetings and Thanks!
Stefan

Sarah Knoop wrote:

AH!!! ... Stefan!

I just reread your email and think I know what is going on. The URI attribute is for the XDS.a profile. You'll need to post to the XDS.a NIST registry endpoint, not the XDS.b one.

See if this fixes things. If not, then post the bug.

- Sarah

Sarah Knoop wrote:
Hi Stefan -- you are correct. XDS's dependancy on the ebXML standard encurrs these length limitations and the work around for URI is to split (as in the example below). OHF already has logic (as you pointed out) to do this splitting. Given the information below ... it seems that this is a bug with NIST (or at least submitting the problem to them). They have a bug reporting system you can submit this too --

http://ihe.univ-rennes1.fr/flyspray/index.php?tasks=all&project=1&highlight=10_2

Be sure to include the stack trace and the entire message. I'll additionally pass this on to a contact in NIST and see what he has to say. Of note - this week NIST is involved in a US NHIN project testing event, so they may be swamped.
- Sarah
Stefan S. wrote:
Hi Everybody!
Recently I have stumbled across an interesting problem, I am not quite sure on how to solve. So I thought the best address would be the OHF Newsgroup. ;)

Basically what I am trying to do is write some code that registers a document set (ITI-14) with an IHE Registry. Currently I am testing with the official NIST Registry (B).

Besides adding a document Hash and Size to every DocumentEntry, I want to submit an URI to support the ITI-14, Retrieve Document.
Basically my URI looks something like:

http://SERVERNAME/axis2/services/DocumentRepositoryService/RetrieveDocument?param0=1.2.3.4.116030179011263034.1219323603286.1&param1=application/pdf

The problem is, that the official NIST Registry rejects my request. As soon as I make the URI shorter (below 128 characters), everything works correctly. Even special characters like ?, /, : and so on are no problem.
So I made some research and found this in the IHE Technical Framework:
The URI of the XDS Document to be used for retrieval by XDS.a Document Consumer actors. XDS.a does not constraint the format of this URI beyond RFC 2616. However, the IHE Retrieve Information for Display Integration Profile defined format may be used in cases where the Document repository is grouped with a RID Information Source Actor (See ITI TF-1:Appendix E.5) RID links can be used only if they yield the document in full fidelity. There are two formats for coding this attribute. If the string representing the URI is 128 characters or shorter, the short format may be used: <rim:Slot name="URI"> <rim:ValueList> <rim:Value>http://www.ihe.net</rim:Value> </rim:ValueList> </rim:Slot> If the string is more than 128 characters long, the long format shall be used: <rim:Slot name="URI"> <rim:ValueList> <rim:Value>1|http://www.ihe.net/ IHERetrieveDocument?</rim:Value> <rim:Value>2|requestType=DOCUMENT&documentUID=1.2.3</rim:Value> <rim:Value>3|&preferredContentType=application%2fpdf</rim:Value> </rim:ValueList> </rim:Slot> Each Value is composed of an ordering prefix followed by a portion of the actual URI string. The ordering prefix shall be sequential starting at the value 1. When the long format is used, all Values shall have an ordering prefix.

So basically String, that are longer than 128 characters have to be "split into" the long format. Taking a look at the message that I am sending to the NIST Registry reveals that is is done exactly as shown in the example above.

But as soon as I have more than 128 characters and therefore use the long format, I am rejected by the NIST Registry.
I hope someone has an answer or at least a helpful advice for me! ;)
Thanks in Advance for both your time and your knowledge!
Stefan
To make things concrete (and more complicated...): This is the message that I am getting from the NIST registry upon sending an URI with more than 128 characters:

Document registration failed. The registry responsemessage is: <rs:RegistryResponse xmlns:rs="urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0"

status="urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Failure"><rs:RegistryErrorList><rs:RegistryError

codeContext="Registry rejected metadata submission: 
com.sun.ebxml.registry.RegistryException: Batch entry 5 INSERT INTO Slot (sequenceId, name_, slotType, value, parent) VALUES( was aborted. Call getNextException() to see the cause.
	at

com.sun.ebxml.registry.persistence.rdb.SlotDAO.insert(SlotDAO.java:226)
	at

com.sun.ebxml.registry.persistence.rdb.RegistryObjectDAO.insert(RegistryObjectDAO.java:243)
	at

com.sun.ebxml.registry.persistence.rdb.ExtrinsicObjectDAO.insert(ExtrinsicObjectDAO.java:155)
	at

com.sun.ebxml.registry.persistence.rdb.SQLPersistenceManagerImpl.insert(SQLPersistenceManagerImpl.java:394)
	at

com.sun.ebxml.registry.persistence.rdb.SQLPersistenceManagerImpl.insert(SQLPersistenceManagerImpl.java:284)
	at

com.sun.ebxml.registry.persistence.PersistenceManagerImpl.insert(PersistenceManagerImpl.java:52)
	at

com.sun.ebxml.registry.lcm.LifeCycleManagerImpl.submitObjects(LifeCycleManagerImpl.java:126)
	at

com.sun.ebxml.registry.interfaces.Request.process(Request.java:146)
	at

gov.nist.ebxml.registry.MultiPartLCM.processLCMPostRequest(MultiPartLCM.java:153)
	at

com.sun.ebxml.registry.interfaces.rest.RestServlet.processPostRequest(RestServlet.java:78)
	at

com.sun.ebxml.registry.interfaces.rest.RestServlet.doPost(RestServlet.java:103)
	at

javax.servlet.http.HttpServlet.service(HttpServlet.java:763)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:856)
	at

org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:284)
	at

org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:204)
	at

org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:257)
	at

org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151)
	at

org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:567)
	at

org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:245)
	at

org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:199)
	at

org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151)
	at

org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:587)
	at

org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:149)
	at

org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:567)
	at

org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:184)
	at

org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151)
	at

org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:164)
	at

org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:149)
	at

org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:578)
	at

org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:149)
	at

org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:567)
	at

org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:156)
	at

org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151)
	at

org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:567)
	at

org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:972)
	at

org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:206)
	at

org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:833)
	at

org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:732)
	at

org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:619)
	at

org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:688)
	at

java.lang.Thread.run(Thread.java:613)


Nested exception was:
Batch entry 5 INSERT INTO Slot (sequenceId, name_, slotType, value, parent) VALUES( was aborted. Call getNextException() to see the cause.
	at

org.postgresql.jdbc2.AbstractJdbc2Statement.executeBatch(AbstractJdbc2Statement.java:107)
	at

com.sun.ebxml.registry.persistence.rdb.SlotDAO.insert(SlotDAO.java:220)
	at