Kwa nini majaribio ya Java hukosa java.net.useSystemProxies

Programu yako hutambua proksi ya mfumo, lakini jaribio la JUnit halitambui. Kabla ya kubadilisha msimbo wa ugunduzi, tambua JVM gani inaendesha kila mchakato na ni hoja gani ilizopokea.

JDK inaeleza java.net.useSystemProxies kama sifa inayokaguliwa mara moja wakati wa kuanza. Kuiweka ndani ya mbinu ya jaribio kunaweza kuwa kuchelewa sana kubadilisha uamuzi huo wa kuanza.

Kianzilishi cha programu cha IDE, kianzilishi cha majaribio cha IDE, Maven yenyewe na mchakato wa majaribio wa Surefire uliogawanywa wote wanaweza kuwa na hoja za VM tofauti. Mpangilio wa proksi katika kianzilishi kimoja si uthibitisho kwamba kianzilishi kingine uliupitisha.

Kagua usanidi wa mchakato uliogawanywa

argLine ya Surefire hutoa chaguo za JVM za mstari wa amri kwa utekelezaji uliogawanywa. Chaguo la uanzishaji linaweza kuwa hapo majaribio yanapoendeshwa katika tawi kama hilo:

<argLine>-Djava.net.useSystemProxies=true</argLine>

Unganisha chaguo hilo na usanidi uliopo wa mradi. Kubadilisha argLine iliyopo kunaweza kutupa mawakala wa ufikiaji au mipangilio mingine ya JVM inayohitajika. Ikiwa build haitumii tawi lolote, kagua JVM inayohudumia majaribio kwa kweli badala yake; argLine imeelezwa kuwa na ufanisi kwa utekelezaji uliogawanywa pekee.

Sifa isiyohusiana na uanzishaji inayotolewa kupitia mfumo wa sifa wa mfumo wa majaribio ina mzunguko wa maisha tofauti. Usidhani kila sifa inafikia VM mapema vya kutosha kwa sababu tu System.getProperty() inarudisha mfuatano unaotakiwa wakati wa jaribio.

Kwa jaribio lengwa la uelekezaji wa proksi, mteja aliyesanidiwa waziwazi anaweza pia kupunguza utegemezi wa usanidi wa kompyuta ya mezani. Java 11+ HttpClient inaweza kutumia HTTP ProxySelector ya ndani ya mteja kwa madhumuni hayo. Weka chaguo hilo likionekana katika nia ya jaribio: kujaribu njia ya mteja na kujaribu ugunduzi wa proksi wa mfumo wa uendeshaji ni ukaguzi tofauti.