można wykryć systemu ustawienia serwera proxy w aplikacji Java, ale nie w JUnit

Question

• Windows 7
• Java 1.8.0_45
• Eclipse Mars

Jeśli proxy System skonfigurowany do HTTP, poniżej będzie drukować HTTP tylko wtedy, gdy uruchomi się z metody java aplikacji main.

Jeśli jednak zostanie wywołana z testu JUnit 4 (w czasie zaćmienia), zawsze wypisze DIRECT.

Należy również zauważyć, że definiowanie -Djava.net.useSystemProxies=true w środowisku Eclipse: Uruchom konfiguracje -> Argumenty -> Argumenty VM. Test po prostu się zawiesza.

Każdy pomysł, co się dzieje?

Dzięki dużo,

public void printSystemProxy() { 
    System.setProperty("java.net.useSystemProxies", "true"); 
    try { 
     final List<Proxy> list = ProxySelector.getDefault().select(new URI("http://foo/bar")); 
     for (final Proxy proxy : list) { 
      System.out.println(proxy.type()); 
     } 
    } 
    catch (final URISyntaxException e) { 
     throw new IllegalStateException(e); 
    } 
} 

Answer 1

spróbuj konfiguracja TestRunner (kliknij prawy/RunAs ...) o następujących parametrach VM:

-Dhttp.proxyHost=<YOUR_PROXY> 
-Dhttp.proxyPort=<YOUR_PORT> 
-Dhttp.nonProxyHosts=<IF YOU NEED THIS (pipe as separator)> 
-Dhttp.proxyUser=<YOUR_NAME> 
-Dhttp.proxyPassword=<YOUR_PASWORD> 

Answer 2

Nie można zmienić systemu Java zachowanie proxy w środowisku wykonawczym. Właściwość systemowa java.net.useSystemProxies jest odczytywana tylko podczas uruchamiania. From the documentation (podkreślenie dodane):

java.net.useSystemProxies (Domyślnie: wyłączona)

W ostatnich systemach Windows oraz systemów Gnome 2.x możliwe jest powiedzieć stos java.net, ustawienie to właściwość true, aby użyć ustawień proxy systemu (oba te systemy umożliwiają ustawianie serwerów proxy na całym świecie za pośrednictwem interfejsu użytkownika). Należy zauważyć, że ta właściwość jest zaznaczona tylko jeden raz podczas uruchamiania.

Ustawienie właściwości systemu w locie nie zmieni zachowania. Musisz wysłać go jako argument JVM przy użyciu -D, tak jak robisz ze swoją metodą main. Alternatywą byłoby nie używanie systemu proxy, a zamiast tego pozwolić użytkownikowi na dostarczanie własnych.

Alternatywnie, inne właściwości proxy, takie jak http.proxyHost, http.proxyPort, itp. (Wymienione na powyższym łączu dokumentacji) mogą być modyfikowane po uruchomieniu aplikacji. W zależności od aplikacji może to i tak być lepszym rozwiązaniem, ponieważ zazwyczaj ma lepszą obsługę wielu platform.

Answer 3

Ustawienia proxy ustawione w programie Eclipse wpłyną na wszystkie narzędzia, w tym samo środowisko Eclipse i Maven. To może być powód, dla którego "wisiałeś" ... może to nie był twój test JUnit, ale sam wieszak (potrzeba wyjaśnienia).

Jednak w tym przypadku wydaje mi się, że można zmienić właściwości systemu z poziomu wtyczki odpowiedzialnej za testy JUnit:

<plugin> 
    <groupId>org.apache.maven.plugins</groupId> 
    <artifactId>maven-surefire-plugin</artifactId> 
    <version>2.18.1</version> 
    <configuration> 
     <systemPropertyVariables> 
     <java.net.useSystemProxies>true</java.net.useSystemProxies> 
     </systemPropertyVariables> 
    </configuration> 
    </plugin> 

[UPDATE]

w niektórych przypadkach właściwość systemu jest używany tylko podczas uruchamiania i działa tylko po ustawieniu go w wierszu polecenia.W takim przypadku, you can supply it as part of the command-line arguments:

<plugin> 
    <groupId>org.apache.maven.plugins</groupId> 
    <artifactId>maven-surefire-plugin</artifactId> 
    <version>2.18.1</version> 
    <configuration> 
     <argLine>-Djava.net.useSystemProxies=true</argLine> 
    </configuration> 
    </plugin> 

Należy również pamiętać, że jeśli chcesz, aby uruchomić go od wewnątrz Maven, musisz wybrać 'Uruchom jako -> test Maven', a nie 'Run as -> JUnit test'.

[ranting Follows]

Nienawidzę tego mówić - ale w tym momencie wsparcie dla proxy jest naprawdę biedny ciągu Java.

Dokonano jeszcze jednego znaczącego ulepszenia: teraz możesz zdefiniować oddzielny serwer proxy dla każdego połączenia, które chcesz ustanowić. Myślę jednak, że powinno to zostać poprawione przez wiele:

1. Oddzielna uwierzytelnianie za pełnomocnika. Teraz, mimo że mogę zdefiniować serwer proxy na połączenie, nienaturalne jest używanie tego samego uwierzytelnienia dla wszystkich. Co gorsza, uruchamia to samo uwierzytelnianie zarówno dla połączenia proxy, jak i HTTP: nie jest w stanie rozróżnić tych dwóch nawet.
2. Lepsze wsparcie dla serwerów proxy SOCKS
3. Lepsza obsługa zapytań systemu o konfigurację proxy. Każdy nowoczesny system operacyjny ma teraz konfigurację domyślnego serwera proxy.
4. Wbudowane wsparcie i interfejsy API dla rzeczywistych serwerów Socket.

Brzmi jak wyrocznia rozczarowanego programisty, ale odpowiedź polega na ich realizacji! Czy to jest godne JEP?