1

Many recommend not to use sun packages for various reasons. Detailed answers are provided here.

However I am using jaxws-rt.jar which uses sun library.

I am wondering if I should jaxws-rt.jar or not. I am running in tomcat container and I do not want to include jaxws implementations of Jboss,GlassFish or any other application servers.

Here is what I am trying to do (setting connection and request timeouts)

import com.sun.xml.internal.ws.client.BindingProviderProperties;
import javax.xml.ws.BindingProvider;

((BindingProvider)soapService).getRequestContext()
        .put(BindingProviderProperties.REQUEST_TIMEOUT,REQUEST_TIMEOUT_MILLI);
((BindingProvider)soapService).getRequestContext()
        .put(BindingProviderProperties.CONNECT_TIMEOUT,CONNECT_TIMEOUT_MILLI);

Thanks

Community
  • 1
  • 1
brain storm
  • 30,124
  • 69
  • 225
  • 393

2 Answers2

2

As you've found, certain behaviors (such as connection timeouts) are controlled through implementation-specific means.

If you're not keen on compiling against (importing) the com.sun packages, one way to remove the compile-time dependencies yet set these properties to control the JAX-WS reference implementation the way you need, you can try just setting the BindingProvider request context properties for the reference implementation by their string values. You can set these properties even when running with other JAX-WS runtimes than the RI - it won't fail (it just may have no effect).

import javax.xml.ws.BindingProvider;

((BindingProvider)soapService).getRequestContext()
    .put("com.sun.xml.ws.request.timeout", 5000L);
((BindingProvider)soapService).getRequestContext()
    .put("com.sun.xml.ws.connect.timeout", 5000L);

Here are the two values for both constants in your question. JAXWSProperties.CONNECT_TIMEOUT and BindingProviderProperties.REQUEST_TIMEOUT.

Scott Heaberlin
  • 3,364
  • 1
  • 23
  • 22
  • There is nothing wrong with compiling against `com.sun.* packages, and it would be more or less impossible to write some programs without it, such as programs that use JNDI for LDAP or COSNaming. – user207421 May 01 '16 at 02:48
  • This is not a question about JNDI or COSNaming. The OP has a concern, this response provides a way to use without compile time dependency. It does not recommend against using com.sun.* – Scott Heaberlin May 01 '16 at 02:55
  • @scotth: thanks. if I set the String constant as you suggested, do I need to still have jaxws-rt dependency in my pom.xml. I am currently including this dependency in pom.xml. and I also noticed that both REQUEST_TIMEOUT and CONNECT_TIMEOUT are different string constants. ( com.sun.xml.ws.request.timeout and com.sun.xml.ws.connect.timeout according to you link you provided) – brain storm May 01 '16 at 05:31
  • Good eye. I've corrected the post. You would still need to include the jars in your war (via pom dependencies in your case) if you want to use the reference implementation. If you were to decide to switch to another implementation such as Apache CXF, using these string constant values would not break but you may have to set the desired connect/request timeout behaviors differently. – Scott Heaberlin May 01 '16 at 10:24
  • so does rt.jar not include any reference implementation. This is where I get confused. I could do wsimport to create java classes from wsdl. but I need to have jaxws-rt.jar (or other RI) in classpath to make soap connections? – brain storm May 01 '16 at 16:25
  • It depends on your jre version, but probably. If you choose not to bundle it (dependency type "provided" in Pom) but run into class not found problems, you can try including it. See http://stackoverflow.com/questions/9116008/does-java-7-include-a-jax-ws-implementation-or-just-the-api – Scott Heaberlin May 01 '16 at 16:32
  • thanks for the link to the post. I have seen it before. I am using java 8. but I get compile error when I call BindingProviderProperties.REQUEST_TIMEOUT without including the dependency (jaxws-rt) in pom.xml. I can get away with including the String constant you mentioned. but wondering if it will have any effect. – brain storm May 01 '16 at 18:12
  • Here is another post I made few days ago. http://stackoverflow.com/questions/36847410/reference-implementation-for-bindingprovider-properites-for-soap-service-in-spri – brain storm May 01 '16 at 18:13
  • Modern JREs come with the JAX-WS API (e.g. the significant interfaces, annotations, and classes) but not an implementation. If you choose to use the open source JAX-WS reference implementation ("RI"), you would use the jar libraries provided by https://jax-ws.java.net/ - or, to use maven dependencies, `com.sun.xml.ws` and `jaxws-rt`. Then, to configure the RI's connect and request timeouts, use the approaches discussed - either by referencing the classes in your code or by using the string constants. – Scott Heaberlin May 01 '16 at 21:18
  • Final reference: overview of JAX-WS classes in the JDK vs those needed to run (via the reference impl) - https://stackoverflow.com/questions/15798351/jax-ws-implementation-included-with-java?rq=1 – Scott Heaberlin May 01 '16 at 21:22
  • Thanks for helping me here. finally one last question. why do I need both `com.sun.xml.ws` and `jaxws-rt`. I was able to get away with latter, Thanks. – brain storm May 02 '16 at 06:04
  • Glad to help. This last one is worth a separate SO question with the [maven](https://stackoverflow.com/questions/tagged/maven) tag. If satisfied with an answer here, please mark an answer as accepted. – Scott Heaberlin May 03 '16 at 00:46
2

This is a misunderstanding.

even though it includes sun libraries?

It doesn't 'include sun libraries'. It refers to a com.sun library. That's a completely different thing. Two completely different things.

Many recommend not to [use] sun packages for various reasons.

There is only one recommendation that counts, and it is the Note about sun.* packages. The operative sentence in that is:

Programs that contain direct calls to the sun.* packages are not 100% Pure Java.

The sun.* packages are there for a reason of course, and that is to provide implementations for various things in the JDK. If that's the only use your program makes of these classes, and specifically if your code doesn't contain 'direct calls to the sun.* packages', you don't have anything to worry about.

user207421
  • 305,947
  • 44
  • 307
  • 483