2016-04-30 5 views
1

Viele empfehlen, sun Pakete aus verschiedenen Gründen nicht zu verwenden. Detaillierte Antworten werden zur Verfügung gestellt here.Können wir jaxws-rt.jar als Laufzeitimplementierung verwenden, obwohl es auch Sun-Bibliotheken enthält?

Allerdings verwende ich jaxws-rt.jar, die Sonnenbibliothek verwendet. Ich frage mich, ob ich jaxws-rt.jar oder nicht sollte. Ich laufe in Tomcat-Container und ich möchte nicht Jaxws-Implementierungen von Jboss, GlassFish oder anderen Anwendungsservern einschließen.

Hier ist, was ich (Einstellung Verbindung und Anfrage-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); 

Dank

Antwort

2

Wie Sie gefunden haben, bestimmte Verhaltensweisen (wie Verbindungs-Timeouts) zu tun versuche, durch umsetzungs gesteuert spezifische Mittel.

Wenn Sie nicht gegen die com.sun-Pakete kompilieren möchten, eine Möglichkeit, die Kompilierungszeitabhängigkeiten zu entfernen und diese Eigenschaften so zu setzen, dass sie die JAX-WS-Referenzimplementierung so steuern, wie Sie benötigen, können Sie es einfach versuchen Setzen der BindingProvider Anfrage Kontexteigenschaften für die Referenzimplementierung durch ihre string values. Sie können diese Eigenschaften auch dann setzen, wenn Sie mit anderen JAX-WS-Laufzeiten als RI laufen - es wird nicht fehlschlagen (es kann nur keinen Effekt haben).

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); 

Hier sind die beiden Werte für beide Konstanten in Ihrer Frage. JAXWSProperties.CONNECT_TIMEOUT und BindingProviderProperties.REQUEST_TIMEOUT.

+0

Es ist nichts falsch mit dem Kompilieren gegen 'com.sun. * -Pakete, und es wäre mehr oder weniger unmöglich, einige Programme ohne es zu schreiben, wie Programme, die JNDI für LDAP oder COSNaming verwenden. – EJP

+0

Dies ist keine Frage über JNDI oder COSNaming. Das OP hat Bedenken, diese Antwort bietet eine Möglichkeit, ohne Kompilierzeitabhängigkeit zu verwenden. Es wird nicht empfohlen gegen com.sun. * –

+0

@scotth: danke. Wenn ich die String-Konstante wie vorgeschlagen einstellen soll, muss ich noch eine jaxws-rt-Abhängigkeit in meiner pom.xml haben. Ich schließe diese Abhängigkeit derzeit in pom.xml ein. und ich habe auch bemerkt, dass sowohl REQUEST_TIMEOUT als auch CONNECT_TIMEOUT unterschiedliche String-Konstanten sind. (com.sun.xml.ws.request.timeout und com.sun.xml.ws.connect.timeout entsprechend dem Link, den Sie zur Verfügung gestellt haben) –

1

Dies ist ein Missverständnis.

obwohl es sun Bibliotheken enthält?

Es enthält keine sun Bibliotheken. Es bezieht sich bezieht sich auf eine com.sun Bibliothek. Das ist eine ganz andere Sache. Zwei völlig verschiedene Dinge.

Viele empfehlen, [sun Pakete aus verschiedenen Gründen nicht zu verwenden].

Es gibt nur eine Empfehlung, und es ist die Note about sun.* packages. Der operative Satz ist:

Programme, die direkte Aufrufe an die Sonne enthalten. * Pakete sind nicht 100% Pure Java.

Die sun.* Pakete gibt es für einen Grund natürlich, und das ist Implementierungen für verschiedene Dinge im JDK zur Verfügung zu stellen. Wenn das der einzige Gebrauch ist, den Ihr Programm von diesen Klassen macht, und speziell, wenn Ihr Code keine direkten Aufrufe an die sun.* Pakete enthält, müssen Sie sich keine Sorgen machen.