Stephen Bash wrote:
Keith-
Thanks for the quick reply. It's nice to know we're on the same page at least.
Yep, and actually last night I went ahead and updated the interface in the CVS to include the namespace. I decided the sooner we do it the better. I still need to update XMLClassDescriptorImpl to actually use the namespace, but at least the api is in place now. This will only be for 0.9.6 or greater.
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.
Yeah currently as it examines the stack it's simply looking for for a field with the proper name and it makes sure the that any matching field comes from a class that specifies the correct location fields. But you can still run into conflicts with this and the field should be double-checked to make sure that it is indeed the correct one. This can be done by comparing the location path. If you have two foo fields but with different namespaces and one (or both) has a location path specified you'll run into the same problem that you described originally where the wrong foo could end up being matched.
Adding the namespace support will go a long way to avoid such conflicts, but the location path should also be examined to make that two foo fields with different nested locations, but same namespaces are matched correctly.
The location attribute was really a hack to allow people to do a bit more complex mappings than what was originally provided. When we initiall wrote Castor we envisioned each element would map to a specific class or field. We didn't have a vision that some elements could be virtual and some fields for a parent class should actually come from child or descendent elements, or some fields should come from ancestors, etc. So I created the location attribute to work around some of that. I made the limitation that the location could only point forward (much easier this way) into the tree and couldn't have any predicates, namespaces are limited to the parent class namespace, etc, so that I could get something working quickly. However I do have plans on allowing the location to be more complex xpath expression at some point. Especially since we have a nice XPath library in Adaptx that we can make use of.
It's just a matter of time.
--Keith
P.S. It's nice to see you chose a school whose mascot shares the same name as this project! :-) It's just a coincidence however, I'm certainly not smart enough for such a prestigious institution.
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/[email protected]/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
