Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

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

מזהה אזור

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

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

צריך להשתמש בקובץ appengine-web.xml כדי להגדיר את האפליקציה רק אם מעבירים אפליקציה קיימת מסביבת זמן ריצה של Java 8 ב-App Engine לגרסה הנתמכת האחרונה של 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>`	זה שינוי אופציונלי. הסבר מלא מופיע בקטע בנושא שינוי גודל אוטומטי.
`<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 Fetch להעברה של `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 מותאמים אישית להפעלה. כך אפשר לבצע אתחול של הקוד של האפליקציה לפי הצורך. יכול להיות שתצטרכו להטמיע מטפל משלכם עבור `/_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	הגדרות ברירת מחדל שמבוססות על App Engine SDK –	ברירות מחדל שמבוססות על 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