Mailing-List: contact users-help@cxf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@cxf.apache.org
Received-SPF: pass (nike.apache.org: domain of sberyozkin@gmail.com designates
 209.85.214.41 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :cc:content-type;
        b=Xrv3eTFlxEvvy/FUVviiq/Eu6XoDHUfMoPQX/MnX8a2CEy2AmtGWTCKYzjmNSqPKN/
         BxCMOG0dPGZVz8l0I3u7X0z0tB2FV376PmdyM43rCCeAjEQ1sCx35zEim1oDVDmT2h9L
         fEOIYo9IA/+o6hSsTGwex+H2YGiBtg7Kbj/LU=
MIME-Version: 1.0
In-Reply-To: <201010011552.07025.dkulp@apache.org>
References: 
 <0A95DE316D40F244B65989915C978B072E89A5C41E@KEX-US-CLUS02.KRONOS.COM>
	<AANLkTikia7jsJ+y=_k-cLuQ6ym2M78KE9HXJnW7x7XL3@mail.gmail.com>
	<0A95DE316D40F244B65989915C978B072E89A5C452@KEX-US-CLUS02.KRONOS.COM>
	<201010011552.07025.dkulp@apache.org>
Date: Fri, 1 Oct 2010 21:20:03 +0100
Message-ID: <AANLkTikgMHR-TDXw5JLbnKH0GL31N7md5CX+y4QSHaaa@mail.gmail.com>
Subject: Re: Aegis Binding without namespaces
From: Sergey Beryozkin <sberyozkin@gmail.com>
To: users@cxf.apache.org
Cc: "Kampf, Eric" <Eric.Kampf@kronos.com>
Content-Type: multipart/alternative; boundary=0016e6dd85c67f3ac1049193eb43

--0016e6dd85c67f3ac1049193eb43
Content-Type: text/plain; charset=ISO-8859-1

Yes, this should work, override a createReader method in the provider and
return a custom reader, here's a basic example :

http://svn.apache.org/repos/asf/cxf/trunk/systests/jaxrs/src/test/java/org/apache/cxf/systest/jaxrs/CustomXmlStreamReader.java

cheers, Sergey


On Fri, Oct 1, 2010 at 8:52 PM, Daniel Kulp <dkulp@apache.org> wrote:

> 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:sberyozkin@gmail.com]
> > Sent: Wednesday, September 29, 2010 5:45 AM
> > To: users@cxf.apache.org
> > 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 <Eric.Kampf@kronos.com>
> 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:bimargulies@gmail.com]
> > > Sent: Tuesday, September 28, 2010 9:09 PM
> > > To: users@cxf.apache.org
> > > 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 <dkulp@apache.org> 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/cxf-user@incubator.apache.org/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
> > > > dkulp@apache.org
> > > > http://dankulp.com/blog
>
> --
> Daniel Kulp
> dkulp@apache.org
> http://dankulp.com/blog
>

--0016e6dd85c67f3ac1049193eb43--