castor

UnmarshalHandler now breaks location processing (1.49->1.50) in at least one case. (mine)

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Blocker Blocker
  • Resolution: Cannot Reproduce
  • Affects Version/s: 0.9.9 M1
  • Fix Version/s: 0.9.9 M2
  • Component/s: XML
  • Labels:
    None
  • Number of attachments :
    2

Description

The issue is solved by reverting to version 1.49.

An example of the XML is included; alongside the mapping. The only thing worthy of note is that the depth of the XML we're skipping is quite large, and not all of the content is mapped. I'm not sure what, in that, causes what problem - I assume it's because we're nulling the descriptor.

As you're the original person responsible for checkin, and this is the only thing that changed between 1.49 and 1.50, I hope you can explain it to me.

Reverting the behavior to only skip, and not null the descriptor, causes it to work as expected.

Attachments

  1. XML File
    istc-dm2-cards.xml
    19/Jul/05 11:22 AM
    1 kB
    Gregory Block
  2. XML File
    problem.xml
    19/Jul/05 11:22 AM
    2 kB
    Gregory Block

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Gregory Block added a comment -

Attaching example XML from the SOAP service generating the XML.

Show
Gregory Block added a comment - Attaching example XML from the SOAP service generating the XML.
Hide
Permalink
Gregory Block added a comment -

Attaching the mapping file we use to parse that XML.

Show
Gregory Block added a comment - Attaching the mapping file we use to parse that XML.
Hide
Permalink
Gregory Block added a comment -

Is there any reason to believe that this behavior may have changed since the bug was written? I guess I'll find out when it comes to test 0.9.9M1, but I'd like to see someone have a peek at the mapping file and the XML to see if...

Submitted by Heri Bender.
----------------------------
revision 1.49
date: 2005/05/21 13:51:24; author: afawcett; state: Exp; lines: +41 -14
Added code to processAttribute to handle multi-value attributes.

is at fault. Again, reverting out that change returns marshalling behavior to normal. At this moment, we are unable to use 0.9.9 in a live service until this bug gets fixed or that patch gets reverted.

Show
Gregory Block added a comment - Is there any reason to believe that this behavior may have changed since the bug was written? I guess I'll find out when it comes to test 0.9.9M1, but I'd like to see someone have a peek at the mapping file and the XML to see if... Submitted by Heri Bender. ---------------------------- revision 1.49 date: 2005/05/21 13:51:24; author: afawcett; state: Exp; lines: +41 -14 Added code to processAttribute to handle multi-value attributes. is at fault. Again, reverting out that change returns marshalling behavior to normal. At this moment, we are unable to use 0.9.9 in a live service until this bug gets fixed or that patch gets reverted.
Hide
Permalink
Gregory Block added a comment -

Marking unassigned, changing to blocker. If this really isn't going to get fixed, then I can't deploy 0.9.9, even in a testing environment. This essentially prevents us from using Castor to parse Microsoft SOAP feeds.

Show
Gregory Block added a comment - Marking unassigned, changing to blocker. If this really isn't going to get fixed, then I can't deploy 0.9.9, even in a testing environment. This essentially prevents us from using Castor to parse Microsoft SOAP feeds.
Hide
Permalink
Werner Guttmann added a comment -

As discussed with Greg a couple of minutes ago, Greg will add more 'realistic' tests to the existing CTF tests to show that the patch committed introduces problems with location hierarchies deeper than 2 elements. As it seems that it is not going to be easy to come up with an improved patch, most likely we'll back this out before releasing 0.9.9 final. As such we need to find a way to communicate to our users that the original problem mentioned in this issue is rendered non-worlking again.

Show
Werner Guttmann added a comment - As discussed with Greg a couple of minutes ago, Greg will add more 'realistic' tests to the existing CTF tests to show that the patch committed introduces problems with location hierarchies deeper than 2 elements. As it seems that it is not going to be easy to come up with an improved patch, most likely we'll back this out before releasing 0.9.9 final. As such we need to find a way to communicate to our users that the original problem mentioned in this issue is rendered non-worlking again.
Hide
Permalink
Werner Guttmann added a comment -

Just found this changelog entry: http://cvs.castor.codehaus.org/changelog/castor?cs=MAIN:afawcett:20050521154542. It looks like this a pretty isolated change, and hence could be backed out easily.

Show
Werner Guttmann added a comment - Just found this changelog entry: http://cvs.castor.codehaus.org/changelog/castor?cs=MAIN:afawcett:20050521154542. It looks like this a pretty isolated change, and hence could be backed out easily.
Hide
Permalink
Gregory Block added a comment -

Ok, I've tracked this down. The problem was:

Original:
<bind-xml name="CardTypes"
location="Body/CardTypesResponse/CardTypesResult/diffgram/NewDataSet/CardTypes"
node="element"/>

Working:
<bind-xml name="CardTypes"
location="Body/CardTypesResponse/CardTypesResult/diffgram/NewDataSet"
node="element"/>

The difference, of course, seems obvious - we're looking in the wrong place for the wrong thing. We meant to look in NewDataSet.

Now, why this used to work, and now doesn't - who knows. However, it does seem the mapping file, as written, is incorrect; updating the mapping file does appear to correct the problem, and as such, the fix should stay as-is.

Show
Gregory Block added a comment - Ok, I've tracked this down. The problem was: Original: <bind-xml name="CardTypes" location="Body/CardTypesResponse/CardTypesResult/diffgram/NewDataSet/CardTypes" node="element"/> Working: <bind-xml name="CardTypes" location="Body/CardTypesResponse/CardTypesResult/diffgram/NewDataSet" node="element"/> The difference, of course, seems obvious - we're looking in the wrong place for the wrong thing. We meant to look in NewDataSet. Now, why this used to work, and now doesn't - who knows. However, it does seem the mapping file, as written, is incorrect; updating the mapping file does appear to correct the problem, and as such, the fix should stay as-is.
Hide
Permalink
Gregory Block added a comment -

Mapping file is incorrect; please verify location="" on mapped nodes if you encounter this problem yourself. Marking unreproducable and closing.

Show
Gregory Block added a comment - Mapping file is incorrect; please verify location="" on mapped nodes if you encounter this problem yourself. Marking unreproducable and closing.

People

Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved:
Atlassian JIRA (v4.4.3#663-r165197) | Report a problem
Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.