Making CXF handle XDSMissingDocument error condition
362 views
Skip to first unread message
Marek0
Sep 21, 2011, 5:45:00 AM9/21/11
to ipf-user
Hi Dymtro,
I am currently implementing IHE ITI-41 server side with ipf-2.3-m2.
One of error conditions requiring specific handling is a missing
attachment in the request (errorCode "XDSMissingDocument").
Before the upgrade to ipf-2.3-m2 I was able to catch that exception
with an onException clause in the Camel route and convert it to an
ebRIM response.
What the ITI-41 component in ipf-2.3-m2 seems to do now, is to run
into an exception within an (internal?) CXF interceptor
("java.lang.IllegalStateException: No attachment for id Document1
found in [Document2]") during the UNMARSHAL phase, subsequently
produce a Fault, which goes as a response to the client. My problem is
that I have not been able to override this behavior yet.
I managed
- to hook into the exception processing using a custom implementation
of WsRejectionHandlingStrategy
- within the handler: to insert an instance of StringPayloadHolder
into the content list of the cxfExchange.outMessage. (My payload is a
dummy XML like "<blah/>" in the first attempt).
Now I am not sure what to do with the "out fault" of the CXF exchange.
When my handleRejectedExchange() triggers, exchg.getOutFaultMessage()
is filled.
If I make it empty, after my handler the message apparently will not
be recognized as fault. I get an NullPointerException in my server
(see below) and a http-Response with "Content-Length:0" in my client.
If I leave the fault ungchange, my client receives a SOAP Fault
response rather than my customized response (which surely is a
meaningful behavior).
Do I have to "manipulate the interceptor chain"... or something?
Do I have to debug into CXF internals to see the cause of the
NullPointerException.
Maybe there is simpler approach to "patch" the reponse. Any help/
suggestion will be greatly appreciated.
Kind Regards
Marek
36924 ["http-bio-8081"-exec-1] WARN
org.apache.cxf.phase.PhaseInterceptorChain - Interceptor for
{urn:ihe:iti:xds-b:2007}DocumentRepository_Service#{urn:ihe:iti:xds-b:
2007}DocumentRepository_
ProvideAndRegisterDocumentSet-b has thrown exception, unwinding now
java.lang.NullPointerException
at
org.apache.cxf.binding.soap.interceptor.Soap12FaultOutInterceptor
$Soap12FaultOutInterceptorInternal.handleMessage(Soap12FaultOutInterceptor.java:
67)
at
org.apache.cxf.binding.soap.interceptor.Soap12FaultOutInterceptor
$Soap12FaultOutInterceptorInternal.handleMessage(Soap12FaultOutInterceptor.java:
56)
at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:
263)
at
org.apache.cxf.interceptor.AbstractFaultChainInitiatorObserver.onMessage(AbstractFaultChainInitiatorObserver.java:
105)
at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:
323)
at
org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:
121)
at
org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:
206)
at
org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:
218)
at
org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:
200)
at
org.apache.cxf.transport.servlet.CXFNonSpringServlet.invoke(CXFNonSpringServlet.java:
114)
at
org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:
184)
at
org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:
107)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:
595)
at
org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:
163)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:
304)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:
210)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:
240)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:
164)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:
462)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:
164)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:
100)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:
118)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:
395)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:
250)
at org.apache.coyote.http11.Http11Protocol
$Http11ConnectionHandler.process(Http11Protocol.java:188)
at org.apache.coyote.http11.Http11Protocol
$Http11ConnectionHandler.process(Http11Protocol.java:166)
at org.apache.tomcat.util.net.JIoEndpoint
$SocketProcessor.run(JIoEndpoint.java:302)
at java.util.concurrent.ThreadPoolExecutor
$Worker.runTask(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown
Source)
at java.lang.Thread.run(Unknown Source)
I am currently implementing IHE ITI-41 server side with ipf-2.3-m2.
One of error conditions requiring specific handling is a missing
attachment in the request (errorCode "XDSMissingDocument").
Before the upgrade to ipf-2.3-m2 I was able to catch that exception
with an onException clause in the Camel route and convert it to an
ebRIM response.
What the ITI-41 component in ipf-2.3-m2 seems to do now, is to run
into an exception within an (internal?) CXF interceptor
("java.lang.IllegalStateException: No attachment for id Document1
found in [Document2]") during the UNMARSHAL phase, subsequently
produce a Fault, which goes as a response to the client. My problem is
that I have not been able to override this behavior yet.
I managed
- to hook into the exception processing using a custom implementation
of WsRejectionHandlingStrategy
- within the handler: to insert an instance of StringPayloadHolder
into the content list of the cxfExchange.outMessage. (My payload is a
dummy XML like "<blah/>" in the first attempt).
Now I am not sure what to do with the "out fault" of the CXF exchange.
When my handleRejectedExchange() triggers, exchg.getOutFaultMessage()
is filled.
If I make it empty, after my handler the message apparently will not
be recognized as fault. I get an NullPointerException in my server
(see below) and a http-Response with "Content-Length:0" in my client.
If I leave the fault ungchange, my client receives a SOAP Fault
response rather than my customized response (which surely is a
meaningful behavior).
Do I have to "manipulate the interceptor chain"... or something?
Do I have to debug into CXF internals to see the cause of the
NullPointerException.
Maybe there is simpler approach to "patch" the reponse. Any help/
suggestion will be greatly appreciated.
Kind Regards
Marek
36924 ["http-bio-8081"-exec-1] WARN
org.apache.cxf.phase.PhaseInterceptorChain - Interceptor for
{urn:ihe:iti:xds-b:2007}DocumentRepository_Service#{urn:ihe:iti:xds-b:
2007}DocumentRepository_
ProvideAndRegisterDocumentSet-b has thrown exception, unwinding now
java.lang.NullPointerException
at
org.apache.cxf.binding.soap.interceptor.Soap12FaultOutInterceptor
$Soap12FaultOutInterceptorInternal.handleMessage(Soap12FaultOutInterceptor.java:
67)
at
org.apache.cxf.binding.soap.interceptor.Soap12FaultOutInterceptor
$Soap12FaultOutInterceptorInternal.handleMessage(Soap12FaultOutInterceptor.java:
56)
at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:
263)
at
org.apache.cxf.interceptor.AbstractFaultChainInitiatorObserver.onMessage(AbstractFaultChainInitiatorObserver.java:
105)
at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:
323)
at
org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:
121)
at
org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:
206)
at
org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:
218)
at
org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:
200)
at
org.apache.cxf.transport.servlet.CXFNonSpringServlet.invoke(CXFNonSpringServlet.java:
114)
at
org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:
184)
at
org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:
107)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:
595)
at
org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:
163)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:
304)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:
210)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:
240)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:
164)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:
462)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:
164)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:
100)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:
118)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:
395)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:
250)
at org.apache.coyote.http11.Http11Protocol
$Http11ConnectionHandler.process(Http11Protocol.java:188)
at org.apache.coyote.http11.Http11Protocol
$Http11ConnectionHandler.process(Http11Protocol.java:166)
at org.apache.tomcat.util.net.JIoEndpoint
$SocketProcessor.run(JIoEndpoint.java:302)
at java.util.concurrent.ThreadPoolExecutor
$Worker.runTask(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown
Source)
at java.lang.Thread.run(Unknown Source)
Dmytro Rud
Sep 21, 2011, 9:26:24 AM9/21/11
to ipf-...@googlegroups.com
Hi Marek,
I am happy to hear that you are using IPF and its newest features in
particular :-)
Regarding your question: The error message "no attachment with id..."
is generated in the method
org.apache.cxf.attachment.LazyDataSource#load(), which is called
during the execution of
org.apache.cxf.interceptor.AttachmentInInterceptor and whose code has
been changed on June 1st, 2011 as shown in
http://svn.apache.org/viewvc/cxf/trunk/rt/core/src/main/java/org/apache/cxf/attachment/LazyDataSource.java?r1=651669&r2=1129987.
In my opinion, CXF behaves correctly. Incompatibility of this correct
behaviour with IHE requirements may be considered problematic, but I
don't know whose problem it is. Further investigation is necessary.
As a workaround, you can revert the mentioned path locally and build
an own CXF version for your project.
BTW, the Rejection Handling mechanism introduced in IPF 2.3-m2 is
generally not intended for changing of message context and/or message
flow. The problem is also, that the failed message is dispatched in a
special way (i.e. throught a special interceptor chain), and hacking
this behaviour seems for me to be a pretty dangerous juggling.
Kind Regards,
Dmytro
2011/9/21 Marek0 <Marek.V...@freenet.de>:
Dmytro Rud
Sep 21, 2011, 9:48:58 AM9/21/11
to ipf-...@googlegroups.com
BTW, Marek, what is your exact situation? Do you have a
{urn:ihe:iti:xds-b:2007}Document element with broken reference? Are
you sure that this case is covered by the XDSMissingDocument code?
{urn:ihe:iti:xds-b:2007}Document element with broken reference? Are
you sure that this case is covered by the XDSMissingDocument code?
Regards
Dmytro
2011/9/21 Dmytro Rud <dmytr...@googlemail.com>:
Marek0
Sep 21, 2011, 12:22:44 PM9/21/11
to ipf-user
Hi Dmytro,
>I am happy to hear that you are using IPF and its newest features in particular :-)
And I am happy to use it. Lightweightenss and versatility is what we
need in the new project - and IPF has it. :-)
>Do you have a {urn:ihe:iti:xds-b:2007}Document element with broken reference?
I took a valid and working ITI-41 request in soapUI having two
documents - and just removed one of the attachments in the
"Attachments" view.
This leads to this in the HTTP log:
Wed Sep 21 18:11:09 CEST 2011:DEBUG:>> "POST /test/ws/iti41Service
HTTP/1.1[\r][\n]"
Wed Sep 21 18:11:09 CEST 2011:DEBUG:>> "Accept-Encoding:
gzip,deflate[\r][\n]"
Wed Sep 21 18:11:09 CEST 2011:DEBUG:>> "Content-Type: multipart/
related; type="application/xop+xml"; start="<root...@soapui.org>";
start-info="application/soap+xml"; action="urn:ihe:iti:
2007:ProvideAndRegisterDocumentSet-b"; boundary="----
=_Part_112_439828433.1316621469049"[\r][\n]"
Wed Sep 21 18:11:09 CEST 2011:DEBUG:>> "MIME-Version: 1.0[\r][\n]"
Wed Sep 21 18:11:09 CEST 2011:DEBUG:>> "User-Agent: Jakarta Commons-
HttpClient/3.1[\r][\n]"
Wed Sep 21 18:11:09 CEST 2011:DEBUG:>> "Host: localhost:8081[\r][\n]"
Wed Sep 21 18:11:09 CEST 2011:DEBUG:>> "Content-Length: 24266[\r][\n]"
Wed Sep 21 18:11:09 CEST 2011:DEBUG:>> "[\r][\n]"
Wed Sep 21 18:11:09 CEST 2011:DEBUG:>> "[\r][\n]"
Wed Sep 21 18:11:09 CEST 2011:DEBUG:>> "------
=_Part_112_439828433.1316621469049"
Wed Sep 21 18:11:09 CEST 2011:DEBUG:>> "[\r][\n]"
Wed Sep 21 18:11:09 CEST 2011:DEBUG:>> "Content-Type: application/xop
+xml; charset=UTF-8; type="application/soap+xml; action=
\"DocumentRepository_ProvideAndRegisterDocumentSet-b\"""
Wed Sep 21 18:11:09 CEST 2011:DEBUG:>> "[\r][\n]"
Wed Sep 21 18:11:09 CEST 2011:DEBUG:>> "Content-Transfer-Encoding:
8bit"
Wed Sep 21 18:11:09 CEST 2011:DEBUG:>> "[\r][\n]"
Wed Sep 21 18:11:09 CEST 2011:DEBUG:>> "Content-ID:
<root...@soapui.org>"
Wed Sep 21 18:11:09 CEST 2011:DEBUG:>> "[\r][\n]"
Wed Sep 21 18:11:09 CEST 2011:DEBUG:>> "[\r][\n]"
Wed Sep 21 18:11:09 CEST 2011:DEBUG:>> "<soapenv:Envelope
xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope">[\n]"
Wed Sep 21 18:11:09 CEST 2011:DEBUG:>> " <soapenv:Header
xmlns:wsa="http://www.w3.org/2005/08/addressing">[\n]"
Wed Sep 21 18:11:09 CEST 2011:DEBUG:>> " [\n]"
Wed Sep 21 18:11:09 CEST 2011:DEBUG:>> " [\n]"
Wed Sep 21 18:11:09 CEST 2011:DEBUG:>> " [\n]"
Wed Sep 21 18:11:09 CEST 2011:DEBUG:>> " <wsa:Action
soapenv:mustUnderstand="1">urn:ihe:iti:
2007:ProvideAndRegisterDocumentSet-b</wsa:Action><wsa:MessageID
soapenv:mustUnderstand="1">uuid:a3ebbc09-0500-4c4b-882c-2e7f28b84f0a</
wsa:MessageID><wsa:To soapenv:mustUnderstand="1">http://localhost:8081/
test/ws/iti41Service</wsa:To></soapenv:Header>[\n]"
Wed Sep 21 18:11:09 CEST 2011:DEBUG:>> " <soapenv:Body>[\n]"
Wed Sep 21 18:11:09 CEST 2011:DEBUG:>> "
<xdsb:ProvideAndRegisterDocumentSetRequest xmlns:xdsb="urn:ihe:iti:xds-
b:2007">[\n]"
Wed Sep 21 18:11:09 CEST 2011:DEBUG:>> "
<lcm:SubmitObjectsRequest xmlns:lcm="urn:oasis:names:tc:ebxml-
regrep:xsd:lcm:3.0">[\n]"
...
Wed Sep 21 18:11:09 CEST 2011:DEBUG:>> " </
lcm:SubmitObjectsRequest>[\n]"
Wed Sep 21 18:11:09 CEST 2011:DEBUG:>> " <xdsb:Document
id="Document01"><inc:Include href="cid:Textdocument.txt"
xmlns:inc="http://www.w3.org/2004/08/xop/include"/></
xdsb:Document>[\n]"
Wed Sep 21 18:11:09 CEST 2011:DEBUG:>> " <xdsb:Document
id="Document02"><inc:Include href="cid:Pdfdocument.pdf"
xmlns:inc="http://www.w3.org/2004/08/xop/include"/></
xdsb:Document>[\n]"
Wed Sep 21 18:11:09 CEST 2011:DEBUG:>> " </
xdsb:ProvideAndRegisterDocumentSetRequest>[\n]"
Wed Sep 21 18:11:09 CEST 2011:DEBUG:>> " </soapenv:Body>[\n]"
Wed Sep 21 18:11:09 CEST 2011:DEBUG:>> "</soapenv:Envelope>"
Wed Sep 21 18:11:09 CEST 2011:DEBUG:>> "[\r][\n]"
Wed Sep 21 18:11:09 CEST 2011:DEBUG:>> "------
=_Part_112_439828433.1316621469049"
Wed Sep 21 18:11:09 CEST 2011:DEBUG:>> "[\r][\n]"
Wed Sep 21 18:11:09 CEST 2011:DEBUG:>> "Content-Type: text/plain;
charset=us-ascii"
Wed Sep 21 18:11:09 CEST 2011:DEBUG:>> "[\r][\n]"
Wed Sep 21 18:11:09 CEST 2011:DEBUG:>> "Content-Transfer-Encoding:
7bit"
Wed Sep 21 18:11:09 CEST 2011:DEBUG:>> "[\r][\n]"
Wed Sep 21 18:11:09 CEST 2011:DEBUG:>> "Content-ID:
<Textdocument.txt>"
Wed Sep 21 18:11:09 CEST 2011:DEBUG:>> "[\r][\n]"
Wed Sep 21 18:11:09 CEST 2011:DEBUG:>> "Content-Disposition:
attachment; name="Textdocument.txt""
Wed Sep 21 18:11:09 CEST 2011:DEBUG:>> "[\r][\n]"
Wed Sep 21 18:11:09 CEST 2011:DEBUG:>> "[\r][\n]"
Wed Sep 21 18:11:09 CEST 2011:DEBUG:>> "This is a sample text."
Wed Sep 21 18:11:09 CEST 2011:DEBUG:>> "[\r][\n]"
Wed Sep 21 18:11:09 CEST 2011:DEBUG:>> "------
=_Part_112_439828433.1316621469049--"
Wed Sep 21 18:11:09 CEST 2011:DEBUG:>> "[\r][\n]"
>Are you sure that this case is covered by the XDSMissingDocument code?
I have not checked whether there are any particular tests, but this is
the way I read the spec:
"XDSDocumentEntry exists in metadata with no corresponding attached
document"
(ITI TF-3, Rev. 8, Tab. 4.1-11 – Error Codes)
By the way, the related error condition "XDSMissingDocumentMetadata:
MIMEpackage contains MIMEpart withContent-Id header not found in
metadata" does not behave to my expectation yet as well. Having
"redundant" attachments unreferenced in the message passes
undiscovered, but IHE wishes "special treatment".
The HTTP log looks like this, then:
Wed Sep 21 18:19:11 CEST 2011:DEBUG:>> "POST /test/ws/iti41Service
HTTP/1.1[\r][\n]"
Wed Sep 21 18:19:11 CEST 2011:DEBUG:>> "Accept-Encoding:
gzip,deflate[\r][\n]"
Wed Sep 21 18:19:11 CEST 2011:DEBUG:>> "Content-Type: multipart/
related; type="application/xop+xml"; start="<root...@soapui.org>";
start-info="application/soap+xml"; action="urn:ihe:iti:
2007:ProvideAndRegisterDocumentSet-b"; boundary="----
=_Part_115_1222679932.1316621951869"[\r][\n]"
Wed Sep 21 18:19:11 CEST 2011:DEBUG:>> "MIME-Version: 1.0[\r][\n]"
Wed Sep 21 18:19:11 CEST 2011:DEBUG:>> "User-Agent: Jakarta Commons-
HttpClient/3.1[\r][\n]"
Wed Sep 21 18:19:11 CEST 2011:DEBUG:>> "Host: localhost:8081[\r][\n]"
Wed Sep 21 18:19:11 CEST 2011:DEBUG:>> "Content-Length: 29212[\r][\n]"
Wed Sep 21 18:19:11 CEST 2011:DEBUG:>> "[\r][\n]"
Wed Sep 21 18:19:11 CEST 2011:DEBUG:>> "[\r][\n]"
Wed Sep 21 18:19:11 CEST 2011:DEBUG:>> "------
=_Part_115_1222679932.1316621951869"
Wed Sep 21 18:19:11 CEST 2011:DEBUG:>> "[\r][\n]"
Wed Sep 21 18:19:11 CEST 2011:DEBUG:>> "Content-Type: application/xop
+xml; charset=UTF-8; type="application/soap+xml; action=
\"DocumentRepository_ProvideAndRegisterDocumentSet-b\"""
Wed Sep 21 18:19:11 CEST 2011:DEBUG:>> "[\r][\n]"
Wed Sep 21 18:19:11 CEST 2011:DEBUG:>> "Content-Transfer-Encoding:
8bit"
Wed Sep 21 18:19:11 CEST 2011:DEBUG:>> "[\r][\n]"
Wed Sep 21 18:19:11 CEST 2011:DEBUG:>> "Content-ID:
<root...@soapui.org>"
Wed Sep 21 18:19:11 CEST 2011:DEBUG:>> "[\r][\n]"
Wed Sep 21 18:19:11 CEST 2011:DEBUG:>> "[\r][\n]"
Wed Sep 21 18:19:11 CEST 2011:DEBUG:>> "<soapenv:Envelope
xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope">[\n]"
Wed Sep 21 18:19:11 CEST 2011:DEBUG:>> " <soapenv:Header
xmlns:wsa="http://www.w3.org/2005/08/addressing">[\n]"
Wed Sep 21 18:19:11 CEST 2011:DEBUG:>> " [\n]"
Wed Sep 21 18:19:11 CEST 2011:DEBUG:>> " [\n]"
Wed Sep 21 18:19:11 CEST 2011:DEBUG:>> " [\n]"
Wed Sep 21 18:19:11 CEST 2011:DEBUG:>> " <wsa:Action
soapenv:mustUnderstand="1">urn:ihe:iti:
2007:ProvideAndRegisterDocumentSet-b</wsa:Action><wsa:MessageID
soapenv:mustUnderstand="1">uuid:2ca39f30-6290-42e5-a4f1-e286fcf49557</
wsa:MessageID><wsa:To soapenv:mustUnderstand="1">http://localhost:8081/
test/ws/iti41Service</wsa:To></soapenv:Header>[\n]"
Wed Sep 21 18:19:11 CEST 2011:DEBUG:>> " <soapenv:Body>[\n]"
Wed Sep 21 18:19:11 CEST 2011:DEBUG:>> "
<xdsb:ProvideAndRegisterDocumentSetRequest xmlns:xdsb="urn:ihe:iti:xds-
b:2007">[\n]"
Wed Sep 21 18:19:11 CEST 2011:DEBUG:>> "
<lcm:SubmitObjectsRequest xmlns:lcm="urn:oasis:names:tc:ebxml-
regrep:xsd:lcm:3.0">[\n]"
...
Wed Sep 21 18:19:11 CEST 2011:DEBUG:>> " </
lcm:SubmitObjectsRequest>[\n]"
Wed Sep 21 18:19:11 CEST 2011:DEBUG:>> " <xdsb:Document
id="Document01"><inc:Include href="cid:Textdocument.txt"
xmlns:inc="http://www.w3.org/2004/08/xop/include"/></
xdsb:Document>[\n]"
Wed Sep 21 18:19:11 CEST 2011:DEBUG:>> " </
xdsb:ProvideAndRegisterDocumentSetRequest>[\n]"
Wed Sep 21 18:19:11 CEST 2011:DEBUG:>> " </soapenv:Body>[\n]"
Wed Sep 21 18:19:11 CEST 2011:DEBUG:>> "</soapenv:Envelope>"
Wed Sep 21 18:19:11 CEST 2011:DEBUG:>> "[\r][\n]"
Wed Sep 21 18:19:11 CEST 2011:DEBUG:>> "------
=_Part_115_1222679932.1316621951869"
Wed Sep 21 18:19:11 CEST 2011:DEBUG:>> "[\r][\n]"
Wed Sep 21 18:19:11 CEST 2011:DEBUG:>> "Content-Type: text/plain;
charset=us-ascii"
Wed Sep 21 18:19:11 CEST 2011:DEBUG:>> "[\r][\n]"
Wed Sep 21 18:19:11 CEST 2011:DEBUG:>> "Content-Transfer-Encoding:
7bit"
Wed Sep 21 18:19:11 CEST 2011:DEBUG:>> "[\r][\n]"
Wed Sep 21 18:19:11 CEST 2011:DEBUG:>> "Content-ID:
<Textdocument.txt>"
Wed Sep 21 18:19:11 CEST 2011:DEBUG:>> "[\r][\n]"
Wed Sep 21 18:19:11 CEST 2011:DEBUG:>> "Content-Disposition:
attachment; name="Textdocument.txt""
Wed Sep 21 18:19:11 CEST 2011:DEBUG:>> "[\r][\n]"
Wed Sep 21 18:19:11 CEST 2011:DEBUG:>> "[\r][\n]"
Wed Sep 21 18:19:11 CEST 2011:DEBUG:>> "This is a sample text."
Wed Sep 21 18:19:11 CEST 2011:DEBUG:>> "[\r][\n]"
Wed Sep 21 18:19:11 CEST 2011:DEBUG:>> "------
=_Part_115_1222679932.1316621951869"
Wed Sep 21 18:19:11 CEST 2011:DEBUG:>> "[\r][\n]"
Wed Sep 21 18:19:11 CEST 2011:DEBUG:>> "Content-Type: application/pdf"
Wed Sep 21 18:19:11 CEST 2011:DEBUG:>> "[\r][\n]"
Wed Sep 21 18:19:11 CEST 2011:DEBUG:>> "Content-Transfer-Encoding:
binary"
Wed Sep 21 18:19:11 CEST 2011:DEBUG:>> "[\r][\n]"
Wed Sep 21 18:19:11 CEST 2011:DEBUG:>> "Content-ID: <Pdfdocument.pdf>"
Wed Sep 21 18:19:11 CEST 2011:DEBUG:>> "[\r][\n]"
Wed Sep 21 18:19:11 CEST 2011:DEBUG:>> "Content-Disposition:
attachment; name="Pdfdocument.pdf""
Wed Sep 21 18:19:11 CEST 2011:DEBUG:>> "[\r][\n]"
Wed Sep 21 18:19:11 CEST 2011:DEBUG:>> "[\r][\n]"
Wed Sep 21 18:19:11 CEST 2011:DEBUG:>> "%PDF-1.3[\n]"
Wed Sep 21 18:19:11 CEST 2011:DEBUG:>> "%...
Wed Sep 21 18:19:11 CEST 2011:DEBUG:>> "13748[\n]"
Wed Sep 21 18:19:11 CEST 2011:DEBUG:>> "%%EOF[\n]"
Wed Sep 21 18:19:11 CEST 2011:DEBUG:>> "[\r][\n]"
Wed Sep 21 18:19:11 CEST 2011:DEBUG:>> "------
=_Part_115_1222679932.1316621951869--"
Wed Sep 21 18:19:11 CEST 2011:DEBUG:>> "[\r][\n]"
>CXF... hacking this behaviour seems for me to be a pretty dangerous juggling
Oh, not dangerous at all: All that happens is that the behavior
persists - no matter what I change :-)
I guess, my chances of getting it right without deep understanding
InterceptorChain and "Fault Observer" in CXF are like shooting at the
moon...
So I have to think of plan B...
1) Verify the validity of the "XDSMissingDocument" test case with IHE.
Maybe this is not what they meant with after all...
2) Use a patched CXF.
3) Revert my project to ipf-2.3-m1 or at least to cxf-2.3 :-)
Thanks and Best Regards
Marek
On 21 Sep., 15:48, Dmytro Rud <dmytro....@googlemail.com> wrote:
> BTW, Marek, what is your exact situation? Do you have a
> {urn:ihe:iti:xds-b:2007}Document element with broken reference? Are
> you sure that this case is covered by the XDSMissingDocument code?
>
> Regards
> Dmytro
>
> 2011/9/21 Dmytro Rud <dmytro....@googlemail.com>:
> >> $Soap12FaultOutInterceptorInternal.handleMessage(Soap12FaultOutInterceptor.java:
> >> 67)
> >> at
> >> org.apache.cxf.binding.soap.interceptor.Soap12FaultOutInterceptor
> >> $Soap12FaultOutInterceptorInternal.handleMessage(Soap12FaultOutInterceptor.java:
> >> 56)
> >> at
> >> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:
> >> 263)
> >> at
> >> org.apache.cxf.interceptor.AbstractFaultChainInitiatorObserver.onMessage(AbstractFaultChainInitiatorObserver.java:
> >> 105)
> >> at
> >> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:
> >> 323)
> >> at
> >> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:
> >> 121)
> >> at
> >> org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:
> >> 206)
> >> at
> >> org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:
> >> 218)
> >> at
> >> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:
> >> 200)
> >> at
> >> org.apache.cxf.transport.servlet.CXFNonSpringServlet.invoke(CXFNonSpringServlet.java:
> >> 114)
> >> at
> >> org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:
> >> 184)
> >> at
> >> org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:
> >> 163)
> >> at
> >> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:
> >> 304)
> >> at
> >> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:
> >> 210)
> >> at
> >> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:
> >> 240)
> >> at
> >> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:
> >> 164)
> >> at
> >> org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:
>
> - Zitierten Text anzeigen -
>I am happy to hear that you are using IPF and its newest features in particular :-)
need in the new project - and IPF has it. :-)
>Do you have a {urn:ihe:iti:xds-b:2007}Document element with broken reference?
documents - and just removed one of the attachments in the
"Attachments" view.
This leads to this in the HTTP log:
Wed Sep 21 18:11:09 CEST 2011:DEBUG:>> "POST /test/ws/iti41Service
HTTP/1.1[\r][\n]"
Wed Sep 21 18:11:09 CEST 2011:DEBUG:>> "Accept-Encoding:
gzip,deflate[\r][\n]"
Wed Sep 21 18:11:09 CEST 2011:DEBUG:>> "Content-Type: multipart/
related; type="application/xop+xml"; start="<root...@soapui.org>";
start-info="application/soap+xml"; action="urn:ihe:iti:
2007:ProvideAndRegisterDocumentSet-b"; boundary="----
=_Part_112_439828433.1316621469049"[\r][\n]"
Wed Sep 21 18:11:09 CEST 2011:DEBUG:>> "MIME-Version: 1.0[\r][\n]"
Wed Sep 21 18:11:09 CEST 2011:DEBUG:>> "User-Agent: Jakarta Commons-
HttpClient/3.1[\r][\n]"
Wed Sep 21 18:11:09 CEST 2011:DEBUG:>> "Host: localhost:8081[\r][\n]"
Wed Sep 21 18:11:09 CEST 2011:DEBUG:>> "Content-Length: 24266[\r][\n]"
Wed Sep 21 18:11:09 CEST 2011:DEBUG:>> "[\r][\n]"
Wed Sep 21 18:11:09 CEST 2011:DEBUG:>> "[\r][\n]"
Wed Sep 21 18:11:09 CEST 2011:DEBUG:>> "------
=_Part_112_439828433.1316621469049"
Wed Sep 21 18:11:09 CEST 2011:DEBUG:>> "[\r][\n]"
Wed Sep 21 18:11:09 CEST 2011:DEBUG:>> "Content-Type: application/xop
+xml; charset=UTF-8; type="application/soap+xml; action=
\"DocumentRepository_ProvideAndRegisterDocumentSet-b\"""
Wed Sep 21 18:11:09 CEST 2011:DEBUG:>> "[\r][\n]"
Wed Sep 21 18:11:09 CEST 2011:DEBUG:>> "Content-Transfer-Encoding:
8bit"
Wed Sep 21 18:11:09 CEST 2011:DEBUG:>> "[\r][\n]"
Wed Sep 21 18:11:09 CEST 2011:DEBUG:>> "Content-ID:
<root...@soapui.org>"
Wed Sep 21 18:11:09 CEST 2011:DEBUG:>> "[\r][\n]"
Wed Sep 21 18:11:09 CEST 2011:DEBUG:>> "[\r][\n]"
Wed Sep 21 18:11:09 CEST 2011:DEBUG:>> "<soapenv:Envelope
xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope">[\n]"
Wed Sep 21 18:11:09 CEST 2011:DEBUG:>> " <soapenv:Header
xmlns:wsa="http://www.w3.org/2005/08/addressing">[\n]"
Wed Sep 21 18:11:09 CEST 2011:DEBUG:>> " [\n]"
Wed Sep 21 18:11:09 CEST 2011:DEBUG:>> " [\n]"
Wed Sep 21 18:11:09 CEST 2011:DEBUG:>> " [\n]"
Wed Sep 21 18:11:09 CEST 2011:DEBUG:>> " <wsa:Action
soapenv:mustUnderstand="1">urn:ihe:iti:
2007:ProvideAndRegisterDocumentSet-b</wsa:Action><wsa:MessageID
soapenv:mustUnderstand="1">uuid:a3ebbc09-0500-4c4b-882c-2e7f28b84f0a</
wsa:MessageID><wsa:To soapenv:mustUnderstand="1">http://localhost:8081/
test/ws/iti41Service</wsa:To></soapenv:Header>[\n]"
Wed Sep 21 18:11:09 CEST 2011:DEBUG:>> " <soapenv:Body>[\n]"
Wed Sep 21 18:11:09 CEST 2011:DEBUG:>> "
<xdsb:ProvideAndRegisterDocumentSetRequest xmlns:xdsb="urn:ihe:iti:xds-
b:2007">[\n]"
Wed Sep 21 18:11:09 CEST 2011:DEBUG:>> "
<lcm:SubmitObjectsRequest xmlns:lcm="urn:oasis:names:tc:ebxml-
regrep:xsd:lcm:3.0">[\n]"
...
Wed Sep 21 18:11:09 CEST 2011:DEBUG:>> " </
lcm:SubmitObjectsRequest>[\n]"
Wed Sep 21 18:11:09 CEST 2011:DEBUG:>> " <xdsb:Document
id="Document01"><inc:Include href="cid:Textdocument.txt"
xmlns:inc="http://www.w3.org/2004/08/xop/include"/></
xdsb:Document>[\n]"
Wed Sep 21 18:11:09 CEST 2011:DEBUG:>> " <xdsb:Document
id="Document02"><inc:Include href="cid:Pdfdocument.pdf"
xmlns:inc="http://www.w3.org/2004/08/xop/include"/></
xdsb:Document>[\n]"
Wed Sep 21 18:11:09 CEST 2011:DEBUG:>> " </
xdsb:ProvideAndRegisterDocumentSetRequest>[\n]"
Wed Sep 21 18:11:09 CEST 2011:DEBUG:>> " </soapenv:Body>[\n]"
Wed Sep 21 18:11:09 CEST 2011:DEBUG:>> "</soapenv:Envelope>"
Wed Sep 21 18:11:09 CEST 2011:DEBUG:>> "[\r][\n]"
Wed Sep 21 18:11:09 CEST 2011:DEBUG:>> "------
=_Part_112_439828433.1316621469049"
Wed Sep 21 18:11:09 CEST 2011:DEBUG:>> "[\r][\n]"
Wed Sep 21 18:11:09 CEST 2011:DEBUG:>> "Content-Type: text/plain;
charset=us-ascii"
Wed Sep 21 18:11:09 CEST 2011:DEBUG:>> "[\r][\n]"
Wed Sep 21 18:11:09 CEST 2011:DEBUG:>> "Content-Transfer-Encoding:
7bit"
Wed Sep 21 18:11:09 CEST 2011:DEBUG:>> "[\r][\n]"
Wed Sep 21 18:11:09 CEST 2011:DEBUG:>> "Content-ID:
<Textdocument.txt>"
Wed Sep 21 18:11:09 CEST 2011:DEBUG:>> "[\r][\n]"
Wed Sep 21 18:11:09 CEST 2011:DEBUG:>> "Content-Disposition:
attachment; name="Textdocument.txt""
Wed Sep 21 18:11:09 CEST 2011:DEBUG:>> "[\r][\n]"
Wed Sep 21 18:11:09 CEST 2011:DEBUG:>> "[\r][\n]"
Wed Sep 21 18:11:09 CEST 2011:DEBUG:>> "This is a sample text."
Wed Sep 21 18:11:09 CEST 2011:DEBUG:>> "[\r][\n]"
Wed Sep 21 18:11:09 CEST 2011:DEBUG:>> "------
=_Part_112_439828433.1316621469049--"
Wed Sep 21 18:11:09 CEST 2011:DEBUG:>> "[\r][\n]"
>Are you sure that this case is covered by the XDSMissingDocument code?
the way I read the spec:
"XDSDocumentEntry exists in metadata with no corresponding attached
document"
(ITI TF-3, Rev. 8, Tab. 4.1-11 – Error Codes)
By the way, the related error condition "XDSMissingDocumentMetadata:
MIMEpackage contains MIMEpart withContent-Id header not found in
metadata" does not behave to my expectation yet as well. Having
"redundant" attachments unreferenced in the message passes
undiscovered, but IHE wishes "special treatment".
The HTTP log looks like this, then:
Wed Sep 21 18:19:11 CEST 2011:DEBUG:>> "POST /test/ws/iti41Service
HTTP/1.1[\r][\n]"
Wed Sep 21 18:19:11 CEST 2011:DEBUG:>> "Accept-Encoding:
gzip,deflate[\r][\n]"
Wed Sep 21 18:19:11 CEST 2011:DEBUG:>> "Content-Type: multipart/
related; type="application/xop+xml"; start="<root...@soapui.org>";
start-info="application/soap+xml"; action="urn:ihe:iti:
2007:ProvideAndRegisterDocumentSet-b"; boundary="----
=_Part_115_1222679932.1316621951869"[\r][\n]"
Wed Sep 21 18:19:11 CEST 2011:DEBUG:>> "MIME-Version: 1.0[\r][\n]"
Wed Sep 21 18:19:11 CEST 2011:DEBUG:>> "User-Agent: Jakarta Commons-
HttpClient/3.1[\r][\n]"
Wed Sep 21 18:19:11 CEST 2011:DEBUG:>> "Host: localhost:8081[\r][\n]"
Wed Sep 21 18:19:11 CEST 2011:DEBUG:>> "Content-Length: 29212[\r][\n]"
Wed Sep 21 18:19:11 CEST 2011:DEBUG:>> "[\r][\n]"
Wed Sep 21 18:19:11 CEST 2011:DEBUG:>> "[\r][\n]"
Wed Sep 21 18:19:11 CEST 2011:DEBUG:>> "------
=_Part_115_1222679932.1316621951869"
Wed Sep 21 18:19:11 CEST 2011:DEBUG:>> "[\r][\n]"
Wed Sep 21 18:19:11 CEST 2011:DEBUG:>> "Content-Type: application/xop
+xml; charset=UTF-8; type="application/soap+xml; action=
\"DocumentRepository_ProvideAndRegisterDocumentSet-b\"""
Wed Sep 21 18:19:11 CEST 2011:DEBUG:>> "[\r][\n]"
Wed Sep 21 18:19:11 CEST 2011:DEBUG:>> "Content-Transfer-Encoding:
8bit"
Wed Sep 21 18:19:11 CEST 2011:DEBUG:>> "[\r][\n]"
Wed Sep 21 18:19:11 CEST 2011:DEBUG:>> "Content-ID:
<root...@soapui.org>"
Wed Sep 21 18:19:11 CEST 2011:DEBUG:>> "[\r][\n]"
Wed Sep 21 18:19:11 CEST 2011:DEBUG:>> "[\r][\n]"
Wed Sep 21 18:19:11 CEST 2011:DEBUG:>> "<soapenv:Envelope
xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope">[\n]"
Wed Sep 21 18:19:11 CEST 2011:DEBUG:>> " <soapenv:Header
xmlns:wsa="http://www.w3.org/2005/08/addressing">[\n]"
Wed Sep 21 18:19:11 CEST 2011:DEBUG:>> " [\n]"
Wed Sep 21 18:19:11 CEST 2011:DEBUG:>> " [\n]"
Wed Sep 21 18:19:11 CEST 2011:DEBUG:>> " [\n]"
Wed Sep 21 18:19:11 CEST 2011:DEBUG:>> " <wsa:Action
soapenv:mustUnderstand="1">urn:ihe:iti:
2007:ProvideAndRegisterDocumentSet-b</wsa:Action><wsa:MessageID
soapenv:mustUnderstand="1">uuid:2ca39f30-6290-42e5-a4f1-e286fcf49557</
wsa:MessageID><wsa:To soapenv:mustUnderstand="1">http://localhost:8081/
test/ws/iti41Service</wsa:To></soapenv:Header>[\n]"
Wed Sep 21 18:19:11 CEST 2011:DEBUG:>> " <soapenv:Body>[\n]"
Wed Sep 21 18:19:11 CEST 2011:DEBUG:>> "
<xdsb:ProvideAndRegisterDocumentSetRequest xmlns:xdsb="urn:ihe:iti:xds-
b:2007">[\n]"
Wed Sep 21 18:19:11 CEST 2011:DEBUG:>> "
<lcm:SubmitObjectsRequest xmlns:lcm="urn:oasis:names:tc:ebxml-
regrep:xsd:lcm:3.0">[\n]"
...
Wed Sep 21 18:19:11 CEST 2011:DEBUG:>> " </
lcm:SubmitObjectsRequest>[\n]"
Wed Sep 21 18:19:11 CEST 2011:DEBUG:>> " <xdsb:Document
id="Document01"><inc:Include href="cid:Textdocument.txt"
xmlns:inc="http://www.w3.org/2004/08/xop/include"/></
xdsb:Document>[\n]"
Wed Sep 21 18:19:11 CEST 2011:DEBUG:>> " </
xdsb:ProvideAndRegisterDocumentSetRequest>[\n]"
Wed Sep 21 18:19:11 CEST 2011:DEBUG:>> " </soapenv:Body>[\n]"
Wed Sep 21 18:19:11 CEST 2011:DEBUG:>> "</soapenv:Envelope>"
Wed Sep 21 18:19:11 CEST 2011:DEBUG:>> "[\r][\n]"
Wed Sep 21 18:19:11 CEST 2011:DEBUG:>> "------
=_Part_115_1222679932.1316621951869"
Wed Sep 21 18:19:11 CEST 2011:DEBUG:>> "[\r][\n]"
Wed Sep 21 18:19:11 CEST 2011:DEBUG:>> "Content-Type: text/plain;
charset=us-ascii"
Wed Sep 21 18:19:11 CEST 2011:DEBUG:>> "[\r][\n]"
Wed Sep 21 18:19:11 CEST 2011:DEBUG:>> "Content-Transfer-Encoding:
7bit"
Wed Sep 21 18:19:11 CEST 2011:DEBUG:>> "[\r][\n]"
Wed Sep 21 18:19:11 CEST 2011:DEBUG:>> "Content-ID:
<Textdocument.txt>"
Wed Sep 21 18:19:11 CEST 2011:DEBUG:>> "[\r][\n]"
Wed Sep 21 18:19:11 CEST 2011:DEBUG:>> "Content-Disposition:
attachment; name="Textdocument.txt""
Wed Sep 21 18:19:11 CEST 2011:DEBUG:>> "[\r][\n]"
Wed Sep 21 18:19:11 CEST 2011:DEBUG:>> "[\r][\n]"
Wed Sep 21 18:19:11 CEST 2011:DEBUG:>> "This is a sample text."
Wed Sep 21 18:19:11 CEST 2011:DEBUG:>> "[\r][\n]"
Wed Sep 21 18:19:11 CEST 2011:DEBUG:>> "------
=_Part_115_1222679932.1316621951869"
Wed Sep 21 18:19:11 CEST 2011:DEBUG:>> "[\r][\n]"
Wed Sep 21 18:19:11 CEST 2011:DEBUG:>> "Content-Type: application/pdf"
Wed Sep 21 18:19:11 CEST 2011:DEBUG:>> "[\r][\n]"
Wed Sep 21 18:19:11 CEST 2011:DEBUG:>> "Content-Transfer-Encoding:
binary"
Wed Sep 21 18:19:11 CEST 2011:DEBUG:>> "[\r][\n]"
Wed Sep 21 18:19:11 CEST 2011:DEBUG:>> "Content-ID: <Pdfdocument.pdf>"
Wed Sep 21 18:19:11 CEST 2011:DEBUG:>> "[\r][\n]"
Wed Sep 21 18:19:11 CEST 2011:DEBUG:>> "Content-Disposition:
attachment; name="Pdfdocument.pdf""
Wed Sep 21 18:19:11 CEST 2011:DEBUG:>> "[\r][\n]"
Wed Sep 21 18:19:11 CEST 2011:DEBUG:>> "[\r][\n]"
Wed Sep 21 18:19:11 CEST 2011:DEBUG:>> "%PDF-1.3[\n]"
Wed Sep 21 18:19:11 CEST 2011:DEBUG:>> "%...
Wed Sep 21 18:19:11 CEST 2011:DEBUG:>> "13748[\n]"
Wed Sep 21 18:19:11 CEST 2011:DEBUG:>> "%%EOF[\n]"
Wed Sep 21 18:19:11 CEST 2011:DEBUG:>> "[\r][\n]"
Wed Sep 21 18:19:11 CEST 2011:DEBUG:>> "------
=_Part_115_1222679932.1316621951869--"
Wed Sep 21 18:19:11 CEST 2011:DEBUG:>> "[\r][\n]"
>CXF... hacking this behaviour seems for me to be a pretty dangerous juggling
Oh, not dangerous at all: All that happens is that the behavior
persists - no matter what I change :-)
I guess, my chances of getting it right without deep understanding
InterceptorChain and "Fault Observer" in CXF are like shooting at the
moon...
So I have to think of plan B...
1) Verify the validity of the "XDSMissingDocument" test case with IHE.
Maybe this is not what they meant with after all...
2) Use a patched CXF.
3) Revert my project to ipf-2.3-m1 or at least to cxf-2.3 :-)
Thanks and Best Regards
Marek
On 21 Sep., 15:48, Dmytro Rud <dmytro....@googlemail.com> wrote:
> BTW, Marek, what is your exact situation? Do you have a
> {urn:ihe:iti:xds-b:2007}Document element with broken reference? Are
> you sure that this case is covered by the XDSMissingDocument code?
>
> Regards
> Dmytro
>
>
>
>
> > Hi Marek,
>
> > I am happy to hear that you are using IPF and its newest features in
> > particular :-)
>
> > Regarding your question: The error message "no attachment with id..."
> > is generated in the method
> > org.apache.cxf.attachment.LazyDataSource#load(), which is called
> > during the execution of
> > org.apache.cxf.interceptor.AttachmentInInterceptor and whose code has
> > been changed on June 1st, 2011 as shown in
> >http://svn.apache.org/viewvc/cxf/trunk/rt/core/src/main/java/org/apac....
>
>
> > Hi Marek,
>
> > I am happy to hear that you are using IPF and its newest features in
> > particular :-)
>
> > Regarding your question: The error message "no attachment with id..."
> > is generated in the method
> > org.apache.cxf.attachment.LazyDataSource#load(), which is called
> > during the execution of
> > org.apache.cxf.interceptor.AttachmentInInterceptor and whose code has
> > been changed on June 1st, 2011 as shown in
>
> > In my opinion, CXF behaves correctly. Incompatibility of this correct
> > behaviour with IHE requirements may be considered problematic, but I
> > don't know whose problem it is. Further investigation is necessary.
>
> > As a workaround, you can revert the mentioned path locally and build
> > an own CXF version for your project.
>
> > BTW, the Rejection Handling mechanism introduced in IPF 2.3-m2 is
> > generally not intended for changing of message context and/or message
> > flow. The problem is also, that the failed message is dispatched in a
> > special way (i.e. throught a special interceptor chain), and hacking
> > this behaviour seems for me to be a pretty dangerous juggling.
>
> > Kind Regards,
> > Dmytro
>
> > 2011/9/21 Marek0 <Marek.Vacla...@freenet.de>:
> > In my opinion, CXF behaves correctly. Incompatibility of this correct
> > behaviour with IHE requirements may be considered problematic, but I
> > don't know whose problem it is. Further investigation is necessary.
>
> > As a workaround, you can revert the mentioned path locally and build
> > an own CXF version for your project.
>
> > BTW, the Rejection Handling mechanism introduced in IPF 2.3-m2 is
> > generally not intended for changing of message context and/or message
> > flow. The problem is also, that the failed message is dispatched in a
> > special way (i.e. throught a special interceptor chain), and hacking
> > this behaviour seems for me to be a pretty dangerous juggling.
>
> > Kind Regards,
> > Dmytro
>
> >> 67)
> >> at
> >> org.apache.cxf.binding.soap.interceptor.Soap12FaultOutInterceptor
> >> $Soap12FaultOutInterceptorInternal.handleMessage(Soap12FaultOutInterceptor.java:
> >> 56)
> >> at
> >> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:
> >> 263)
> >> at
> >> org.apache.cxf.interceptor.AbstractFaultChainInitiatorObserver.onMessage(AbstractFaultChainInitiatorObserver.java:
> >> 105)
> >> at
> >> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:
> >> 323)
> >> at
> >> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:
> >> 121)
> >> at
> >> org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:
> >> 206)
> >> at
> >> org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:
> >> 218)
> >> at
> >> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:
> >> 200)
> >> at
> >> org.apache.cxf.transport.servlet.CXFNonSpringServlet.invoke(CXFNonSpringServlet.java:
> >> 114)
> >> at
> >> org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:
> >> 184)
> >> at
> >> org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:
> >> 107)
> >> at javax.servlet.http.HttpServlet.service(HttpServlet.java:
> >> 595)
> >> at
> >> org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:
> >> at javax.servlet.http.HttpServlet.service(HttpServlet.java:
> >> 595)
> >> at
> >> 163)
> >> at
> >> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:
> >> 304)
> >> at
> >> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:
> >> 210)
> >> at
> >> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:
> >> 240)
> >> at
> >> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:
> >> 164)
> >> at
> >> org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:
> >> 462)
> >> at
> >> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:
> >> 164)
> >> at
> >> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:
> >> 100)
> >> at
> >> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:
> >> at
> >> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:
> >> 164)
> >> at
> >> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:
> >> 100)
> >> at
> >> 118)
> >> at
> >> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:
> >> 395)
> >> at
> >> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:
> >> 250)
> >> at org.apache.coyote.http11.Http11Protocol
> >> $Http11ConnectionHandler.process(Http11Protocol.java:188)
> >> at org.apache.coyote.http11.Http11Protocol
> >> $Http11ConnectionHandler.process(Http11Protocol.java:166)
> >> at org.apache.tomcat.util.net.JIoEndpoint
> >> $SocketProcessor.run(JIoEndpoint.java:302)
> >> at java.util.concurrent.ThreadPoolExecutor
> >> $Worker.runTask(Unknown Source)
> >> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown
> >> Source)
> >> at java.lang.Thread.run(Unknown Source)- Zitierten Text ausblenden -
> >> at
> >> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:
> >> 395)
> >> at
> >> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:
> >> 250)
> >> at org.apache.coyote.http11.Http11Protocol
> >> $Http11ConnectionHandler.process(Http11Protocol.java:188)
> >> at org.apache.coyote.http11.Http11Protocol
> >> $Http11ConnectionHandler.process(Http11Protocol.java:166)
> >> at org.apache.tomcat.util.net.JIoEndpoint
> >> $SocketProcessor.run(JIoEndpoint.java:302)
> >> at java.util.concurrent.ThreadPoolExecutor
> >> $Worker.runTask(Unknown Source)
> >> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown
> >> Source)
>
> - Zitierten Text anzeigen -
Dmytro Rud
Sep 22, 2011, 4:29:20 AM9/22/11
to ipf-...@googlegroups.com
Hi Marek,
2011/9/21 Marek0 <Marek.V...@freenet.de>:
>>Do you have a {urn:ihe:iti:xds-b:2007}Document element with broken reference?
> I took a valid and working ITI-41 request in soapUI having two
> documents - and just removed one of the attachments in the
> "Attachments" view.
> This leads to this in the HTTP log:
Ok, so you have an ITI-41 request containing a Document Entry which
references a Document with id="Document02" which references a
non-existent MIME attachment with id="cid:Pdfdocument.pdf".
In this case, the error actually occurs on a lower level of the
protocol stack than the one where IHE operates --- XOP vs.
transaction-specific message semantics. And therefore I'm still of
the opinion that CXF behaves correctly --- as it would when, for
example, the MIME structure of the request was broken or the SOAP part
was not well-formed.
Generally spoken, I consider it to be a specification design flaw to
prescribe on a level N+m, how to handle events which occur on the
level N. When the SOAP part is not well-formed, when a required HTTP
header is missing, when the TCP/IP handshake fails, when the Ethernet
cable is torn and there is no power in the wall outlet --- are these
really the cases one has to react with an ebXML message to?
> By the way, the related error condition "XDSMissingDocumentMetadata:
> MIMEpackage contains MIMEpart withContent-Id header not found in
> metadata" does not behave to my expectation yet as well. Having
> "redundant" attachments unreferenced in the message passes
> undiscovered, but IHE wishes "special treatment".
This is a wrong requirement as well. Just imagine that a system wants
to transfer some security certificate as an additional attachment
along with the ITI-41 request. I understand the wish of IHE to assure
message correctness (logical consistency, in particular), but the way
they do it seems not to be the best sometimes.
They ignore also the fact that the link between an XDSDocumentEntry
element and the corresponding MIME attachment is not direct, but is
based on an intermediary Document element. The check for missing and
orphan MIME attachments can be efficiently performed by CXF (and it
is, at least partially), but the correspondence between
XDSDocumentEntry and Document elements is a transaction-level one ---
and am I permitted to ask where in the IHE specification is it
prescribed to check its consistency? Overstandardization and
understandardization in the same document, wow.
Kind Regards,
Dmytro
Marek0
Sep 24, 2011, 3:38:00 PM9/24/11
to ipf-user
Hello Dmytro,
thanks for taking your time to assess the root cause. You must know
that I am painfully aware of the problems arising from "low level"
requirements in "high level" (IHE ITI) specifications.
Nevertheless, if the IHE ITI profile contains such requirements, as a
profile implementor I see merely two sustainable options:
a) fulfill the requirements
b) use the IHE process to let the requirements be officialy removed.
The latter may be difficult with a final specification, unless an
unambigous crude violation of refrenced standards comes out.
Regarding the design discussion. From what I know, it is possible to
audit failed TLS-handshakes with IPF (ATNA event "Node authentication
failed."). It is possible to return a well-formed HL7-2.x response to
a non-parsable HL7-2.x-request with IPF. Those are also cases of
tracking/handling low level errors with high level means. The XDS.b
"attachment consistence" stuff sounds similar, except that CXF
internals seem to be involved.
Of course, error handling is not critical for the overall
functionality. If this is an issue at all, it surely is a minor one.
Anyway, I would like to avoid the trouble of seeing a pre-connectathon
or connectathon test fail. I will try to investigate in XDSToolkit,
whether the two specific error codes "XDSMissingDocument",
"XDSMissingDocumentMetadata" are covered and if so, what the negative
test messages look like there... Or has anybody already done that
before?
Kind Regards
Marek
On 22 Sep., 10:29, Dmytro Rud <dmytro....@googlemail.com> wrote:
> Hi Marek,
>
> 2011/9/21 Marek0 <Marek.Vacla...@freenet.de>:
thanks for taking your time to assess the root cause. You must know
that I am painfully aware of the problems arising from "low level"
requirements in "high level" (IHE ITI) specifications.
Nevertheless, if the IHE ITI profile contains such requirements, as a
profile implementor I see merely two sustainable options:
a) fulfill the requirements
b) use the IHE process to let the requirements be officialy removed.
The latter may be difficult with a final specification, unless an
unambigous crude violation of refrenced standards comes out.
Regarding the design discussion. From what I know, it is possible to
audit failed TLS-handshakes with IPF (ATNA event "Node authentication
failed."). It is possible to return a well-formed HL7-2.x response to
a non-parsable HL7-2.x-request with IPF. Those are also cases of
tracking/handling low level errors with high level means. The XDS.b
"attachment consistence" stuff sounds similar, except that CXF
internals seem to be involved.
Of course, error handling is not critical for the overall
functionality. If this is an issue at all, it surely is a minor one.
Anyway, I would like to avoid the trouble of seeing a pre-connectathon
or connectathon test fail. I will try to investigate in XDSToolkit,
whether the two specific error codes "XDSMissingDocument",
"XDSMissingDocumentMetadata" are covered and if so, what the negative
test messages look like there... Or has anybody already done that
before?
Kind Regards
Marek
On 22 Sep., 10:29, Dmytro Rud <dmytro....@googlemail.com> wrote:
> Hi Marek,
>
> 2011/9/21 Marek0 <Marek.Vacla...@freenet.de>:
Dmytro Rud
Sep 26, 2011, 4:00:53 AM9/26/11
to ipf-...@googlegroups.com
Hi Marek,
[...]
> Regarding the design discussion. From what I know, it is possible to
> audit failed TLS-handshakes with IPF (ATNA event "Node authentication
> failed.").
Currently in MLLP-based transactions only. For WS-based ones, an
instrumentation of the corresponding container (e. g. Tomcat) is
necessary, because IPF components rely on the container's SSL support.
> It is possible to return a well-formed HL7-2.x response to
> a non-parsable HL7-2.x-request with IPF.
But this response is not specific to the particular transaction, it is
a simple ACK. In the same way, it is possible to return a well-formed
SOAP Fault response to a non-parsable SOAP request --- CXF does it for
us. So there is actually no contradiction ;-)
[...]
> I will try to investigate in XDSToolkit,
> whether the two specific error codes "XDSMissingDocument",
> "XDSMissingDocumentMetadata" are covered and if so, what the negative
> test messages look like there...
I appreciate your work and hope that you will share results of your
investigation with the IPF community :-)
IPF'ly yours,
Dmytro
Marek0
Oct 10, 2011, 10:40:44 AM10/10/11
to ipf-user
> > I will try to investigate in XDSToolkit, whether the two specific error codes "XDSMissingDocument",
> > "XDSMissingDocumentMetadata" are covered and if so, what the negative test messages look like there...
> I appreciate your work and hope that you will share results of your investigation with the IPF community :-)
I have found only one test within the XDS Toolkit covering the use of
> > "XDSMissingDocumentMetadata" are covered and if so, what the negative test messages look like there...
> I appreciate your work and hope that you will share results of your investigation with the IPF community :-)
error codes "XDSDocumentMissing" and "XDSDocumentMetadataMissing":
The test #11983 (http://ihewiki.wustl.edu/wiki/index.php/
XDS_Test_Kit_Test_Descriptions#11983) has two steps: "doc_missing" and
"doc_metadata_missing". Both test steps validate consistency _only_
within the SOAP body and do _not_ evaluate the MIME multipart
attachments. An extract from the log files (SOAP level) below.
"doc_missing" is apparently covered by IPF validation, producing
codeDetail="A document was provided without a corresponding document
entry. UUID=...".
"doc_metadata_missing" can be detected and wrapped up as registry
response in the IPF route
So the changed behavior of cxf apparently does no effect the result of
XDS Toolkit tests.
Hence, there is no need to change anything in IPF. :-)
Best Regards
Marek
----------------------------------------------
doc_metadata_missing:
=================
There is an <xdsb:Document> element with id="Document01" (after the
<lcm:SubmitObjectsRequest> element), but this id is not referenced
anywhere else in the request.
<?xml version='1.0' encoding='UTF-8'?>
<soapenv:Envelope xmlns:soapenv="http://www.w3.org/2003/05/soap-
envelope" xmlns:wsa="http://www.w3.org/2005/08/addressing">
<soapenv:Header>
<wsa:To>http://localhost:58081/test/ws/iti41Service</wsa:To>
<wsa:MessageID>urn:uuid:954CB36BF71D6A1E821318245356209</
wsa:MessageID>
<wsa:Action>urn:ihe:iti:2007:ProvideAndRegisterDocumentSet-b</
wsa:Action>
</soapenv:Header>
<soapenv:Body>
<xdsb:ProvideAndRegisterDocumentSetRequest
xmlns:xdsb="urn:ihe:iti:xds-b:2007">
<lcm:SubmitObjectsRequest xmlns:lcm="urn:oasis:names:tc:ebxml-
regrep:xsd:lcm:3.0">
<rim:RegistryObjectList xmlns:rim="urn:oasis:names:tc:ebxml-
regrep:xsd:lcm:3.0">
regrep:xsd:rim:3.0">
<rim:RegistryPackage id="urn:uuid:8307c9f4-21c2-418c-b4fb-
d04efa6fb876" objectType="urn:oasis:names:tc:ebxml-
regrep:ObjectType:RegistryObject:RegistryPackage">
...
</rim:RegistryPackage>
<rim:Classification classifiedObject="urn:uuid:
8307c9f4-21c2-418c-b4fb-d04efa6fb876"
classificationNode="urn:uuid:a54d6aa5-d40d-43f9-88c5-b4633d873bdd"
id="urn:uuid:d520541f-402a-40c9-a9e9-e4cdf7d12717"
objectType="urn:oasis:names:tc:ebxml-
regrep:ObjectType:RegistryObject:Classification"/>
</rim:RegistryObjectList>
</lcm:SubmitObjectsRequest>
<xdsb:Document id="Document01">
<xop:Include href="cid:1.urn:uuid:
954CB36BF71D6A1...@apache.org" xmlns:xop="http://
www.w3.org/2004/08/xop/include" />
</xdsb:Document>
</xdsb:ProvideAndRegisterDocumentSetRequest>
</soapenv:Body>
</soapenv:Envelope>
----------------------------------------------
doc_missing:
=================
Document entryUuid “urn:uuid:36f6a1ce-e4a2-49a2-9d4b-f97e05ece1b7” is
referenced correctly throughout the message, but there is no
<xdsb:Document> element after <lcm:SubmitObjectsRequest>.
<?xml version='1.0' encoding='UTF-8'?>
<soapenv:Envelope xmlns:soapenv="http://www.w3.org/2003/05/soap-
envelope" xmlns:wsa="http://www.w3.org/2005/08/addressing">
<soapenv:Header>
<wsa:To>http://localhost:58081/test/ws/iti41Service</wsa:To>
<wsa:MessageID>urn:uuid:954CB36BF71D6A1E821318245362217</
wsa:MessageID>
<wsa:Action>urn:ihe:iti:2007:ProvideAndRegisterDocumentSet-b</
wsa:Action>
</soapenv:Header>
<soapenv:Body>
<xdsb:ProvideAndRegisterDocumentSetRequest
xmlns:xdsb="urn:ihe:iti:xds-b:2007">
<lcm:SubmitObjectsRequest xmlns:lcm="urn:oasis:names:tc:ebxml-
regrep:xsd:lcm:3.0">
<rim:RegistryObjectList xmlns:rim="urn:oasis:names:tc:ebxml-
regrep:xsd:lcm:3.0">
regrep:xsd:rim:3.0">
<rim:ExtrinsicObject id="urn:uuid:36f6a1ce-e4a2-49a2-9d4b-
f97e05ece1b7" mimeType="text/xds" objectType="urn:uuid:
7edca82f-054d-47f2-a032-9b2a5b5186c1">
...
</rim:ExtrinsicObject>
<rim:RegistryPackage id="urn:uuid:29a5e8ab-7db8-446a-868b-
a88d1c790361" objectType="urn:oasis:names:tc:ebxml-
regrep:ObjectType:RegistryObject:RegistryPackage">
...
</rim:RegistryPackage>
<rim:Classification classifiedObject="urn:uuid:
29a5e8ab-7db8-446a-868b-a88d1c790361"
classificationNode="urn:uuid:a54d6aa5-d40d-43f9-88c5-b4633d873bdd"
id="urn:uuid:12bd3056-36ed-4e13-ab92-c083aa4d19d0"
objectType="urn:oasis:names:tc:ebxml-
regrep:ObjectType:RegistryObject:Classification"/>
<rim:Association associationType="urn:oasis:names:tc:ebxml-
regrep:AssociationType:HasMember" sourceObject="urn:uuid:
29a5e8ab-7db8-446a-868b-a88d1c790361" targetObject="urn:uuid:36f6a1ce-
e4a2-49a2-9d4b-f97e05ece1b7" id="urn:uuid:593fda80-2655-4d4a-b2ff-
d62d55fa11f1" objectType="urn:oasis:names:tc:ebxml-
regrep:ObjectType:RegistryObject:Association">
<rim:Slot name="SubmissionSetStatus">
<rim:ValueList>
<rim:Value>Original</rim:Value>
</rim:ValueList>
</rim:Slot>
</rim:Association>
</rim:RegistryObjectList>
</lcm:SubmitObjectsRequest>
</xdsb:ProvideAndRegisterDocumentSetRequest>
</soapenv:Body>
</soapenv:Envelope>
Dmytro Rud
Oct 10, 2011, 11:00:19 AM10/10/11
to ipf-...@googlegroups.com
Reply all
Reply to author
Forward
0 new messages