Hi Gabo
The snapshot containing the fix has not been released yet, it's on the trunk
only.
See the interface[1], implementation[2] and test[3] (testAddGetBook)
Cheers, Sergey
[1]
https://svn.apache.org/repos/asf/cxf/trunk/systests/src/test/java/org/apache/cxf/systest/jaxrs/BookStoreJaxrsJaxws.java
[2]
https://svn.apache.org/repos/asf/cxf/trunk/systests/src/test/java/org/apache/cxf/systest/jaxrs/BookStoreSoapRestImpl.java
[3]
https://svn.apache.org/repos/asf/cxf/trunk/systests/src/test/java/org/apache/cxf/systest/jaxrs/JaxRsJaxWsBookTest.java
----- Original Message -----
From: "Gabo Manuel" <[EMAIL PROTECTED]>
To: <users@cxf.apache.org>
Sent: Thursday, October 23, 2008 8:14 AM
Subject: Re: [JAX-WS][JAX-RS][JAVA-FIRST] Problem in the auto-generated wsdl
Hi Sergey,
The fix does not seem to work. I tried using what was included in
2.2-SNAPSHOT. Same problem. My current work-around is to have all the
logic in an abstract class. Then have 2 classes inheriting that class,
one containing the JAX-WS annotations, the other containing JAX-RS
annotations. It is a bit messy, but at the least gets the job done.
Next stop for me is security. Things should be pretty straight-forward
from here.
Again, my thanks for the help.
Gabo
Sergey Beryozkin wrote:
Hi Gabo
The fix is on 2.2-SNAPSHOT trunk (will be in 2.1.4-SNAPSHOT a bit later)
Thanks for helping to discover and fixing a subtle bug :-) !
Sergey
Hi Sergey,
I have created the JIRA
(https://issues.apache.org/jira/browse/CXF-1882). Would update you
with the results of my tests tomorrow.
Again, my thanks for your help. :)
Gabo
Sergey Beryozkin wrote:
Hi Gabo
Hi Sergey,
> here the Account will be unmarshalled as expected but because you
have
> the runtime mistakenly ignores it....
Thanks for that. So the JAX-WS annotation is indeed messing with the
JAX-RS?
It's rather JAX-RS runtime which is mistakenly getting confused - I
see it now and will get it fixed shortly
Do I still open a JIRA? Is it ok if I submit an archive containing the
files or it is really preferred that the code is pasted along with the
email text (kinda' messy)?
If you can open the JIRA and just say that
JAX-RS can't unmarshall request body if the corresponding parameter
is annotated with non-JAX-RS annotation then it will be cool. It's
up to you - if you have an extra min or two...
It's all working in cases like
@Path("{id}")
void foo(@PathParam("id") WebParam(name="id") String id)
as the value is coming from the URI, but not in
@POST or @PUT
void foo(WebParam(name="id") Account acc)
Thanks, Sergey
On my side, I would try to have two interfaces which would have the
same
set of methods but with different sets of annotation. Then have one
implementation class implementing both interfaces... I'm not sure what
this would yield, but if the issue is just with regards to the
mix-up of
annotations, I think this would be an acceptable work-around for
now...
I'll update you with the results of that test too.
Again, my thanks for your time.
Gabo
Sergey Beryozkin wrote:
I think I might know what might be happening - JAXRS runtime does not
recognize the Account as being a standalone method parameter as it's
annotated with a JAXWS annotation. On other words, in JAX-RS,
providers(by default) are used only when unmarshalling parameters not
annotated with JAX-RS annotations, for ex
void foo(@PathParam("id") String id, Account acc);
here the Account will be unmarshalled as expected but because you
have
void foo(@WebParam(name="account") Account account);
the runtime mistakenly ignores it....
I'll get back to you on this one...Stay tuned :-)
Sergey
Hi Gabo
Can you please open a JIRA and attach a sample root resource class,
Account class, and beans.xml.
You're saying that during the non-SOAP invocation a
JAXBElementProvider is never invoked - I don't see how it can be
happening - it must be at least checked once (isReadbale method must
be invoked), given that JAXBElementProvider in the list of default
providers. I need to investigate but I honestly don't see how it can
be happening.
Can you give me one more favour please and put a breakpoint in
org.apache.cxf.interceptor.JAXRSInInterceptor.handleMessage and
proceed from there ?
Many thanks, Sergey
Hi Sergey,
Sorry for the late response. I had to leave earlier than usual
yesterday. I added the break points as you have asked. I also
added a
breakpoint in the constructor just to make sure it is being
created.
The
provider is being created, however during the processing of the
request,
the said class is never invoked.
The classes AbstractJAXBProvider and JAXBElementProvider are never
invoked during request processing.
Again, my thanks.
Gabo
Sergey Beryozkin wrote:
How is it going ? Did you get a chance to get to hit a
breakpoint in
the AbstractJAXBProvider ?
Cheers, Sergey
Hi,
> In org.apache.cxf.jaxrs.provider.JAXBElementProvider class,
put a
breakpoint in isReadable() method and see why it returns
false. If
it returns true then check why readFrom() fails. I'll try to run
test locally too.
The cxf version I have does not have any isReadable method. I
added
breakpoints in methods readFrom and writeTo. The transaction
never
passed through the break point (see stacktrace above).
Sorry, can you put a breakpoint in
AbstractJAXBProvider.isReadable,
which JAXBElementProvider extends ?
Cheers, Sergey
Again, thanks for your time.
Gabo Manuel
------------------------------------------------------------------------
No virus found in this incoming message.
Checked by AVG - http://www.avg.com
Version: 8.0.173 / Virus Database: 270.8.2/1735 - Release Date:
10/20/2008 2:52 PM
------------------------------------------------------------------------
No virus found in this incoming message.
Checked by AVG - http://www.avg.com
Version: 8.0.175 / Virus Database: 270.8.2/1738 - Release Date:
10/21/2008 2:10 PM
------------------------------------------------------------------------
No virus found in this incoming message.
Checked by AVG - http://www.avg.com Version: 8.0.175 / Virus
Database: 270.8.2/1738 - Release Date: 10/21/2008 2:10 PM
------------------------------------------------------------------------
No virus found in this incoming message.
Checked by AVG - http://www.avg.com
Version: 8.0.175 / Virus Database: 270.8.2/1740 - Release Date: 10/22/2008 7:24 PM
