Java ಪರೀಕ್ಷೆಗಳು java.net.useSystemProxies ಅನ್ನು ಏಕೆ ತಪ್ಪಿಸಿಕೊಳ್ಳುತ್ತವೆ
ಪ್ರಾರಂಭ-ಸಂವೇದಿ Java ಪ್ರಾಕ್ಸಿ ಪತ್ತೆ ಆಯ್ಕೆಗಳನ್ನು ಪರೀಕ್ಷೆಗಳನ್ನು ನಡೆಸುವ JVM ಗೆ ರವಾನಿಸಿ, ಅಪ್ಲಿಕೇಶನ್ ಅಥವಾ ಬಿಲ್ಡ್ ಲಾಂಚರ್‌ಗೆ ಮಾತ್ರವಲ್ಲ.
ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಸಿಸ್ಟಮ್ ಪ್ರಾಕ್ಸಿಯನ್ನು ಪತ್ತೆ ಮಾಡುತ್ತದೆ, ಆದರೆ JUnit ಪರೀಕ್ಷೆ ಮಾಡುವುದಿಲ್ಲ. ಪತ್ತೆ ಕೋಡ್ ಬದಲಿಸುವ ಮೊದಲು, ಯಾವ JVM ಪ್ರತಿ ಪ್ರಕ್ರಿಯೆಯನ್ನು ನಡೆಸುತ್ತದೆ ಮತ್ತು ಯಾವ ಆರ್ಗ್ಯುಮೆಂಟ್‌ಗಳನ್ನು ಪಡೆದಿದೆ ಎಂಬುದನ್ನು ಗುರುತಿಸಿ.
JDK java.net.useSystemProxies ಅನ್ನು ಪ್ರಾರಂಭದಲ್ಲಿ ಒಮ್ಮೆ ಪರಿಶೀಲಿಸುವ ಗುಣಲಕ್ಷಣವೆಂದು ದಾಖಲಿಸುತ್ತದೆ. ಅದನ್ನು ಪರೀಕ್ಷಾ ವಿಧಾನದೊಳಗೆ ಹೊಂದಿಸುವುದು ಆ ಪ್ರಾರಂಭ ನಿರ್ಧಾರವನ್ನು ಬದಲಿಸಲು ತುಂಬಾ ತಡವಾಗಿರಬಹುದು.
IDE ಅಪ್ಲಿಕೇಶನ್ ಲಾಂಚರ್, IDE ಪರೀಕ್ಷಾ ರನ್ನರ್, Maven ಸ್ವತಃ ಮತ್ತು ಫೋರ್ಕ್ ಮಾಡಿದ Surefire ಪರೀಕ್ಷಾ ಪ್ರಕ್ರಿಯೆ ಎಲ್ಲವೂ ವಿಭಿನ್ನ VM ಆರ್ಗ್ಯುಮೆಂಟ್‌ಗಳನ್ನು ಹೊಂದಿರಬಹುದು. ಒಂದು ಲಾಂಚರ್‌ನಲ್ಲಿನ ಪ್ರಾಕ್ಸಿ ಸೆಟ್ಟಿಂಗ್ ಇನ್ನೊಂದು ಲಾಂಚರ್ ಅದನ್ನು ರವಾನಿಸಿದೆ ಎಂಬುದಕ್ಕೆ ಸಾಕ್ಷಿಯಲ್ಲ.
ಫೋರ್ಕ್ ಮಾಡಿದ ಪ್ರಕ್ರಿಯೆಯ ಸಂರಚನೆಯನ್ನು ಪರಿಶೀಲಿಸಿ
Surefire ನ argLine ಫೋರ್ಕ್ ಮಾಡಿದ ಕಾರ್ಯಾಚರಣೆಗಳಿಗೆ ಕಮಾಂಡ್-ಲೈನ್ JVM ಆಯ್ಕೆಗಳನ್ನು ಒದಗಿಸುತ್ತದೆ. ಪರೀಕ್ಷೆಗಳು ಅಂತಹ ಫೋರ್ಕ್‌ನಲ್ಲಿ ಚಲಿಸಿದಾಗ ಪ್ರಾರಂಭ ಆಯ್ಕೆ ಅಲ್ಲಿರಬಹುದು:
<argLine>-Djava.net.useSystemProxies=true</argLine>ಆಯ್ಕೆಯನ್ನು ಪ್ರಾಜೆಕ್ಟ್‌ನ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಸಂರಚನೆಗೆ ಸೇರಿಸಿ. ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ argLine ಅನ್ನು ಬದಲಿಸುವುದರಿಂದ ಕವರೇಜ್ ಏಜೆಂಟ್‌ಗಳು ಅಥವಾ ಇತರ ಅಗತ್ಯ JVM ಸೆಟ್ಟಿಂಗ್‌ಗಳು ಕಳೆದುಹೋಗಬಹುದು. ಬಿಲ್ಡ್ ಯಾವುದೇ ಫೋರ್ಕ್ ಬಳಸದಿದ್ದರೆ, ಬದಲಿಗೆ ಪರೀಕ್ಷೆಗಳನ್ನು ನಿಜವಾಗಿ ಹೋಸ್ಟ್ ಮಾಡುವ JVM ಅನ್ನು ಪರಿಶೀಲಿಸಿ; argLine ಫೋರ್ಕ್ ಮಾಡಿದ ಕಾರ್ಯಾಚರಣೆಗಳಿಗೆ ಮಾತ್ರ ಪರಿಣಾಮಕಾರಿ ಎಂದು ದಾಖಲಾಗಿದೆ.
ಪರೀಕ್ಷಾ ಚೌಕಟ್ಟಿನ ಗುಣಲಕ್ಷಣ ಕಾರ್ಯವಿಧಾನದ ಮೂಲಕ ಒದಗಿಸಲಾದ ಪ್ರಾರಂಭ-ಸಂವೇದಿಯಲ್ಲದ ಗುಣಲಕ್ಷಣವು ಬೇರೆ ಜೀವನಚಕ್ರವನ್ನು ಹೊಂದಿದೆ. System.getProperty() ಪರೀಕ್ಷೆಯ ಸಮಯದಲ್ಲಿ ಬಯಸಿದ ಸ್ಟ್ರಿಂಗ್ ಅನ್ನು ಹಿಂತಿರುಗಿಸುತ್ತದೆ ಎಂಬ ಕಾರಣಕ್ಕೆ ಪ್ರತಿ ಗುಣಲಕ್ಷಣವೂ VM ತಲುಪುತ್ತದೆ ಎಂದು ಊಹಿಸಬೇಡಿ.
ಕೇಂದ್ರೀಕೃತ ಪ್ರಾಕ್ಸಿ-ರೂಟಿಂಗ್ ಪರೀಕ್ಷೆಗೆ, ಸ್ಪಷ್ಟವಾಗಿ ಸಂರಚಿಸಿದ ಕ್ಲೈಂಟ್ ಡೆಸ್ಕ್‌ಟಾಪ್ ಸಂರಚನೆಯ ಮೇಲಿನ ಅವಲಂಬನೆಯನ್ನು ಸಹ ಕಡಿಮೆ ಮಾಡಬಹುದು. Java 11+ HttpClient ಆ ಉದ್ದೇಶಕ್ಕಾಗಿ ಕ್ಲೈಂಟ್-ಸ್ಥಳೀಯ HTTP ProxySelector ಬಳಸಬಹುದು. ಆ ಆಯ್ಕೆಯನ್ನು ಪರೀಕ್ಷೆಯ ಉದ್ದೇಶದಲ್ಲಿ ಗೋಚರವಾಗಿರಿಸಿ: ಕ್ಲೈಂಟ್ ಮಾರ್ಗವನ್ನು ಪರೀಕ್ಷಿಸುವುದು ಮತ್ತು ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್‌ನ ಪ್ರಾಕ್ಸಿ ಪತ್ತೆಯನ್ನು ಪರೀಕ್ಷಿಸುವುದು ಬೇರೆ ಬೇರೆ ಪರಿಶೀಲನೆಗಳು.