Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
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 18:55 Go to next message
Jesse Pangburn is currently offline Jesse PangburnFriend
Messages: 166
Registered: July 2009
Senior Member
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 21:47 Go to previous messageGo to next message
Jesse Pangburn is currently offline Jesse PangburnFriend
Messages: 166
Registered: July 2009
Senior Member
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] Fri, 21 March 2008 00:30 Go to previous messageGo to next message
Jesse Pangburn is currently offline Jesse PangburnFriend
Messages: 166
Registered: July 2009
Senior Member
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 20:56 Go to previous messageGo to next message
Matthew DavisFriend
Messages: 269
Registered: July 2009
Senior Member
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 21:23 Go to previous message
Jesse Pangburn is currently offline Jesse PangburnFriend
Messages: 166
Registered: July 2009
Senior Member
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 21:47 Go to previous message
Jesse Pangburn is currently offline Jesse PangburnFriend
Messages: 166
Registered: July 2009
Senior Member
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 #585008 is a reply to message #41672] Fri, 21 March 2008 00:30 Go to previous message
Jesse Pangburn is currently offline Jesse PangburnFriend
Messages: 166
Registered: July 2009
Senior Member
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 #585017 is a reply to message #41703] Mon, 24 March 2008 20:56 Go to previous message
Matthew DavisFriend
Messages: 269
Registered: July 2009
Senior Member
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 #585041 is a reply to message #41734] Mon, 24 March 2008 21:23 Go to previous message
Jesse Pangburn is currently offline Jesse PangburnFriend
Messages: 166
Registered: July 2009
Senior Member
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
>>
>>
Previous Topic:ATNA - Authenticate Node
Next Topic:OHF Bridge 0.3.0 problems
Goto Forum:
  


Current Time: Fri Apr 19 02:06:52 GMT 2024

Powered by FUDForum. Page generated in 0.02519 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top