2015-07-14 19:26 GMT+02:00 Chris Wolf :
> Again, referring to the example code at:
>
> https://cwiki.apache.org/confluence/display/CXF20DOC/JAXRS+Testing
>
> This client code works:
>
> @Test
> public void testGetBookWithProxy() {
> MyJaxrsResource client =
> JAXRSClientFactory.crea
CXF JAX-RS supports registered custom providers, the default
JSONProvider is Jettison based and depends on JAXB, register Jackson
instead if needed
Sergey
On 15/07/15 02:55, Chris Wolf wrote:
No, it's just a plain POJO with no annotations. I'm pretty sure I
used Jackson to handle JSON-to-POJO
For legacy reasons, all of the resource methods in the project I'm
working on have a signature similar to:
@GET
@Path("/book")
public Response getBook(@Context HttpServletRequest request,
@Context HttpServletResponse response);
When I change to local transport (to save ru
No, it's just a plain POJO with no annotations. I'm pretty sure I
used Jackson to handle JSON-to-POJO and POJO-to_JSON without requiring
annotations. That's not supported in CXF/JAX-RS?
Thanks
Chris
On Tue, Jul 14, 2015 at 2:59 PM, Sergey Beryozkin wrote:
> CXF JSONProvider only supports JAXB
Ok, that's really helpful. I see that cglib was, in fact, mentioned
in the docs.
On Tue, Jul 14, 2015 at 2:57 PM, Sergey Beryozkin wrote:
> Have a look at
> https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=blob;f=systests/jaxrs/src/test/java/org/apache/cxf/systest/jaxrs/JAXRSLocalTransportTes
Hi Colm,
We are running a simple HelloWorld service, with the attached web.xml, under
Tomcat and set Digest authentication for GET.
After some further investigation we saw that a HEAD request was sent rather
than a GET with Digest.
With Basic authentication a GET is sent. The following error ap
CXF JSONProvider only supports JAXB annotated beans, with
XmlRootElement, is Book.class in your code below a JAXB bean ?
Sergey
On 14/07/15 18:26, Chris Wolf wrote:
Again, referring to the example code at:
https://cwiki.apache.org/confluence/display/CXF20DOC/JAXRS+Testing
This client code work
Have a look at
https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=blob;f=systests/jaxrs/src/test/java/org/apache/cxf/systest/jaxrs/JAXRSLocalTransportTest.java;h=05229fdc472c999a6edf7536842577ef8c238290;hb=HEAD
The node about cglib is here
http://cxf.apache.org/docs/jax-rs-client-api.html#JAX-RS
Again, referring to the example code at:
https://cwiki.apache.org/confluence/display/CXF20DOC/JAXRS+Testing
This client code works:
@Test
public void testGetBookWithProxy() {
MyJaxrsResource client =
JAXRSClientFactory.create(ENDPOINT_ADDRESS, MyJaxrsResource.class);
Web
I am looking at this page:
https://cwiki.apache.org/confluence/display/CXF20DOC/JAXRS+Testing
I was finally able to get the Jetty version running in spite of the
missing code (Book.java, MyJaxrsResource.java). It also took a lot
of hours to figure out what caused this error:
java.lang.IllegalA
Hi Francesco,
The generator checks which operations are the same path operations, I've
checked the code and it also compares a number of path and matrix
parameters, so PUT was also sharing the same root resource, before it
had a keyId method parameter.
If PUT where inside a keyId resource th
It looks like a bug. Could you create a test-case to reproduce the problem?
Colm.
On Mon, Jul 13, 2015 at 4:30 AM, Talkov, Roger
wrote:
> Hi,
>
> I am able to read a WSDL with Basic Authentication, but not Digest.
> The code is the same except for the authorizationType.
> I create a Bus and set
I agree, that this might rather be a Felix problem than a CXF problem. I will
look into it and maybe also contact the Felix mailing list on this topic.
Thanks so far,
Thomas
-Ursprüngliche Nachricht-
Von: Christian Schneider [mailto:cschneider...@gmail.com] Im Auftrag von
Christian Sch
Hi all,
any obvious reason why two distinct resources with path "/{key}" [1] are
generated from [2]?
TIA
Regards.
[1] https://paste.apache.org/lQbF
[2]
https://github.com/apache/syncope/blob/master/common/rest-api/src/main/java/org/apache/syncope/common/rest/api/service/AnyTypeService.java
Now I get it. That explains why the open(true) helped. I think though
this should be fixed in felix.
A HttpService provider should not require the clients to know a
proprietary interface.
I think the real problem might be in
org.apache.felix.http.base.internal.service.HttpServiceFactory.HttpSe
Hi Christian,
as I see the problem is not the default org.osgi.service.http.HttpService
Interface itself but org.apache.felix.http.api.ExtHttpService which is
introduced by Felix and which inherits from HttpService. So in the end when
context.getServiceReferences() is called from the ServiceTra
16 matches
Mail list logo
