Konec podpory GlassFishe - co to přesně znamená

Nedávno Oracle oznámil ukončení komerční podpory serveru GlassFish, který kdysi získal akvizicí společnosti Sun Microsystems. K verzi GlassFish 4.x už tedy nebude poskytována komerční podpora, bude podporována pouze v rámci Open Source komunity. Zákazníkům, kteří vyžadují komerční podporu, je doporučeno přejít na aplikační server Oracle WebLogic . Tento přechod by měl být usnadněn podporou migrace původních GlassFish deployment deskriptorů na WebLogic server.

Jak už bylo řečeno, GlassFish byl k dispozici (podobně jako třeba JBoss) ve dvou edicích - Open Source a Commercial. Výše uvedené ukončení podpory se vztahuje pouze na verzi Commercial, Open Source bude žít dál a bude i nadále sloužit jako referenční implementace pro nové verze JEE specifikací. Tedy i pro JEE 8, stejně jako u předchozích verzí JEE, bude k dispozici jako první její vzorová implementace na GlassFishi. Alespoň tak to Oracle veřejně oznámil na JavaOne. Tato implementace má představovat verzi GlassFish Server Open Source Edition 5.

Nejnovější nadcházející verzí bude GlassFish Server Open Source Edition 4.1, která bude uvolněna během roku 2014.
Zajímavé srovnání tohoto kroku Oraclu se strategií dalších klíčových hráčů v oblasti aplikačních serverů, IBM a JBoss, najdete na tomto blogu. Vyplývá z něj, že Oracle provedl v podstatě stejný krok, jako už před ním IBMka a JBoss.

Refresh DNS dat nodů WLS clusteru ve WLInitialContextFactory

Pro komunikaci mezi dvěma WLS clustery je často používáno JMS, přičemž pro identifikaci cílového clusteru je používána jeho cluster DNS adresa. Když s její pomocí získáme initial JNDI context, máme ve weblogic.jndi.WLInitialContextFactory seznam všech adres, které jsou namapované na dané DNS jméno cílového clusteru. Tento seznam je uložen v cache každé instance zdrojového clusteru. Pak obvykle rozdělujeme zátěž mezi jednotlivé cílové servery pomocí DNS load balancingu.
 Z těchto cached listů jsou pak round-robin algoritmem obsluhována všechna další čtení initial contextu. Pokud je některá z adres uložených v cached listu nedostupná, je z listu odstraněna. Address list je z DNS znovu opětovně načten jedině tehdy, když nebude dostupná žádná z adres v něm, tedy bude-li prázdný.

Tak to popisuje Oraclí dokumentace třeba zde:

http://docs.oracle.com/cd/E17904_01/web.1111/e13709/setup.htm:

"When clients obtain an initial JNDI context by supplying the cluster DNS name, weblogic.jndi.WLInitialContextFactory obtains the list of all addresses that are mapped to the DNS name. This list is cached by WebLogic Server instances, and new initial context requests are fulfilled using addresses in the cached list with a round-robin algorithm. If a server instance in the cached list is unavailable, it is removed from the list. The address list is refreshed from the DNS service only if the server instance is unable to reach any address in its cache."

To až donedávna nepředstavovalo žádný problém. Ale s příchodem cloudu/dynamických clusterů a dynamickým spouštěním instancí v clusteru jsou do něj často ad hoc přidávány a odebírány instance, a v souladu s těmito operacemi dochází ke změnám v DNS. Tyto nové adresy však zdrojový cluster nenačítá, neví o nich a používá nadále jen ty instance, které už v cílovém clusteru "znal". Když je tedy postupem času v cílovém clusteru většina serverů odstavena a časem znovu spuštěna, dochází ke koncetraci requestů na stále menší množství cílových serverů, až nakonec jdou všechny requesty jen na jediný server, tedy N/1. O ostatních cílových serverech, které byly mezitím spuštěny nebo restartovány, totiž zdrojový cluster neví, neboť o nich nemá žádné záznamy v cached listu .

Aktualizace/obnova DNS cache, která načte adresy "nových" serverů cílového clusteru, je provedena až po zastavení posledního cílového serveru, jehož adresa byla předtím v cache uložena.

Je tedy zapotřebí, abychom na zdrojovém clusteru mohli periodicky obnovovat data z DNS cache a předešli výše popsaným bottleneckům. V dokumentaci Weblogicu ale žádný takový parametr nenajdete, nicméně naštěstí existuje. Je to nedokumentovaná interní JNDI property, vytvořená před pár lety přesně k tomuto účelu.
Při vytváření initial contextu tedy přidáme tuto propertu, která se jmenuje weblogic.jndi.forceResolveDNSName, nastavenou na true.
Také je zapotřebí zakázat DNS caching na úrovni JVM.

Použití v kódu pak může vypadat třeba následovně:

Hashtable ht = new Hashtable();ht.put(Context.INITIAL_CONTEXT_FACTORY, "weblogic.jndi.WLInitialContextFactory");…ht.put(“weblogic.jndi.forceResolveDNSName”, "true");
Context ctx = new InitialContext(ht);

Nový JDK 7 Update 40

Tak jsme vypustili do světa 7u40, oplývající pár zajímavými vlastnůstkami. Na JavaOne by o ní měli mluvit dost podrobně, snad budou později k dispozici online záznamy ze seminářů.
V této verzi:

• by měla být dokončená plná implementace Java Mission Control a Flight Recorderu. Je to tedy další důležitý krok ke spojení Hospotu a JRockitu.
• je implementovaná nová vlastnost Deployment Rule Set, která umožňuje adminům ve velkých organizacích nastavit, jaké aplikace nebo applety bude moci provozovat koncový užívák.
• nově podporuje Macovské displeje Retina v jejich plném rozlišení, což určitě potěší Ajpeďáky.

Verze WebLogic serverů v clusteru

Dlouhou dobu platilo, že verze serverů v clusteru musí být naprosto identické, a to nejen pro major verzi (např. 8.1), ale i minor verzi (tedy zejména patche jako např. 8.1.1.1).

To se změnilo s příchodem WLS 9, který zavedl rolling upgrade. Ten umožňuje cluster memberům běžet po krátkou, omezenou dobu, na různé minor verzi nebo patchi. Díky tomu je možné provádět postupně upgrade jednoho serveru po druhém, a upgradovat tak celý cluster / doménu, aniž by bylo nutné je restartovat. Tato funkcionalita je omezená pouze na samotný WebLogic, ostatní produkty z Oracle FMW stacku ji bohužel zatím nepodporují.

V současné době je major version č. 12.1 a minor version je 2 (tedy 12.1.2). Oracle samozřejmě doporučuje nejdříve rolling upgrade nejdříve odzkoušet na testovacím prostředí, a až poté aplikovat v produkci.

Pokud tedy někdo říká, že je možné WLS servery v clusteru provozovat na různých minor verzích, je to sice pravda, ale jedná se o temporary konfiguraci, kterou lze provozovat pouze po dobu nezbytně nutnou pro upgrade nebo aplikaci patchí v celé doméně.

Podpora a switching PDB databází ve WLS

V poslední verzi Oracle DB 12c je implementovaná pěkná vlastnost, zvaná Multitenant container database (CDB). Je to možnost dynamicky přenášet a během chvilky připojovat a zprovoznit databáze - Pluggable database (PDB):

Podrobné informace o Multitenant architektuře jsou zde.

Nyní vyvstává otázka, jak je to s podporou těchto vlastností na WLS. Oficiální stanovisko Oraclu, uvedené v dokumentaci k WLS 12.1.2 zde uvádí zdánlivě schizofrenní tvrzení. 
Dle něj je totiž PDB podporována na WLS 10.3.6 a 12.1.1 dokonce s driverem pro 11g. Je tam ale zmíněno omezení, a to poměrně podstatné: nelze používat příkaz Set Container. No a právě tímto příkazem se přepínají databáze, takže v praxi toto omezení znamená, že db už musí být připojená a kontejner není možné z WLS s touto konfigurací měnit. Využívá jen db službu, která již s PDB byla asociovaná v okamžiku připojení. Z tohoto důvodu bych pro maximální využití investic do db 12c a její plné funkcionalilty doporučoval nasazení příslušných 12c driverů.

V konfiguraci WLS 10.3.6/12.1.1 s 12c driverem / 12c DB, bude možné bez problémů přepínat PDB pomocí ALTER SESSION SET CONTAINER. Přitom si JDBC driver a datasource connection drží stavy, asociované s PDB a uživatelem/session. Tyto stavové informace je třeba při přepnutí PDB odmazat a reinicializovat. A právě tento cleanup kód existuje pouze ve 12c driveru a 12.1.2 datasourcu.

Využívání PDB se staršími 11g drivery s sebou přináší riziko security vulnerability a míchání informací mezi různými PDB a jejich uživateli.

Podpora Web Socket Proxy a Apache 2.4 ve WLS Plug-Inu

Plugin je možné stáhnout z OTN: http://www.oracle.com/technetwork/middleware/ias/downloads/wls-plugins-096117.html
V poslední verzi pluginu 12.1.2 jsou implementována rozšíření:

• podpory Apache web serveru, který je nyní podporován ve verzích 2.2.x a 2.4.x.
• podpora WebSocket proxy, která umožňuje komunikovat WebSocketem na aplikace, deployované na WLS 12.1.2. Zatím je tato funkcionalita podporována pouze na výše zmíněné verzi Apache, na OHS, IIS a iPlanetu zatím není implementována.
• OHS bude podporovat WebSocket až ve verzi 12.1.3. (viz enhancement bug 17085296).

Implementace SSL na WebLogicu

WebLogic až do verze 10.3. používal pro implementaci SSL knihovny od Certicomu, plus od verze 10.3.3. také JSSE (Java Secure Socket Extension). Od verze 12c (12.1.1) jsou však pro implementaci SSLka použité pouze knihovny JSSE, tedy standardní Javovský framework. Certicom byl z WLS 12c kompletně odstraněn.
JSSE je kompatibilní s Certicomem a zachovává plnou interoperabilitu interakcí mezi WLS 12c a staršími verzemi WebLogicu, až do 8.1. Z toho vyplývá, že i Oracle Service Bus, který je zatím certifikován jen na WLS 10.3.6. a tedy Certicom knihovnách, bez problémů funguje s WLS 12c, jenž může být v roli jak klienta, tak i serveru.
Více viz dokumentace.

Srovnání různých edicí aplikačních serverů WebLogic

Zákazníkům často není jasné, jaké jsou různé edice WebLogicu, co obsahují a jak přejít z fosilního Oracle iASu na WebLogic. Tato matice obsahuje velmi podrobné srovnání všech vlastností, které jsou k dispozici v různých edicích WebLogicu, včetně dnes již nepoužívaných edicí, které kdysi distribuovala BEA.

Vysvětlení k prvnímu sloupci: verze iAS EE (with WebLogic Server Basic) je speciální edice WebLogicu, kterou zákazník dostává náhradou za licenci iAS EE. Je tedy používaná zákazníky, kteří se rozhodnou přejít z iASu na WebLogic server (což je zajisté rozhodnutí správné, které jim do budoucna ušetří spoustu nákladů. Přejít bude do budoucna určitě nutné, a nůžky mezi WLS a iASem se stále rozevírají víc a víc).
Po přechodu na WLS Basic edition však zákazník nemá k dispozici plnou a neomezenou funkcionalitu WebLogic, ale jen její část, odpovídající tomu, co je k dispozici v iASu. Podrobný popis omezení ve WLS Basic je v dokumentaci WLS.

Prezentace ze semináře Summer Tech Days

Prezentace ze dnešního semináře o WebLogicu 12c můžete stáhnout zde. Díky za účast a zájem o WebLogic.

Podpora WebSocketu ve WLS 12c

V poslední době se zákazníci často ptají, zda a nebo kdy bude WLS podporovat WebSocket.
Situace je bohužel taková, že podpora WebSocketu je zatím product managementem WebLogicu jen zvažovaná. Určitě nebude v nadcházející verzi 12.1.2, a dosud není ani určena verze, která bude WebSocket podporovat. Nicméně se zdá, že podpora nejspíše bude, a to i JMS over WebSocket.

Zajímavý blog o integraci WebSocketu s JMS je zde.

Patchování v nadcházejícím WLS 12.1.2

Oracle přestává v této nadcházející verzi WebLogicu podporovat Smart Update a nadále bude podporovat již jen OPatch.

Hogging thready

Koncept tzv. hogging threadů byl poprvé implementován ve WLS 9.2. Jsou to thready, které běží delší dobu, než je průměrný execution time běžícího threadu, který je průběžně vypočítáván WLS kernelem. Dalo by se tedy říci, že jsou to pomalé nebo "zlobivé" thready.
Pokud je u threadu nastaven atribut hogging po určitou (nastavitelnou) dobu, která defaultně činí 600 vteřin, přechází thread do stavu stuck.

Hogging thready je možné potkat často u instalací, které využívají Active GridLink. ONS messaging totiž provádí blocking volání internalDequeue() a čeká na příchod zprávy po určitou dobu (timeout). Pokud z RACu nepřijde žádná zpráva, nevykazuje thread žádnou aktivitu a blokuje až do příchodu zprávy, nebo timeoutu. Je-li timeout nastaven na 0, pak thread čeká po neomezenou dobu.

Na konzoli to může vypadat takto:

OSB replace: jak modifikovat všechny výskyty elementu v dokumentu

Je-li třeba na OSB v XML dokumentu nahradit všechny výskyty daného elementu (např. root/employee/dept) nějakou jinou hodnotou, která může být třeba dohledána v číselníku, lze to provést několika způsoby.

Pomocí xquery je to zbytečně komplikované (musí se provést přemapování celé struktury). Pokud mají být všechny elementy přepsány jednou stejnou hodnotou, pak na to stačí 1 replace node:









Má-li být v každém elementu ve výsledku něco jiného na základě aktuální hodnoty daného node, musí se použít replace volaný z for-each konstrukce:

Migrace aplikací z OAS/ADF (verze 10.1.3) na WebLogic 10.3.6

Pokud potřebujete portovat aplikace, jejichž vývoj je už ukončen či mají jen minoritní úpravy a pouze je třeba je spustit na WebLogicu, nemusíte je upgradovat. Můžete vzít aplikaci verze 10.1.3.5, přibalit k aplikaci všechny ADF/Toplink knihovny, které používá a deploynout ji na Weblogicu. Jak to udělat je popsáno zde – článek je sice pro starší verze, ale mělo by to fungovat i s 11g.

Potřebujete-li aplikaci plně přeportovat, tento bulletin popisuje, jakým způsobem to provést, co je ošetřeno automaticky a co je třeba řešit manuálně.

Instalace OSB 11g nad WLS 12c

Očekávaná verze OSB 12 je zatím stále v nedohlednu, a poslední verzí zůstává 11.1.1.6, běžící nad WLS 10.3.6. Nad WLS 12c bohužel stále není certifikována, ačkoli tento je k dispozici už více než rok.
Nicméně pokud byste  si chtěli OSB přece jen rozchodit a odzkoušet nad WLS 12c, je to možné provést následujícím způsobem (pro Windows):

1. Nejdříve stáhněte a nainstalujte WLS 12c (jako MW_HOME třeba c:\oracle\middleware). Můžete klidně stáhnout samostatnou instalaci bez OEPE, neboť verze OEPE 12.1.1., která je standardně obsažena v instalačním balíku s WLS 12c, není instalátorem OSB podporována. Pokud byste to chtěli přece jen zkusit s OEPE 12.x, bude vám později v kroku 4 installer OSBčka hlásit chybu: INST-07248: Specified OEPE home location is not a valid location Enter a valid OEPE home location a nepustí vás dál. Dalo by se to obejít editací konfiguračních souborů instaleru, ale pak můžete při práci s Eclipsou narazit na další problémy způsobené nekompatibilitou knihoven.
2. Stáhněte certifikovanou verzi OEPE, což je OEPE 11.1.1.8. (seznam certifikací je zde, stáhnout OEPE je možné tady).
3. Vytvořte adresář MW_HOME/oepe_11.1.1.8.0 a rozbalte do něj OEPE.
4. Dále stáhněte generickou instalaci OSB a nainstalujte ji. Instalátor je javovský a aby se spustil, je třeba zadat cestu k JRE (např. setup.exe -jreLoc C:\Oracle\Middleware\jdk160_29).
5. Pokud chcete nainstalovat sample aplikace, zvolte custom instalaci a povolte je. Instalátor by měl sám najít MW_HOME i instalaci OEPE. Pokud se tak nestane, nastavte ji ručně. 
6. Až doběhne instalace, měli byste už být schopni spustit OSB sample, defaultně na adrese http://localhost:7021/sbconsole/