You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by David Savage <da...@paremus.com> on 2008/06/27 18:02:13 UTC
cxf in an OSGi environment
Hi there,
I'm trying to get cxf to work in an OSGi environment and have been
banging my head against the desk a bit, suspect it might be due to
leaping in at the deep end but any help would be appreciated.
Ok here's what I've got working:
JaxWsServerFactoryBean svrFactory = new JaxWsServerFactoryBean();
svrFactory.setServiceClass(HelloWorld.class);
svrFactory.setServiceBean(HelloWorldImpl());
svrFactory.setAddress("http://localhost:9000/hello" );
svrFactory.create();
This launches an internal jetty server and when I test this using a web
browser I can at least see that the server is running as I get a soap
response:
<soap:Envelope>
<soap:Body>
<soap:Fault>
<faultcode>soap:Server</faultcode>
<faultstring>No such operation: </faultstring>
</soap:Fault>
</soap:Body>
</soap:Envelope>
However I've not been able to get a client working in OSGi. Initially
this was due to code in the
org.apache.cxf.frontend.ClientProxyFactoryBean which assumed the
classloader to generate the proxy would be the loader of the client
interface. I've worked around that in a local patch here by setting
Thread.contextClassLoader.
Here's what I have on the client side:
JaxWsProxyFactoryBean factory = new JaxWsProxyFactoryBean();
factory.setServiceClass(reference.getInterface());
factory.setAddress("http://localhost:9000/hello");
// set context classloader
...
HelloWorld proxy = factory.create();
proxy.sayHello("World");
However the client still fails due to a null BindingDetails object which
is loaded when my test method is invoked:
javax.xml.ws.WebServiceException: Could not find wsdl:binding
operation info for web method sayHello.
at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:150)
at $Proxy35.sayHello(Unknown Source)
Is there a stage I'm missing here?
I'm also trying to get cxf to work with an https connection (both client
and server). On the server side I've figured out that the process has
something to do with doing something like:
server = svrFactory.create();
JettyHTTPDestination dest = (JettyHTTPDestination) server.getDestination();
JettyHTTPServerEngine engine = (JettyHTTPServerEngine) dest.getEngine();
if ( secure ) {
TLSServerParameters params = new TLSServerParameters();
// set params
engine.setTlsServerParameters(params);
}
But again I'm not having much luck. Is there any example code I can
follow or that someone can post to show how this should work?
Thanks in advance for any help.
Regards,
Dave
_______________________________________________________________________
Paremus Limited. Registered in England
No. 4181472
Registered Office: 22-24 Broad Street, Wokingham, Berks RG40 1BA
Postal Address: 107-111 Fleet Street, London, EC4A 2AB
The information transmitted is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited.
If you received this in error, please contact the sender and delete the material from any computer.
_______________________________________________________________________
Re: cxf in an OSGi environment
Posted by Benson Margulies <bi...@gmail.com>.
Thanks. I was really astounded to discover how hard it was to find a sort of
'hello world' sample of a Java main program that would bootstrap the OSGi
environment, load some bundles, and get started.
On Sat, Jul 5, 2008 at 7:09 AM, David Savage <da...@paremus.com>
wrote:
> Hi Benson,
>
> We're using equinox and knopflerfish at the moment - we're currently
> resolving a couple of minor issues to get working on felix. Turns out
> there a couple of differences with the way felix handles locking in
> the base level osgi log service implementation compared to equinox and
> knopflerfish. Probably wouldn't effect most end users but we're trying
> to do some funky stuff as a platform and it's causing us some
> headaches.
>
> Anyway that's all an aside. The bundle fragment system is part of the
> OSGi specification so should be supported by all OSGi containers not
> just equinox - certainly it works in knopflerfish but I've not yet
> tried felix.
>
> A word of warning, bundle fragments can initially seem very useful but
> often get very messy in the long term. It may well be posting
> questions on this to the osgi-dev list as I'm sure you'll get some
> very good feedback as to whether your use case warrants the hassle
> fragments can cause :)
>
> Regards,
>
> Dave
>
> 2008/7/5 Benson Margulies <bi...@gmail.com>:
> > Could I ask a question in return about OSGi?
> >
> > Are you using Felix or Equinox? Do you happen to know if the Eclipse
> native
> > code bundle fragment system is a generic OSGi feature or specific to
> > Eclipse?
> >
> >
> > On Fri, Jul 4, 2008 at 7:24 AM, David Savage <da...@paremus.com>
> > wrote:
> >>
> >> Hi Daniel,
> >>
> >> This was with CXF 2.1.1 I'm actually working on getting CXF working
> >> within infiniflow (based on newton - http://newton.codecauldron.org)
> >> as a provider of a web services binding.
> >>
> >> I've now managed to get the JaxWsProxyFactoryBean working now though
> >> it still needs the patch I mentioned to
> >> org.apache.cxf.frontend.ClientProxyFactoryBean - diff file attached.
> >> In this usecase the CXF libraries are packaged in one bundle but the
> >> "client" code i.e. the code that asks for the proxy to be created is
> >> packaged in a separate bundle. The CXF code is then linked to the
> >> client through the SCA of a binding.
> >>
> >> This allows multiple client bundles to reuse CXF without having to
> >> embed it in the client bundle (or for that matter even know that CXF
> >> is involved - they just ask for an SCA <binding.ws /> which happens to
> >> be implemented by CXF). However this means that the client bundle does
> >> not have the CXF libraries in it's bundle classpath - hence the need
> >> to do some classloader juggling via the Thread.contextClassLoader.
> >>
> >> In general I'm not a big fan of using Thread.contextClassLoader as
> >> it's a little ambiguous - prefer an explicit declaration of the
> >> classloader to be used but this would have been a much larger change
> >> to the CXF code which I didn't want to attempt without the aid of a
> >> safety net :)
> >>
> >> The "javax.xml.ws.WebServiceException: Could not find wsdl:binding
> >> operation info..." issue turned out to be with the way I was using the
> >> interface/impl - the combination that worked in the end was to
> >> explicitly add the @WebService etc annotations to the class/interface
> >> etc, like so:
> >>
> >> package com.paremus.infiniflow.example.cxf;
> >>
> >> import javax.jws.WebParam;
> >> import javax.jws.WebService;
> >>
> >> @WebService
> >> public interface HelloWorld {
> >> String sayHello(@WebParam(name="text") String name);
> >> }
> >>
> >> -------------------------------------------------------------
> >>
> >> package com.paremus.infiniflow.example.cxf;
> >>
> >> import javax.jws.WebService;
> >>
> >> @WebService(endpointInterface =
> >> "com.paremus.infiniflow.example.cxf.HelloWorld",
> >> serviceName = "HelloWorld")
> >>
> >> public class HelloWorldImpl implements HelloWorld {
> >> public String sayHello(String name) {
> >> return "Hello " + name;
> >> }
> >> }
> >>
> >> I didn't get around to exploring what the minimum set of annotations
> >> was to get this working. Incidentally is there a case for CXF
> >> automagically inferring webservice info from interfaces that are this
> >> trivial? It seems a little verbose in this case to have to annotate a
> >> single method interface/impl. Though I appreciate this is not the
> >> general use case...
> >>
> >> I'm still having some problems with https but not sure this is OSGi
> >> related so possibly best to follow up in a separate email thread if
> >> necessary. I currently suspect issue is with my certificate chain as
> >> get a message
> >>
> >> 2008-07-03 13:23:25.023::WARN: EXCEPTION
> >> javax.net.ssl.SSLHandshakeException: Received fatal alert:
> >> certificate_unknown
> >> at
> >> com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:150)
> >>
> >> When the JaxWsProxy tries to invoke the method call on the client.
> >>
> >> Regards,
> >>
> >> Dave
> >>
> >> 2008/7/1 Daniel Kulp <dk...@apache.org>:
> >> >
> >> > Have you tried this with CXF 2.1.1 or 2.1 or other?
> >> >
> >> > We did some work in 2.1.1 to hopefully help some of the issues, but
> I'm
> >> > not really sure about this specific issue.
> >> >
> >> >
> >> > In general, we kind of recommend using the spring dynamic modules for
> >> > OSGi. The servicemix 4 folks have an example at:
> >> >
> http://servicemix.apache.org/SMX4/cxf-examples.html#CXFexamples-Inside
> >> > that shows how that works. When you do that, all the spring config
> >> > things should work.
> >> >
> >> > Dan
> >> >
> >> > On Jun 27, 2008, at 12:02 PM, David Savage wrote:
> >> >
> >> >> Hi there,
> >> >>
> >> >> I'm trying to get cxf to work in an OSGi environment and have been
> >> >> banging my head against the desk a bit, suspect it might be due to
> leaping
> >> >> in at the deep end but any help would be appreciated.
> >> >>
> >> >> Ok here's what I've got working:
> >> >>
> >> >> JaxWsServerFactoryBean svrFactory = new JaxWsServerFactoryBean();
> >> >> svrFactory.setServiceClass(HelloWorld.class);
> >> >> svrFactory.setServiceBean(HelloWorldImpl());
> >> >> svrFactory.setAddress("http://localhost:9000/hello" );
> >> >> svrFactory.create();
> >> >>
> >> >> This launches an internal jetty server and when I test this using a
> web
> >> >> browser I can at least see that the server is running as I get a soap
> >> >> response:
> >> >>
> >> >> <soap:Envelope>
> >> >> <soap:Body>
> >> >> <soap:Fault>
> >> >> <faultcode>soap:Server</faultcode>
> >> >> <faultstring>No such operation: </faultstring>
> >> >> </soap:Fault>
> >> >> </soap:Body>
> >> >> </soap:Envelope>
> >> >>
> >> >> However I've not been able to get a client working in OSGi. Initially
> >> >> this was due to code in the
> org.apache.cxf.frontend.ClientProxyFactoryBean
> >> >> which assumed the classloader to generate the proxy would be the
> loader of
> >> >> the client interface. I've worked around that in a local patch here
> by
> >> >> setting Thread.contextClassLoader.
> >> >>
> >> >> Here's what I have on the client side:
> >> >>
> >> >> JaxWsProxyFactoryBean factory = new JaxWsProxyFactoryBean();
> >> >> factory.setServiceClass(reference.getInterface());
> >> >> factory.setAddress("http://localhost:9000/hello");
> >> >> // set context classloader
> >> >> ...
> >> >> HelloWorld proxy = factory.create();
> >> >> proxy.sayHello("World");
> >> >>
> >> >>
> >> >> However the client still fails due to a null BindingDetails object
> >> >> which is loaded when my test method is invoked:
> >> >>
> >> >> javax.xml.ws.WebServiceException: Could not find wsdl:binding
> operation
> >> >> info for web method sayHello.
> >> >> at
> >> >>
> org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:150)
> >> >> at $Proxy35.sayHello(Unknown Source)
> >> >>
> >> >> Is there a stage I'm missing here?
> >> >>
> >> >> I'm also trying to get cxf to work with an https connection (both
> >> >> client and server). On the server side I've figured out that the
> process has
> >> >> something to do with doing something like:
> >> >>
> >> >> server = svrFactory.create();
> >> >>
> >> >> JettyHTTPDestination dest = (JettyHTTPDestination)
> >> >> server.getDestination();
> >> >> JettyHTTPServerEngine engine = (JettyHTTPServerEngine)
> >> >> dest.getEngine();
> >> >>
> >> >> if ( secure ) {
> >> >> TLSServerParameters params = new TLSServerParameters();
> >> >> // set params
> >> >> engine.setTlsServerParameters(params);
> >> >> }
> >> >>
> >> >> But again I'm not having much luck. Is there any example code I can
> >> >> follow or that someone can post to show how this should work?
> >> >>
> >> >> Thanks in advance for any help.
> >> >>
> >> >> Regards,
> >> >>
> >> >> Dave
> >> >>
> >> >>
> _______________________________________________________________________
> >> >> Paremus Limited. Registered in England
> >> >> No. 4181472
> >> >> Registered Office: 22-24 Broad Street, Wokingham, Berks RG40 1BA
> >> >> Postal Address: 107-111 Fleet Street, London, EC4A 2AB
> >> >> The information transmitted is intended only for the person(s) or
> >> >> entity to which it is addressed and may contain confidential and/or
> >> >> privileged material. Any review, retransmission, dissemination or
> other use
> >> >> of, or taking of any action in reliance upon, this information by
> persons or
> >> >> entities other than the intended recipient is prohibited.
> >> >> If you received this in error, please contact the sender and delete
> the
> >> >> material from any computer.
> >> >>
> _______________________________________________________________________
> >> >
> >> > ---
> >> > Daniel Kulp
> >> > dkulp@apache.org
> >> > http://www.dankulp.com/blog
> >> >
> >> >
> >> >
> >> >
> >
> >
>
Re: cxf in an OSGi environment
Posted by David Savage <da...@paremus.com>.
Hi Benson,
We're using equinox and knopflerfish at the moment - we're currently
resolving a couple of minor issues to get working on felix. Turns out
there a couple of differences with the way felix handles locking in
the base level osgi log service implementation compared to equinox and
knopflerfish. Probably wouldn't effect most end users but we're trying
to do some funky stuff as a platform and it's causing us some
headaches.
Anyway that's all an aside. The bundle fragment system is part of the
OSGi specification so should be supported by all OSGi containers not
just equinox - certainly it works in knopflerfish but I've not yet
tried felix.
A word of warning, bundle fragments can initially seem very useful but
often get very messy in the long term. It may well be posting
questions on this to the osgi-dev list as I'm sure you'll get some
very good feedback as to whether your use case warrants the hassle
fragments can cause :)
Regards,
Dave
2008/7/5 Benson Margulies <bi...@gmail.com>:
> Could I ask a question in return about OSGi?
>
> Are you using Felix or Equinox? Do you happen to know if the Eclipse native
> code bundle fragment system is a generic OSGi feature or specific to
> Eclipse?
>
>
> On Fri, Jul 4, 2008 at 7:24 AM, David Savage <da...@paremus.com>
> wrote:
>>
>> Hi Daniel,
>>
>> This was with CXF 2.1.1 I'm actually working on getting CXF working
>> within infiniflow (based on newton - http://newton.codecauldron.org)
>> as a provider of a web services binding.
>>
>> I've now managed to get the JaxWsProxyFactoryBean working now though
>> it still needs the patch I mentioned to
>> org.apache.cxf.frontend.ClientProxyFactoryBean - diff file attached.
>> In this usecase the CXF libraries are packaged in one bundle but the
>> "client" code i.e. the code that asks for the proxy to be created is
>> packaged in a separate bundle. The CXF code is then linked to the
>> client through the SCA of a binding.
>>
>> This allows multiple client bundles to reuse CXF without having to
>> embed it in the client bundle (or for that matter even know that CXF
>> is involved - they just ask for an SCA <binding.ws /> which happens to
>> be implemented by CXF). However this means that the client bundle does
>> not have the CXF libraries in it's bundle classpath - hence the need
>> to do some classloader juggling via the Thread.contextClassLoader.
>>
>> In general I'm not a big fan of using Thread.contextClassLoader as
>> it's a little ambiguous - prefer an explicit declaration of the
>> classloader to be used but this would have been a much larger change
>> to the CXF code which I didn't want to attempt without the aid of a
>> safety net :)
>>
>> The "javax.xml.ws.WebServiceException: Could not find wsdl:binding
>> operation info..." issue turned out to be with the way I was using the
>> interface/impl - the combination that worked in the end was to
>> explicitly add the @WebService etc annotations to the class/interface
>> etc, like so:
>>
>> package com.paremus.infiniflow.example.cxf;
>>
>> import javax.jws.WebParam;
>> import javax.jws.WebService;
>>
>> @WebService
>> public interface HelloWorld {
>> String sayHello(@WebParam(name="text") String name);
>> }
>>
>> -------------------------------------------------------------
>>
>> package com.paremus.infiniflow.example.cxf;
>>
>> import javax.jws.WebService;
>>
>> @WebService(endpointInterface =
>> "com.paremus.infiniflow.example.cxf.HelloWorld",
>> serviceName = "HelloWorld")
>>
>> public class HelloWorldImpl implements HelloWorld {
>> public String sayHello(String name) {
>> return "Hello " + name;
>> }
>> }
>>
>> I didn't get around to exploring what the minimum set of annotations
>> was to get this working. Incidentally is there a case for CXF
>> automagically inferring webservice info from interfaces that are this
>> trivial? It seems a little verbose in this case to have to annotate a
>> single method interface/impl. Though I appreciate this is not the
>> general use case...
>>
>> I'm still having some problems with https but not sure this is OSGi
>> related so possibly best to follow up in a separate email thread if
>> necessary. I currently suspect issue is with my certificate chain as
>> get a message
>>
>> 2008-07-03 13:23:25.023::WARN: EXCEPTION
>> javax.net.ssl.SSLHandshakeException: Received fatal alert:
>> certificate_unknown
>> at
>> com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:150)
>>
>> When the JaxWsProxy tries to invoke the method call on the client.
>>
>> Regards,
>>
>> Dave
>>
>> 2008/7/1 Daniel Kulp <dk...@apache.org>:
>> >
>> > Have you tried this with CXF 2.1.1 or 2.1 or other?
>> >
>> > We did some work in 2.1.1 to hopefully help some of the issues, but I'm
>> > not really sure about this specific issue.
>> >
>> >
>> > In general, we kind of recommend using the spring dynamic modules for
>> > OSGi. The servicemix 4 folks have an example at:
>> > http://servicemix.apache.org/SMX4/cxf-examples.html#CXFexamples-Inside
>> > that shows how that works. When you do that, all the spring config
>> > things should work.
>> >
>> > Dan
>> >
>> > On Jun 27, 2008, at 12:02 PM, David Savage wrote:
>> >
>> >> Hi there,
>> >>
>> >> I'm trying to get cxf to work in an OSGi environment and have been
>> >> banging my head against the desk a bit, suspect it might be due to leaping
>> >> in at the deep end but any help would be appreciated.
>> >>
>> >> Ok here's what I've got working:
>> >>
>> >> JaxWsServerFactoryBean svrFactory = new JaxWsServerFactoryBean();
>> >> svrFactory.setServiceClass(HelloWorld.class);
>> >> svrFactory.setServiceBean(HelloWorldImpl());
>> >> svrFactory.setAddress("http://localhost:9000/hello" );
>> >> svrFactory.create();
>> >>
>> >> This launches an internal jetty server and when I test this using a web
>> >> browser I can at least see that the server is running as I get a soap
>> >> response:
>> >>
>> >> <soap:Envelope>
>> >> <soap:Body>
>> >> <soap:Fault>
>> >> <faultcode>soap:Server</faultcode>
>> >> <faultstring>No such operation: </faultstring>
>> >> </soap:Fault>
>> >> </soap:Body>
>> >> </soap:Envelope>
>> >>
>> >> However I've not been able to get a client working in OSGi. Initially
>> >> this was due to code in the org.apache.cxf.frontend.ClientProxyFactoryBean
>> >> which assumed the classloader to generate the proxy would be the loader of
>> >> the client interface. I've worked around that in a local patch here by
>> >> setting Thread.contextClassLoader.
>> >>
>> >> Here's what I have on the client side:
>> >>
>> >> JaxWsProxyFactoryBean factory = new JaxWsProxyFactoryBean();
>> >> factory.setServiceClass(reference.getInterface());
>> >> factory.setAddress("http://localhost:9000/hello");
>> >> // set context classloader
>> >> ...
>> >> HelloWorld proxy = factory.create();
>> >> proxy.sayHello("World");
>> >>
>> >>
>> >> However the client still fails due to a null BindingDetails object
>> >> which is loaded when my test method is invoked:
>> >>
>> >> javax.xml.ws.WebServiceException: Could not find wsdl:binding operation
>> >> info for web method sayHello.
>> >> at
>> >> org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:150)
>> >> at $Proxy35.sayHello(Unknown Source)
>> >>
>> >> Is there a stage I'm missing here?
>> >>
>> >> I'm also trying to get cxf to work with an https connection (both
>> >> client and server). On the server side I've figured out that the process has
>> >> something to do with doing something like:
>> >>
>> >> server = svrFactory.create();
>> >>
>> >> JettyHTTPDestination dest = (JettyHTTPDestination)
>> >> server.getDestination();
>> >> JettyHTTPServerEngine engine = (JettyHTTPServerEngine)
>> >> dest.getEngine();
>> >>
>> >> if ( secure ) {
>> >> TLSServerParameters params = new TLSServerParameters();
>> >> // set params
>> >> engine.setTlsServerParameters(params);
>> >> }
>> >>
>> >> But again I'm not having much luck. Is there any example code I can
>> >> follow or that someone can post to show how this should work?
>> >>
>> >> Thanks in advance for any help.
>> >>
>> >> Regards,
>> >>
>> >> Dave
>> >>
>> >> _______________________________________________________________________
>> >> Paremus Limited. Registered in England
>> >> No. 4181472
>> >> Registered Office: 22-24 Broad Street, Wokingham, Berks RG40 1BA
>> >> Postal Address: 107-111 Fleet Street, London, EC4A 2AB
>> >> The information transmitted is intended only for the person(s) or
>> >> entity to which it is addressed and may contain confidential and/or
>> >> privileged material. Any review, retransmission, dissemination or other use
>> >> of, or taking of any action in reliance upon, this information by persons or
>> >> entities other than the intended recipient is prohibited.
>> >> If you received this in error, please contact the sender and delete the
>> >> material from any computer.
>> >> _______________________________________________________________________
>> >
>> > ---
>> > Daniel Kulp
>> > dkulp@apache.org
>> > http://www.dankulp.com/blog
>> >
>> >
>> >
>> >
>
>
Re: cxf in an OSGi environment
Posted by Benson Margulies <bi...@gmail.com>.
Could I ask a question in return about OSGi?
Are you using Felix or Equinox? Do you happen to know if the Eclipse native
code bundle fragment system is a generic OSGi feature or specific to
Eclipse?
On Fri, Jul 4, 2008 at 7:24 AM, David Savage <da...@paremus.com>
wrote:
> Hi Daniel,
>
> This was with CXF 2.1.1 I'm actually working on getting CXF working
> within infiniflow (based on newton - http://newton.codecauldron.org)
> as a provider of a web services binding.
>
> I've now managed to get the JaxWsProxyFactoryBean working now though
> it still needs the patch I mentioned to
> org.apache.cxf.frontend.ClientProxyFactoryBean - diff file attached.
> In this usecase the CXF libraries are packaged in one bundle but the
> "client" code i.e. the code that asks for the proxy to be created is
> packaged in a separate bundle. The CXF code is then linked to the
> client through the SCA of a binding.
>
> This allows multiple client bundles to reuse CXF without having to
> embed it in the client bundle (or for that matter even know that CXF
> is involved - they just ask for an SCA <binding.ws /> which happens to
> be implemented by CXF). However this means that the client bundle does
> not have the CXF libraries in it's bundle classpath - hence the need
> to do some classloader juggling via the Thread.contextClassLoader.
>
> In general I'm not a big fan of using Thread.contextClassLoader as
> it's a little ambiguous - prefer an explicit declaration of the
> classloader to be used but this would have been a much larger change
> to the CXF code which I didn't want to attempt without the aid of a
> safety net :)
>
> The "javax.xml.ws.WebServiceException: Could not find wsdl:binding
> operation info..." issue turned out to be with the way I was using the
> interface/impl - the combination that worked in the end was to
> explicitly add the @WebService etc annotations to the class/interface
> etc, like so:
>
> package com.paremus.infiniflow.example.cxf;
>
> import javax.jws.WebParam;
> import javax.jws.WebService;
>
> @WebService
> public interface HelloWorld {
> String sayHello(@WebParam(name="text") String name);
> }
>
> -------------------------------------------------------------
>
> package com.paremus.infiniflow.example.cxf;
>
> import javax.jws.WebService;
>
> @WebService(endpointInterface =
> "com.paremus.infiniflow.example.cxf.HelloWorld",
> serviceName = "HelloWorld")
>
> public class HelloWorldImpl implements HelloWorld {
> public String sayHello(String name) {
> return "Hello " + name;
> }
> }
>
> I didn't get around to exploring what the minimum set of annotations
> was to get this working. Incidentally is there a case for CXF
> automagically inferring webservice info from interfaces that are this
> trivial? It seems a little verbose in this case to have to annotate a
> single method interface/impl. Though I appreciate this is not the
> general use case...
>
> I'm still having some problems with https but not sure this is OSGi
> related so possibly best to follow up in a separate email thread if
> necessary. I currently suspect issue is with my certificate chain as
> get a message
>
> 2008-07-03 13:23:25.023::WARN: EXCEPTION
> javax.net.ssl.SSLHandshakeException: Received fatal alert:
> certificate_unknown
> at
> com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:150)
>
> When the JaxWsProxy tries to invoke the method call on the client.
>
> Regards,
>
> Dave
>
> 2008/7/1 Daniel Kulp <dk...@apache.org>:
> >
> > Have you tried this with CXF 2.1.1 or 2.1 or other?
> >
> > We did some work in 2.1.1 to hopefully help some of the issues, but I'm
> not really sure about this specific issue.
> >
> >
> > In general, we kind of recommend using the spring dynamic modules for
> OSGi. The servicemix 4 folks have an example at:
> > http://servicemix.apache.org/SMX4/cxf-examples.html#CXFexamples-Inside
> > that shows how that works. When you do that, all the spring config
> things should work.
> >
> > Dan
> >
> > On Jun 27, 2008, at 12:02 PM, David Savage wrote:
> >
> >> Hi there,
> >>
> >> I'm trying to get cxf to work in an OSGi environment and have been
> banging my head against the desk a bit, suspect it might be due to leaping
> in at the deep end but any help would be appreciated.
> >>
> >> Ok here's what I've got working:
> >>
> >> JaxWsServerFactoryBean svrFactory = new JaxWsServerFactoryBean();
> >> svrFactory.setServiceClass(HelloWorld.class);
> >> svrFactory.setServiceBean(HelloWorldImpl());
> >> svrFactory.setAddress("http://localhost:9000/hello" );
> >> svrFactory.create();
> >>
> >> This launches an internal jetty server and when I test this using a web
> browser I can at least see that the server is running as I get a soap
> response:
> >>
> >> <soap:Envelope>
> >> <soap:Body>
> >> <soap:Fault>
> >> <faultcode>soap:Server</faultcode>
> >> <faultstring>No such operation: </faultstring>
> >> </soap:Fault>
> >> </soap:Body>
> >> </soap:Envelope>
> >>
> >> However I've not been able to get a client working in OSGi. Initially
> this was due to code in the org.apache.cxf.frontend.ClientProxyFactoryBean
> which assumed the classloader to generate the proxy would be the loader of
> the client interface. I've worked around that in a local patch here by
> setting Thread.contextClassLoader.
> >>
> >> Here's what I have on the client side:
> >>
> >> JaxWsProxyFactoryBean factory = new JaxWsProxyFactoryBean();
> >> factory.setServiceClass(reference.getInterface());
> >> factory.setAddress("http://localhost:9000/hello");
> >> // set context classloader
> >> ...
> >> HelloWorld proxy = factory.create();
> >> proxy.sayHello("World");
> >>
> >>
> >> However the client still fails due to a null BindingDetails object which
> is loaded when my test method is invoked:
> >>
> >> javax.xml.ws.WebServiceException: Could not find wsdl:binding operation
> info for web method sayHello.
> >> at
> org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:150)
> >> at $Proxy35.sayHello(Unknown Source)
> >>
> >> Is there a stage I'm missing here?
> >>
> >> I'm also trying to get cxf to work with an https connection (both client
> and server). On the server side I've figured out that the process has
> something to do with doing something like:
> >>
> >> server = svrFactory.create();
> >>
> >> JettyHTTPDestination dest = (JettyHTTPDestination)
> server.getDestination();
> >> JettyHTTPServerEngine engine = (JettyHTTPServerEngine) dest.getEngine();
> >>
> >> if ( secure ) {
> >> TLSServerParameters params = new TLSServerParameters();
> >> // set params
> >> engine.setTlsServerParameters(params);
> >> }
> >>
> >> But again I'm not having much luck. Is there any example code I can
> follow or that someone can post to show how this should work?
> >>
> >> Thanks in advance for any help.
> >>
> >> Regards,
> >>
> >> Dave
> >>
> >> _______________________________________________________________________
> >> Paremus Limited. Registered in England
> >> No. 4181472
> >> Registered Office: 22-24 Broad Street, Wokingham, Berks RG40 1BA
> >> Postal Address: 107-111 Fleet Street, London, EC4A 2AB
> >> The information transmitted is intended only for the person(s) or entity
> to which it is addressed and may contain confidential and/or privileged
> material. Any review, retransmission, dissemination or other use of, or
> taking of any action in reliance upon, this information by persons or
> entities other than the intended recipient is prohibited.
> >> If you received this in error, please contact the sender and delete the
> material from any computer.
> >> _______________________________________________________________________
> >
> > ---
> > Daniel Kulp
> > dkulp@apache.org
> > http://www.dankulp.com/blog
> >
> >
> >
> >
>
Re: cxf in an OSGi environment
Posted by David Savage <da...@paremus.com>.
Hi Daniel,
This was with CXF 2.1.1 I'm actually working on getting CXF working
within infiniflow (based on newton - http://newton.codecauldron.org)
as a provider of a web services binding.
I've now managed to get the JaxWsProxyFactoryBean working now though
it still needs the patch I mentioned to
org.apache.cxf.frontend.ClientProxyFactoryBean - diff file attached.
In this usecase the CXF libraries are packaged in one bundle but the
"client" code i.e. the code that asks for the proxy to be created is
packaged in a separate bundle. The CXF code is then linked to the
client through the SCA of a binding.
This allows multiple client bundles to reuse CXF without having to
embed it in the client bundle (or for that matter even know that CXF
is involved - they just ask for an SCA <binding.ws /> which happens to
be implemented by CXF). However this means that the client bundle does
not have the CXF libraries in it's bundle classpath - hence the need
to do some classloader juggling via the Thread.contextClassLoader.
In general I'm not a big fan of using Thread.contextClassLoader as
it's a little ambiguous - prefer an explicit declaration of the
classloader to be used but this would have been a much larger change
to the CXF code which I didn't want to attempt without the aid of a
safety net :)
The "javax.xml.ws.WebServiceException: Could not find wsdl:binding
operation info..." issue turned out to be with the way I was using the
interface/impl - the combination that worked in the end was to
explicitly add the @WebService etc annotations to the class/interface
etc, like so:
package com.paremus.infiniflow.example.cxf;
import javax.jws.WebParam;
import javax.jws.WebService;
@WebService
public interface HelloWorld {
String sayHello(@WebParam(name="text") String name);
}
-------------------------------------------------------------
package com.paremus.infiniflow.example.cxf;
import javax.jws.WebService;
@WebService(endpointInterface = "com.paremus.infiniflow.example.cxf.HelloWorld",
serviceName = "HelloWorld")
public class HelloWorldImpl implements HelloWorld {
public String sayHello(String name) {
return "Hello " + name;
}
}
I didn't get around to exploring what the minimum set of annotations
was to get this working. Incidentally is there a case for CXF
automagically inferring webservice info from interfaces that are this
trivial? It seems a little verbose in this case to have to annotate a
single method interface/impl. Though I appreciate this is not the
general use case...
I'm still having some problems with https but not sure this is OSGi
related so possibly best to follow up in a separate email thread if
necessary. I currently suspect issue is with my certificate chain as
get a message
2008-07-03 13:23:25.023::WARN: EXCEPTION
javax.net.ssl.SSLHandshakeException: Received fatal alert: certificate_unknown
at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:150)
When the JaxWsProxy tries to invoke the method call on the client.
Regards,
Dave
2008/7/1 Daniel Kulp <dk...@apache.org>:
>
> Have you tried this with CXF 2.1.1 or 2.1 or other?
>
> We did some work in 2.1.1 to hopefully help some of the issues, but I'm not really sure about this specific issue.
>
>
> In general, we kind of recommend using the spring dynamic modules for OSGi. The servicemix 4 folks have an example at:
> http://servicemix.apache.org/SMX4/cxf-examples.html#CXFexamples-Inside
> that shows how that works. When you do that, all the spring config things should work.
>
> Dan
>
> On Jun 27, 2008, at 12:02 PM, David Savage wrote:
>
>> Hi there,
>>
>> I'm trying to get cxf to work in an OSGi environment and have been banging my head against the desk a bit, suspect it might be due to leaping in at the deep end but any help would be appreciated.
>>
>> Ok here's what I've got working:
>>
>> JaxWsServerFactoryBean svrFactory = new JaxWsServerFactoryBean();
>> svrFactory.setServiceClass(HelloWorld.class);
>> svrFactory.setServiceBean(HelloWorldImpl());
>> svrFactory.setAddress("http://localhost:9000/hello" );
>> svrFactory.create();
>>
>> This launches an internal jetty server and when I test this using a web browser I can at least see that the server is running as I get a soap response:
>>
>> <soap:Envelope>
>> <soap:Body>
>> <soap:Fault>
>> <faultcode>soap:Server</faultcode>
>> <faultstring>No such operation: </faultstring>
>> </soap:Fault>
>> </soap:Body>
>> </soap:Envelope>
>>
>> However I've not been able to get a client working in OSGi. Initially this was due to code in the org.apache.cxf.frontend.ClientProxyFactoryBean which assumed the classloader to generate the proxy would be the loader of the client interface. I've worked around that in a local patch here by setting Thread.contextClassLoader.
>>
>> Here's what I have on the client side:
>>
>> JaxWsProxyFactoryBean factory = new JaxWsProxyFactoryBean();
>> factory.setServiceClass(reference.getInterface());
>> factory.setAddress("http://localhost:9000/hello");
>> // set context classloader
>> ...
>> HelloWorld proxy = factory.create();
>> proxy.sayHello("World");
>>
>>
>> However the client still fails due to a null BindingDetails object which is loaded when my test method is invoked:
>>
>> javax.xml.ws.WebServiceException: Could not find wsdl:binding operation info for web method sayHello.
>> at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:150)
>> at $Proxy35.sayHello(Unknown Source)
>>
>> Is there a stage I'm missing here?
>>
>> I'm also trying to get cxf to work with an https connection (both client and server). On the server side I've figured out that the process has something to do with doing something like:
>>
>> server = svrFactory.create();
>>
>> JettyHTTPDestination dest = (JettyHTTPDestination) server.getDestination();
>> JettyHTTPServerEngine engine = (JettyHTTPServerEngine) dest.getEngine();
>>
>> if ( secure ) {
>> TLSServerParameters params = new TLSServerParameters();
>> // set params
>> engine.setTlsServerParameters(params);
>> }
>>
>> But again I'm not having much luck. Is there any example code I can follow or that someone can post to show how this should work?
>>
>> Thanks in advance for any help.
>>
>> Regards,
>>
>> Dave
>>
>> _______________________________________________________________________
>> Paremus Limited. Registered in England
>> No. 4181472
>> Registered Office: 22-24 Broad Street, Wokingham, Berks RG40 1BA
>> Postal Address: 107-111 Fleet Street, London, EC4A 2AB
>> The information transmitted is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited.
>> If you received this in error, please contact the sender and delete the material from any computer.
>> _______________________________________________________________________
>
> ---
> Daniel Kulp
> dkulp@apache.org
> http://www.dankulp.com/blog
>
>
>
>
Re: cxf in an OSGi environment
Posted by Daniel Kulp <dk...@apache.org>.
Have you tried this with CXF 2.1.1 or 2.1 or other?
We did some work in 2.1.1 to hopefully help some of the issues, but
I'm not really sure about this specific issue.
In general, we kind of recommend using the spring dynamic modules for
OSGi. The servicemix 4 folks have an example at:
http://servicemix.apache.org/SMX4/cxf-examples.html#CXFexamples-Inside
that shows how that works. When you do that, all the spring config
things should work.
Dan
On Jun 27, 2008, at 12:02 PM, David Savage wrote:
> Hi there,
>
> I'm trying to get cxf to work in an OSGi environment and have been
> banging my head against the desk a bit, suspect it might be due to
> leaping in at the deep end but any help would be appreciated.
>
> Ok here's what I've got working:
>
> JaxWsServerFactoryBean svrFactory = new JaxWsServerFactoryBean();
> svrFactory.setServiceClass(HelloWorld.class);
> svrFactory.setServiceBean(HelloWorldImpl());
> svrFactory.setAddress("http://localhost:9000/hello" );
> svrFactory.create();
>
> This launches an internal jetty server and when I test this using a
> web browser I can at least see that the server is running as I get a
> soap response:
>
> <soap:Envelope>
> <soap:Body>
> <soap:Fault>
> <faultcode>soap:Server</faultcode>
> <faultstring>No such operation: </faultstring>
> </soap:Fault>
> </soap:Body>
> </soap:Envelope>
>
> However I've not been able to get a client working in OSGi.
> Initially this was due to code in the
> org.apache.cxf.frontend.ClientProxyFactoryBean which assumed the
> classloader to generate the proxy would be the loader of the client
> interface. I've worked around that in a local patch here by setting
> Thread.contextClassLoader.
>
> Here's what I have on the client side:
>
> JaxWsProxyFactoryBean factory = new JaxWsProxyFactoryBean();
> factory.setServiceClass(reference.getInterface());
> factory.setAddress("http://localhost:9000/hello");
> // set context classloader
> ...
> HelloWorld proxy = factory.create();
> proxy.sayHello("World");
>
>
> However the client still fails due to a null BindingDetails object
> which is loaded when my test method is invoked:
>
> javax.xml.ws.WebServiceException: Could not find wsdl:binding
> operation info for web method sayHello.
> at
> org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:
> 150)
> at $Proxy35.sayHello(Unknown Source)
>
> Is there a stage I'm missing here?
>
> I'm also trying to get cxf to work with an https connection (both
> client and server). On the server side I've figured out that the
> process has something to do with doing something like:
>
> server = svrFactory.create();
>
> JettyHTTPDestination dest = (JettyHTTPDestination)
> server.getDestination();
> JettyHTTPServerEngine engine = (JettyHTTPServerEngine)
> dest.getEngine();
>
> if ( secure ) {
> TLSServerParameters params = new TLSServerParameters();
> // set params
> engine.setTlsServerParameters(params);
> }
>
> But again I'm not having much luck. Is there any example code I can
> follow or that someone can post to show how this should work?
>
> Thanks in advance for any help.
>
> Regards,
>
> Dave
>
> _______________________________________________________________________
> Paremus Limited. Registered in England
> No. 4181472
> Registered Office: 22-24 Broad Street, Wokingham, Berks RG40 1BA
> Postal Address: 107-111 Fleet Street, London, EC4A 2AB
> The information transmitted is intended only for the person(s) or
> entity to which it is addressed and may contain confidential and/or
> privileged material. Any review, retransmission, dissemination or
> other use of, or taking of any action in reliance upon, this
> information by persons or entities other than the intended recipient
> is prohibited.
> If you received this in error, please contact the sender and delete
> the material from any computer.
> _______________________________________________________________________
---
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog