"לעבוד" על jacoco בעזרת lambda?

[TakeCtrl]

בנוסף לכך גם לappender עצמו יש trehshold

(במוצר שאנחנו משתמשים בו יש את זה), נגיד שאיכפת לך לראות errors ושלא ייעלמו לך בהצפות.. אתה מגדיר 2 appender לאותו לוגר, ואחר מהם מעביר לtreshold error ואז יש לך קובץ של רק errors.
&nbsp
בנתיים אגב, הטענות של הexception N מפריעים מגיעות רק ממפתחים אחרים (או יותר נכון מפתחת אחת...)

 

[choo]

ובגלל מפתחת אחת אתה חוסם את יכולתך לדבג בעיות?

 

[TakeCtrl]

היא מפתחת "עסבנית" והיא הרימה מספיק צעקות על זה

והראש צוות שלי רוצה להיות בסדר עם כולם ולזה לא נראה מספיק חשוב להשאר על זה..
ברנשית נחמדה בדרך כלל אבל עם פיוז קצר. והיא שם הרבה זמן . זו גם אחת הסיבות שאני נמנע לעשות איתה code review. כשאני אומר לQA שלנו שהתנגד למונח שמציגים בUI שיילך להסביר לה את זה הוא עונה בצחוק " לא, מה פתאום אני רוצה לחזור הבייתה בשלום"
&nbsp
היה לי מספיק קרבות רק על הנטייה שלי לשים final במשתנים. אז אני חושב פעמיים עכשיו על כל שינוי דרסטי שאני רוצה לעשות, לדוגמא, כל , אבל כל ההגדרות שלנו בxsd הינם ref
של simpletype מוגדרים במקום , כלומר כל פעם שאתה רוצה להוסיף property חדש, אתה חייב להגדיר אותו במקום גלובלי ואז בelement לשים אותו כref לאותו אחד. בין אם זה name של משהו אפילו, היא התנגדה באופן מאוד חזק למשהו אחר לא סגור בסוף מה החלטנו.
לא הייית אף פעם במקום עבודה עם אנשי צוות "בולטים"?

 

[choo]

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

&nbsp
אם מישהו מתעקש על צורת קידוד שמונעת ממני ארת היכולת לדבג, אני אחפש פשרה שתתאים לשנינו, או שאעקוף אותו (הצורה שתארתי עם שני הלוגים, היא דוגמא לפשרה/עקיפה כזו). אני לא אתווכח איתו (לפחות לא בהתחלה) על דברים שלא באמת מונעים ממני לעבוד - אבל בדברים שמונעים ממני את היכולת לעבוד - אני לא אוותר ואמצע דרך להכניס אותם.

 

[טרול המתכנן]

זו נשמעת לי גישה אנכרוניסטית. יש מספיק log viewers חינמיים

מי שלא רוצה לראות הודעות debug מסמן exclude DEBUG וסיימנו.
קשה להפיק תועלת מקובץ של "רק דיבאג" לא? חלק מה flow שלך יהיה ברמת לוג אחרת.

 

[user32]

דווקא מאוד פרקטי

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

 

[טרול המתכנן]

התוצאה היא או שאתה משכפל קוד

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

לא מבין באיזו סיטואציה זה פתרון ראוי.

 

[טרול המתכנן]

סליחה ראיתי עכשיו ש choo כתב "מרמת debug ומעלה"

פיספסתי את ה ומעלה הזה.
טוב את זה אני יכול להבין איכשהו. יכול לדמיין use case.

 

[choo]

זו דוגמא ל"קריאת הכותרת בלבד"

&nbsp
הצעתי לכתוב סקריפט לסינון הלוגים בתור הצעה חלופית. תן לשואל המקורי לבחור את הפתרון שמתאים לו.

 

[user32]

* אלה שעוטפים את הלוגר ב"לוגר משלנו" *

 

[TakeCtrl]

נו, לפחות זה נוח לעשות שינויים דרסטיים....

 

[אוהב להתווכח]

למה זה כזה נורא?

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

 

[user32]

תשובה

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

לא יודע עם איזה לוגר עבדת אבל כמעט כל לוגר מאפשר להגדיר בקובץ או בכל דרך אחרת את רמת הלוג עבור package, class מסויים וכו'. זה בנוי בצורה של עץ ואפשר לשחק עם ההגדרות ולהגיע לכל תצורה אפשרית. לי למשל הפריעו הלוגים של Spring וHibernate אז ביטלתי אותם ברמת org.spring וכו'.
היתרון של זה כמובן שהכל מוגדר בקובץ, זה סוג של סטנדרט מקובל ולא צריך לחפש בקוד או חלילה לקמפל כל מיני גרסאות כדי לעשות שינויים בלוג. עקרונית, לוגר אמור לאפשר שליטה בהגדרות מבלי לקמפל/להעלות גרסה. זה בדיוק הרעיון של לוג: לקבל מידע מהתוכנה שלאו דווקא נמצא בסביבת הפיתוח במעבדה.

 

[zaske]

כל מילה בסלע ובזמנו גם במקום הקודם אם זכור לי נכון

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

http://www.slf4j.org/api/org/slf4j/MDC.html

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

 

[TakeCtrl]

מצד שני, שימוש במעטפת משלך מקל עליך לעבור מימוש

אם תרצה (כמו שslf4j או commons עושים), הlogger שלנו, לא בדיוק יורד לפרטים, קריאות הלוג שלנו סה"כ הינן deletator לlogger.log גם הקונפיגורציה עדיין נשמרת בקובץ
הטריק הנוסף הוא שאם הLogger שלנו שם לב שהlog4j.xml דפוק (אולי כי הלקוח או טכנאי שכח סוגר) הוא מחזיר חזרה קובץ Log4j.xml של ברירת מחדל שלנו.
בנוסף לכך יש לנו client windows שבין השאר מאפשר לאנשי תמיכה להגדיר בזמן ריצה logger נוספים ולשייך אותם לappenders.
&nbsp

 

[user32]

ממש לא תירוץ

זה הסיפור הכי עתיק בספר: "שנוכל להחליף מימוש". בפועל, אף אחד לא מחליף מימוש. גם אם כן תחליפו מימוש תמיד אפשר לעשות טריק כמו מעטפת למימוש החדש proxy, adapter, bridge או כל DP של ירושה/עטיפה כדי לעבור למימוש החדש שכאמור כמעט בטוח שלא יקרה גם ככה.
זה בדיוק המקרים האלה שמנסים להיות גנריים כשזה בעיקר גורם לנזק.

כל מה שתיארת: ולידציה לXML, קליינט שמאפשר קונפיגורציה וכו' יכול להתבצע בקלות בלוגר סטנדרטי.

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

 

[TakeCtrl]

הנה דוגמא, אם נרצה לעבור לlog4j2 נוכל להחליף רק את הlogger

אע"פ "שאני לא הייתי כותב את זה ככה" (בוודאי לא משתמש בgetStackTrace אבל יכול להיות שזו הסיבה שכתבו את הלוגר מלכתחילה ) , לי זה יהיה נוח.
אבל עזוב לוגר, יש כאן מימושים שהם ממש העתקה של מspring-beans עושה (כתיבת classes בxml וקניפוג פרמטרים שלהם),

 

[אוהב להתווכח]

איך היית עושה את זה בלי מעטפת

נניח שאתה רוצה לא לאפשר לוג לשום ספריה שאתה משתמש בה אלא רק לקוד שלך. ממה שאני ראיתי זה בלתי אפשרי בLOG4J או SLF4J. איך היית עושה את זה בלי מעטפת? עם מעטפת עשיתי את זה די בקלות. הקוד מצורף.

public static void initLog4j(String log4JPropertyFullPath) throws IOException {
    Properties p = new Properties();
    p.load(new FileInputStream(log4JPropertyFullPath));
    PropertyConfigurator.configure(p);
    Log.level = Logger.getRootLogger().getLevel();
    Logger.getRootLogger().setLevel(Level.OFF);
}

private Log(Class clazz){
    logger = Logger.getLogger(clazz);
    logger.setLevel(level);
}

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

 

[טרול המתכנן]

איך אתה משנה log level תוך כדי ריצה עם הקוד שלך?

ומה הוא בעצם עושה שקובץ settings של log4j לא עושה??
על פניו הדוגמה הזו מחזקת את כל מה ש-user32 טען לעיל...

 

[אוהב להתווכח]

אני צריך לעשות ריסטרט לאפליקציה

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