On Friday 01 October 2010 2:28:34 pm Kampf, Eric wrote: > Sergey, > > I implemented your suggestion and it worked for outgoing data. > Unfortunately incoming data is an issue. Aegis still requires the > namespace information to be able to unmarshal the XML. > > So what I am really looking for is a way to entirely disable namespace > mapping in the binding. I realize it is not directly supported, but > perhaps there is some way to "trick" the binding? Any suggestions?
Is it possible to do the reverse on the way in? Wrapper the XMLStreamReader with one that always returns a preconfigured namespace for all the calls the pull a namespace? Dan > > Thanks again for all your help to this point. > > -Eric > > -----Original Message----- > From: Sergey Beryozkin [mailto:[email protected]] > Sent: Wednesday, September 29, 2010 5:45 AM > To: [email protected] > Subject: Re: Aegis Binding without namespaces > > Hi Eric > > the way you can do it is as follows. > > Extend AegisElementProvider [1] and override its createStreamWriter method > and create a custom writer, see [2] for an example, just pass to it the > writer instance AegisElementProvider creates. > > You just probably need to override writeNamespace(...) with a no-op > implementation and writeStartElement and block the namespaces. > > I believe you work with DOSGI. In that case, do not use > org.apache.cxf.rs.databindng property but rather an > "org.apache.cxf.rs.providers" and list the full name of your custom > provider. > > hope it helps, Sergey > > [1] > http://svn.apache.org/repos/asf/cxf/trunk/rt/frontend/jaxrs/src/main/java/o > rg/apache/cxf/jaxrs/provider/AegisElementProvider.java [2] > http://svn.apache.org/repos/asf/cxf/trunk/systests/jaxrs/src/test/java/org/ > apache/cxf/systest/jaxrs/CustomXmlStreamWriter.java > > On Wed, Sep 29, 2010 at 2:15 AM, Kampf, Eric <[email protected]> wrote: > > Yes the reason for this is that our primary clients are mobile devices, > > some of which have very limited XML parsing capabilities. REST seems to > > emphasize simplicity and namespace handling is not always simple. SOAP > > is a little too 2009 for my taste. :-) > > > > -----Original Message----- > > From: Benson Margulies [mailto:[email protected]] > > Sent: Tuesday, September 28, 2010 9:09 PM > > To: [email protected] > > Subject: Re: Aegis Binding without namespaces > > > > It's a big problem. The mapping of packages to namespaces avoids > > collisions. If you don't want namespaces, then you have to find > > another solution. > > > > I personally find no-namespace XML to be entirely too 1999 for my > > taste, but I imagine that you have a good reason for it. > > > > On Tue, Sep 28, 2010 at 4:49 PM, Daniel Kulp <[email protected]> wrote: > > > I honestly don't think anyone has looked at this at all. If it's > > > > something > > > > > you need, you'll likely have to work on it and submit patches. > > > > > > Dan > > > > > > On Tuesday 28 September 2010 4:26:35 pm Kampf, Eric wrote: > > >> Hello, > > >> > > >> I would like to use CXF's Aegis data binding for a REST service (I > > >> have multiple reasons for preferring Aegis over JAXB...). The > > >> biggest impediment I face however is the presence of namespaces on > > >> all elements. This will be a hardship for most of our clients. > > >> > > >> I see that this topic came up a couple of years ago on this list: > > >> http://www.mail-archive.com/[email protected]/msg04683.htm > > >> l > > > > . > > > > >> It even resulted in the creation of a JIRA issue which is still listed > > > > as > > > > >> open: > > https://issues.apache.org/jira/browse/CXF-1291?page=com.atlassian.jira.pl > > u > > > > >> gin.system.issuetabpanels:comment-tabpanel. > > >> > > >> Does anyone know if there is a solution for this? Our clients are > > > > simply > > > > >> not going to be able to use namespaces. Is there any hope of > > > > configuring > > > > >> Aegis to function without namespaces? > > >> > > >> Thanks. > > >> > > >> -Eric > > > > > > -- > > > Daniel Kulp > > > [email protected] > > > http://dankulp.com/blog -- Daniel Kulp [email protected] http://dankulp.com/blog
