Aegis versus jaxrs
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 entire service?
Re: Aegis versus jaxrs
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 configured per-MessageBodyProvider. My proposal is that the JAXRSServerFactoryBean could be given DataBinding objects, and the ProviderFactory would use them. If there aren't any, it would do what it does now. On a more detailed note, how would you propose that the ProviderFactory arbitrate between using JAXB and Aegis? They support the same annotations on the code. Isn't this another reason to have a Server Factory configuration, to specify which data binding to use by default? Or is some other mechanism at work here that I haven't comprehended? On Thu, Jul 31, 2008 at 10:23 AM, Sergey Beryozkin [EMAIL PROTECTED] wrote: Hi 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. At the moment yes, and this is a reson I excluded a jaxb-databinding module, just to minimize the size of the cxf-jaxrs bundle. I think jaxb api is picked up recursively from some other module, I actually didn't check from which one. I think I can do likewise for Aegis, sort of, but it could get ugly. If you'd like to do an Aegis Provider and a jaxb binding module would help you then please do include it in the pom again. Does JAX-RS give us no ability to configure a data binding at the level of the entire service? In JAX-RS, it's individual MessageBodyProviders which are responsible for (un)marshalling. So probably, not... Perhaps the default JAXBProvider can be updated to reuse some of the code from a jaxb binding, not sure Cheers, Sergey IONA Technologies PLC (registered in Ireland) Registered Number: 171387 Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
[QUESTION OF TASTE] Resurrect AegisServiceConfiguration or pick a new name?
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 XFire-style '/'s to the ends of URLs. Dan suggests un-deprecating this and adding in the code to fix up the parameters and all that jazz. I'm not happy about enshrining the trailing / convention as a permanent feature of Aegis in CXF. Possibilities: 1) Create a new AegisServiceConfiguration in org.apache.cxf.aegis.service. 2) Make the trailing-/ behavior optional, turned off by default. 3) Just leave the trailing-/ out, and document the need to toss in the XFireCompatibilityServiceConfiguration to the stack to get that behavior in 2.1.x. 4) create org.cxf.aegis.databinding.AegisXmlServiceConfiguration to make it clear that all this is doing is respecting .aegis.xml files, not anything else. I'm kind of partial to #4, but I'm prepared to be cooperative.
[QUESTION OF TASTE] Should an Aegis(Xml)ServiceConfiguration demand the presence of an AegisDatabinding?
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 configuration to be mixed with anything else by just going ahead and reading the file (if any) at that point. The former is less work and arguably less confusing, but I'll do the later if others think it superior.
Re: [QUESTION OF TASTE] Resurrect AegisServiceConfiguration or pick a new name?
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 logical way to address this is a ServiceConfiguration. We have a deprecated AegisServiceConfiguration that has the effect of adding XFire-style '/'s to the ends of URLs. Dan suggests un-deprecating this and adding in the code to fix up the parameters and all that jazz. I'm not happy about enshrining the trailing / convention as a permanent feature of Aegis in CXF. Possibilities: 1) Create a new AegisServiceConfiguration in org.apache.cxf.aegis.service. 2) Make the trailing-/ behavior optional, turned off by default. 3) Just leave the trailing-/ out, and document the need to toss in the XFireCompatibilityServiceConfiguration to the stack to get that behavior in 2.1.x. 4) create org.cxf.aegis.databinding.AegisXmlServiceConfiguration to make it clear that all this is doing is respecting .aegis.xml files, not anything else. I'm kind of partial to #4, but I'm prepared to be cooperative. --- Daniel Kulp [EMAIL PROTECTED] http://www.dankulp.com/blog
Re: [QUESTION OF TASTE] Resurrect AegisServiceConfiguration or pick a new name?
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 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 XFire-style '/'s to the ends of URLs. Dan suggests un-deprecating this and adding in the code to fix up the parameters and all that jazz. I'm not happy about enshrining the trailing / convention as a permanent feature of Aegis in CXF. Possibilities: 1) Create a new AegisServiceConfiguration in org.apache.cxf.aegis.service. 2) Make the trailing-/ behavior optional, turned off by default. 3) Just leave the trailing-/ out, and document the need to toss in the XFireCompatibilityServiceConfiguration to the stack to get that behavior in 2.1.x. 4) create org.cxf.aegis.databinding.AegisXmlServiceConfiguration to make it clear that all this is doing is respecting .aegis.xml files, not anything else. I'm kind of partial to #4, but I'm prepared to be cooperative. --- Daniel Kulp [EMAIL PROTECTED] http://www.dankulp.com/blog
