You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Stuart Bingë <st...@complinet.com> on 2007/07/18 13:17:31 UTC

JAX-WS/annotated SOAP services -- exporting implementation methods rather than interface ones?

Hello all,

We've been using XFire (specifically its SOAP transport) together with JSR-181 
annotations for some time now in our internal Spring-based web services 
(hosted in Tomcat), and are now in the process of looking to upgrade to CXF 
as part of a general systems upgrade. The web services are "java-first", 
where we code to a SEI and then rely on XFire to generate the WSDL as 
appropriate. In addition, the SOAP binding used is RPC/Literal for 
interoperability with PHP clients.

After following the "Writing a service with Spring" article on the CXF site 
(http://cwiki.apache.org/CXF20DOC/writing-a-service-with-spring.html), as 
well as attempting the basic "HelloWorld" applet that the article describes 
(i.e. separate from our existing environment/services), I've discovered some 
strange behaviour that wasn't present with XFire.

When exposing an endpoint via <jaxws:endpoint ... />, the generated WSDL 
appears to be coming from the implementation class rather than the service 
interface -- i.e. getters and setters for implementation-specific properties 
are included in the WSDL.

Is this the expected behaviour with <jaxws:endpoint />? If so, what other 
methods are available/recommended for exposing an endpoint via an interface 
rather than an implementation object?

This can be solved with @WebMethod(ignore = true) annotations on the 
implementation class, but obviously this isn't ideal and shouldn't be needed 
in the first place. We'd like to continue just exposing the interface as the 
service contract and then be able to implement the service in whatever way we 
deem fit.

Any pointers would be greatly appreciated!

Cheers,
-- 
Stuart Bingë

______________________________________________________________________

“Complinet Ltd is registered in England. Registered office at Vintners Place, 68 Upper Thames Street, London EC4V 3BJ. Company number 3170722. VAT No. 749 324 021.
Complinet Inc is a corporation registered in Delaware, USA.”

This email has been scanned by the MessageLabs Email Security System.

Re: JAX-WS/annotated SOAP services -- exporting implementation methods rather than interface ones?

Posted by Stuart Bingë <st...@complinet.com>.
On Thursday 19 July 2007 19:59:17 Daniel Kulp wrote:
> Confirmed as a bug and logged as:
> https://issues.apache.org/jira/browse/CXF-813
> I'm testing a fix now.

Thanks for your help Daniel -- I'll eagerly await the next release then :-)

Cheers,
Stuart

______________________________________________________________________

“Complinet Ltd is registered in England. Registered office at Vintners Place, 68 Upper Thames Street, London EC4V 3BJ. Company number 3170722. VAT No. 749 324 021.
Complinet Inc is a corporation registered in Delaware, USA.”

This email has been scanned by the MessageLabs Email Security System.

Re: JAX-WS/annotated SOAP services -- exporting implementation methods rather than interface ones?

Posted by Daniel Kulp <dk...@apache.org>.
Confirmed as a bug and logged as:
https://issues.apache.org/jira/browse/CXF-813
I'm testing a fix now.

Dan


On Thursday 19 July 2007 04:49, Stuart Bingë wrote:
> Hi Dan,
>
> On Wednesday 18 July 2007 23:10:46 Dan Diephouse wrote:
> > Hi Stuart,
> > Did you specify a @WebService(endpointInterface="...YourInterface")
> > on the implementation class? You're using the JAX-WS frontend and
> > per the JAX-WS spec, thats how its supposed to work :-)
>
> Yeah, I've got my implementation class pointing to the interface via
> endpointInterface -- I pretty much copied and pasted the example from
> that page, then tried to add a property to the implementation class.
> Here's my current test code, if it helps:
>
> Interface:
> @WebService(name = "HelloWorld")
> @SOAPBinding(style=Style.RPC, use=Use.LITERAL)
> public interface HelloWorld {
>
>     String sayHi(@WebParam(name = "text") String text);
>
> }
>
> Implementation:
> @WebService(endpointInterface = "showcase.cxf.HelloWorld")
> public class HelloWorldImpl implements HelloWorld {
>
>     private String  prefix      = "*** unspecified ***";
>
>     @Override
>     public String sayHi(@WebParam(name = "text") String text)
>     {
>         return prefix + text;
>     }
>
>     @WebMethod(exclude = true)
>     public String getPrefix()
>     {
>         return prefix;
>     }
>
>     @WebMethod(exclude = true)
>     public void setPrefix(String prefix)
>     {
>         this.prefix = prefix;
>     }
>
> }
>
> So essentially the problem is if you take out the "@WebMethod(exclude
> = true)" on the getter and setter, they're included in the generated
> WSDL as methods of the service :-/
>
> > Cheers,
> > - Dan
> >
> > On 7/18/07, Stuart Bingë <st...@complinet.com> wrote:
> > > Hello all,
> > >
> > > We've been using XFire (specifically its SOAP transport) together
> > > with JSR-181
> > > annotations for some time now in our internal Spring-based web
> > > services (hosted in Tomcat), and are now in the process of looking
> > > to upgrade to CXF
> > > as part of a general systems upgrade. The web services are
> > > "java-first", where we code to a SEI and then rely on XFire to
> > > generate the WSDL as appropriate. In addition, the SOAP binding
> > > used is RPC/Literal for interoperability with PHP clients.
> > >
> > > After following the "Writing a service with Spring" article on the
> > > CXF site
> > > (http://cwiki.apache.org/CXF20DOC/writing-a-service-with-spring.ht
> > >ml), as well as attempting the basic "HelloWorld" applet that the
> > > article describes
> > > (i.e. separate from our existing environment/services), I've
> > > discovered some
> > > strange behaviour that wasn't present with XFire.
> > >
> > > When exposing an endpoint via <jaxws:endpoint ... />, the
> > > generated WSDL appears to be coming from the implementation class
> > > rather than the service interface -- i.e. getters and setters for
> > > implementation-specific properties
> > > are included in the WSDL.
> >
> > Is this the expected behaviour with <jaxws:endpoint />? If so, what
> > other
> >
> > > methods are available/recommended for exposing an endpoint via an
> > > interface
> > > rather than an implementation object?
> >
> > This can be solved with @WebMethod(ignore = true) annotations on the
> >
> > > implementation class, but obviously this isn't ideal and shouldn't
> > > be needed
> > > in the first place. We'd like to continue just exposing the
> > > interface as the
> > > service contract and then be able to implement the service in
> > > whatever way we
> > > deem fit.
> > >
> > > Any pointers would be greatly appreciated!
> > >
> > > Cheers,
> > > --
> > > Stuart Bingë
> > >
> > > __________________________________________________________________
> > >____
> > >
> > > "Complinet Ltd is registered in England. Registered office at
> > > Vintners Place, 68 Upper Thames Street, London EC4V 3BJ. Company
> > > number 3170722. VAT No. 749 324 021.
> > > Complinet Inc is a corporation registered in Delaware, USA."
> > >
> > > This email has been scanned by the MessageLabs Email Security
> > > System.
>
> ______________________________________________________________________
>
> “Complinet Ltd is registered in England. Registered office at Vintners
> Place, 68 Upper Thames Street, London EC4V 3BJ. Company number
> 3170722. VAT No. 749 324 021. Complinet Inc is a corporation
> registered in Delaware, USA.”
>
> This email has been scanned by the MessageLabs Email Security System.

-- 
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727    C: 508-380-7194
daniel.kulp@iona.com
http://www.dankulp.com/blog

Re: JAX-WS/annotated SOAP services -- exporting implementation methods rather than interface ones?

Posted by Stuart Bingë <st...@complinet.com>.
Hi Dan,

On Wednesday 18 July 2007 23:10:46 Dan Diephouse wrote:
> Hi Stuart,
> Did you specify a @WebService(endpointInterface="...YourInterface") on the
> implementation class? You're using the JAX-WS frontend and per the JAX-WS
> spec, thats how its supposed to work :-)

Yeah, I've got my implementation class pointing to the interface via 
endpointInterface -- I pretty much copied and pasted the example from that 
page, then tried to add a property to the implementation class. Here's my 
current test code, if it helps:

Interface:
@WebService(name = "HelloWorld")
@SOAPBinding(style=Style.RPC, use=Use.LITERAL)
public interface HelloWorld {

    String sayHi(@WebParam(name = "text") String text);

}

Implementation:
@WebService(endpointInterface = "showcase.cxf.HelloWorld")
public class HelloWorldImpl implements HelloWorld {

    private String  prefix      = "*** unspecified ***";

    @Override
    public String sayHi(@WebParam(name = "text") String text)
    {
        return prefix + text;
    }

    @WebMethod(exclude = true)
    public String getPrefix()
    {
        return prefix;
    }

    @WebMethod(exclude = true)
    public void setPrefix(String prefix)
    {
        this.prefix = prefix;
    }

}

So essentially the problem is if you take out the "@WebMethod(exclude = true)" 
on the getter and setter, they're included in the generated WSDL as methods 
of the service :-/

>
> Cheers,
> - Dan
>
> On 7/18/07, Stuart Bingë <st...@complinet.com> wrote:
> > Hello all,
> >
> > We've been using XFire (specifically its SOAP transport) together with
> > JSR-181
> > annotations for some time now in our internal Spring-based web services
> > (hosted in Tomcat), and are now in the process of looking to upgrade to
> > CXF
> > as part of a general systems upgrade. The web services are "java-first",
> > where we code to a SEI and then rely on XFire to generate the WSDL as
> > appropriate. In addition, the SOAP binding used is RPC/Literal for
> > interoperability with PHP clients.
> >
> > After following the "Writing a service with Spring" article on the CXF
> > site
> > (http://cwiki.apache.org/CXF20DOC/writing-a-service-with-spring.html), as
> > well as attempting the basic "HelloWorld" applet that the article
> > describes
> > (i.e. separate from our existing environment/services), I've discovered
> > some
> > strange behaviour that wasn't present with XFire.
> >
> > When exposing an endpoint via <jaxws:endpoint ... />, the generated WSDL
> > appears to be coming from the implementation class rather than the
> > service interface -- i.e. getters and setters for implementation-specific
> > properties
> > are included in the WSDL.
>
> Is this the expected behaviour with <jaxws:endpoint />? If so, what other
>
> > methods are available/recommended for exposing an endpoint via an
> > interface
> > rather than an implementation object?
>
> This can be solved with @WebMethod(ignore = true) annotations on the
>
> > implementation class, but obviously this isn't ideal and shouldn't be
> > needed
> > in the first place. We'd like to continue just exposing the interface as
> > the
> > service contract and then be able to implement the service in whatever
> > way we
> > deem fit.
> >
> > Any pointers would be greatly appreciated!
> >
> > Cheers,
> > --
> > Stuart Bingë
> >
> > ______________________________________________________________________
> >
> > "Complinet Ltd is registered in England. Registered office at Vintners
> > Place, 68 Upper Thames Street, London EC4V 3BJ. Company number 3170722.
> > VAT No. 749 324 021.
> > Complinet Inc is a corporation registered in Delaware, USA."
> >
> > This email has been scanned by the MessageLabs Email Security System.

______________________________________________________________________

“Complinet Ltd is registered in England. Registered office at Vintners Place, 68 Upper Thames Street, London EC4V 3BJ. Company number 3170722. VAT No. 749 324 021.
Complinet Inc is a corporation registered in Delaware, USA.”

This email has been scanned by the MessageLabs Email Security System.

Re: JAX-WS/annotated SOAP services -- exporting implementation methods rather than interface ones?

Posted by Daniel Kulp <dk...@apache.org>.

Actually, I think there is a bug with using the methods on the impl 
instead of the interface.    I ran into something very similar today 
while writing a testcase for CXF-655.   I just didn't have time to 
investigate as CXF-655 was troublesome enough.     I'll dig into it more 
tomorrow.


Dan




On Wednesday 18 July 2007 18:10, Dan Diephouse wrote:
> Hi Stuart,
> Did you specify a @WebService(endpointInterface="...YourInterface") on
> the implementation class? You're using the JAX-WS frontend and per the
> JAX-WS spec, thats how its supposed to work :-)
>
> Cheers,
> - Dan
>
> On 7/18/07, Stuart Bingë <st...@complinet.com> wrote:
> > Hello all,
> >
> > We've been using XFire (specifically its SOAP transport) together
> > with JSR-181
> > annotations for some time now in our internal Spring-based web
> > services (hosted in Tomcat), and are now in the process of looking
> > to upgrade to CXF
> > as part of a general systems upgrade. The web services are
> > "java-first", where we code to a SEI and then rely on XFire to
> > generate the WSDL as appropriate. In addition, the SOAP binding used
> > is RPC/Literal for interoperability with PHP clients.
> >
> > After following the "Writing a service with Spring" article on the
> > CXF site
> > (http://cwiki.apache.org/CXF20DOC/writing-a-service-with-spring.html
> >), as well as attempting the basic "HelloWorld" applet that the
> > article describes
> > (i.e. separate from our existing environment/services), I've
> > discovered some
> > strange behaviour that wasn't present with XFire.
> >
> > When exposing an endpoint via <jaxws:endpoint ... />, the generated
> > WSDL appears to be coming from the implementation class rather than
> > the service interface -- i.e. getters and setters for
> > implementation-specific properties
> > are included in the WSDL.
>
> Is this the expected behaviour with <jaxws:endpoint />? If so, what
> other
>
> > methods are available/recommended for exposing an endpoint via an
> > interface
> > rather than an implementation object?
>
> This can be solved with @WebMethod(ignore = true) annotations on the
>
> > implementation class, but obviously this isn't ideal and shouldn't
> > be needed
> > in the first place. We'd like to continue just exposing the
> > interface as the
> > service contract and then be able to implement the service in
> > whatever way we
> > deem fit.
> >
> > Any pointers would be greatly appreciated!
> >
> > Cheers,
> > --
> > Stuart Bingë
> >
> > ____________________________________________________________________
> >__
> >
> > "Complinet Ltd is registered in England. Registered office at
> > Vintners Place, 68 Upper Thames Street, London EC4V 3BJ. Company
> > number 3170722. VAT No. 749 324 021.
> > Complinet Inc is a corporation registered in Delaware, USA."
> >
> > This email has been scanned by the MessageLabs Email Security
> > System.

-- 
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727    C: 508-380-7194
daniel.kulp@iona.com
http://www.dankulp.com/blog

Re: JAX-WS/annotated SOAP services -- exporting implementation methods rather than interface ones?

Posted by Dan Diephouse <da...@envoisolutions.com>.
Hi Stuart,
Did you specify a @WebService(endpointInterface="...YourInterface") on the
implementation class? You're using the JAX-WS frontend and per the JAX-WS
spec, thats how its supposed to work :-)

Cheers,
- Dan

On 7/18/07, Stuart Bingë <st...@complinet.com> wrote:
>
> Hello all,
>
> We've been using XFire (specifically its SOAP transport) together with
> JSR-181
> annotations for some time now in our internal Spring-based web services
> (hosted in Tomcat), and are now in the process of looking to upgrade to
> CXF
> as part of a general systems upgrade. The web services are "java-first",
> where we code to a SEI and then rely on XFire to generate the WSDL as
> appropriate. In addition, the SOAP binding used is RPC/Literal for
> interoperability with PHP clients.
>
> After following the "Writing a service with Spring" article on the CXF
> site
> (http://cwiki.apache.org/CXF20DOC/writing-a-service-with-spring.html), as
> well as attempting the basic "HelloWorld" applet that the article
> describes
> (i.e. separate from our existing environment/services), I've discovered
> some
> strange behaviour that wasn't present with XFire.
>
> When exposing an endpoint via <jaxws:endpoint ... />, the generated WSDL
> appears to be coming from the implementation class rather than the service
> interface -- i.e. getters and setters for implementation-specific
> properties
> are included in the WSDL.




Is this the expected behaviour with <jaxws:endpoint />? If so, what other
> methods are available/recommended for exposing an endpoint via an
> interface
> rather than an implementation object?


This can be solved with @WebMethod(ignore = true) annotations on the
> implementation class, but obviously this isn't ideal and shouldn't be
> needed
> in the first place. We'd like to continue just exposing the interface as
> the
> service contract and then be able to implement the service in whatever way
> we
> deem fit.
>
> Any pointers would be greatly appreciated!
>
> Cheers,
> --
> Stuart Bingë
>
> ______________________________________________________________________
>
> "Complinet Ltd is registered in England. Registered office at Vintners
> Place, 68 Upper Thames Street, London EC4V 3BJ. Company number 3170722. VAT
> No. 749 324 021.
> Complinet Inc is a corporation registered in Delaware, USA."
>
> This email has been scanned by the MessageLabs Email Security System.
>



-- 
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog