-20 komentáře “Část #2: Modulární systémy ve Spring Frameworku

  1. Hlidani zmen konfiguracnich souboru je mozna trivialni, ale stejne by me zajimalo, jak to na projektu delate. Diky. Pavel

  2. To opravdu záleží na situaci – Spring sám o sobě provádí refresh v synchronizované metodě, kde hned na začátku nastaví flag active na false. Při jakémkoli požadavku na beanu ve chvíli, kdy není kontext aktivní vypadne IllegalStateException. Pokud to neošetříte, může to typicky na web vrstvě skončit 500kou (tzn. uživatel bude chvíli dostávat chybové odpovědi).

    My tento případ ošetřujeme tak, že neprovádíme refresh toho stejného stromu, ale bokem si vytváříme strom nový. Teprve pokud inicializace nového stromu kontextů proběhne bez chyby, vyměníme původní strom za nový, a starý uzavřeme. Vůči uživateli je toto samozřejmě příjemnější přístup, jelikož mu nehrozí žádný výpadek, ale klade to větší nároky na programátory. Aplikace musí být programována tak, aby jí nevadilo, že existuje 2x ve stejný čas ve stejném JVM (narážím na problematiku singletonů a statických proměnných).

  3. Napadá mě otázka jak se bude chovat aplikace, která je zrovna uprostřed refresche (což může trvat i několik (možná desítek) sekund, a přijde na ní request…Obávám se, že to bude nepěkné NullPointerException.
    Zdá se mi bezpečnější reloadovat celý kontext aplikace i za cenu její nepřístupnost.