How to hide warning in jax-ws client which (maybe) caused by jax-ws library

Question

I'm using netbeans to generate web service client in my application. And my program using jax-ws library to set timeout in calling web service.

Problem arise because it generate a lot of this warning message whenever i start this program.:

Dec 13, 2010 4:35:21 PM [com.sun.xml.ws.policy.EffectiveAlternativeSelector] selectAlternatives WARNING: WSP0075: Policy assertion "{http://schemas.xmlsoap.org/ws/2004/10/wsat}ATAlwaysCapability" was evaluated as "UNKNOWN".

Dec 13, 2010 4:35:21 PM [com.sun.xml.ws.policy.EffectiveAlternativeSelector] selectAlternatives WARNING: WSP0075: Policy assertion "{http://schemas.xmlsoap.org/ws/2004/10/wsat}ATAssertion" was evaluated as "UNKNOWN".

Dec 13, 2010 4:35:21 PM [com.sun.xml.ws.policy.EffectiveAlternativeSelector] selectAlternatives WARNING: WSP0019: Suboptimal policy alternative selected on the client side with fitness "UNKNOWN".

I found the same problem with mine in here: http://forums.java.net/node/707265 , but it also have no answer until now.

Is there any way to hide this warning? I try to search using google, and can't find any match answer for this problem..

Radish

Answer 1

My guess is that the WSDL from which the client was generated contains policy assertions related to WS-AtomicTransaction. Since WS-AtomicTransaction requires a transaction manager and the JRE doesn't contain one, it's not surprising that the JAX-WS runtime in the JRE has no support for WS-AtomicTransaction and doesn't understand these policy assertions.

If you don't need WS-AtomicTransaction, then you have two options to get rid of these warnings:

• Configure logging to suppress these warnings.
• Remove the assertions from the WSDL.

If you need WS-AtomicTransaction, then you will probably have to run the code in an application server or as a Java EE application client.

Toms

In my particular case, the WSDL contains a wsaw:UsingAddressing policy assertion. That is the only policy assertion in the WSDL. Any suggestions on how to set up the client to properly handle the addressing requirement? I'd rather fix it than just suppress the warning. – Reinert

wsaw:UsingAddressing is not a policy assertion, but a WSDL extension, which is something else. What is the warning message that you get in your particular case? – Toms

Dec 29, 2011 2:10:34 PM [com.sun.xml.internal.ws.policy.EffectiveAlternativeSelector] selectAlternatives WARNING: WSP0075: Policy assertion "{w3.org/2006/05/addressing/wsdl}UsingAddressing" was evaluated as "UNKNOWN". Dec 29, 2011 2:10:34 PM [com.sun.xml.internal.ws.policy.EffectiveAlternativeSelector] selectAlternatives WARNING: WSP0019: Suboptimal policy alternative selected on the client side with fitness "UNKNOWN". – Reinert

Can you post the WSDL somewhere, or at least a relevant fragment that shows how the UsingAddressing element is used? – Toms

<wsp:Policy wsu:Id="WSHttpBinding_IX12RequestService_policy"> <wsp:ExactlyOne> <wsp:All> <wsaw:UsingAddressing/> </wsp:All> </wsp:ExactlyOne> </wsp:Policy> <wsdl:types> ... </wsdl:types> <wsdl:binding name="WSHttpBinding_IX12RequestService" type="tns:IX12RequestService"> <wsp:PolicyReference URI="#WSHttpBinding_IX12RequestService_policy"/> <soap12:binding transport="schemas.xmlsoap.org/soap/http"> ... </wsdl:binding> – Reinert

The WS-Addressing spec indeed says that wsaw:UsingAddressing may be used as a policy assertion (in contrast to what I said earlier). However, the issue java.net/jira/browse/JAX_WS-852 suggests that the people who are developing the JAX-WS reference implementation (which is used in Java 7) consider this as non-standard and that it is not supported. You may be able to fix this by replacing wsaw:UsingAddressing by the equivalent assertion (wsam:Addressing) from the WS-Addressing Metadata spec. – Toms

Answer 2

You must be using an outdated version of jax-ws (I didn't find EffectiveAlternativeSelector in my 2.2.1 copy), but let me try.

1. Create a logging.properties file on some path accessible while launching your application (at the very least you may use the one found at $JAVA_HOME/lib/logging.properties)
2. Add the following line to that file: com.sun.xml.ws.policy.EffectiveAlternativeSelector.level=OFF
3. Launch your application as

java -Djava.util.logging.config.file=/path/to/your/logging.properties MainClass

Zanazander

I ran into this using Java SE 7u2 sDK downloaded from the Oracle main downloads page just a few days ago. javac and java report version 1.7.0_02. Is Oracle publishing outdated distros? – Reinert

I meant the jax-ws distro. How did you get it? Does it come bundled with Java SDK? – Zanazander

It must have been bundled with the Java SDK because I haven't installed anything else. The wsimport generated code says "This class was generated by the JAX-WS RI. * JAX-WS RI 2.2.4-b01 * Generated source version: 2.2 " – Reinert

I encounter this problem in java 1.7 but works well in 1.6.45 – Oedipus

Answer 3

9 years after the question, but maybe someone else needs to set this in java code in 2019.

If you just want to hide the warnings (instead of solving the underlying issue) you can easily set the the logging level in your code like this and no messages should appear:

      PolicyLogger logger = PolicyLogger.getLogger(EffectiveAlternativeSelector.class);
      logger.setLevel(Level.OFF);

Naples

Answer 4

i think turning of the debugging isn't a solution

http://dannythorpe.com/2012/01/04/java-wcf-usingaddressing-warning/ describes a way to fix this.

Stibine

Answer 5

The @SupressWarnings() does not help in this case. That annotation is to tell the compiler to not warn you when you are potentially misusing some java type. These ws warnings are getting piped into System.err

Daff

Answer 6

Is @SupressWarning(value="?") of any use here ?

Wolff