Eclipse Community Forums: OHF » bridge's document query response not matching wsdl

Home » Archived » OHF » bridge's document query response not matching wsdl

bridge's document query response not matching wsdl [message #41623]

Wed, 19 March 2008 14:55

Eclipse User

Hi,
I've found that when using the bridge and issuing a document query to the
registry, the WSDL says that each document will have both an "author" and
an "authors" element. However, there is no author element returned.

Looking into this it's because in the XDSDocType.java file there is the
following method:
public void setAuthor(PatientInfoType pAuthor) {
authors = new PatientInfoType[]{pAuthor};
}

There is no corresponding getter method because this set method is simply
a convenience method to avoid calling setAuthors instead. However, Axis
sees this setter method as indicating there should be a field called
"author" passed so it puts that in the WSDL. When Axis is marshalling the
java objects into XML though, there is no getter method so no author
element is created- leaving the mismatch between the WSDL and what's sent
over the wire.

The only place I can find that this is being called is this line in the
IheXdsBridge.java:
xdsDocument.setAuthor(authorToPatientInfoType(documentEntry. getAuthor()));

I think the convenience method should be removed and the above line
changed to:
PatientInfoType tempAuthor =
authorToPatientInfoType(documentEntry.getAuthor());
PatientInfoType tempAuthors = new PatientInfoType[]{tempAuthor};
xdsDocument.setAuthors(tempAuthors);

It could be condensed if you like, but I separated it to multiple lines
for clarity. Do you guys agree, and if so, should I submit a bug?

thanks,
Jesse

Re: bridge's document query response not matching wsdl [message #41672 is a reply to message #41623]

Thu, 20 March 2008 17:47

Eclipse User

Hi all,
I've fixed this and as well found that the confidentiality code has a
similar problem where the wsdl shows both a confidentiality code and codes
(with an 's'). These two problems are fixed with the following changes to
XDSDocType.java:
- remove the setAuthor method
- remove the setConfidentialityCode method
- remove the getConfidentialityCode method
- add a getConfidentialityCodes method
public CodedMetadataType[] getConfidentialityCodes(){
return confidentialityCodes;
}

The IheXdsBridge.java needs only the following change:
- remove this line
xdsDocument.setAuthor(authorToPatientInfoType(documentEntry. getAuthor()));
- replace it with this line
xdsDocument.setAuthors(new
PatientInfoType[]{authorToPatientInfoType(documentEntry.getA uthor())});

If you agree, please let me know and I'll create a bug for this. You guys
can check in the changes and that should take care of this bug. The
confidentiality codes and event codes are always blank I think because of
the other bug we talked about, but at least this fix makes the xml sent
over the wire match the WSDL.

thanks,
Jesse

Jesse Pangburn wrote:

> Hi,
> I've found that when using the bridge and issuing a document query to the
> registry, the WSDL says that each document will have both an "author" and
> an "authors" element. However, there is no author element returned.

> Looking into this it's because in the XDSDocType.java file there is the
> following method:
> public void setAuthor(PatientInfoType pAuthor) {
> authors = new PatientInfoType[]{pAuthor};
> }

> There is no corresponding getter method because this set method is simply
> a convenience method to avoid calling setAuthors instead. However, Axis
> sees this setter method as indicating there should be a field called
> "author" passed so it puts that in the WSDL. When Axis is marshalling the
> java objects into XML though, there is no getter method so no author
> element is created- leaving the mismatch between the WSDL and what's sent
> over the wire.

> The only place I can find that this is being called is this line in the
> IheXdsBridge.java:
> xdsDocument.setAuthor(authorToPatientInfoType(documentEntry. getAuthor()));

> I think the convenience method should be removed and the above line
> changed to:
> PatientInfoType tempAuthor =
> authorToPatientInfoType(documentEntry.getAuthor());
> PatientInfoType tempAuthors = new PatientInfoType[]{tempAuthor};
> xdsDocument.setAuthors(tempAuthors);

> It could be condensed if you like, but I separated it to multiple lines
> for clarity. Do you guys agree, and if so, should I submit a bug?

> thanks,
> Jesse

Re: bridge's document query response not matching wsdl [message #41703 is a reply to message #41672]

Thu, 20 March 2008 20:30

Eclipse User

OK, I hope this is my last post on this, sorry I didn't realize there was
going to be a number of these. On the document retrieval (which I don't
understand why a different type is used from document query as they have
the same fields) the same problem exists with document and documents. It
is fixed with the following changes:
RetrieveDocumentResponseType.java
- remove the setDocument method
AbstractXdsBridge.java
- remove the line
response.setDocument(xdsDocument);
- replace it with
response.setDocuments(new XDSDocType[]{xdsDocument});

In this case, now the return type just has an array of documents instead
of a lone document element and an array- but where the message on the wire
just has the array.

While looking at this problem, I noticed that the
RetrieveDocumentRequestType has a request field and a requests field.
This is used in the RetrieveDocumentSet operation and it appears that the
client can use either element that they want to set a single request, or
if you want to get multiple back then you use the plural version. Since
the client is generating this, matching the schema is not a problem but it
seems like it could easily be confusing to people about how they're
supposed to use these. Is there any reason not to remove the "request"
field and just leave "requests"? It's exactly the same thing to put a
list with one element in the "requests" field.

OK, I'm done for the day ;-)

thanks,
Jesse

Jesse Pangburn wrote:

> Hi all,
> I've fixed this and as well found that the confidentiality code has a
> similar problem where the wsdl shows both a confidentiality code and codes
> (with an 's'). These two problems are fixed with the following changes to
> XDSDocType.java:
> - remove the setAuthor method
> - remove the setConfidentialityCode method
> - remove the getConfidentialityCode method
> - add a getConfidentialityCodes method
> public CodedMetadataType[] getConfidentialityCodes(){
> return confidentialityCodes;
> }

> The IheXdsBridge.java needs only the following change:
> - remove this line
> xdsDocument.setAuthor(authorToPatientInfoType(documentEntry. getAuthor()));
> - replace it with this line
> xdsDocument.setAuthors(new
> PatientInfoType[]{authorToPatientInfoType(documentEntry.getA uthor())});

> If you agree, please let me know and I'll create a bug for this. You guys
> can check in the changes and that should take care of this bug. The
> confidentiality codes and event codes are always blank I think because of
> the other bug we talked about, but at least this fix makes the xml sent
> over the wire match the WSDL.

> thanks,
> Jesse

> Jesse Pangburn wrote:

>> Hi,
>> I've found that when using the bridge and issuing a document query to the
>> registry, the WSDL says that each document will have both an "author" and
>> an "authors" element. However, there is no author element returned.

>> Looking into this it's because in the XDSDocType.java file there is the
>> following method:
>> public void setAuthor(PatientInfoType pAuthor) {
>> authors = new PatientInfoType[]{pAuthor};
>> }

>> There is no corresponding getter method because this set method is simply
>> a convenience method to avoid calling setAuthors instead. However, Axis
>> sees this setter method as indicating there should be a field called
>> "author" passed so it puts that in the WSDL. When Axis is marshalling the
>> java objects into XML though, there is no getter method so no author
>> element is created- leaving the mismatch between the WSDL and what's sent
>> over the wire.

>> The only place I can find that this is being called is this line in the
>> IheXdsBridge.java:
>> xdsDocument.setAuthor(authorToPatientInfoType(documentEntry. getAuthor()));

>> I think the convenience method should be removed and the above line
>> changed to:
>> PatientInfoType tempAuthor =
>> authorToPatientInfoType(documentEntry.getAuthor());
>> PatientInfoType tempAuthors = new PatientInfoType[]{tempAuthor};
>> xdsDocument.setAuthors(tempAuthors);

>> It could be condensed if you like, but I separated it to multiple lines
>> for clarity. Do you guys agree, and if so, should I submit a bug?

>> thanks,
>> Jesse

Re: bridge's document query response not matching wsdl [message #41734 is a reply to message #41703]

Mon, 24 March 2008 16:56

Eclipse User

Hi Jesse,

Sorry for the delay, was out of the country last week.

Thanks for the work and heads up. I agree with all the changes and will
commit them soon. Please submit a bug with at least a generic
description of the changes "for the record".

Thanks again,

-Matt

Jesse Pangburn wrote:
> OK, I hope this is my last post on this, sorry I didn't realize there
> was going to be a number of these. On the document retrieval (which I
> don't understand why a different type is used from document query as
> they have the same fields) the same problem exists with document and
> documents. It is fixed with the following changes:
> RetrieveDocumentResponseType.java
> - remove the setDocument method
> AbstractXdsBridge.java
> - remove the line
> response.setDocument(xdsDocument);
> - replace it with
> response.setDocuments(new XDSDocType[]{xdsDocument});
>
> In this case, now the return type just has an array of documents instead
> of a lone document element and an array- but where the message on the
> wire just has the array.
>
> While looking at this problem, I noticed that the
> RetrieveDocumentRequestType has a request field and a requests field.
> This is used in the RetrieveDocumentSet operation and it appears that
> the client can use either element that they want to set a single
> request, or if you want to get multiple back then you use the plural
> version. Since the client is generating this, matching the schema is
> not a problem but it seems like it could easily be confusing to people
> about how they're supposed to use these. Is there any reason not to
> remove the "request" field and just leave "requests"? It's exactly the
> same thing to put a list with one element in the "requests" field.
>
> OK, I'm done for the day ;-)
>
> thanks,
> Jesse
>
> Jesse Pangburn wrote:
>
>> Hi all,
>> I've fixed this and as well found that the confidentiality code has a
>> similar problem where the wsdl shows both a confidentiality code and
>> codes (with an 's'). These two problems are fixed with the following
>> changes to XDSDocType.java:
>> - remove the setAuthor method
>> - remove the setConfidentialityCode method
>> - remove the getConfidentialityCode method
>> - add a getConfidentialityCodes method
>> public CodedMetadataType[] getConfidentialityCodes(){
>> return confidentialityCodes;
>> }
>
>> The IheXdsBridge.java needs only the following change:
>> - remove this line
>> xdsDocument.setAuthor(authorToPatientInfoType(documentEntry. getAuthor()));
>>
>> - replace it with this line
>> xdsDocument.setAuthors(new
>> PatientInfoType[]{authorToPatientInfoType(documentEntry.getA uthor())});
>
>> If you agree, please let me know and I'll create a bug for this. You
>> guys can check in the changes and that should take care of this bug.
>> The confidentiality codes and event codes are always blank I think
>> because of the other bug we talked about, but at least this fix makes
>> the xml sent over the wire match the WSDL.
>
>> thanks,
>> Jesse
>
>> Jesse Pangburn wrote:
>
>>> Hi,
>>> I've found that when using the bridge and issuing a document query to
>>> the registry, the WSDL says that each document will have both an
>>> "author" and an "authors" element. However, there is no author
>>> element returned.
>
>>> Looking into this it's because in the XDSDocType.java file there is
>>> the following method:
>>> public void setAuthor(PatientInfoType pAuthor) {
>>> authors = new PatientInfoType[]{pAuthor};
>>> }
>
>>> There is no corresponding getter method because this set method is
>>> simply a convenience method to avoid calling setAuthors instead.
>>> However, Axis sees this setter method as indicating there should be a
>>> field called "author" passed so it puts that in the WSDL. When Axis
>>> is marshalling the java objects into XML though, there is no getter
>>> method so no author element is created- leaving the mismatch between
>>> the WSDL and what's sent over the wire.
>
>>> The only place I can find that this is being called is this line in
>>> the IheXdsBridge.java:
>>> xdsDocument.setAuthor(authorToPatientInfoType(documentEntry. getAuthor()));
>>>
>
>>> I think the convenience method should be removed and the above line
>>> changed to:
>>> PatientInfoType tempAuthor =
>>> authorToPatientInfoType(documentEntry.getAuthor());
>>> PatientInfoType tempAuthors = new PatientInfoType[]{tempAuthor};
>>> xdsDocument.setAuthors(tempAuthors);
>
>>> It could be condensed if you like, but I separated it to multiple
>>> lines for clarity. Do you guys agree, and if so, should I submit a bug?
>
>>> thanks,
>>> Jesse
>
>

Re: bridge's document query response not matching wsdl [message #41797 is a reply to message #41734]

Mon, 24 March 2008 17:23

Eclipse User

Hi Matt,
No problem, hopefully you had a fun trip! I submitted a bug with a
condensed version of the problems and the solutions that I used. You can
find it here:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=223731

Of course I'm glad to help and be able to give a little back :-)

thanks,
Jesse

Matthew Davis wrote:

> Hi Jesse,

> Sorry for the delay, was out of the country last week.

> Thanks for the work and heads up. I agree with all the changes and will
> commit them soon. Please submit a bug with at least a generic
> description of the changes "for the record".

> Thanks again,

> -Matt

> Jesse Pangburn wrote:
>> OK, I hope this is my last post on this, sorry I didn't realize there
>> was going to be a number of these. On the document retrieval (which I
>> don't understand why a different type is used from document query as
>> they have the same fields) the same problem exists with document and
>> documents. It is fixed with the following changes:
>> RetrieveDocumentResponseType.java
>> - remove the setDocument method
>> AbstractXdsBridge.java
>> - remove the line
>> response.setDocument(xdsDocument);
>> - replace it with
>> response.setDocuments(new XDSDocType[]{xdsDocument});
>>
>> In this case, now the return type just has an array of documents instead
>> of a lone document element and an array- but where the message on the
>> wire just has the array.
>>
>> While looking at this problem, I noticed that the
>> RetrieveDocumentRequestType has a request field and a requests field.
>> This is used in the RetrieveDocumentSet operation and it appears that
>> the client can use either element that they want to set a single
>> request, or if you want to get multiple back then you use the plural
>> version. Since the client is generating this, matching the schema is
>> not a problem but it seems like it could easily be confusing to people
>> about how they're supposed to use these. Is there any reason not to
>> remove the "request" field and just leave "requests"? It's exactly the
>> same thing to put a list with one element in the "requests" field.
>>
>> OK, I'm done for the day ;-)
>>
>> thanks,
>> Jesse
>>
>> Jesse Pangburn wrote:
>>
>>> Hi all,
>>> I've fixed this and as well found that the confidentiality code has a
>>> similar problem where the wsdl shows both a confidentiality code and
>>> codes (with an 's'). These two problems are fixed with the following
>>> changes to XDSDocType.java:
>>> - remove the setAuthor method
>>> - remove the setConfidentialityCode method
>>> - remove the getConfidentialityCode method
>>> - add a getConfidentialityCodes method
>>> public CodedMetadataType[] getConfidentialityCodes(){
>>> return confidentialityCodes;
>>> }
>>
>>> The IheXdsBridge.java needs only the following change:
>>> - remove this line
>>> xdsDocument.setAuthor(authorToPatientInfoType(documentEntry. getAuthor()));
>>>
>>> - replace it with this line
>>> xdsDocument.setAuthors(new
>>> PatientInfoType[]{authorToPatientInfoType(documentEntry.getA uthor())});
>>
>>> If you agree, please let me know and I'll create a bug for this. You
>>> guys can check in the changes and that should take care of this bug.
>>> The confidentiality codes and event codes are always blank I think
>>> because of the other bug we talked about, but at least this fix makes
>>> the xml sent over the wire match the WSDL.
>>
>>> thanks,
>>> Jesse
>>
>>> Jesse Pangburn wrote:
>>
>>>> Hi,
>>>> I've found that when using the bridge and issuing a document query to
>>>> the registry, the WSDL says that each document will have both an
>>>> "author" and an "authors" element. However, there is no author
>>>> element returned.
>>
>>>> Looking into this it's because in the XDSDocType.java file there is
>>>> the following method:
>>>> public void setAuthor(PatientInfoType pAuthor) {
>>>> authors = new PatientInfoType[]{pAuthor};
>>>> }
>>
>>>> There is no corresponding getter method because this set method is
>>>> simply a convenience method to avoid calling setAuthors instead.
>>>> However, Axis sees this setter method as indicating there should be a
>>>> field called "author" passed so it puts that in the WSDL. When Axis
>>>> is marshalling the java objects into XML though, there is no getter
>>>> method so no author element is created- leaving the mismatch between
>>>> the WSDL and what's sent over the wire.
>>
>>>> The only place I can find that this is being called is this line in
>>>> the IheXdsBridge.java:
>>>>
xdsDocument.setAuthor(authorToPatientInfoType(documentEntry. getAuthor()));
>>>>
>>
>>>> I think the convenience method should be removed and the above line
>>>> changed to:
>>>> PatientInfoType tempAuthor =
>>>> authorToPatientInfoType(documentEntry.getAuthor());
>>>> PatientInfoType tempAuthors = new PatientInfoType[]{tempAuthor};
>>>> xdsDocument.setAuthors(tempAuthors);
>>
>>>> It could be condensed if you like, but I separated it to multiple
>>>> lines for clarity. Do you guys agree, and if so, should I submit a bug?
>>
>>>> thanks,
>>>> Jesse
>>
>>

Re: bridge's document query response not matching wsdl [message #584993 is a reply to message #41623]

Thu, 20 March 2008 17:47

Eclipse User