You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@servicemix.apache.org by Marc <Ma...@gmail.com> on 2013/09/21 02:23:34 UTC
JAXWSProperties in Servicemix
hello,
I'm trying to write some a very portable library that I want to be able to
use inside of Servicemix but also distribute outside of Servicemix.
The library I'm writing is using a JAX-WS Contract First WSDL. The WSDL and
JAXB code was built from WSDL2JAVA.
I've written everything in Java using JAX-WS and no CXF. Things worked in
the first prototype now I've hit a wall.
The problem has to do with the SSLSocketFactory and HostnameVerifier.
Using JAX-WS I set those on my WSDL with the following code.
*AuWSDLPortType port = auService.getAuService();
BindingProvider bindingProvider = (BindingProvider)port;
bindingProvider.getRequestContext().put(JAXWSProperties.SSL_SOCKET_FACTORY,
getCustomSocketFactory());
bindingProvider.getRequestContext().put(JAXWSProperties.HOSTNAME_VERIFIER,
getCustomHostnameVerifier());*
(in reality I'm not using JAXWSProperties but the strings i.e.
"com.sun.xml.internal.ws.transport.https.client.SSLSocketFactory")
The code works outside of servicemix but in Servicemix and I get a huge
stack trace with the following error:
/"Cause by: sun.security.provider.certpath.SunCertPathBuilderException:
unable to find valid certification path to request target"/
Turning on javax.xml.debug=all shows me that my custom TrustStore (1 entry)
configured in getCustomSocketFactory() is never loaded and that instead the
default truststore (100+ entries) is loaded.
JAXWSProperties don't exist in Servicemix and conversely CXF, which is the
code in Servicemix that is handling my JAX-WS endpoint. So what I'm trying
to figure out now is how do I write something that works both outside of
Servicemix and in Servicemix and only relies on the core Java libraries? So
using CXF HttpConduit would not be ideal because it would limit portability
by requiring CXF to use what is suppose to be a lightweight library.
I was hoping that an equivalent string to JAXWProperties might exist in CXF
maybe?
Or maybe there is something I can do in my code to figure out if the
underlying WS implementation is Java core or CXF and switch between the two?
Or maybe there is a way I can tell Servicemix (from within the bundle) that
I would like to use the Java WSDL impl?
I don't know what I don't know so I'm open to suggestions and approaches : (
--
View this message in context: http://servicemix.396122.n5.nabble.com/JAXWSProperties-in-Servicemix-tp5717833.html
Sent from the ServiceMix - User mailing list archive at Nabble.com.
Re: JAXWSProperties in Servicemix
Posted by Marc <Ma...@gmail.com>.
So I'm coming to understand how JAX-WS works. JAX-WS is an API and there are
a bunch of implementations for it, Metro being the default one bundled with
the JDK. GlassFish and CXF implement the JAX-WS API.
If I understood that correctly then my question becomes, does the JAX-WS API
allow me to perform a change to the SSLSocketFactory in a manner that is
universally portable with all the other JAX-WS implementations?
The more I read and the more I understand the more I think the answer is...
no. Am I right? Is portability impossible?
--
View this message in context: http://servicemix.396122.n5.nabble.com/JAXWSProperties-in-Servicemix-tp5717833p5717845.html
Sent from the ServiceMix - User mailing list archive at Nabble.com.
Re: JAXWSProperties in Servicemix
Posted by Marc <Ma...@gmail.com>.
I've heard about "metro", but I don't understand what it means. However
JAXWSProperties is in the JDK 1.7_25 libraries so I thought that was very
portable. Still it's com.sun.internal so not a good idea I know, but I've
looked at a lot of solutions online and no one has a good simple solution.
I work in a big company and my library needs to be easy for other groups in
the company to use. If I use CXF then some people who have JBOSS might have
trouble. Also some people have older Servicemixes, so I would have to build
"two" libraries, one with an old CXF and one with a new CXF. Some groups
don't use Servicemix and need normal java libraries. If I include CXF then
they need to add all the CXF libraries and make sure there are no class
package conflicts.
Less code and less java libraries is always better code, don't you agree?
I was hoping to avoid a lot of problems by only using libraries from Java,
but I can't figure out how. I also don't have much time left. My company
wants my library to be done in 2 days : (
Right now the only solution I have is to have two java libraries.
Library A - Uses only Java libraries
Library B - Uses library A but I create a Factory to give me back CXF WSDL
service instance.
Outside of Servicemix I use only A.
Inside of Servicemix I use A and B.
Not the best solution but it is all I can think of. Freeman, since you are a
CXF expert can you think of a better solution that only uses the Java
Libraries? CXF was built on top of JAX-WS so I would think there is a
solution of some kind that would work for both.
--
View this message in context: http://servicemix.396122.n5.nabble.com/JAXWSProperties-in-Servicemix-tp5717833p5717844.html
Sent from the ServiceMix - User mailing list archive at Nabble.com.
Re: JAXWSProperties in Servicemix
Posted by Freeman Fang <fr...@gmail.com>.
Hi,
SMX ship CXF as jaxws impl OOTB, the JAXWSProperties you used here is metro specific, it even won't from the JAXWS specific, so the way you used here is hard to say "portable"
－－－－－－－－－－－－－
Freeman(Yue) Fang
Red Hat, Inc.
FuseSource is now part of Red Hat
Web: http://fusesource.com | http://www.redhat.com/
Twitter: freemanfang
Blog: http://freemanfang.blogspot.com
http://blog.sina.com.cn/u/1473905042
weibo: @Freeman小屋
On 2013-9-21, at 上午8:23, Marc wrote:
> hello,
>
> I'm trying to write some a very portable library that I want to be able to
> use inside of Servicemix but also distribute outside of Servicemix.
>
> The library I'm writing is using a JAX-WS Contract First WSDL. The WSDL and
> JAXB code was built from WSDL2JAVA.
>
> I've written everything in Java using JAX-WS and no CXF. Things worked in
> the first prototype now I've hit a wall.
>
> The problem has to do with the SSLSocketFactory and HostnameVerifier.
>
> Using JAX-WS I set those on my WSDL with the following code.
>
> *AuWSDLPortType port = auService.getAuService();
> BindingProvider bindingProvider = (BindingProvider)port;
>
> bindingProvider.getRequestContext().put(JAXWSProperties.SSL_SOCKET_FACTORY,
> getCustomSocketFactory());
> bindingProvider.getRequestContext().put(JAXWSProperties.HOSTNAME_VERIFIER,
> getCustomHostnameVerifier());*
>
> (in reality I'm not using JAXWSProperties but the strings i.e.
> "com.sun.xml.internal.ws.transport.https.client.SSLSocketFactory")
>
> The code works outside of servicemix but in Servicemix and I get a huge
> stack trace with the following error:
>
> /"Cause by: sun.security.provider.certpath.SunCertPathBuilderException:
> unable to find valid certification path to request target"/
>
> Turning on javax.xml.debug=all shows me that my custom TrustStore (1 entry)
> configured in getCustomSocketFactory() is never loaded and that instead the
> default truststore (100+ entries) is loaded.
>
> JAXWSProperties don't exist in Servicemix and conversely CXF, which is the
> code in Servicemix that is handling my JAX-WS endpoint. So what I'm trying
> to figure out now is how do I write something that works both outside of
> Servicemix and in Servicemix and only relies on the core Java libraries? So
> using CXF HttpConduit would not be ideal because it would limit portability
> by requiring CXF to use what is suppose to be a lightweight library.
>
> I was hoping that an equivalent string to JAXWProperties might exist in CXF
> maybe?
> Or maybe there is something I can do in my code to figure out if the
> underlying WS implementation is Java core or CXF and switch between the two?
> Or maybe there is a way I can tell Servicemix (from within the bundle) that
> I would like to use the Java WSDL impl?
>
> I don't know what I don't know so I'm open to suggestions and approaches : (
>
>
>
> --
> View this message in context: http://servicemix.396122.n5.nabble.com/JAXWSProperties-in-Servicemix-tp5717833.html
> Sent from the ServiceMix - User mailing list archive at Nabble.com.