‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

מאמרי עזרה בנושא appengine-web.xml

מזהה אזור

‫REGION_ID הוא קוד מקוצר ש-Google מקצה על סמך האזור שבוחרים כשיוצרים את האפליקציה. הקוד לא תואם למדינה או למחוז, למרות שחלק ממזהי האזורים עשויים להיראות דומים לקודים נפוצים של מדינות ומחוזות. באפליקציות שנוצרו אחרי פברואר 2020, REGION_ID.r נכלל בכתובות URL של App Engine. באפליקציות קיימות שנוצרו לפני התאריך הזה, מזהה האזור הוא אופציונלי בכתובת ה-URL.

מידע נוסף על מזהי אזורים

צריך להשתמש בקובץ appengine-web.xml כדי להגדיר את האפליקציה רק אם מעבירים אפליקציה קיימת מסביבת זמן ריצה של App Engine Java 8 לגרסה האחרונה של Java שנתמכת, ורוצים להשתמש בשירותים מדור קודם. אם אתם משתמשים ב-appengine-web.xml בפרויקט, המערכת יוצרת בשבילכם את app.yaml באופן אוטומטי בזמן הפריסה.

אפליקציות Java ב-App Engine משתמשות בקובץ הגדרות בשם appengine-web.xml כדי לציין מידע על האפליקציה ולזהות אילו קבצים בקובץ WAR של האפליקציה הם קבצים סטטיים (כמו תמונות) ואילו הם קובצי משאבים שמשמשים את האפליקציה.

תחביר

באפליקציית Java של App Engine צריך להיות קובץ בשם appengine-web.xml ב-WAR, בספרייה WEB-INF/. זהו קובץ XML שרכיב הבסיס שלו הוא <appengine-web-app>.

אפשר למצוא את הגדרת סוג המסמך ואת מפרטי הסכימה של appengine-web.xml בספרייה docs/ של ה-SDK.

רכיב	תיאור
`<application>`	לא נדרש אם פורסים את האפליקציה באמצעות כלים שמבוססים על Google Cloud SDK, כמו הפקודה `gcloud app deploy`, תוספים של IntelliJ, תוספים של Maven או Gradle. הכלים שמבוססים על Google Cloud SDK מתעלמים מהרכיב הזה ומקבלים את מזהה הפרויקט מהמאפיין gcloud config project. שימו לב: למרות שאפשר לשנות את מזהה הפרויקט באמצעות Google Cloud CLI, הפעולה הזו מגדירה מזהה פרויקט לכל המכונה, וזה עלול לגרום לבלבול אם מפתחים כמה פרויקטים. הרכיב `<application>` מכיל את מזהה הפרויקט של האפליקציה. זהו מזהה הפרויקט שאתם רושמים כשאתם יוצרים את הפרויקט ב- Google Cloud console.
`app_engine_apis`	זה שינוי אופציונלי. מגדירים את השדה הזה לערך `true` כדי להפעיל גישה לכל השירותים בחבילה עבור סביבות זמן ריצה מהדור השני. אם מגדירים את השדה הזה לערך `true` או `false`, הפריסות יצליחו רק אם ההגדרה `app_engine_bundled_services` לא צוינה. מומלץ להשתמש ב-`app_engine_bundled_services` כדי לציין את השירותים בחבילה שהאפליקציה שלכם דורשת. הגישה הזו מאפשרת שליטה מדויקת יותר ומשפרת את האבטחה על ידי צמצום החשיפה לשירותים לא נחוצים. בנוסף, הוא מוודא שהאפליקציה מקבלת עדכונים קריטיים לשירותים שהיא משתמשת בהם בפועל, וכך אפשר לתחזק אותה.
`app_engine_bundled_services`	זה שינוי אופציונלי. צריך להגדיר את השדה הזה כדי לאפשר גישה לשירותים ספציפיים בחבילה בסביבות זמן ריצה מהדור השני. אי אפשר להשתמש בהגדרה הזו אם מגדירים את השדה `app_engine_apis`. מציינים את אחד מהשירותים הנתמכים הבאים בחבילה באמצעות ההגדרה הזו: זהות האפליקציה: `app_identity_service` Blobstore: ‏ `blobstore` יכולות: `capability_service` ‫Datastore: `datastore_v3` תמונות: `images` מרחבי שמות: `namespaces` חיפוש: `search` נדחה: `deferred` אימייל: `mail` Memcache: `memcache` מודולים: `modules` תורי משימות: `taskqueue` אחזור כתובת URL: `urlfetch` משתמש: `user` לדוגמה: <app-engine-bundled-services> <api>datastore_v3</api> <api>memcache</api> </app-engine-bundled-services> בדוגמה הזו, האפליקציה יכולה להשתמש רק בשירותים המשולבים Datastore ו-Memcache.
`<entrypoint>`	אופציונלי, רק לזמני ריצה מהדור השני. מבטל את נקודת הכניסה שמוגדרת כברירת מחדל, שהיא שורת הפקודה של התהליך שמפעילה את אפליקציית Java. כברירת מחדל, נקודת הכניסה שנוצרת עבור סוג מכונה F4 (הגדרות הזיכרון מחושבות מסוג המכונה) שווה להגדרה הבאה: <appengine-web-app xmlns="http://appengine.google.com/ns/1.0"> <entrypoint> java -showversion -Xms32M -Xmx819M -XX:+UseG1GC -XX:+ParallelRefProcEnabled -XX:+PrintCommandLineFlags --add-opens java.base/java.lang=ALL-UNNAMED --add-opens java.base/java.nio.charset=ALL-UNNAMED --add-opens java.logging/java.util.logging=ALL-UNNAMED --add-opens java.base/java.util.concurrent=ALL-UNNAMED -Dclasspath.runtimebase=/base/java_runtime -Djava.class.path=/base/java_runtime/runtime-main.jar -Djava.library.path=/base/java_runtime: com/google/apphosting/runtime/JavaRuntimeMainWithDefaults --fixed_application_path=/workspace /base/java_runtime </entrypoint> </appengine-web-app> אפשר לשנות את ההגדרה כדי להוסיף דגלים נוספים של תהליך JVM או להגדיר תהליך משלכם לאתחול. שימו לב שהאפליקציה נפרסת בספרייה `/workspace`, וקובצי ה-JAR של זמן הריצה נמצאים בספרייה `/base/java_runtime`. איך משתמשים במשתני סביבה כדי להתאים אישית את נקודת הכניסה לזמן הריצה של Java
`<async-session-persistence>`	זה שינוי אופציונלי. אפשר להקטין את זמן האחזור של הבקשה על ידי הגדרת האפליקציה כך שתכתוב נתונים של סשנים ב-HTTP ב-Datastore באופן אסינכרוני: <async-session-persistence enabled="true" /> אם מפעילים את התכונה 'שמירת נתוני סשן אסינכרונית', App Engine ישלח משימה ל-Task Queue כדי לכתוב את נתוני הסשן ל-Datastore לפני כתיבת הנתונים ל-memcache. כברירת מחדל, המשימה תוגש לתור ברירת המחדל. אם רוצים להשתמש בתור אחר, מוסיפים את המאפיין `queue-name`: <async-session-persistence enabled="true" queue-name="myqueue"/> נתוני ביקורים תמיד נכתבים באופן סינכרוני ל-memcache. אם בקשה מנסה לקרוא את נתוני הסשן כש-memcache לא זמין (או כשנתוני הסשן נמחקו), היא תעבור ל-Datastore, שבו יכול להיות שעדיין לא יהיו נתוני הסשן העדכניים ביותר. המשמעות היא ששימור סשנים אסינכרוני עלול לגרום לאפליקציה שלכם לראות נתוני סשנים לא עדכניים. עם זאת, ברוב האפליקציות היתרון של השהיה נמוכה עולה בהרבה על הסיכון.
`<auto-id-policy>`	זה שינוי אופציונלי. אם הגדרתם מזהים של ישויות באופן אוטומטי, תוכלו לשנות את השיטה שבה נעשה שימוש על ידי הגדרת מדיניות המזהים האוטומטיים. אלה האפשרויות התקינות: `default` ברירת מחדל. משתמש במזהים אוטומטיים מפוזרים שהם מספרים שלמים גדולים ומפוזרים היטב, אבל קטנים מספיק כדי להיות מיוצגים על ידי מספרים ממשיים של 64 ביט. `legacy` האפשרות הקודמת תוצא משימוש בגרסה עתידית ותוסר בסופו של דבר. מידע נוסף זמין בפוסט בבלוג שבו הודענו על השינוי הזה.
`<automatic-scaling>`	זה שינוי אופציונלי. הסבר מלא מופיע בקטע בנושא התאמה אוטומטית לעומס (automatic scaling).
`<basic-scaling>`	זה שינוי אופציונלי. הסבר מלא מופיע בקטע שינוי גודל בסיסי.
`<env-variables>`	זה שינוי אופציונלי. בקובץ `appengine-web.xml` אפשר להגדיר משתני סביבה שמוגדרים כשהאפליקציה פועלת. <env-variables> <env-var name="DEFAULT_ENCODING" value="UTF-8" /> </env-variables> כדי למנוע התנגשויות עם הסביבה המקומית, שרת הפיתוח לא מגדיר משתני סביבה על סמך הקובץ הזה, ונדרש שמשתנים אלה כבר יוגדרו בסביבה המקומית לערכים תואמים. export DEFAULT_ENCODING="UTF-8" dev_appserver war כשפורסים את האפליקציה ב-App Engine, הסביבה נוצרת עם המשתנים האלה שכבר מוגדרים. כדי לקבוע כמה זמן חיבור נשאר בלי פעילות בלי העברת נתונים לפני שהלקוח סוגר אותו, צריך להגדיר זמן קצוב לתפוגה למצב המתנה באמצעות התחביר הבא: <env-variables> <env-var name="APPENGINE_API_CALLS_IDLE_TIMEOUT_MS" value="TIMEOUT_IN_MS" /> </env-variables> מחליפים את `TIMEOUT_IN_MS` בערך הזמן הקצוב לתפוגה הנדרש במילישניות. כדי להתאים למועד האחרון של 60 שניות לאחזור בקשה או כתובת URL, מגדירים את הערך ל-`60000`. לחלופין, כדאי להגדיר אותו קצת פחות מהזמן הקצוב לתפוגה בצד השרת (לרוב 60 שניות), למשל `59000`. ערך ברירת המחדל הנוכחי הוא `58000` אלפיות השנייה. הגדרת הזמן הקצוב לתפוגה של חוסר פעילות לא זהה לזמן הקצוב הכולל לתפוגה של בקשה לצורך שינוי גודל, או לזמן הקצוב לתפוגה של URL Fetch API שמוגדר באמצעות `appengine.api.urlfetch.defaultDeadline`.
`<inbound-services>`	זה שינוי אופציונלי. כדי שאפליקציה תוכל לקבל אימייל, צריך להגדיר אותה כך שהשירות יופעל. כדי להפעיל את השירות לאפליקציית Java, צריך לכלול קטע `<inbound-services>` בקובץ `appengine-web.xml`. השירות הנכנס הבא זמין: `mail` מאפשרת לאפליקציה לקבל אימייל.
`<instance-class>`	זה שינוי אופציונלי. גודל מחלקת המופעים של המודול הזה. אלה המחלקות של המופעים שזמינות כשמציינים אפשרויות שונות של שינוי גודל: `automatic_scaling` כשמשתמשים בהתאמה אוטומטית לעומס (automatic scaling), אפשר להשתמש בסוגי המופעים F1,‏ F2,‏ F4 ו-F4_1G. ברירת מחדל: אם לא מציינים סוג מכונה יחד עם הרכיב `automatic_scaling`, מוקצה F1. `basic_scaling` כשמשתמשים בהרחבה בסיסית, אפשר להשתמש בסוגי המופעים B1,‏ B2,‏ B4,‏ B4_1G ו-B8. ברירת מחדל: אם לא מציינים סוג מכונה יחד עם הרכיב `basic_scaling`, מוקצה B2. `manual_scaling` כשמשתמשים בהתאמת קנה מידה ידנית, אפשר להשתמש במכונות מסוג B1,‏ B2,‏ B4,‏ B4_1G ו-B8. ברירת מחדל: אם לא מציינים סוג מכונה יחד עם הרכיב `manual_scaling`, מוקצה B2. הערה: אם הערך של `instance-class` מוגדר ל-`F2` ומעלה, אפשר לבצע אופטימיזציה של המופעים על ידי הגדרת הערך של `max-concurrent-requests` לערך גבוה מ-10, שהוא ערך ברירת המחדל. כדי למצוא את הערך האופטימלי, מגדילים אותו בהדרגה ועוקבים אחרי הביצועים של האפליקציה.
`<manual-scaling>`	זה שינוי אופציונלי. הסבר מלא מופיע בקטע שינוי גודל ידני.
`<precompilation-enabled>`	זה שינוי אופציונלי. ‫App Engine משתמש בתהליך של "קומפילציה מראש" עם קוד הבייטים של Java באפליקציה כדי לשפר את הביצועים של האפליקציה בסביבת זמן הריצה של Java. קוד שעבר קומפילציה מראש פועל בדיוק כמו הבייטקוד המקורי. אם מסיבה כלשהי אתם מעדיפים שהאפליקציה שלכם לא תשתמש בהידור מראש, אתם יכולים להשבית את האפשרות הזו על ידי הוספת השורה הבאה לקובץ `appengine-web.xml`: <precompilation-enabled>false</precompilation-enabled>
`<module>`	הערה: השם של המודולים הוא עכשיו Services, והשירותים עדיין מוצהרים בקובצי `appengine-web.xml` כמודולים, לדוגמה: `<module>service_name</module>`. חובה אם יוצרים שירות. אופציונלי לשירות ברירת המחדל. לכל שירות ולכל גרסה צריך להיות שם. שם יכול להכיל מספרים, אותיות ומקפים. השם לא יכול להיות ארוך מ-63 תווים, הוא לא יכול להתחיל או להסתיים במקף, והוא לא יכול להכיל את המחרוזת ‎ `-dot`‎. צריך לבחור שם ייחודי לכל שירות ולכל גרסה. אל תשתמשו באותם שמות בשירותים ובגרסאות שונים. אפשר לעיין גם בשירות.
`<public-root>`	זה שינוי אופציונלי. ‫`<public-root>` היא תיקייה באפליקציה שמכילה את הקבצים הסטטיים של האפליקציה. כשמתקבלת בקשה לקובץ סטטי, ה-`<public-root>` של האפליקציה מתווסף לתחילת נתיב הבקשה. השדה הזה מציין את הנתיב של קובץ אפליקציה שמכיל את התוכן המבוקש. ערך ברירת המחדל `<public-root>` הוא `/`. לדוגמה, הפקודה הבאה תמפה את נתיב כתובת ה-URL‏ `/index.html` לנתיב האפליקציה `/static/index.html`: <public-root>/static</public-root>
`<resource-files>`	זה שינוי אופציונלי. אפשר לגשת לקבצים שמפורטים ברכיב `<resource-files>` באמצעות קוד האפליקציה דרך מערכת הקבצים. הקבצים האלה מאוחסנים בשרתי האפליקציות עם האפליקציה, בניגוד לאופן שבו קבצים סטטיים מאוחסנים ומוצגים. רכיב `<resource-files>` יכול להכיל את הרכיבים הבאים: `<include>` רכיב `<include>` מציין שהקבצים הם קובצי משאבים ושהם זמינים לקוד האפליקציה. הקבצים האלה זמינים לקוד רק לקריאה, ולא להצגת תנועה. הכללה והחרגה של קבצים. `<exclude>` קבצים וספריות שתואמים לתבניות `<exclude>` לא יועלו ולא יהיו זמינים לקוד של האפליקציה. עם זאת, האפליקציה תוכל לגשת לקבצים ולספריות האלה כשהיא תפעל בשרת הפיתוח המקומי. מידע נוסף זמין במאמר בנושא הכללה והחרגה של קבצים. לדוגמה: <resource-files> <include path="/.xml" /> <exclude path="/feeds/.xml" /> </resource-files> בדוגמה הזו אנחנו מראים איך להגדיר את כל קובצי `.xml` כקבצי משאבים, למעט הקבצים שבספרייה `feeds/` ובכל ספריות המשנה שלה. קריאת קובצי משאבים של App Engine מתבצעת באמצעות `java.io.File` או `javax.servlet.ServletContext.getResource/getResourceAsStream`. אי אפשר לגשת אליהם באמצעות `Class.getResourceAsStream()`.
`<runtime>`	כדי להשתמש בגרסה העדכנית ביותר של Java שנתמכת, צריך לציין את הערך הזה עם הערך `java25`. לדוגמה: <runtime>java25</runtime>
`<service>`	השירותים נקראו בעבר מודולים. הגדרת שירות באופן הבא: `<service>service_name</service >` נתמכת רק בפקודות של gcloud app.
`<service-account>`	זה שינוי אופציונלי. רכיב `<service-account>` מאפשר לציין חשבון שירות שמנוהל על ידי משתמש כזהות של הגרסה. חשבון השירות שצוין ישמש לגישה לשירותים אחרים של Google Cloud Google ולביצוע משימות. לדוגמה: <service-account>[SERVICE_ACCOUNT_NAME]@[PROJECT_ID].iam.gserviceaccount.com</service-account>
`<sessions-enabled>`	זה שינוי אופציונלי. ‫App Engine כולל הטמעה של סשנים באמצעות ממשק הסשן של servlet. ההטמעה מאחסנת את נתוני הסשן ב-Datastore לצורך שמירה, ומשתמשת גם ב-memcache כדי להגביר את המהירות. בדומה לרוב מאגרי ה-servlet האחרים, מאפייני הסשן שמוגדרים באמצעות ‎ `session.setAttribute()`‎ במהלך הבקשה נשמרים בסוף הבקשה. התכונה הזו מושבתת כברירת מחדל. כדי להפעיל את האפשרות, מוסיפים את השורה הבאה אל `appengine-web.xml`: לדוגמה: <sessions-enabled>true</sessions-enabled> ההטמעה יוצרת ישויות Datastore מסוג `_ah_SESSION`, ורשומות במטמון באמצעות מפתחות עם קידומת של `_ahs`. אפשר למחוק את הישויות האלה באמצעות תבנית Dataflow. הערה: מכיוון ש-App Engine מאחסן נתוני סשן ב-Datastore וב-memcache, כל הערכים שמאוחסנים בסשן צריכים להטמיע את הממשק `java.io.Serializable`. במאמר בנושא רכיב `async-session-persistence` מוסבר איך לקצר את זמן האחזור של אחסון נתוני הסשן.
`<ssl-enabled>`	זה שינוי אופציונלי. כברירת מחדל, כל משתמש יכול לגשת לכל כתובת URL באמצעות HTTP או HTTPS. אפשר להגדיר אפליקציה כך שיידרש HTTPS לכתובות URL מסוימות בקובץ תיאור הפריסה. מידע נוסף אם רוצים לאסור את השימוש ב-HTTPS באפליקציה, צריך להוסיף את השורה הבאה לקובץ `appengine-web.xml`: <ssl-enabled>false</ssl-enabled> בסביבת זמן הריצה של Java, אין אפשרות להשבית את HTTPS עבור נתיבי כתובות URL מסוימים ולא עבור אחרים.
`<static-error-handlers>`	זה שינוי אופציונלי. כשמתרחשות שגיאות מסוימות, App Engine מציג דף שגיאה גנרי. אתם יכולים להגדיר את האפליקציה כך שתציג קובץ סטטי מותאם אישית במקום דפי השגיאה הכלליים האלה, בתנאי שנתוני השגיאה המותאמים אישית קטנים מ-10 קילובייט. אפשר להגדיר קבצים סטטיים שונים שיוצגו לכל קוד שגיאה נתמך. כדי לעשות זאת, צריך לציין את הקבצים בקובץ `appengine-web.xml` של האפליקציה. כדי להציג דפי שגיאה מותאמים אישית, מוסיפים קטע `<static-error-handlers>` ל-`appengine-web.xml`, כמו בדוגמה הזו: <static-error-handlers> <handler file="default_error.html" /> <handler file="over_quota.html" error-code="over_quota" /> </static-error-handlers> אזהרה: חשוב לוודא שהנתיב לקובץ תגובת השגיאה לא חופף לנתיבים של קובצי handler סטטיים. כל ערך `file` מציין קובץ סטטי שצריך להציג במקום תגובת השגיאה הגנרית. התג `error-code` מציין איזה קוד שגיאה צריך לגרום להצגת הקובץ המשויך. אלה קודי השגיאה הנתמכים: `over_quota` מציין שהאפליקציה חרגה ממכסת המשאבים. `timeout` המודעה מוצגת אם מגיע מועד סיום לפני שמתקבלת תשובה מהאפליקציה. השדה `error-code` הוא אופציונלי. אם לא מציינים אותו, הקובץ שצוין הוא תגובת השגיאה שמוגדרת כברירת מחדל לאפליקציה. אפשר גם לציין `mime-type` שבו ישתמשו כשמוצגת השגיאה המותאמת אישית. רשימה מלאה של סוגי MIME
`<static-files>`	זה שינוי אופציונלי. רכיב `<static-files>` מציין תבניות שתואמות לנתיבי קבצים שצריך לכלול או להחריג מרשימת הקבצים הסטטיים, ומבטל או משנה את התנהגות ברירת המחדל. קובץ סטטי מוגש משרתים וממטמונים ייעודיים, נפרדים משרתי האפליקציות, והוא שימושי להגשת תוכן סטטי כמו תמונות, גיליונות סגנונות של CSS או קובצי JavaScript. רכיב `<static-files>` יכול להכיל את הרכיבים הבאים: `<include>` רכיב `<include>` מבטל את התנהגות ברירת המחדל של הכללת כל הקבצים שאינם JSP. רכיב `<include>` יכול לציין כותרות HTTP לשימוש בתגובה לבקשה למשאבים שצוינו. מידע נוסף זמין במאמר בנושא הכללה והחרגה של קבצים. אפשר לשנות את ברירת המחדל של תפוגת המטמון הסטטי על ידי ציון המאפיין `expiration` ברכיב include. הערך הוא מחרוזת של מספרים ויחידות, שמופרדים באמצעות רווחים. היחידות יכולות להיות `d` לימים, `h` לשעות, `m` לדקות ו-`s` לשניות. לדוגמה, `"4d 5h"` מגדיר את תפוגת המטמון ל-4 ימים ו-5 שעות אחרי שהקובץ נדרש בפעם הראשונה. מידע נוסף זמין במאמר בנושא תפוגה של מטמון. `<exclude>` קבצים וספריות שתואמים לתבניות `<exclude>` לא יועלו כשפורסים את האפליקציה ב-App Engine. עם זאת, עדיין תהיה לאפליקציה גישה לקבצים ולספריות האלה כשהיא תפעל בשרת הפיתוח המקומי. מידע נוסף זמין במאמר בנושא הכללה והחרגה של קבצים. דוגמה <static-files> <include path="/my_static-files" > <http-header name="Access-Control-Allow-Origin" value="http://example.org" /> </include> </static-files>
`<system-properties>`	זה שינוי אופציונלי. בקובץ `appengine-web.xml` אפשר להגדיר מאפייני מערכת ומשתני סביבה שמוגדרים כשהאפליקציה פועלת. <system-properties> <property name="myapp.maximum-message-length" value="140" /> <property name="myapp.notify-every-n-signups" value="1000" /> <property name="myapp.notify-url" value="http://www.example.com/signupnotify" /> </system-properties> <env-variables> <env-var name="DEFAULT_ENCODING" value="UTF-8" /> </env-variables> זה שינוי אופציונלי. אתם יכולים להגדיר מחבר HTTP כדי לשפר את השימוש במעבד ובזיכרון. אם האפליקציה שלכם מבצעת אינטראקציה עם פעולות של Datastore או Task Queues, כדאי להגדיר מעקב כדי לעקוב אחרי ההשפעות על הביצועים וההתנהגות אחרי הפעלת התכונה הזו. <system-properties> <property name="appengine.use.httpconnector" value="true"/> </system-properties> זה שינוי אופציונלי. אפשר להגדיר את זמן הריצה הבסיסי של Java 17 כך שיפעל ב-EE 8, את Java 21 ב-EE 10 או את Java 25 ב-EE 11 באמצעות מאפיין המערכת הבא. מידע נוסף על תמיכה ב-EE זמין במאמר שדרוג Java בגרסה תואמת של Enterprise Edition‏ (EE). ‫ <system-properties> <property name="appengine.use.EE11" value="true"/><!--only for Java 25--> </system-properties> החל מ-Java 21, אפשר להגדיר את שרת האינטרנט של Java לשימוש בשרשורים וירטואליים. לדוגמה: <system-properties> <property name="appengine.use.virtualthreads" value="true"/> </system-properties> מידע נוסף על תמיכה בשרשורים זמין במאמר Jetty 12 – Virtual Threads Support.
`<url-stream-handler>`	זה שינוי אופציונלי. הערכים האפשריים הם `native` או `urlfetch`. ערך ברירת המחדל הוא `native`, כלומר מחלקות רשת רגילות של Java משתמשות בהעברת HTTP(S) רגילה של Java. כדי להשתמש בהגדרה הזו, צריך להפעיל את החיוב על האפליקציה. אחרת, יתקבלו חריגים שמפורטים במאמר בנושא בקשות לבעיות. אם מגדירים את `url-stream-handler` ל-`urlfetch`,‏ `URL.openConnection` ושיטות קשורות ישתמשו באחזור כתובות URL להעברת `http` ו-`https`. <url-stream-handler>urlfetch</url-stream-handler>
`<version>`	הרכיב `<version>` מכיל את מזהה הגרסה של הגרסה האחרונה של קוד האפליקציה. מזהה הגרסה יכול להכיל אותיות קטנות, ספרות ומקפים. השם לא יכול להתחיל בקידומת ah- והשמות default ו-latest שמורים ואי אפשר להשתמש בהם. שמות הגרסאות צריכים להתחיל באות, כדי להבדיל אותם ממופעים מספריים שתמיד מצוינים על ידי מספר. כך נמנעת דו-משמעות בכתובות URL כמו `123.my-module.uc.r.appspot.com`, שאפשר לפרש אותן בשתי דרכים: אם קיימת גרסה 123, היעד יהיה גרסה 123 של המודול הנתון. אם הגרסה הזו לא קיימת, היעד יהיה מופע מספר 123 של גרסת ברירת המחדל של המודול.
`<warmup-requests-enabled>`	זה שינוי אופציונלי. ברירת מחדל: true. בקשות חימום מופעלות כברירת מחדל באפליקציות Java. אם מפעילים בקשות הפעלה, התשתית של App Engine שולחת בקשות GET אל `/_ah/warmup`, ומבצעת אתחול של רכיבי servlet‏ `<load-on-startup>`,‏ `ServletContextListeners` ורכיבי servlet מותאמים אישית להפעלה. כך אפשר לבצע אתחול של הקוד של האפליקציה לפי הצורך. יכול להיות שתצטרכו להטמיע handler משלכם עבור `/_ah/warmup`, בהתאם לשיטה שתבחרו. כדי להשבית את בקשות החימום, מציינים `false` ברכיב הזה: <warmup-requests-enabled>false</warmup-requests-enabled>
`<vpc-access-connector>`	זה שינוי אופציונלי. הגדרת האפליקציה לשימוש במחבר של חיבור לרשת (VPC) מאפליקציית serverless, כדי לאפשר לאפליקציה לשלוח בקשות למשאבים פנימיים ברשת ה-VPC. מציינים את השם המלא של המחבר ברכיב `<name>`: <vpc-access-connector> <name>projects/[PROJECT_ID]/locations/[REGION]/connectors/[CONNECTOR_NAME]</name> </vpc-access-connector> מידע נוסף זמין במאמר התחברות למשאבים פנימיים ברשת VPC.

שינוי גודל של אלמנטים

בטבלה הבאה מפורטות האפשרויות להגדרת האופן שבו האפליקציה שלכם צריכה להתרחב.

השוואה בין תכונות הביצועים של סוגי ההתאמה לגודל

רכיב תיאור

רכיב	תיאור
`<automatic-scaling>`	זה שינוי אופציונלי. כברירת מחדל, המערכת מניחה שמתבצעת התאמה אוטומטית לעומס, עם סוג ברירת מחדל של מופע `F1`, אלא אם צוין אחרת. רכיב `automatic_scaling` מגדיר רמות מינימליות ומקסימליות של מספר המופעים, זמן האחזור והחיבורים בו-זמנית של מודול. האלמנט הזה יכול להכיל את האלמנטים הבאים: `<target-cpu-utilization>` אופציונלי. מציינים ערך בין 0.5 ל-0.95. הפרמטר הזה מציין את סף השימוש במעבד שמעליו יופעלו מופעים חדשים כדי לטפל בתנועה. כך אפשר לאזן בין ביצועים לעלות: ערכים נמוכים משפרים את הביצועים ומגדילים את העלות, וערכים גבוהים מפחיתים את הביצועים אבל גם את העלות. לדוגמה, ערך של 0.7 אומר שמופעים חדשים יופעלו אחרי ששימוש המעבד יגיע ל-70%. `<target-throughput-utilization>` אופציונלי. מציינים ערך בין 0.5 ל-0.95. המאפיין הזה משמש עם `max-concurrent-requests` כדי לציין מתי מופעלת מכונה וירטואלית חדשה בגלל בקשות מקבילות. כאשר מספר הבקשות המקבילות מגיע לערך ששווה ל-`max-concurrent-requests` כפול `target-throughput-utilization`, מתזמן המשימות מפעיל מופע חדש. `<max-instances>` אופציונלי. מספר המופעים המקסימלי ש-App Engine יכול ליצור עבור גרסת האפליקציה הזו. כדאי להשתמש בזה כדי להגביל את העלויות של מודול. מציינים ערך בין 0 ל-2147483647. `<min-instances>` אופציונלי. מספר המופעים המינימלי ש-App Engine צריך ליצור לגרסת המודול הזו. המופעים האלה מציגים תנועה כשהבקשות מגיעות, וממשיכים להציג תנועה גם כשמופעים נוספים מופעלים לפי הצורך כדי לטפל בתנועה. מציינים ערך בין 0 ל-1,000. אפשר להגדיר את הפרמטר לערך 0 כדי לאפשר שינוי קנה מידה ל-0 מופעים, וכך להפחית את העלויות כשלא מתבצעות בקשות. חשוב לדעת שאתם מחויבים על מספר המקרים שצוין, בין אם הם מקבלים תנועה ובין אם לא. `<max-concurrent-requests>` זה שינוי אופציונלי. מספר הבקשות בו-זמניות שמופע של התאמה אוטומטית לעומס יכול לקבל לפני שתזמן יצירת מופע חדש (ברירת מחדל: 10, מקסימום: 80). אם ההגדרה הזו גבוהה מדי, יכול להיות שזמן האחזור של ה-API יתארך. שימו לב: יכול להיות שהמתזמן ייצור מופע חדש לפני שיושג המספר המקסימלי בפועל של בקשות. הערה: אם הערך של `instance-class` מוגדר כ-`F2` או יותר, אפשר לבצע אופטימיזציה של המופעים על ידי הגדרת הערך של `max-concurrent-requests` כערך גבוה מ-10, שהוא ערך ברירת המחדל. כדי למצוא את הערך האופטימלי, מגדילים אותו בהדרגה ועוקבים אחרי הביצועים של האפליקציה. `<max-idle-instances>` המספר המקסימלי של מופעים לא פעילים ש-App Engine צריך לשמור לגרסה הזו. ערך ברירת המחדל הוא 'אוטומטי'. חשוב לזכור: ערך מקסימלי גבוה יותר יקטין את מספר המכונות הווירטואליות הלא פעילות בצורה הדרגתית יותר כשרמות העומס יחזרו למצב נורמלי אחרי עלייה חדה. השיטה הזו עוזרת לאפליקציה לשמור על ביצועים יציבים גם כשיש תנודות בעומס הבקשות, אבל היא גם מגדילה את מספר המופעים הלא פעילים (ואת עלויות ההפעלה שנובעות מכך) בתקופות של עומס כבד. הגדרת ערך מקסימלי נמוך מאפשרת לשמור על עלויות הפעלה נמוכות, אבל עלולה לפגוע בביצועים במקרים של עומסי תנועה משתנים. הערה: כשחוזרים לרמות רגילות אחרי עלייה פתאומית בעומס, יכול להיות שמספר המקרים הלא פעילים יעלה באופן זמני על המספר המקסימלי שהגדרתם. עם זאת, לא נחייב אתכם על יותר מופעים מהמספר המקסימלי שציינתם. `<max-pending-latency>` כמות הזמן המקסימלית ש-App Engine צריך לאפשר לבקשה להמתין בתור להמתנה לפני הפעלת מופעים נוספים לטיפול בבקשות, כדי לצמצם את זמן האחזור של בקשות בהמתנה. ערך נמוך של המקסימום אומר ש-App Engine יתחיל מופעים חדשים מוקדם יותר עבור בקשות בהמתנה, מה שישפר את הביצועים אבל יעלה את עלויות ההפעלה. ערך מקסימלי גבוה אומר שאם יש בקשות בהמתנה ואין מופעים פנויים שיכולים לטפל בהן, המשתמשים יצטרכו לחכות יותר זמן עד שהבקשות שלהם יטופלו, אבל העלות של הפעלת האפליקציה תהיה נמוכה יותר. `<min-idle-instances>` מספר המקרים שצריכים להמשיך לפעול ולהיות מוכנים להצגת תנועה.ההגדרה הזו חלה רק על הגרסה שמקבלת את רוב התנועה. חשוב לזכור: ערך מינימלי נמוך עוזר לשמור על עלויות ההפעלה נמוכות בתקופות של חוסר פעילות, אבל המשמעות היא שפחות מופעים עשויים להיות זמינים באופן מיידי כדי להגיב לעלייה פתאומית בעומס. ערך מינימלי גבוה מאפשר לכם להכין את האפליקציה לעליות חדות ומהירות בעומס הבקשות. ‫App Engine שומר על מספר מינימלי של מופעים פעילים כדי לטפל בבקשות נכנסות. החיוב הוא על מופעים, בין אם הם מטפלים בבקשות ובין אם לא. כדי שהתכונה הזו תפעל כמו שצריך, צריך לוודא ש בקשות חימום מופעלות ושהאפליקציה מטפלת בבקשות חימום. אם מגדירים מספר מינימלי של מופעים לא פעילים, לזמן האחזור של בקשות בהמתנה תהיה השפעה פחותה על ביצועי האפליקציה. מכיוון ש-App Engine שומר מכונות במצב המתנה, סביר להניח שהבקשות לא ייכנסו לתור ההמתנה, אלא אם יהיו עליות חדות בעומס. כדי לקבוע את מספר המופעים האידיאלי שצריך לשמור, תצטרכו לבדוק את האפליקציה ואת נפח התנועה הצפוי. `<min-pending-latency>` משך הזמן המינימלי בשניות שבו מערכת App Engine צריכה לאפשר לבקשה להמתין בתור להמתנה לפני שהיא מתחילה מופע חדש כדי לטפל בה. מציינים ערך בין 0.01 ל-15. מינימום נמוך אומר שהבקשות צריכות לבלות פחות זמן בתור להמתנה כשכל המופעים הקיימים פעילים. כך משפרים את הביצועים, אבל מגדילים את העלות של הפעלת האפליקציה. אם המינימום גבוה, הבקשות יישארו בהמתנה למשך זמן ארוך יותר אם כל המקרים הקיימים פעילים. כך אפשר להקטין את עלויות ההפעלה, אבל משך הזמן שהמשתמשים צריכים לחכות עד שהבקשות שלהם יטופלו מתארך. דוגמה <appengine-web-app xmlns="http://appengine.google.com/ns/1.0"> <application>simple-app</application> <module>default</module> <version>uno</version> <instance-class>F2</instance-class> <automatic-scaling> <target-cpu-utilization>0.65</target-cpu-utilization> <min-instances>5</min-instances> <max-instances>100</max-instances> <max-concurrent-requests>50</max-concurrent-requests> </automatic-scaling> </appengine-web-app>
`<basic-scaling>`	זה שינוי אופציונלי. רכיב `<basic-scaling>` מגדיר את מספר המופעים של מודול. האלמנט הזה יכול להכיל את האלמנטים הבאים: `<idle-timeout>` אופציונלי. המופע יושבת אחרי פרק הזמן הזה, אחרי קבלת הבקשה האחרונה שלו. ערך ברירת המחדל הוא 5 דקות. `<max-instances>` שדה חובה. מספר המכונות המקסימלי ש-App Engine יכול ליצור עבור גרסת המודול הזו. כדאי להשתמש בזה כדי להגביל את העלויות של מודול. דוגמה <appengine-web-app xmlns="http://appengine.google.com/ns/1.0"> <application>simple-app</application> <module>default</module> <version>uno</version> <instance-class>B8</instance-class> <basic-scaling> <max-instances>11</max-instances> <idle-timeout>10m</idle-timeout> </basic-scaling> </appengine-web-app>
`<manual-scaling>`	זה שינוי אופציונלי. האלמנט `<manual-scaling>` מאפשר שינוי גודל ידני של מודול ומגדיר את מספר המופעים של מודול. האלמנט הזה יכול להכיל את האלמנטים הבאים: `<instances>` מספר המופעים להקצאה למודול בהתחלה. דוגמה <appengine-web-app xmlns="http://appengine.google.com/ns/1.0"> <application>simple-app</application> <module>default</module> <version>uno</version> <instance-class>B8</instance-class> <manual-scaling> <instances>5</instances> </manual-scaling> </appengine-web-app>

<automatic-scaling>

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

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

האלמנט הזה יכול להכיל את האלמנטים הבאים:

<target-cpu-utilization>

אופציונלי. מציינים ערך בין 0.5 ל-0.95.

הפרמטר הזה מציין את סף השימוש במעבד שמעליו יופעלו מופעים חדשים כדי לטפל בתנועה. כך אפשר לאזן בין ביצועים לעלות: ערכים נמוכים משפרים את הביצועים ומגדילים את העלות, וערכים גבוהים מפחיתים את הביצועים אבל גם את העלות. לדוגמה, ערך של 0.7 אומר שמופעים חדשים יופעלו אחרי ששימוש המעבד יגיע ל-70%.

<target-throughput-utilization>

אופציונלי. מציינים ערך בין 0.5 ל-0.95.

המאפיין הזה משמש עם max-concurrent-requests כדי לציין מתי מופעלת מכונה וירטואלית חדשה בגלל בקשות מקבילות. כאשר מספר הבקשות המקבילות מגיע לערך ששווה ל-max-concurrent-requests כפול target-throughput-utilization, מתזמן המשימות מפעיל מופע חדש.

<max-instances>

אופציונלי. מספר המופעים המקסימלי ש-App Engine יכול ליצור עבור גרסת האפליקציה הזו. כדאי להשתמש בזה כדי להגביל את העלויות של מודול. מציינים ערך בין 0 ל-2147483647.

<min-instances>

אופציונלי. מספר המופעים המינימלי ש-App Engine צריך ליצור לגרסת המודול הזו. המופעים האלה מציגים תנועה כשהבקשות מגיעות, וממשיכים להציג תנועה גם כשמופעים נוספים מופעלים לפי הצורך כדי לטפל בתנועה.

מציינים ערך בין 0 ל-1,000. אפשר להגדיר את הפרמטר לערך 0 כדי לאפשר שינוי קנה מידה ל-0 מופעים, וכך להפחית את העלויות כשלא מתבצעות בקשות. חשוב לדעת שאתם מחויבים על מספר המקרים שצוין, בין אם הם מקבלים תנועה ובין אם לא.

<max-concurrent-requests>

זה שינוי אופציונלי. מספר הבקשות בו-זמניות שמופע של התאמה אוטומטית לעומס יכול לקבל לפני שתזמן יצירת מופע חדש (ברירת מחדל: 10, מקסימום: 80).

אם ההגדרה הזו גבוהה מדי, יכול להיות שזמן האחזור של ה-API יתארך. שימו לב: יכול להיות שהמתזמן ייצור מופע חדש לפני שיושג המספר המקסימלי בפועל של בקשות.

הערה: אם הערך של instance-class מוגדר כ-F2 או יותר, אפשר לבצע אופטימיזציה של המופעים על ידי הגדרת הערך של max-concurrent-requests כערך גבוה מ-10, שהוא ערך ברירת המחדל. כדי למצוא את הערך האופטימלי, מגדילים אותו בהדרגה ועוקבים אחרי הביצועים של האפליקציה.

<max-idle-instances>

המספר המקסימלי של מופעים לא פעילים ש-App Engine צריך לשמור לגרסה הזו. ערך ברירת המחדל הוא 'אוטומטי'. חשוב לזכור:

ערך מקסימלי גבוה יותר יקטין את מספר המכונות הווירטואליות הלא פעילות בצורה הדרגתית יותר כשרמות העומס יחזרו למצב נורמלי אחרי עלייה חדה. השיטה הזו עוזרת לאפליקציה לשמור על ביצועים יציבים גם כשיש תנודות בעומס הבקשות, אבל היא גם מגדילה את מספר המופעים הלא פעילים (ואת עלויות ההפעלה שנובעות מכך) בתקופות של עומס כבד.
הגדרת ערך מקסימלי נמוך מאפשרת לשמור על עלויות הפעלה נמוכות, אבל עלולה לפגוע בביצועים במקרים של עומסי תנועה משתנים.

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

<max-pending-latency>

כמות הזמן המקסימלית ש-App Engine צריך לאפשר לבקשה להמתין בתור להמתנה לפני הפעלת מופעים נוספים לטיפול בבקשות, כדי לצמצם את זמן האחזור של בקשות בהמתנה.

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

<min-idle-instances>

מספר המקרים שצריכים להמשיך לפעול ולהיות מוכנים להצגת תנועה.ההגדרה הזו חלה רק על הגרסה שמקבלת את רוב התנועה. חשוב לזכור:

ערך מינימלי נמוך עוזר לשמור על עלויות ההפעלה נמוכות בתקופות של חוסר פעילות, אבל המשמעות היא שפחות מופעים עשויים להיות זמינים באופן מיידי כדי להגיב לעלייה פתאומית בעומס.
ערך מינימלי גבוה מאפשר לכם להכין את האפליקציה לעליות חדות ומהירות בעומס הבקשות. ‫App Engine שומר על מספר מינימלי של מופעים פעילים כדי לטפל בבקשות נכנסות. החיוב הוא על מופעים, בין אם הם מטפלים בבקשות ובין אם לא. כדי שהתכונה הזו תפעל כמו שצריך, צריך לוודא ש בקשות חימום מופעלות ושהאפליקציה מטפלת בבקשות חימום.

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

<min-pending-latency>

משך הזמן המינימלי בשניות שבו מערכת App Engine צריכה לאפשר לבקשה להמתין בתור להמתנה לפני שהיא מתחילה מופע חדש כדי לטפל בה. מציינים ערך בין 0.01 ל-15.

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

דוגמה

<appengine-web-app xmlns="http://appengine.google.com/ns/1.0">
  <application>simple-app</application>
  <module>default</module>
  <version>uno</version>
  <instance-class>F2</instance-class>
  <automatic-scaling>
    <target-cpu-utilization>0.65</target-cpu-utilization>
    <min-instances>5</min-instances>
    <max-instances>100</max-instances>
    <max-concurrent-requests>50</max-concurrent-requests>
  </automatic-scaling>
</appengine-web-app>

<basic-scaling>

זה שינוי אופציונלי. רכיב <basic-scaling> מגדיר את מספר המופעים של מודול.

האלמנט הזה יכול להכיל את האלמנטים הבאים:

<idle-timeout>: אופציונלי. המופע יושבת אחרי פרק הזמן הזה, אחרי קבלת הבקשה האחרונה שלו. ערך ברירת המחדל הוא 5 דקות.
<max-instances>: שדה חובה. מספר המכונות המקסימלי ש-App Engine יכול ליצור עבור גרסת המודול הזו. כדאי להשתמש בזה כדי להגביל את העלויות של מודול.

דוגמה

<appengine-web-app xmlns="http://appengine.google.com/ns/1.0">
  <application>simple-app</application>
  <module>default</module>
  <version>uno</version>
  <instance-class>B8</instance-class>
  <basic-scaling>
    <max-instances>11</max-instances>
    <idle-timeout>10m</idle-timeout>
  </basic-scaling>
</appengine-web-app>

<manual-scaling>

זה שינוי אופציונלי. האלמנט <manual-scaling> מאפשר שינוי גודל ידני של מודול ומגדיר את מספר המופעים של מודול.

האלמנט הזה יכול להכיל את האלמנטים הבאים:

<instances>: מספר המופעים להקצאה למודול בהתחלה.

דוגמה

<appengine-web-app xmlns="http://appengine.google.com/ns/1.0">
  <application>simple-app</application>
  <module>default</module>
  <version>uno</version>
  <instance-class>B8</instance-class>
  <manual-scaling>
    <instances>5</instances>
  </manual-scaling>
</appengine-web-app>

אלמנטים של Staging

חלק גדול מהעבודה שמתבצעת במהלך פריסה מתרחש באופן מקומי בשלב הכנה שנקרא העברה לבמה, שבו קובצי JAR מורכבים, קובצי JSP עוברים קומפילציה וכן הלאה. אפשר גם להגדיר חלקים מסוימים בהתנהגות של הסביבה הזמנית באמצעות רכיבים של הסביבה הזמנית בקובץ ההגדרות של האפליקציה. רוב האפליקציות יופעלו בהצלחה בלי שתצטרכו להגדיר ידנית את אופן הפעולה של הסביבה הזמנית. אם האפליקציה לא נפרסת, יכול להיות שתצטרכו להגדיר את הסביבה הזמנית באמצעות האפשרויות שמופיעות בטבלה הבאה.

רכיב תיאור

רכיב	תיאור
`<staging>`	זה שינוי אופציונלי. ברוב האפליקציות אין צורך לשנות את התנהגות ברירת המחדל. רכיב ההכנה מאפשר לציין הגדרת הכנה ספציפית אם נדרש כזה לצורך פריסה. האלמנט הזה יכול להכיל את האלמנטים הבאים: `<enable-jar-splitting>` זה שינוי אופציונלי. מפצלים קובצי JAR גדולים (גדולים מ-10 מגה-בייט) לחלקים קטנים יותר. (ברירת מחדל: true). `<jar-splitting-excludes>` מציינת רשימה מופרדת בפסיקים של סיומות קבצים. אם האפשרות `enable-jar-splitting` מופעלת, כל הקבצים שתואמים לסיומות לא ייכללו בכל קובצי ה-JAR. `<disable_jar_jsps>` לא ליצור קובץ JAR של כיתות שנוצרו מ-JSP. (ברירת מחדל: false). `<enable-jar-classes>` יוצרים קובץ JAR של התוכן של WEB-INF/classes. (ברירת מחדל: true). `<delete-jsps>` מוחקים את קובצי המקור של JSP אחרי ההידור. (ברירת מחדל: true). `<compile-encoding>` קידוד הקלט של קובצי המקור לקומפילציה. (ברירת מחדל: utf-8). לדוגמה: <staging> <delete-jsps>false</delete-jsps> </staging>

<staging>

זה שינוי אופציונלי. ברוב האפליקציות אין צורך לשנות את התנהגות ברירת המחדל.

רכיב ההכנה מאפשר לציין הגדרת הכנה ספציפית אם נדרש כזה לצורך פריסה.

האלמנט הזה יכול להכיל את האלמנטים הבאים:

<enable-jar-splitting>: זה שינוי אופציונלי. מפצלים קובצי JAR גדולים (גדולים מ-10 מגה-בייט) לחלקים קטנים יותר. (ברירת מחדל: true).
<jar-splitting-excludes>: מציינת רשימה מופרדת בפסיקים של סיומות קבצים. אם האפשרות enable-jar-splitting מופעלת, כל הקבצים שתואמים לסיומות לא ייכללו בכל קובצי ה-JAR.
<disable_jar_jsps>: לא ליצור קובץ JAR של כיתות שנוצרו מ-JSP. (ברירת מחדל: false).
<enable-jar-classes>: יוצרים קובץ JAR של התוכן של WEB-INF/classes. (ברירת מחדל: true).
<delete-jsps>: מוחקים את קובצי המקור של JSP אחרי ההידור. (ברירת מחדל: true).
<compile-encoding>: קידוד הקלט של קובצי המקור לקומפילציה. (ברירת מחדל: utf-8).

לדוגמה:

        <staging>
          <delete-jsps>false</delete-jsps>
        </staging>

ברירות מחדל של אפשרויות ההעברה לסביבת הפיתוח

הגדרות ברירת המחדל לאפשרויות ההעברה לבמה משתנות בהתאם לכלי שבו משתמשים: כלי שמבוסס על Google Cloud SDK, כמו ה-CLI של gcloud, או תוספים שמבוססים על Google Cloud SDK‏: Maven,‏ Gradle או IntelliJ.

רכיב Staging	הגדרות ברירת מחדל מבוססות SDK של App Engine –	ברירות מחדל שמבוססות על Google Cloud SDK
`enable-jar-splitting`	`false`	`true`
`jar-splitting-excludes`	לא רלוונטי	לא רלוונטי
`disable-jar-jsps`	`false`	`false`
`enable-jar-classes`	`false`	‫`true`. זה יכול להשפיע על סדר טעינת המחלקות, לכן אם האפליקציה שלכם תלויה בסדר מסוים באמצעות ברירת המחדל הקודמת `false`, אתם יכולים להגדיר את זה ל-`false`.
`delete-jsps`	`false`	`true`
`compile-encoding`	`utf-8`	`utf-8`

תחביר של הכללה והחרגה

תבניות נתיב מצוינות באמצעות אפס רכיבי <include> או יותר ורכיבי <exclude>. בתבנית, '*' מייצג אפס או יותר מכל תו בשם של קובץ או ספרייה, ו-** מייצג אפס או יותר ספריות בנתיב. קבצים וספריות שתואמים לתבניות <exclude> לא יועלו כשפורסים את האפליקציה ב-App Engine. עם זאת, האפליקציה שלכם עדיין תוכל לגשת לקבצים ולספריות האלה כשהיא פועלת בשרת הפיתוח המקומי.

רכיב <include> מבטל את התנהגות ברירת המחדל של הכללת כל הקבצים. רכיב <exclude> חל אחרי כל התבניות של <include> (וגם אחרי ברירת המחדל אם לא סופק <include> מפורש).

בדוגמה הבאה מוצג איך להגדיר את כל הקבצים png כקבצים סטטיים (חוץ מאלה שבספרייה data/ ובכל תיקיות המשנה שלה):

<static-files>
  <include path="/**.png" />
  <exclude path="/data/**.png" />
</static-files>

אפשר גם להגדיר כותרות HTTP לשימוש בתגובה לבקשות למשאבים סטטיים.

<static-files>
  <include path="/my_static-files" >
    <http-header name="Access-Control-Allow-Origin"
                 value="http://example.org" />
  </include>
</static-files>

סוגי MIME לקבצים סטטיים

כברירת מחדל, קבצים סטטיים מוגשים באמצעות סוג MIME שנבחר על סמך הסיומת בשם הקובץ. אתם יכולים לשייך סוגי MIME מותאמים אישית לתוספי שמות קבצים עבור קבצים סטטיים באמצעות רכיבי mime-mapping ב-web.xml.

פסק זמן ב-URLFetch

אפשר להגדיר מועד אחרון לכל בקשת URLFetch. כברירת מחדל, הדדליין לאחזור הוא 5 שניות. אפשר לשנות את ברירת המחדל הזו על ידי הכללת ההגדרה הבאה בקובץ ההגדרות appengine-web.xml. מציינים את הזמן הקצוב לתפוגה בשניות:

<system-properties>
    <property name="appengine.api.urlfetch.defaultDeadline" value="10"/>
</system-properties>

מאמרי עזרה בנושא appengine-web.xml קל לארגן דפים בעזרת אוספים אפשר לשמור ולסווג תוכן על סמך ההעדפות שלך.

מזהה אזור

תחביר

שינוי גודל של אלמנטים

אלמנטים של Staging

ברירות מחדל של אפשרויות ההעברה לסביבת הפיתוח

תחביר של הכללה והחרגה

סוגי MIME לקבצים סטטיים

פסק זמן ב-URLFetch

מאמרי עזרה בנושא appengine-web.xml