cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sergey Beryozkin" <sbery...@progress.com>
Subject RE: Question about the JAXRS client's schema
Date Sun, 31 May 2009 21:31:38 GMT
Hi Willem

Perhaps implementing support for @serviceClass attribute should be
enough, at least for a start. In the spring parser for jaxrs:server we
can just convert the value into a singleton list, for a
"resourceClasses" property.

So you can do:

cxfrs://http://localhost:9000?resourceClass=org.apache.camel.component.c
xf.jaxrs.testbean.CustomerService

I've seen your commit, where you restored @transportId, plus binding and
@bindingId. So we let some elements/attributes go but restored those
which may be needed :-)

thanks for your help, Sergey 

-----Original Message-----
From: Willem Jiang [mailto:willem.jiang@gmail.com] 
Sent: 31 May 2009 01:59
To: dev@cxf.apache.org
Subject: Re: Question about the JAXRS client's schema

Hi Sergey,

Since CXF support multi-transport, I think the JAXRS front end may
leverage that, so we need to use the transportId :)

Here is another thing, JAXRSClientFactoryBean and JAXRSServerFactoryBean
have the setResourcesClasses method, but there is no attribute or
element definition of it in the schema.

In most case, we could use serviceBeans elements to setup the resource
instance, so I don't know if we need to add the resourceClasses element
into the schema.

But in Camel cxfrs URI, I added this resourcesClasses option like this
cxfrs://http://localhost:9000?resourceClasses=org.apache.camel.component
.cxf.jaxrs.testbean.CustomerService

Willem

Sergey Beryozkin wrote:
> Hi William
> 
> Ok, I haven't thought about it that in Camel one may want to route say
> JMS messages to it, so I will add a @transportId back...
> 
>> BTW, I found the @serviceClass does not work for JAXRS server
> 
> I think in JAXWS it's meant to point to a real class when Spring
proxies
> are used but since we introduced (Spring) proxy helper that attribute
> has never been used in JAX-RS. In jaxrs:server you can register a list
> of resource classes using serviceBeans (using a List
programmatically).
> But I do agree
> It can be handy using @serviceClass when only a single resource class
is
> used, this simplifying a configuration a bit.
> 
> Thanks, Sergey 
> 
> -----Original Message-----
> From: Willem Jiang [mailto:willem.jiang@gmail.com] 
> Sent: 30 May 2009 06:23
> To: dev@cxf.apache.org
> Subject: Re: Question about the JAXRS client's schema
> 
> Hi Sergey,
> 
> I think we may need to use the @transportId if we want to configure
> the transport for JAXRS endpoint, such as JMS transport or local
> transport.
> 
> BTW, I found the @serviceClass does not work for JAXRS server, and I'm
> heading to fix it.
> 
> Willem
> 
> Sergey Beryozkin wrote:
>> Hi Willem
>>
>>> <xsd:element name="invoker" type="xsd:anyType" minOccurs="0"/>
>> This one is a copy and paste error. I just removed it from
> jaxrs:client.
>> I also removed the following from jaxrs:server :
>>
>> jaxrs:binding 
>> jaxrs:serviceFactory
>> @transportId
>> @bindingId
>> @endpointName
>> @serviceName
>>
>> as they most likely made it into jaxrs:server as a result of copying
>> from jaxws:endpoint. We may end up adding some of these
>> elements/attributes back, but at the moment we just don't use them...
>>
>> thanks for raising the issue on the dev list
>> Sergey  
>>  
>>
>> -----Original Message-----
>> From: Willem Jiang [mailto:willem.jiang@gmail.com] 
>> Sent: 26 May 2009 04:06
>> To: dev@cxf.apache.org
>> Subject: Question about the JAXRS client's schema
>>
>> Hi Sergey,
>>
>> I'm working on integrating the CXF JAXRS with Camel, and just found
>> there are some elements which are defined in the JAXRS client are
>> useless.
>> such as
>> <xsd:element name="executor" type="xsd:anyType" minOccurs="0"/>
>> <xsd:element name="invoker" type="xsd:anyType" minOccurs="0"/>
>>
>> Did I miss something ?
>>
>> Thanks,
>>
>> Willem
>>
> 
> 


Mime
View raw message