I see. So do these toolkits produce messages with namespaces? If
not we're gonna need to add extend aegis to not expect namespaces
when reading. This is one of changes I had to in the extensions for
SOAP encoded.
-dain
On Dec 12, 2007, at 6:56 PM, Daniel Kulp wrote:
Dain,
One of the main use cases for such "namespace free" responses is
for the
REST style things where a client does a "get" on a URL and receives an
XML response back. The XML parsers in various toolkits (and
browsers)
don't always work well with the namespaces that JAXB and Aegis would
always spit out.
Most likely, you would register a service on two URL's. One that
would
return a proper XML that is consumable by smarter clients and another
that would have the strip interceptor setup. You may be able to do
something really smart in the interceptor like look at the user
agent or
something and only strip for certain agents.
Dan
On Wednesday 12 December 2007, Dain Sundstrom wrote:
On Dec 12, 2007, at 7:55 AM, Daniel Kulp wrote:
On Wednesday 12 December 2007, Vespa, Anthony J wrote:
I would be interested in this as well for Aegis bindings - it does
not
make some of the JS libraries out there too happy.
That is why doing it at the interceptor level is ideal. It would
be completely independent of the databinding. Heck, you would be
able to
feed it a DOMSource if using a Provider<Source> type thing and the
namespaces would get stripped out as well.
I'm not sure this can be done with an interceptor. I'd guess that,
client that expects messages to be namespace free are unlikely to
send messages with the proper namespaces in the first place. When
aegis sees the xml without namespaces, it isn't going match nested
elements in the BeanType class to the xml elements because it matches
on qname.
From what I have seen of the BeanType code, think that you can make
aegis expect namespace free nested elements using a new TypeCreater
which creates BeanTypes with no namespace expectations. This is how
the StructType works.
Now that I think about it, I bet the javascript libraries are
expecting soap encoding which doesn't have namespace qualified nested
elements.
-dain
--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727 C: 508-380-7194
[EMAIL PROTECTED]
http://www.dankulp.com/blog
