You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Gabo Manuel <km...@solegysystems.com> on 2008/10/16 07:59:21 UTC
[JAX-WS][JAX-RS]
Hi All,
I currently have a service which I want to expose as both ReST(ian/ful)
and SOAP.
AccountService.java:
@Path("/rest/Accounts")
public class AccountService {
@GET
@Path("/Account/{uniqueId}")
public Account get(
@PathParam("uniqueId")
long uniqueId
) {
System.out.println("got in");
logger.info("get received: " + uniqueId);
try{
return generateAccount();
} finally {
}
}
}
beans.xml:
<jaxrs:server id="accountRestService" address="/">
<jaxrs:serviceBeans>
<ref bean="accountServiceClass" />
</jaxrs:serviceBeans>
</jaxrs:server>
<bean id="accountServiceClass" class="my.package.AccountService" />
<jaxws:endpoint
id="accountSoapService"
address="/soap/Accounts"
implementor="#accountServiceClass"
>
</jaxws:endpoint>
** As stated in http://cwiki.apache.org/CXF20DOC/jax-rs-jsr-311.html
The ReST part works fine. However, there seems to be problem with the
soap part. The wsdl is all messed up, no object/method definitions,
nothing from what you would expect from a standard SOAP wsdl.
I could be missing some parameters/settings/properties in the jaxws tag.
Or do I mix both jax-rs and jax-ws annotations?
@GET
@Path("/Account/{uniqueId}")
@WebMethod(operationName="get")
public Account get(
@WebParam(name="uniqueId")
long uniqueId
Initially, I had everything using jax-ws. I used http-binding for the
ReST part and let the default settings handle the SOAP part. But as
advised in my previous question
(http://www.nabble.com/-REST--HTTP-BINDING-Service-does-not-receive-Post-parameter-tt19986914.html#a19991022),
so now I am trying to have it in jax-rs-ws tandem.
Again, thanks in advance.
P.S.
This is also a sort of follow-up regarding the issue raised in this
other thread:
(CXF-1695) Service listings for JAX-RS endpoints
(http://www.nabble.com/Created%3A-%28CXF-1695%29-Service-listings-for-JAX-RS-endpoints-tt18363145.html#a18363145)
Re: [JAX-WS][JAX-RS][JAVA-FIRST] Problem in the auto-generated wsdl
Posted by Gabo Manuel <km...@solegysystems.com>.
Hi Sergey,
A few final questions, though this is arguably not related to the
initial problem.
1. 404 is experienced on this link at 4:13 GMT
http://people.apache.org/repo/m2-snapshot-repository/org/apache/cxf/apache-cxf/2.1.4-SNAPSHOT/
2. Why are there two official releases? 2.1 and 2.0, does this mean that
changes in 2.0 are not reflected in 2.1?
I'll be testing 2.2-SNAPSHOT, will update this with the results.
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
>
Re: [JAX-WS][JAX-RS][JAVA-FIRST] Problem in the auto-generated wsdl
Posted by Gabo Manuel <km...@solegysystems.com>.
Hi Sergey,
Thanks for the update. I am currently testing 2.1.4-snapshot and the
annotations are not "messing" with each other now. :D
I'll try and test the 2.2-snapshot later on.
Gabo
Sergey Beryozkin wrote:
> Hi Gabo
> Both snapshots have a fix. Any problems that you see ?
>
> Cheers, Sergey
>
Re: [JAX-WS][JAX-RS][JAVA-FIRST] Problem in the auto-generated wsdl
Posted by Sergey Beryozkin <sb...@progress.com>.
Hi Gabo - no worries :-) - thanks for helping me to sort out this issue
Cheers, Sergey
----- Original Message -----
From: "Gabo Manuel" <km...@solegysystems.com>
To: <us...@cxf.apache.org>
Sent: Tuesday, February 03, 2009 7:23 AM
Subject: Re: [JAX-WS][JAX-RS][JAVA-FIRST] Problem in the auto-generated wsdl
> Hi Sergey,
>
> Sorry for that. Ignore that email. It is working now. Old versions of
> cxf and jsr were loaded in the class path. My mistake. :)
>
> Gabo
>
> Gabo Manuel wrote:
>> Hi Sergey,
>>
>> I'm sorry it took this long for a response. I tried using CXF2.2
>> snapshot. All is working fine except for the following case:
>>
>> import javax.ws.rs.POST;
>> import javax.ws.rs.Consumes;
>> import javax.ws.rs.Produces;
>> import javax.jws.WebMethod;
>> import javax.jws.WebParam;
>> import javax.jws.WebService;
>> import javax.ws.rs.Path;
>>
>> @Consumes("*/xml")
>> @Produces("*/xml")
>> @WebService(serviceName="AccountService", portName="AccountServicePort")
>> public class AccountService{
>> @POST
>> @Path("/")
>> @WebMethod
>> public int updateAccount(
>> @WebParam(name="account")
>> WSAccount account) {
>> logger.info("update Account Received: " + account);
>> }
>> }
>>
>>
>> @XmlType(name="Account")
>> @XmlAccessorType(XmlAccessType.PROPERTY)
>> @XmlRootElement(name="Account")
>> public class WSAccount {
>> private String accountID;
>>
>> @GET
>> @Path("/accountID")
>> public String getAccountID() {
>> return accountID;
>> }
>>
>> public void setAccountID(String accountID) {
>> this.accountID = accountID;
>> }
>> }
>>
>>
>> I am using jsr311-api-1.0 as stated in the user's guide.
>>
>> With the '@WebParam' the WSAccount is not properly loaded by the
>> default MessageBodyReader. If I remove the said annotation, the
>> service works fine and the object's fields are properly loaded.
>>
>> Unfortunately, if I remove the said annotation, the wsdl generated for
>> the Soap endpoint renders the parameter's name as arg0. If there is
>> another way to set the parameter name to something else, that would
>> help too.
>>
>> Again, thanks for the assistance.
>>
>> Gabo Manuel
>>
>> Sergey Beryozkin wrote:
>>> Hi Gabo
>>> Both snapshots have a fix. Any problems that you see ?
>>>
>>> Cheers, Sergey
>>>
>>> ----- Original Message ----- From: "Gabo Manuel"
>>> <km...@solegysystems.com>
>>> To: <us...@cxf.apache.org>
>>> Sent: Friday, December 12, 2008 7:50 AM
>>> Subject: Re: [JAX-WS][JAX-RS][JAVA-FIRST] Problem in the
>>> auto-generated wsdl
>>>
>>>
>>>> Hi Sergey,
>>>>
>>>> Just would like to confirm if the fix regarding this issue is
>>>> available to both 2.1.4-snapshot and that of 2.2-snapshot?
>>>>
>>>> Gabo
>>>
>> ------------------------------------------------------------------------
>>
>>
>> No virus found in this incoming message.
>> Checked by AVG - www.avg.com
>> Version: 8.0.233 / Virus Database: 270.10.17/1931 - Release Date: 02/01/09 18:02:00
>>
>>
>
Re: [JAX-WS][JAX-RS][JAVA-FIRST] Problem in the auto-generated wsdl
Posted by Gabo Manuel <km...@solegysystems.com>.
Hi Sergey,
Sorry for that. Ignore that email. It is working now. Old versions of
cxf and jsr were loaded in the class path. My mistake. :)
Gabo
Gabo Manuel wrote:
> Hi Sergey,
>
> I'm sorry it took this long for a response. I tried using CXF2.2
> snapshot. All is working fine except for the following case:
>
> import javax.ws.rs.POST;
> import javax.ws.rs.Consumes;
> import javax.ws.rs.Produces;
> import javax.jws.WebMethod;
> import javax.jws.WebParam;
> import javax.jws.WebService;
> import javax.ws.rs.Path;
>
> @Consumes("*/xml")
> @Produces("*/xml")
> @WebService(serviceName="AccountService", portName="AccountServicePort")
> public class AccountService{
> @POST
> @Path("/")
> @WebMethod
> public int updateAccount(
> @WebParam(name="account")
> WSAccount account) {
> logger.info("update Account Received: " + account);
> }
> }
>
>
> @XmlType(name="Account")
> @XmlAccessorType(XmlAccessType.PROPERTY)
> @XmlRootElement(name="Account")
> public class WSAccount {
> private String accountID;
>
> @GET
> @Path("/accountID")
> public String getAccountID() {
> return accountID;
> }
>
> public void setAccountID(String accountID) {
> this.accountID = accountID;
> }
> }
>
>
> I am using jsr311-api-1.0 as stated in the user's guide.
>
> With the '@WebParam' the WSAccount is not properly loaded by the
> default MessageBodyReader. If I remove the said annotation, the
> service works fine and the object's fields are properly loaded.
>
> Unfortunately, if I remove the said annotation, the wsdl generated for
> the Soap endpoint renders the parameter's name as arg0. If there is
> another way to set the parameter name to something else, that would
> help too.
>
> Again, thanks for the assistance.
>
> Gabo Manuel
>
> Sergey Beryozkin wrote:
>> Hi Gabo
>> Both snapshots have a fix. Any problems that you see ?
>>
>> Cheers, Sergey
>>
>> ----- Original Message ----- From: "Gabo Manuel"
>> <km...@solegysystems.com>
>> To: <us...@cxf.apache.org>
>> Sent: Friday, December 12, 2008 7:50 AM
>> Subject: Re: [JAX-WS][JAX-RS][JAVA-FIRST] Problem in the
>> auto-generated wsdl
>>
>>
>>> Hi Sergey,
>>>
>>> Just would like to confirm if the fix regarding this issue is
>>> available to both 2.1.4-snapshot and that of 2.2-snapshot?
>>>
>>> Gabo
>>
> ------------------------------------------------------------------------
>
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> Version: 8.0.233 / Virus Database: 270.10.17/1931 - Release Date: 02/01/09 18:02:00
>
>
Re: [JAX-WS][JAX-RS][JAVA-FIRST] Problem in the auto-generated wsdl
Posted by Sergey Beryozkin <sb...@progress.com>.
Hi
I can't reproduce it, I've tried exactly the same AccountService and WSAccount you posted and I've no problems seeing a loaded
WSAccount instance. Perhaps the 2.2 SNAPSHOT you tried does not contain the fix ?
Can you try the latest one available from here :
http://people.apache.org/repo/m2-snapshot-repository/org/apache/cxf/apache-cxf/2.2-SNAPSHOT/ ?
Cheers, Sergey
> Hi Sergey,
>
> I'm sorry it took this long for a response. I tried using CXF2.2 snapshot. All is working fine except for the following case:
>
> import javax.ws.rs.POST;
> import javax.ws.rs.Consumes;
> import javax.ws.rs.Produces;
> import javax.jws.WebMethod;
> import javax.jws.WebParam;
> import javax.jws.WebService;
> import javax.ws.rs.Path;
>
> @Consumes("*/xml")
> @Produces("*/xml")
> @WebService(serviceName="AccountService", portName="AccountServicePort")
> public class AccountService{
> @POST
> @Path("/")
> @WebMethod
> public int updateAccount(
> @WebParam(name="account")
> WSAccount account) {
> logger.info("update Account Received: " + account);
> }
> }
>
>
> @XmlType(name="Account")
> @XmlAccessorType(XmlAccessType.PROPERTY)
> @XmlRootElement(name="Account")
> public class WSAccount {
> private String accountID;
>
> @GET
> @Path("/accountID")
> public String getAccountID() {
> return accountID;
> }
>
> public void setAccountID(String accountID) {
> this.accountID = accountID;
> }
> }
>
>
> I am using jsr311-api-1.0 as stated in the user's guide.
>
> With the '@WebParam' the WSAccount is not properly loaded by the default MessageBodyReader. If I remove the said annotation, the
> service works fine and the object's fields are properly loaded.
>
> Unfortunately, if I remove the said annotation, the wsdl generated for the Soap endpoint renders the parameter's name as arg0. If
> there is another way to set the parameter name to something else, that would help too.
>
> Again, thanks for the assistance.
>
> Gabo Manuel
>
> Sergey Beryozkin wrote:
>> Hi Gabo
>> Both snapshots have a fix. Any problems that you see ?
>>
>> Cheers, Sergey
>>
>> ----- Original Message ----- From: "Gabo Manuel" <km...@solegysystems.com>
>> To: <us...@cxf.apache.org>
>> Sent: Friday, December 12, 2008 7:50 AM
>> Subject: Re: [JAX-WS][JAX-RS][JAVA-FIRST] Problem in the auto-generated wsdl
>>
>>
>>> Hi Sergey,
>>>
>>> Just would like to confirm if the fix regarding this issue is available to both 2.1.4-snapshot and that of 2.2-snapshot?
>>>
>>> Gabo
>>
Re: [JAX-WS][JAX-RS][JAVA-FIRST] Problem in the auto-generated wsdl
Posted by Gabo Manuel <km...@solegysystems.com>.
Hi Sergey,
I'm sorry it took this long for a response. I tried using CXF2.2
snapshot. All is working fine except for the following case:
import javax.ws.rs.POST;
import javax.ws.rs.Consumes;
import javax.ws.rs.Produces;
import javax.jws.WebMethod;
import javax.jws.WebParam;
import javax.jws.WebService;
import javax.ws.rs.Path;
@Consumes("*/xml")
@Produces("*/xml")
@WebService(serviceName="AccountService", portName="AccountServicePort")
public class AccountService{
@POST
@Path("/")
@WebMethod
public int updateAccount(
@WebParam(name="account")
WSAccount account) {
logger.info("update Account Received: " + account);
}
}
@XmlType(name="Account")
@XmlAccessorType(XmlAccessType.PROPERTY)
@XmlRootElement(name="Account")
public class WSAccount {
private String accountID;
@GET
@Path("/accountID")
public String getAccountID() {
return accountID;
}
public void setAccountID(String accountID) {
this.accountID = accountID;
}
}
I am using jsr311-api-1.0 as stated in the user's guide.
With the '@WebParam' the WSAccount is not properly loaded by the default
MessageBodyReader. If I remove the said annotation, the service works
fine and the object's fields are properly loaded.
Unfortunately, if I remove the said annotation, the wsdl generated for
the Soap endpoint renders the parameter's name as arg0. If there is
another way to set the parameter name to something else, that would help
too.
Again, thanks for the assistance.
Gabo Manuel
Sergey Beryozkin wrote:
> Hi Gabo
> Both snapshots have a fix. Any problems that you see ?
>
> Cheers, Sergey
>
> ----- Original Message ----- From: "Gabo Manuel"
> <km...@solegysystems.com>
> To: <us...@cxf.apache.org>
> Sent: Friday, December 12, 2008 7:50 AM
> Subject: Re: [JAX-WS][JAX-RS][JAVA-FIRST] Problem in the
> auto-generated wsdl
>
>
>> Hi Sergey,
>>
>> Just would like to confirm if the fix regarding this issue is
>> available to both 2.1.4-snapshot and that of 2.2-snapshot?
>>
>> Gabo
>
Re: [JAX-WS][JAX-RS][JAVA-FIRST] Problem in the auto-generated wsdl
Posted by Sergey Beryozkin <se...@progress.com>.
Hi Gabo
Both snapshots have a fix. Any problems that you see ?
Cheers, Sergey
----- Original Message -----
From: "Gabo Manuel" <km...@solegysystems.com>
To: <us...@cxf.apache.org>
Sent: Friday, December 12, 2008 7:50 AM
Subject: Re: [JAX-WS][JAX-RS][JAVA-FIRST] Problem in the auto-generated wsdl
> Hi Sergey,
>
> Just would like to confirm if the fix regarding this issue is available
> to both 2.1.4-snapshot and that of 2.2-snapshot?
>
> 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
>>
>>
>
Re: [JAX-WS][JAX-RS][JAVA-FIRST] Problem in the auto-generated wsdl
Posted by Gabo Manuel <km...@solegysystems.com>.
Hi Sergey,
Just would like to confirm if the fix regarding this issue is available
to both 2.1.4-snapshot and that of 2.2-snapshot?
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
>
>
Re: [JAX-WS][JAX-RS][JAVA-FIRST] Problem in the auto-generated wsdl
Posted by Sergey Beryozkin <se...@progress.com>.
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" <km...@solegysystems.com>
To: <us...@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
>>
>>
>
Re: [JAX-WS][JAX-RS][JAVA-FIRST] Problem in the auto-generated wsdl
Posted by Gabo Manuel <km...@solegysystems.com>.
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
>
>
Re: [JAX-WS][JAX-RS][JAVA-FIRST] Problem in the auto-generated wsdl
Posted by Sergey Beryozkin <se...@progress.com>.
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
>>
>>
>
Re: [JAX-WS][JAX-RS][JAVA-FIRST] Problem in the auto-generated wsdl
Posted by Gabo Manuel <km...@solegysystems.com>.
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
>
>
Re: [JAX-WS][JAX-RS][JAVA-FIRST] Problem in the auto-generated wsdl
Posted by Sergey Beryozkin <se...@progress.com>.
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
>>
>>
>
Re: [JAX-WS][JAX-RS][JAVA-FIRST] Problem in the auto-generated wsdl
Posted by Gabo Manuel <km...@solegysystems.com>.
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?
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)?
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
>
>
Re: [JAX-WS][JAX-RS][JAVA-FIRST] Problem in the auto-generated wsdl
Posted by Sergey Beryozkin <se...@progress.com>.
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
>>>
>>>
>>
>
Re: [JAX-WS][JAX-RS][JAVA-FIRST] Problem in the auto-generated wsdl
Posted by Sergey Beryozkin <se...@progress.com>.
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
>>
>>
>
Re: [JAX-WS][JAX-RS][JAVA-FIRST] Problem in the auto-generated wsdl
Posted by Gabo Manuel <km...@solegysystems.com>.
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
>
>
Re: [JAX-WS][JAX-RS][JAVA-FIRST] Problem in the auto-generated wsdl
Posted by Sergey Beryozkin <se...@progress.com>.
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
>>
>
Re: [JAX-WS][JAX-RS][JAVA-FIRST] Problem in the auto-generated wsdl
Posted by Sergey Beryozkin <se...@progress.com>.
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
>
Re: [JAX-WS][JAX-RS][JAVA-FIRST] Problem in the auto-generated wsdl
Posted by Gabo Manuel <km...@solegysystems.com>.
Hi Sergey,
> Can you paste the stack trace in the email message ?
Captured stacktrace below:
Thread [btpool0-1] (Suspended (breakpoint at line 103 in
AccountService))
AccountService.insert(Account) line: 103
NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not
available [native method]
NativeMethodAccessorImpl.invoke(Object, Object[]) line: not
available
DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: not
available
Method.invoke(Object, Object...) line: not available
JAXRSInvoker(AbstractInvoker).performInvocation(Exchange, Object,
Method, Object[]) line: 136
JAXRSInvoker(AbstractInvoker).invoke(Exchange, Object, Method,
List<Object>) line: 82
JAXRSInvoker.invoke(Exchange, Object, List<Object>) line: 109
JAXRSInvoker.invoke(Exchange, Object) line: 63
ServiceInvokerInterceptor$1.run() line: 56
SynchronousExecutor.execute(Runnable) line: 37
ServiceInvokerInterceptor.handleMessage(Message) line: 92
PhaseInterceptorChain.doIntercept(Message) line: 220
ChainInitiationObserver.onMessage(Message) line: 78
JettyHTTPDestination.serviceRequest(ServletContext,
HttpServletRequest, HttpServletResponse) line: 278
JettyHTTPDestination.doService(ServletContext, HttpServletRequest,
HttpServletResponse) line: 252
JettyHTTPHandler.handle(String, HttpServletRequest,
HttpServletResponse, int) line: 70
ContextHandler.handle(String, HttpServletRequest,
HttpServletResponse, int) line: 726
ContextHandlerCollection.handle(String, HttpServletRequest,
HttpServletResponse, int) line: 206
Server(HandlerWrapper).handle(String, HttpServletRequest,
HttpServletResponse, int) line: 152
Server.handle(HttpConnection) line: 324
HttpConnection.handleRequest() line: 505
HttpConnection$RequestHandler.content(Buffer) line: 842
HttpParser.parseNext() line: 648
HttpParser.parseAvailable() line: 211
HttpConnection.handle() line: 380
SelectChannelConnector$ConnectorEndPoint(SelectChannelEndPoint).run()
line: 395
BoundedThreadPool$PoolThread.run() line: 450
> So here's the class :
That is correct. Of course I have other methods included, e.g. getters.
> Is AccountService.insert(Account account) ever called ?
Yes. and the 'account' is always logged as null.
> 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).
Again, thanks for your time.
Gabo Manuel
Sergey Beryozkin wrote:
> Hi,
>
> no problems at all, thanks for trying to help me to find the problem.
>
> Can you paste the stack trace in the email message ?
>
> So here's the class :
>
> @Path("/")
> @WebService(serviceName="AccountService")
> public class AccountService {
> @PUT
> @Path("/Account")
> @WebMethod
> public long insert(
> @WebParam(name="account")
> Account account
> ) {
> logger.info("insert Received: " + account);
> return 0;
> }
> }
>
> Is AccountService.insert(Account account) ever called ?
>
> 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.
>
> Cheers, Sergey
>
> ----- Original Message -----
> From: Gabo Manuel
> To: users@cxf.apache.org
> Sent: Tuesday, October 21, 2008 10:48 AM
> Subject: Re: [JAX-WS][JAX-RS][JAVA-FIRST] Problem in the auto-generated wsdl
>
>
> Hi Sergey,
>
> > it's not a SOAP invocation which is being handled
>
> Yes. the invocation is on the ReST/jax-rs endpoint.
>
> > Is there any chance you can debug your service and see if JAXElementProvider.isReadable is even invoked ?
>
> I am not sure what I should be looking for or how I would do it, so here is my attempt to provide the information you asked.
>
> Steps taken:
> 1. Created a server using JAXRSServerFactoryBean as is done in the samples.
> 2. Using eclipse, I added a break point in the first line of the invoked method in my service implementation. (sorry, too many 'in's)
> 3. Ran the Server class in debug mode. Ran the client in debug mode as well.
>
> Attached is the snapshot of the stacktrace when the breakpoint was reached. The class you mentioned, JAX(B)ElementProvider, is not in the list. I could be doing something wrong... how do I properly check if the provider is being invoked.
>
> Again, thanks for your time.
>
> Gabo Manuel
>
> Gabo Manuel wrote:
> Hi Sergey,
>
> > Unfortunately I've been able to spend just a minor fraction of my time on JAX-RS support during the last few months so my apologies for a 'slack' support.
>
> We have our (other) lives to live. ;)
>
> > how does the generated wsdl look like ?
>
> With the RS-WS mixed tags, the WSDL is pretty much what you would expect from a standard SOAP service. I'm thinking it's a good thing that the WS annotations does not create problems for the RS process, and vice-versa.
>
> > Yes. Just curious, do you have any specific plans at this stage for consuming somehow such documents ?
>
> Since ReSTful services could easily be consumed by Http clients, there is no immediate need. However, it would be nice if we could have something similar to wsdl2java for ReSTful services, so consumers could just see SOAP and ReST as just services. (It does somehow defeat the purpose of ReST a bit)
>
> > So it does happen when the invocation goes through the JAX-RS runtime, not the JAX-WS one, that is it's not a SOAP invocation which is being handled, right ? It does look like that the JAX-RS JAXB provider is not invoked. Is there any chance you can debug your service and see if JAXElementProvider.isReadable is even invoked ?
>
> I would have to get back to you on this. I have other things to get done first for the day. Might be able to get back to you on Monday (atleast you have one less person/topic to think about over the week-end).
>
> Again, thansk for your time.
>
> Sergey Beryozkin wrote:
>
> Hi,
>
>
> Hi Sergey,
>
> Thank you so much for your time. To answer your questions:
>
>
> Unfortunately I've been able to spend just a minor fraction of my time on JAX-RS support during the last few months so my apologies for a 'slack' support. This is about to change and I'm really planning to spend more time on the JAX-RS, though I'll still need to do some work on the DOSGI project (currently in sandbox) and look at some pending WS-Policy issues.
>
>
>
> > 1. With JAX-RS involved, generated WSDL for a soap service is wrong
>
> With JAX-RS alone, the WSDL for the SOAP service is wrong. I ended up
> mixing the annotations of JAX-RS and JAX-WS as previously posted in this
> thread.
>
>
> Ok. So, given this class :
>
>
> @Path("/")
> @WebService(serviceName="AccountService")
> public class AccountService {
> @PUT
> @Path("/Account")
> @WebMethod
> public long insert(
> @WebParam(name="account")
> Account account
> ) {
> logger.info("insert Received: " + account);
> return 0;
> }
> }
>
>
> how does the generated wsdl look like ?
>
>
>
> Also, are there plans for auto-generation of WADL or WSDL2 for
> java-first ReST services?
>
>
> Yes. Just curious, do you have any specific plans at this stage for consuming somehow such documents ?
>
>
>
> > 2. Unmarshalling problem : does it happen as part of JAX-RS invocation ?
> > If yes, what sort of problem it is ? do you get Account as null ?
>
> It happens in the method invocation. I follow the directions stated in
> the user guide, but the method keeps reporting (via logs) that the
> object it received is null.
>
>
> So it does happen when the invocation goes through the JAX-RS runtime, not the JAX-WS one, that is it's not a SOAP invocation which is being handled, right ? It does look like that the JAX-RS JAXB provider is not invoked. Is there any chance you can debug your service and see if JAXElementProvider.isReadable is even invoked ?
>
> Thanks, Sergey
>
>
>
> > 3. Service listings : do you still see the soap service listed ?
>
> They share one servlet, so I assume there is only one list which would
> include both ReST and SOAP services. Am I wrong in this? It keeps on
> saying NPE somewhere in the Endpoint class. This has been reported here too:
>
> http://www.nabble.com/Created%3A-%28CXF-1695%29-Service-listings-for-JAX-RS-endpoints-tt18363145.html#a18363145
>
> Again, my thanks.
>
>
> ------------------------------------------------------------------------
>
>
> No virus found in this incoming message.
> Checked by AVG - http://www.avg.com Version: 8.0.173 / Virus Database: 270.8.1/1727 - Release Date: 10/15/2008 8:02 PM
>
>
>
>
> ----------------------------------------------------------------------------
>
> No virus found in this incoming message.
> Checked by AVG - http://www.avg.com
> Version: 8.0.173 / Virus Database: 270.8.1/1729 - Release Date: 10/16/2008 7:12 PM
>
>
>
> ------------------------------------------------------------------------
>
>
> 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
>
>
Re: [JAX-WS][JAX-RS][JAVA-FIRST] Problem in the auto-generated wsdl
Posted by Sergey Beryozkin <se...@progress.com>.
Hi,
no problems at all, thanks for trying to help me to find the problem.
Can you paste the stack trace in the email message ?
So here's the class :
@Path("/")
@WebService(serviceName="AccountService")
public class AccountService {
@PUT
@Path("/Account")
@WebMethod
public long insert(
@WebParam(name="account")
Account account
) {
logger.info("insert Received: " + account);
return 0;
}
}
Is AccountService.insert(Account account) ever called ?
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.
Cheers, Sergey
----- Original Message -----
From: Gabo Manuel
To: users@cxf.apache.org
Sent: Tuesday, October 21, 2008 10:48 AM
Subject: Re: [JAX-WS][JAX-RS][JAVA-FIRST] Problem in the auto-generated wsdl
Hi Sergey,
> it's not a SOAP invocation which is being handled
Yes. the invocation is on the ReST/jax-rs endpoint.
> Is there any chance you can debug your service and see if JAXElementProvider.isReadable is even invoked ?
I am not sure what I should be looking for or how I would do it, so here is my attempt to provide the information you asked.
Steps taken:
1. Created a server using JAXRSServerFactoryBean as is done in the samples.
2. Using eclipse, I added a break point in the first line of the invoked method in my service implementation. (sorry, too many 'in's)
3. Ran the Server class in debug mode. Ran the client in debug mode as well.
Attached is the snapshot of the stacktrace when the breakpoint was reached. The class you mentioned, JAX(B)ElementProvider, is not in the list. I could be doing something wrong... how do I properly check if the provider is being invoked.
Again, thanks for your time.
Gabo Manuel
Gabo Manuel wrote:
Hi Sergey,
> Unfortunately I've been able to spend just a minor fraction of my time on JAX-RS support during the last few months so my apologies for a 'slack' support.
We have our (other) lives to live. ;)
> how does the generated wsdl look like ?
With the RS-WS mixed tags, the WSDL is pretty much what you would expect from a standard SOAP service. I'm thinking it's a good thing that the WS annotations does not create problems for the RS process, and vice-versa.
> Yes. Just curious, do you have any specific plans at this stage for consuming somehow such documents ?
Since ReSTful services could easily be consumed by Http clients, there is no immediate need. However, it would be nice if we could have something similar to wsdl2java for ReSTful services, so consumers could just see SOAP and ReST as just services. (It does somehow defeat the purpose of ReST a bit)
> So it does happen when the invocation goes through the JAX-RS runtime, not the JAX-WS one, that is it's not a SOAP invocation which is being handled, right ? It does look like that the JAX-RS JAXB provider is not invoked. Is there any chance you can debug your service and see if JAXElementProvider.isReadable is even invoked ?
I would have to get back to you on this. I have other things to get done first for the day. Might be able to get back to you on Monday (atleast you have one less person/topic to think about over the week-end).
Again, thansk for your time.
Sergey Beryozkin wrote:
Hi,
Hi Sergey,
Thank you so much for your time. To answer your questions:
Unfortunately I've been able to spend just a minor fraction of my time on JAX-RS support during the last few months so my apologies for a 'slack' support. This is about to change and I'm really planning to spend more time on the JAX-RS, though I'll still need to do some work on the DOSGI project (currently in sandbox) and look at some pending WS-Policy issues.
> 1. With JAX-RS involved, generated WSDL for a soap service is wrong
With JAX-RS alone, the WSDL for the SOAP service is wrong. I ended up
mixing the annotations of JAX-RS and JAX-WS as previously posted in this
thread.
Ok. So, given this class :
@Path("/")
@WebService(serviceName="AccountService")
public class AccountService {
@PUT
@Path("/Account")
@WebMethod
public long insert(
@WebParam(name="account")
Account account
) {
logger.info("insert Received: " + account);
return 0;
}
}
how does the generated wsdl look like ?
Also, are there plans for auto-generation of WADL or WSDL2 for
java-first ReST services?
Yes. Just curious, do you have any specific plans at this stage for consuming somehow such documents ?
> 2. Unmarshalling problem : does it happen as part of JAX-RS invocation ?
> If yes, what sort of problem it is ? do you get Account as null ?
It happens in the method invocation. I follow the directions stated in
the user guide, but the method keeps reporting (via logs) that the
object it received is null.
So it does happen when the invocation goes through the JAX-RS runtime, not the JAX-WS one, that is it's not a SOAP invocation which is being handled, right ? It does look like that the JAX-RS JAXB provider is not invoked. Is there any chance you can debug your service and see if JAXElementProvider.isReadable is even invoked ?
Thanks, Sergey
> 3. Service listings : do you still see the soap service listed ?
They share one servlet, so I assume there is only one list which would
include both ReST and SOAP services. Am I wrong in this? It keeps on
saying NPE somewhere in the Endpoint class. This has been reported here too:
http://www.nabble.com/Created%3A-%28CXF-1695%29-Service-listings-for-JAX-RS-endpoints-tt18363145.html#a18363145
Again, my thanks.
------------------------------------------------------------------------
No virus found in this incoming message.
Checked by AVG - http://www.avg.com Version: 8.0.173 / Virus Database: 270.8.1/1727 - Release Date: 10/15/2008 8:02 PM
----------------------------------------------------------------------------
No virus found in this incoming message.
Checked by AVG - http://www.avg.com
Version: 8.0.173 / Virus Database: 270.8.1/1729 - Release Date: 10/16/2008 7:12 PM
Re: [JAX-WS][JAX-RS][JAVA-FIRST] Problem in the auto-generated wsdl
Posted by Gabo Manuel <km...@solegysystems.com>.
Hi Sergey,
> it's not a SOAP invocation which is being handled
Yes. the invocation is on the ReST/jax-rs endpoint.
> Is there any chance you can debug your service and see if
JAXElementProvider.isReadable is even invoked ?
I am not sure what I should be looking for or how I would do it, so here
is my attempt to provide the information you asked.
Steps taken:
1. Created a server using JAXRSServerFactoryBean as is done in the samples.
2. Using eclipse, I added a break point in the first line of the invoked
method in my service implementation. (sorry, too many 'in's)
3. Ran the Server class in debug mode. Ran the client in debug mode as well.
Attached is the snapshot of the stacktrace when the breakpoint was
reached. The class you mentioned, JAX(B)ElementProvider, is not in the
list. I could be doing something wrong... how do I properly check if the
provider is being invoked.
Again, thanks for your time.
Gabo Manuel
Gabo Manuel wrote:
> Hi Sergey,
>
> > Unfortunately I've been able to spend just a minor fraction of my
> time on JAX-RS support during the last few months so my apologies for
> a 'slack' support.
>
> We have our (other) lives to live. ;)
>
> > how does the generated wsdl look like ?
>
> With the RS-WS mixed tags, the WSDL is pretty much what you would
> expect from a standard SOAP service. I'm thinking it's a good thing
> that the WS annotations does not create problems for the RS process,
> and vice-versa.
>
> > Yes. Just curious, do you have any specific plans at this stage for
> consuming somehow such documents ?
>
> Since ReSTful services could easily be consumed by Http clients, there
> is no immediate need. However, it would be nice if we could have
> something similar to wsdl2java for ReSTful services, so consumers
> could just see SOAP and ReST as just services. (It does somehow defeat
> the purpose of ReST a bit)
>
> > So it does happen when the invocation goes through the JAX-RS
> runtime, not the JAX-WS one, that is it's not a SOAP invocation which
> is being handled, right ? It does look like that the JAX-RS JAXB
> provider is not invoked. Is there any chance you can debug your
> service and see if JAXElementProvider.isReadable is even invoked ?
>
> I would have to get back to you on this. I have other things to get
> done first for the day. Might be able to get back to you on Monday
> (atleast you have one less person/topic to think about over the
> week-end).
>
> Again, thansk for your time.
>
> Sergey Beryozkin wrote:
>> Hi,
>>
>>> Hi Sergey,
>>>
>>> Thank you so much for your time. To answer your questions:
>>
>> Unfortunately I've been able to spend just a minor fraction of my
>> time on JAX-RS support during the last few months so my apologies for
>> a 'slack' support. This is about to change and I'm really planning to
>> spend more time on the JAX-RS, though I'll still need to do some work
>> on the DOSGI project (currently in sandbox) and look at some pending
>> WS-Policy issues.
>>
>>>
>>> > 1. With JAX-RS involved, generated WSDL for a soap service is wrong
>>>
>>> With JAX-RS alone, the WSDL for the SOAP service is wrong. I ended up
>>> mixing the annotations of JAX-RS and JAX-WS as previously posted in
>>> this
>>> thread.
>>
>> Ok. So, given this class :
>>
>>>>> @Path("/")
>>>>> @WebService(serviceName="AccountService")
>>>>> public class AccountService {
>>>>> @PUT
>>>>> @Path("/Account")
>>>>> @WebMethod
>>>>> public long insert(
>>>>> @WebParam(name="account")
>>>>> Account account
>>>>> ) {
>>>>> logger.info("insert Received: " + account);
>>>>> return 0;
>>>>> }
>>>>> }
>>
>> how does the generated wsdl look like ?
>>
>>>
>>> Also, are there plans for auto-generation of WADL or WSDL2 for
>>> java-first ReST services?
>>
>> Yes. Just curious, do you have any specific plans at this stage for
>> consuming somehow such documents ?
>>
>>>
>>> > 2. Unmarshalling problem : does it happen as part of JAX-RS
>>> invocation ?
>>> > If yes, what sort of problem it is ? do you get Account as null ?
>>>
>>> It happens in the method invocation. I follow the directions stated in
>>> the user guide, but the method keeps reporting (via logs) that the
>>> object it received is null.
>>
>> So it does happen when the invocation goes through the JAX-RS
>> runtime, not the JAX-WS one, that is it's not a SOAP invocation which
>> is being handled, right ? It does look like that the JAX-RS JAXB
>> provider is not invoked. Is there any chance you can debug your
>> service and see if JAXElementProvider.isReadable is even invoked ?
>>
>> Thanks, Sergey
>>
>>>
>>> > 3. Service listings : do you still see the soap service listed ?
>>>
>>> They share one servlet, so I assume there is only one list which would
>>> include both ReST and SOAP services. Am I wrong in this? It keeps on
>>> saying NPE somewhere in the Endpoint class. This has been reported
>>> here too:
>>>
>>> http://www.nabble.com/Created%3A-%28CXF-1695%29-Service-listings-for-JAX-RS-endpoints-tt18363145.html#a18363145
>>>
>>>
>>> Again, my thanks.
>>>
>> ------------------------------------------------------------------------
>>
>>
>> No virus found in this incoming message.
>> Checked by AVG - http://www.avg.com Version: 8.0.173 / Virus
>> Database: 270.8.1/1727 - Release Date: 10/15/2008 8:02 PM
>>
>>
>
> ------------------------------------------------------------------------
>
>
> No virus found in this incoming message.
> Checked by AVG - http://www.avg.com
> Version: 8.0.173 / Virus Database: 270.8.1/1729 - Release Date: 10/16/2008 7:12 PM
>
>
Re: [JAX-WS][JAX-RS][JAVA-FIRST] Problem in the auto-generated wsdl
Posted by Gabo Manuel <km...@solegysystems.com>.
Hi Sergey,
> Unfortunately I've been able to spend just a minor fraction of my
time on JAX-RS support during the last few months so my apologies for a
'slack' support.
We have our (other) lives to live. ;)
> how does the generated wsdl look like ?
With the RS-WS mixed tags, the WSDL is pretty much what you would expect
from a standard SOAP service. I'm thinking it's a good thing that the WS
annotations does not create problems for the RS process, and vice-versa.
> Yes. Just curious, do you have any specific plans at this stage for
consuming somehow such documents ?
Since ReSTful services could easily be consumed by Http clients, there
is no immediate need. However, it would be nice if we could have
something similar to wsdl2java for ReSTful services, so consumers could
just see SOAP and ReST as just services. (It does somehow defeat the
purpose of ReST a bit)
> So it does happen when the invocation goes through the JAX-RS
runtime, not the JAX-WS one, that is it's not a SOAP invocation which is
being handled, right ? It does look like that the JAX-RS JAXB provider
is not invoked. Is there any chance you can debug your service and see
if JAXElementProvider.isReadable is even invoked ?
I would have to get back to you on this. I have other things to get done
first for the day. Might be able to get back to you on Monday (atleast
you have one less person/topic to think about over the week-end).
Again, thansk for your time.
Sergey Beryozkin wrote:
> Hi,
>
>> Hi Sergey,
>>
>> Thank you so much for your time. To answer your questions:
>
> Unfortunately I've been able to spend just a minor fraction of my time
> on JAX-RS support during the last few months so my apologies for a
> 'slack' support. This is about to change and I'm really planning to
> spend more time on the JAX-RS, though I'll still need to do some work
> on the DOSGI project (currently in sandbox) and look at some pending
> WS-Policy issues.
>
>>
>> > 1. With JAX-RS involved, generated WSDL for a soap service is wrong
>>
>> With JAX-RS alone, the WSDL for the SOAP service is wrong. I ended up
>> mixing the annotations of JAX-RS and JAX-WS as previously posted in this
>> thread.
>
> Ok. So, given this class :
>
>>>> @Path("/")
>>>> @WebService(serviceName="AccountService")
>>>> public class AccountService {
>>>> @PUT
>>>> @Path("/Account")
>>>> @WebMethod
>>>> public long insert(
>>>> @WebParam(name="account")
>>>> Account account
>>>> ) {
>>>> logger.info("insert Received: " + account);
>>>> return 0;
>>>> }
>>>> }
>
> how does the generated wsdl look like ?
>
>>
>> Also, are there plans for auto-generation of WADL or WSDL2 for
>> java-first ReST services?
>
> Yes. Just curious, do you have any specific plans at this stage for
> consuming somehow such documents ?
>
>>
>> > 2. Unmarshalling problem : does it happen as part of JAX-RS
>> invocation ?
>> > If yes, what sort of problem it is ? do you get Account as null ?
>>
>> It happens in the method invocation. I follow the directions stated in
>> the user guide, but the method keeps reporting (via logs) that the
>> object it received is null.
>
> So it does happen when the invocation goes through the JAX-RS runtime,
> not the JAX-WS one, that is it's not a SOAP invocation which is being
> handled, right ? It does look like that the JAX-RS JAXB provider is
> not invoked. Is there any chance you can debug your service and see if
> JAXElementProvider.isReadable is even invoked ?
>
> Thanks, Sergey
>
>>
>> > 3. Service listings : do you still see the soap service listed ?
>>
>> They share one servlet, so I assume there is only one list which would
>> include both ReST and SOAP services. Am I wrong in this? It keeps on
>> saying NPE somewhere in the Endpoint class. This has been reported
>> here too:
>>
>> http://www.nabble.com/Created%3A-%28CXF-1695%29-Service-listings-for-JAX-RS-endpoints-tt18363145.html#a18363145
>>
>>
>> Again, my thanks.
>>
> ------------------------------------------------------------------------
>
>
> No virus found in this incoming message.
> Checked by AVG - http://www.avg.com
> Version: 8.0.173 / Virus Database: 270.8.1/1727 - Release Date: 10/15/2008 8:02 PM
>
>
Re: [JAX-WS][JAX-RS][JAVA-FIRST] Problem in the auto-generated wsdl
Posted by Sergey Beryozkin <se...@progress.com>.
Hi,
> Hi Sergey,
>
> Thank you so much for your time. To answer your questions:
Unfortunately I've been able to spend just a minor fraction of my time on JAX-RS support during the last few months so my apologies
for a 'slack' support. This is about to change and I'm really planning to spend more time on the JAX-RS, though I'll still need to
do some work on the DOSGI project (currently in sandbox) and look at some pending WS-Policy issues.
>
> > 1. With JAX-RS involved, generated WSDL for a soap service is wrong
>
> With JAX-RS alone, the WSDL for the SOAP service is wrong. I ended up
> mixing the annotations of JAX-RS and JAX-WS as previously posted in this
> thread.
Ok. So, given this class :
>>> @Path("/")
>>> @WebService(serviceName="AccountService")
>>> public class AccountService {
>>> @PUT
>>> @Path("/Account")
>>> @WebMethod
>>> public long insert(
>>> @WebParam(name="account")
>>> Account account
>>> ) {
>>> logger.info("insert Received: " + account);
>>> return 0;
>>> }
>>> }
how does the generated wsdl look like ?
>
> Also, are there plans for auto-generation of WADL or WSDL2 for
> java-first ReST services?
Yes. Just curious, do you have any specific plans at this stage for consuming somehow such documents ?
>
> > 2. Unmarshalling problem : does it happen as part of JAX-RS invocation ?
> > If yes, what sort of problem it is ? do you get Account as null ?
>
> It happens in the method invocation. I follow the directions stated in
> the user guide, but the method keeps reporting (via logs) that the
> object it received is null.
So it does happen when the invocation goes through the JAX-RS runtime, not the JAX-WS one, that is it's not a SOAP invocation which
is being handled, right ? It does look like that the JAX-RS JAXB provider is not invoked. Is there any chance you can debug your
service and see if JAXElementProvider.isReadable is even invoked ?
Thanks, Sergey
>
> > 3. Service listings : do you still see the soap service listed ?
>
> They share one servlet, so I assume there is only one list which would
> include both ReST and SOAP services. Am I wrong in this? It keeps on
> saying NPE somewhere in the Endpoint class. This has been reported here too:
>
> http://www.nabble.com/Created%3A-%28CXF-1695%29-Service-listings-for-JAX-RS-endpoints-tt18363145.html#a18363145
>
> Again, my thanks.
>
Re: [JAX-WS][JAX-RS][JAVA-FIRST] Problem in the auto-generated wsdl
Posted by Gabo Manuel <km...@solegysystems.com>.
Hi Sergey,
Thank you so much for your time. To answer your questions:
> 1. With JAX-RS involved, generated WSDL for a soap service is wrong
With JAX-RS alone, the WSDL for the SOAP service is wrong. I ended up
mixing the annotations of JAX-RS and JAX-WS as previously posted in this
thread.
Also, are there plans for auto-generation of WADL or WSDL2 for
java-first ReST services?
> 2. Unmarshalling problem : does it happen as part of JAX-RS invocation ?
> If yes, what sort of problem it is ? do you get Account as null ?
It happens in the method invocation. I follow the directions stated in
the user guide, but the method keeps reporting (via logs) that the
object it received is null.
> 3. Service listings : do you still see the soap service listed ?
They share one servlet, so I assume there is only one list which would
include both ReST and SOAP services. Am I wrong in this? It keeps on
saying NPE somewhere in the Endpoint class. This has been reported here too:
http://www.nabble.com/Created%3A-%28CXF-1695%29-Service-listings-for-JAX-RS-endpoints-tt18363145.html#a18363145
Again, my thanks.
Sergey Beryozkin wrote:
> Hi,
>
> So, to summarize, currently you're seeing 2 problems :
>
> 1. With JAX-RS involved, generated WSDL for a soap service is wrong
>
> 2. Unmarshalling problem : does it happen as part of JAX-RS invocation ?
> If yes, what sort of problem it is ? do you get Account as null ?
>
> 3. Service listings : do you still see the soap service listed ?
>
> Cheers, Sergey
>
>
>> Hi all,
>>
>> I tried mixing the annotations. as follows:
>>
>> @Path("/")
>> @WebService(serviceName="AccountService")
>> public class AccountService {
>> @PUT
>> @Path("/Account")
>> @WebMethod
>> public long insert(
>> @WebParam(name="account")
>> Account account
>> ) {
>> logger.info("insert Received: " + account);
>> return 0;
>> }
>> }
>>
>> @XmlRootElement(name="Account")
>> @XmlType(name="Account")
>> @XmlAccessorType(XmlAccessType.PROPERTY)
>> public class Account {
>> //properties goes here...
>> }
>>
>> Things are working, though again, the service list is messed up. Down
>> to the last stretch. As I have posted in
>> http://www.nabble.com/-REST--HTTP-BINDING-Service-does-not-receive-Post-parameter-tt19986914.html#a19991022
>>
>>
>> There seems to be a problem with unmarshalling the object. I could be
>> missing something with the xml so I am posting it here as well:
>>
>> <Account xmlns="http://account.subscriber.ws.solegy.com/">
>> <accountID>someVal</accountID>
>> <!-- other properties here-->
>> </Account>
>>
>> I don't have a wsdl to verify things so I am pretty much lost. I have
>> tried it as 'account' or wrapped with 'insert' tag to no avail. Would
>> appreciate some help.
>>
>> Thanks in advance.
> ------------------------------------------------------------------------
>
>
> No virus found in this incoming message.
> Checked by AVG - http://www.avg.com
> Version: 8.0.173 / Virus Database: 270.8.1/1727 - Release Date: 10/15/2008 8:02 PM
>
>
Re: [JAX-WS][JAX-RS][JAVA-FIRST] Problem in the auto-generated wsdl
Posted by Sergey Beryozkin <se...@progress.com>.
Hi,
So, to summarize, currently you're seeing 2 problems :
1. With JAX-RS involved, generated WSDL for a soap service is wrong
2. Unmarshalling problem : does it happen as part of JAX-RS invocation ?
If yes, what sort of problem it is ? do you get Account as null ?
3. Service listings : do you still see the soap service listed ?
Cheers, Sergey
> Hi all,
>
> I tried mixing the annotations. as follows:
>
> @Path("/")
> @WebService(serviceName="AccountService")
> public class AccountService {
> @PUT
> @Path("/Account")
> @WebMethod
> public long insert(
> @WebParam(name="account")
> Account account
> ) {
> logger.info("insert Received: " + account);
> return 0;
> }
> }
>
> @XmlRootElement(name="Account")
> @XmlType(name="Account")
> @XmlAccessorType(XmlAccessType.PROPERTY)
> public class Account {
> //properties goes here...
> }
>
> Things are working, though again, the service list is messed up. Down to
> the last stretch. As I have posted in
> http://www.nabble.com/-REST--HTTP-BINDING-Service-does-not-receive-Post-parameter-tt19986914.html#a19991022
>
> There seems to be a problem with unmarshalling the object. I could be
> missing something with the xml so I am posting it here as well:
>
> <Account xmlns="http://account.subscriber.ws.solegy.com/">
> <accountID>someVal</accountID>
> <!-- other properties here-->
> </Account>
>
> I don't have a wsdl to verify things so I am pretty much lost. I have
> tried it as 'account' or wrapped with 'insert' tag to no avail. Would
> appreciate some help.
>
> Thanks in advance.
Re: [JAX-WS][JAX-RS][JAVA-FIRST] Problem in the auto-generated wsdl
Posted by Gabo Manuel <km...@solegysystems.com>.
Hi all,
I tried mixing the annotations. as follows:
@Path("/")
@WebService(serviceName="AccountService")
public class AccountService {
@PUT
@Path("/Account")
@WebMethod
public long insert(
@WebParam(name="account")
Account account
) {
logger.info("insert Received: " + account);
return 0;
}
}
@XmlRootElement(name="Account")
@XmlType(name="Account")
@XmlAccessorType(XmlAccessType.PROPERTY)
public class Account {
//properties goes here...
}
Things are working, though again, the service list is messed up. Down to
the last stretch. As I have posted in
http://www.nabble.com/-REST--HTTP-BINDING-Service-does-not-receive-Post-parameter-tt19986914.html#a19991022
There seems to be a problem with unmarshalling the object. I could be
missing something with the xml so I am posting it here as well:
<Account xmlns="http://account.subscriber.ws.solegy.com/">
<accountID>someVal</accountID>
<!-- other properties here-->
</Account>
I don't have a wsdl to verify things so I am pretty much lost. I have
tried it as 'account' or wrapped with 'insert' tag to no avail. Would
appreciate some help.
Thanks in advance.
Re: [JAX-WS][JAX-RS][JAVA-FIRST] Problem in the auto-generated wsdl
Posted by Gabo Manuel <km...@solegysystems.com>.
Hopefully, this would change the subject to something more meaningful...
Gabo Manuel wrote:
> Hi All,
>
> I currently have a service which I want to expose as both
> ReST(ian/ful) and SOAP.
>
> AccountService.java:
> @Path("/rest/Accounts")
> public class AccountService {
> @GET
> @Path("/Account/{uniqueId}")
> public Account get(
> @PathParam("uniqueId")
> long uniqueId
> ) {
> System.out.println("got in");
> logger.info("get received: " + uniqueId);
> try{
> return generateAccount();
> } finally {
> }
> }
> }
>
> beans.xml:
> <jaxrs:server id="accountRestService" address="/">
> <jaxrs:serviceBeans>
> <ref bean="accountServiceClass" />
> </jaxrs:serviceBeans>
> </jaxrs:server>
>
> <bean id="accountServiceClass" class="my.package.AccountService" />
>
> <jaxws:endpoint
> id="accountSoapService"
> address="/soap/Accounts"
> implementor="#accountServiceClass"
> >
> </jaxws:endpoint>
>
> ** As stated in http://cwiki.apache.org/CXF20DOC/jax-rs-jsr-311.html
>
> The ReST part works fine. However, there seems to be problem with the
> soap part. The wsdl is all messed up, no object/method definitions,
> nothing from what you would expect from a standard SOAP wsdl.
>
> I could be missing some parameters/settings/properties in the jaxws
> tag. Or do I mix both jax-rs and jax-ws annotations?
>
> @GET
> @Path("/Account/{uniqueId}")
> @WebMethod(operationName="get")
> public Account get(
> @WebParam(name="uniqueId")
> long uniqueId
>
> Initially, I had everything using jax-ws. I used http-binding for the
> ReST part and let the default settings handle the SOAP part. But as
> advised in my previous question
> (http://www.nabble.com/-REST--HTTP-BINDING-Service-does-not-receive-Post-parameter-tt19986914.html#a19991022),
> so now I am trying to have it in jax-rs-ws tandem.
>
> Again, thanks in advance.
>
> P.S.
>
> This is also a sort of follow-up regarding the issue raised in this
> other thread:
>
> (CXF-1695) Service listings for JAX-RS endpoints
> (http://www.nabble.com/Created%3A-%28CXF-1695%29-Service-listings-for-JAX-RS-endpoints-tt18363145.html#a18363145)
>
>
> ------------------------------------------------------------------------
>
>
> No virus found in this incoming message.
> Checked by AVG - http://www.avg.com
> Version: 8.0.173 / Virus Database: 270.8.1/1727 - Release Date: 10/15/2008 8:02 PM
>
>