Eric,

I think that there is a more maintainable solution here.

What you want is to customize the mapping of FQCNs to URIs. I'm about
to walk out of the house, but when I get back I will re-excavate the
question of whether there is a class you could subclass and stuff into
a setter (irish or otherwise) to take control of this process.



On Fri, Oct 1, 2010 at 9:57 PM, Kampf, Eric <[email protected]> wrote:
> Hmmm.  If I understand this correctly (and I may not), this would work but it 
> might not be maintainable.  Here's why:  From what I've seen of Aegis, the 
> namespace mappings are specified on a per-object basis.  The objects I am 
> dealing with a fairly complex (i.e. many layers of nested objects) and they 
> are maintained by other developers.  The first object change that did not 
> have a corresponding Aegis config change might break the service.
>
> In any case I'll still give this a try.  Hopefully I will find a magic switch 
> in Aegis that simplifies the overriding of namespaces.
>
> I'll let you know how it goes.
>
> Thanks.
>
> -Eric
>
> From: Sergey Beryozkin [mailto:[email protected]]
> Sent: Friday, October 01, 2010 4:20 PM
> To: [email protected]
> Cc: Kampf, Eric
> Subject: Re: Aegis Binding without namespaces
>
> 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 
> <[email protected]<mailto:[email protected]>> 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:[email protected]<mailto:[email protected]>]
>> Sent: Wednesday, September 29, 2010 5:45 AM
>> To: [email protected]<mailto:[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]<mailto:[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]<mailto:[email protected]>]
>> > Sent: Tuesday, September 28, 2010 9:09 PM
>> > To: [email protected]<mailto:[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]<mailto:[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]<mailto:[email protected]>
>> > > http://dankulp.com/blog
> --
> Daniel Kulp
> [email protected]<mailto:[email protected]>
> http://dankulp.com/blog
>
>

Reply via email to