20 komentáře “Máte jistotu, že do session ukládáte pouze serializovatelné objekty?

  1. Zajímavý řešení, zkusím si ho zapamatovat. My jsme vždycky sledovali logy, někdy to řve přímo framework (třeba Wicket).

  2. No to byl system napsanej v C#, což je (na rozdíl od Javy) staticky typovej jazyk, takže s kolekcema nebyl problém. Věci jako Object[] patřej do Ruby 😛 #hehe #flame

  3. My jsme to řešili např. u message a DTO objektů tak, že byl jeden unit test, kterej vzal všechny typy z určitýho namespace a zroundtripoval je, tzn. vytvořil instanci do který nacpal náhodný hodnoty (případně i referencovaný objekty), serializoval, deserializoval a pak porovnal jestli jsou si rovný. Testovalo to binární i XML serializaci.

    • Chápu, a pak byl prostě standard – chceš-li něco strčit do session, vyrob DTO v tomhle namespace a dej ho tam – a nesmíš používat obecné kolekce, do kterých lze strčit cokoliv. Pak na to zaberou automatizované testy, které ověří mj. i serializovatelnost.

      Tj. základem je disciplína.

  4. Jste bych zminil -Dsun.io.serialization.extendedDebugInfo=true pri hledani neserializovatelnych objektu v grafu.

  5. Pouzivame plugin Findbugs do Eclipse – funguje to pekne a jenkins takovy plugin ma taky (az me to nekdy sere ze to tak pekne funguje kdyz potrebuju rychle neco jen tak zmastit 🙂

    • A odhalí ta inspekce findbugs i problémy s deep serializovatelností? Tj. že když do session uložíte Mapu, která serializovatelná je a pak jinde v kódu do té mapy uložíte neserializovatelný objekt tak to taky ten problém odhalí? To by mě totiž docela překvapilo, protože tohle diagnostikovat není vůbec jednoduché. Například Idea tyhle problémy odhalit neumí.

      • Ted doufam ze jsem pochopil co mas na mysli – kdyz udelam tohle:

        import java.util.HashMap;
        import java.util.Map;
        import javax.servlet.http.HttpSession;
        import com.google.inject.Inject;
        public class TestFindbugs
        {
          @Inject
          HttpSession session;
        
          private Map myMap = new HashMap();
        
          public static class MyObject  {}
        
          public void save() {
            session.setAttribute("test", "test");
            session.setAttribute("test", new MyObject()); <----- Findbugs reports a bug
          }
        }

        Tak me jenkins (a eclipse) padne s tim ze se snazim ulozit neserializovatelny (kurna to je slovo) object do session na radku dve v metode save – tohle me zachyti v celym kodu, cross-class, nezalezi kde do te session/mapy ukladam. Odchyti mi i kdyz ukladam deep structured object kde treba jen jen attribut tridy nekde ve stromu neni serializovatelny.

      • A kdyby to bylo zapsané takhle?

        import java.util.HashMap;
        import java.util.Map;
        import javax.servlet.http.HttpSession;
        import com.google.inject.Inject;
        public class TestFindbugs {
          @Inject
          HttpSession session;
        
          public static class MyObject  {}
        
          private Map getMap() {
             Map result = new HashMap();
             result.put("nonSerializable", new MyObject());
             return result;
          }
        
          public void save() {
            session.setAttribute("test", "test");
            session.setAttribute("test", getMap());
          }
        }
        
      • Z nejakeho duvodu nemuzu odpovedet na prispevek dole tak je pro poradek hlasim, ze ten uvedeny priklad finbugs neodhali.

      • Jo ty diskuse jsou jen 2-úrovňové, takže se pak musí reagovat na vyšší příspěvek.

        Já jsem si to myslel, že to tenhle scénář neodhalí, protože to technicky není vůbec jednoduché. Idea to taky nenahlásí. Pravda je, že pokud je disciplinovaný tým a do session se strkají pouze generifikované DTO, kde je všechno striktně serializovatelné (jak píše Dkl), tak riziko nehrozí …. ale realita je dost často někde jinde … a proto ten náš záchytný Servlet filtr 🙂

  6. Dobrý! Matně si vzpomínám na warningy, pokud se do session ukládal neserializovatelný objekt. Pravda, vyžaduje to od programátorů aktivnější přístup než vyhození výjimky.

    Jeden šťouravý dotaz, respektive bych se i rád něčemu přiučil. Koukám, že máte logger jako private static final a název malými písmeny. Co na to sonar? Máte nějaké pravidlo, které názvy loggerů nezařazuje mezi violation?

    • No Sonar jsme sice experimentálně nasadili na pár projektech, ale nějak jsme si na něj nezvykli. Používáme statickou analýzu z IntelliJ Idey, která problémy napovídá už v rámci psaní kódu. A ta si na logger s malými písmeny nestěžuje – i když u konstant to vyžaduje. Oni mají tu inspekci totiž docela chytrou – cituji dokumentaci:

      This inspection reports any constants whose names are either too short, too long, or do not follow the specified regular expression pattern. Constants are fields declared static final.
      Use the fields provided below to specify minimum length, maximum length and regular expression expected for constant names (Regular expressions are in standard java.util.regex format). Use the checkbox below to specify that only immutable static final fields should be checked by this inspection.

      Tj. tím, že logger není immutable, tak ta inspekce neřve. Idea je v tomhle prostě boží .)

      • To zní slibně. Sonar má tu výhodu, že je to centrální místo s reporty a statistikou, jak se dané měřené hodnoty měnily v čase.

      • Jo to dává logiku. V teamcity, je teda taky možné pouštět inspekce z Idey centrálně a získávat reporty. Nicméně – hmm, nepoužíváme to … asi máme ještě dost prostoru pro zlepšování svého vývojového procesu 😉

        Máš nějakou přímou zkušenost, jak tyhle statistiky zlepšují kvalitu vašeho kódu? Je někdo vyčleněný, kdo to pravidelně sleduje a pak dává náměty na zlepšení? Nebo ty výsledky sledují všichni? Ono to totiž může zabrat dost času a na rovinu – business chce fíčury, kvalitu kódu cheme my v devu. Takže jde o to časově rozumně vyvážit .

      • Sami od sebe statistiky kvalitu nezlepší, jsou to jen hlídací psi. Sledovat by to měl každý, zabere jim to tak pět minut týdně, jako kontrolu, zda se projekt nezhoršuje. Já nasazuji sonar u zákazníků k definování stavu nula (to se většinou sonar málem pomine a já taky), od kterého musí být vše lepší. Od určitého bodu chaosu je totiž hrozně pracné nové fíčury přidávat na tak chatrný domeček z karet, aby se nezřítil.

      • Statistiky sami o sobě nezlepšují kvalitu. Ale pokud jsou spojený s notifikacemi z CI (a kontrola se provede hned po komitu), tak to funguje velmi dobře.