
| Key: |
XW-535
|
| Type: |
Bug
|
| Status: |
Resolved
|
| Resolution: |
Fixed
|
| Priority: |
Major
|
| Assignee: |
tm_jee
|
| Reporter: |
tm_jee
|
| Votes: |
0
|
| Watchers: |
0
|
|
If you were logged in you would be able to see more operations.
|
|
|
XWork
Created: 01/Jul/07 09:37 AM
Updated: 12/Jun/08 08:58 AM
|
|
| Component/s: |
None
|
| Affects Version/s: |
1.2.2
|
| Fix Version/s: |
1.2.3,
2.1.2
|
|
external-ref tag's content cannot be read occasionally by some parser
See http://forums.opensymphony.com/thread.jspa?threadID=79530&tstart=0 for more info.
Currently in XmlHelper, the way <external-ref> content is being look up is that it doesn't take into account looking into each childNodes of the dom element, it just assumes its the first one, this is not how result and param's content are looked up (see XmlHelper#getParams(Element) and XmlConfigurationProvider#buildResults(Element, PackageConfig) respectively for more info). It should be implemented like XmlHelper#getParams(Element) does.
I think it'd be better if we refactor this logic into XmlHelper, (the logic of reading in a tag's content eg. <result>... the content...</result>, where it could be make a public static method in XmlHelper such that XmlHelper#getParams(Element) could make use of it, XmlConfigurationProvider#buildResults(Element, PackageConfig) and XmlConfigurationProvider#buildExternalRefs(Element, PackageConfig) could use it.
|
|
Description
|
external-ref tag's content cannot be read occasionally by some parser
See http://forums.opensymphony.com/thread.jspa?threadID=79530&tstart=0 for more info.
Currently in XmlHelper, the way <external-ref> content is being look up is that it doesn't take into account looking into each childNodes of the dom element, it just assumes its the first one, this is not how result and param's content are looked up (see XmlHelper#getParams(Element) and XmlConfigurationProvider#buildResults(Element, PackageConfig) respectively for more info). It should be implemented like XmlHelper#getParams(Element) does.
I think it'd be better if we refactor this logic into XmlHelper, (the logic of reading in a tag's content eg. <result>... the content...</result>, where it could be make a public static method in XmlHelper such that XmlHelper#getParams(Element) could make use of it, XmlConfigurationProvider#buildResults(Element, PackageConfig) and XmlConfigurationProvider#buildExternalRefs(Element, PackageConfig) could use it.
|
Show » |
|
the last time we fix this, we've left out <external-ref>..</external-ref>
We should refactor the logic where the content of tag eg. <external-ref>,..</external-ref> to be in XmlHelper, so it would be scatered arround like it currently is.