Re: [castor-user] [XML] Problem with namespace mapping (References Earlier Thread)

[Stephen Bash]

Keith-
Thanks for the quick reply.  It's nice to know we're on the same page at 
least.  Coming from a different angle, what do you think of my second 
idea of having Castor try to match some or all of the element's XPath 
rather than just the element name?  This idea comes more from my Perl 
programming days (where I learned XML), where, depending on the XML 
package, the entire XPath has to match before a specific element is 
modified.  As I mentioned in my original e-mail, using the full path 
might cause unnecessary rigidity in the XML file layout, but perhaps 
just checking the element name and the location tag for the given field 
to provide a form of pseudo namespace would be worth it?  I'd like to 
hear any thoughts you have on the matter.  Thanks again for the help.

Stephen
Keith Visco wrote:
Hi Stephen,
What you want *SHOULD* be supported by Castor, but currently isn't due 
to some limitations of the legacy API.

The problem is that the XMLClassDescriptor interface only accepts a name 
and not a namespace, changing the interface will break backward 
compatability.

To solve the problem without breaking the interface, we could combine 
the name and namespace like "{namespace}name", though that will 
certainly add additional overhead first by creating the new string and 
second by breaking it apart once we've past it to the method.

Or we just bite the bullet and break the interface and backward 
compatibility.

Something definately needs to be done however, because this 
functionality is important and needs to be supported.

--Keith
Stephen Bash wrote:
I recently began using Castor (v0.9.5.4-xml) and I'm having some 
issues with namespaces which seem to have been discussed on the list 
before 
(http://www.mail-archive.com/castor-user@exolab.org/msg00028.html). 
Most of the messages I've found discuss the first half of the problem 
(marshalling something out and having Castor apply the correct 
namespace to each element), and the problem I'm running into is on 
unmarshalling.

To quickly outline the problem, I have a Java object with two fields 
of the same type, but with different values/meanings to the parent 
object.    When I marshall these objects I want to send them to the 
same to the same element name (to emphasize they are the same type) 
but in different namespaces to separate the fields.  When I 
unmarshall, I get an exception (Exception text at end of message).  
Stepping through the code in a debugger it looks like the 
UnmarshalHandler looks for the first FieldDescriptor that matches the 
element name, but when the namespaces clash, it says it can't find the 
handler (when the handler it needs is next in the array, but there is 
no way to get there).

I also tried to solve this problem by wrapping the data elements using 
the location attribute of the bind-xml element in the mapping file 
hoping that Castor would check the XPath and associate the data to the 
correct fields (with further thought I realized checking the full 
XPath could be troublesome, but using the mapping file and the 
location tag might allow for some flexibility).

So I guess I have a two fold question.  First, is there a better way 
to approach this problem?  And second, am I abusing the concept of an 
XML namespace with my current implementation in a way that Castor 
SHOULDN'T support it?  My (perhaps naive) idea on the matter is that 
if the UnmarshalHandler finds an element that matches, but the 
namespaces clash, then the Handler should initiate a search from the 
next point in the array to see if there is a second descriptor with a 
matching element name and a matching namespace.  In a quick code 
survey, I think this would require redefining some interfaces, so it 
wouldn't be easy, but it might be value-added.

Thanks everyone for your time, and I look forward to hearing your 
comments.

Stephen Bash
Exception Stack Trace:
unable to find FieldDescriptor for 'BarData' in ClassDescriptor of 
Element2
org.xml.sax.SAXException: unable to find FieldDescriptor for 'BarData' 
in ClassDescriptor of Element2
    at 
org.exolab.castor.xml.UnmarshalHandler.startElement(UnmarshalHandler.java:1853) 

    at 
org.exolab.castor.xml.UnmarshalHandler.startElement(UnmarshalHandler.java:1330) 

    at 
org.apache.xerces.parsers.SAXParser.startElement(SAXParser.java:1376)
    at 
org.apache.xerces.validators.common.XMLValidator.callStartElement(XMLValidator.java:965) 

    at 
org.apache.xerces.framework.XMLDocumentScanner.scanElement(XMLDocumentScanner.java:1858) 

    at 
org.apache.xerces.framework.XMLDocumentScanner$ContentDispatcher.dispatch(XMLDocumentScanner.java:1234) 

    at 
org.apache.xerces.framework.XMLDocumentScanner.parseSome(XMLDocumentScanner.java:381) 

    at org.apache.xerces.framework.XMLParser.parse(XMLParser.java:952)
    at 
org.exolab.castor.xml.Unmarshaller.unmarshal(Unmarshaller.java:657)
    at 
org.exolab.castor.xml.Unmarshaller.unmarshal(Unmarshaller.java:565)
    at UnmarshalEx3.main(UnmarshalEx3.java:53)


----------------------------------------------------------- If you 
wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
       unsubscribe castor-user


----------------------------------------------------------- If you wish 
to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
       unsubscribe castor-user



----------------------------------------------------------- 
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
       unsubscribe castor-user