הגדירו את שני המסלולים כבר באתחול, עם מאמת ה-IAM שנמסר בפועל לשירות:

import java.net.InetSocketAddress;
import java.net.Proxy;
import com.ibm.cloud.sdk.core.http.HttpConfigOptions;

var proxy = new Proxy(
    Proxy.Type.HTTP,
    new InetSocketAddress("proxy.example.net", 8080));

authenticator.setProxy(proxy);

var options = new HttpConfigOptions.Builder()
    .proxy(proxy)
    .build();
service.configureClient(options);

כאן authenticator ו-service הם האובייקטים הקיימים של היישום. החילו את ההגדרות לפני שמתחילים קבלת האסימון או בקשות השירות, עם אימות תעודות רגיל פעיל. במקום שבו היישום רשאי להשתמש בנקודת קצה HTTP ציבורית לשני היעדים, כתובות מועמדות זמינות ברשימת פרוקסי HTTP.

שתי ההקצאות מכסות בקשות שונות. authenticator.setProxy מכסה את מסלול האסימון של IAM; service.configureClient מחיל את הפרוקסי על תעבורת השירות. הגדרת האחד אינה קובעת את המסלול של האחר.

בכשל, זהו את המארח הנקוב בבקשה שנכשלה. קבלת אסימון בהצלחה מצמצמת את הבעיה למסלול השירות; אך היא אינה מוכיחה שהמסלול הזה אכן קיבל את אפשרויות הפרוקסי שלו.

HttpConfigOptions מגיע מ-IBM Java SDK Core. בעת התאמת דוגמת ConversationService ישנה, השתמשו בחבילת Core ובמהדורת השירות שנבחרה על ידי היישום, במקום להעתיק מחלקת רשת ישנה הייחודית לשירות.

מאמרים קשורים