Hi
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.
if you look at the JSONElementProvider, you can see it has setProperties(), and
this provider
instance can pick all the required properties when it's configured using Spring.
Aegis configuration properties would be specific to an Aegis provider only so
I'm not sure what your concern
is...
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.
I'm sorry, I'm not following :-).
For, here's a typical method a JAX-RS can handle :
Customer doIt(@QueryParam("bar") String bar, Customer customer);
I don't understand how your proposal would make it easier to handle the conversion of the InputStream into an instance of Customer.
Please explain. In other words why can't an AegisProvider reuse the code from the DataBinding directly ?
ProviderFactory's job is to create providers based on the asked media types and
classes
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?
ProviderFactory does not need to arbitrate in this case it's this the JAX-RS
runtime itself which will do it indirectly.
Suppose we have a Customer which either a JAXBProvider or AegisProvider can handle. Explictly configuring AegisProvider as one of
the providers to be used in the spring config for jaxrs:server would ensure that it'll be given a chance to serialize/deserialize
before a JAXBProvider will be asked to do the same....
Thanks for starting to look into it anyway, I'm sure we'll a have a cool JAX-RS
AegisProvider eventually :-)
Cheers, Sergey
P.S. I'll be on holidays for the most part of August, so I won't be able to
contribute to this thread during the next month
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
----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
