If I'm reading the JAX-RS code correctly, which I'm probably not, it doesn't
use the JAXB DataBinding object. It interacts class-by-class with JAXB.
I think I can do likewise for Aegis, sort of, but it could get ugly. Does
JAX-RS give us no ability to configure a data binding at the level of the
When a CXF service offers JAX-RS, some CXF-specific configuration is
involved, no? So, could we not have some properties at the service level
which the ProviderFactory consumes-if-provided? Aegis in particular has a
set of configuration options, it would be very cumbersome to force those to
be
We come to discover that there's a bunch of Aegis per-service configuration
which is dead in CXF because the service factory doesn't talk to the data
binding. The logical way to address this is a ServiceConfiguration.
We have a deprecated AegisServiceConfiguration that has the effect of adding
Proposal:
The service configuration will obtain the data binding from the
service factory. If it is Aegis, it will extract the desired
customizations. If it is not Aegis, it will do nothing. It will NOT
independently pull in and parse the XML.
The alternative is, of course, to allow Aegis
I'm quite OK with #4. Makes it explicitly clear what it's doing.
Dan
On Jul 31, 2008, at 1:44 PM, Benson Margulies wrote:
We come to discover that there's a bunch of Aegis per-service
configuration
which is dead in CXF because the service factory doesn't talk to the
data
binding. The
Thanks.
On Thu, Jul 31, 2008 at 3:20 PM, Daniel Kulp [EMAIL PROTECTED] wrote:
I'm quite OK with #4. Makes it explicitly clear what it's doing.
Dan
On Jul 31, 2008, at 1:44 PM, Benson Margulies wrote:
We come to discover that there's a bunch of Aegis per-service
configuration
which
