Re: Způsob deploymentu x paměťová náročnost

[Martin Václavík]

Problémů se statickou inicializaci apd. jsem si vědom, ale v mém případě by se to mělo dotknout jenom log4j konfigurace. Pro aplikační server je v produkčním prostředí vyhrazen hardware, na kterém běží více aplikací, takže možnosti navyšování paměti jsou omezené. Díky za odpověd Martin Václavík Roman Pichlík napsal(a): Pokud je tam velke mnozstvi knihoven, ktere je mozne sdilet mezi WARy, EJB moduly ci EARy pak ano, protoze troda by natazena pouze a jenom jednim classloaderem. Ac se takovato optimalizace primo nabizi, tak muze mit docela neprijemne side effecty. Predevsim se jedna o jakykoliv kod, ktery dela nejakou statickou inicializaci jako jsou napriklad singltony atd. Vas deployment ted zarucoval, ze vse bylo oddelene minimalne na urovni EARu. Tim, ze sesypete vse na jednu hromadu o tohle prijdete. Z jakeho duvodu nenavysite pamet AS, je to kvuli developmentu? 2009/3/6 Martin Václavík <m...@tmapy.cz>: Dobrý den, mám vytvořenou JEE aplikaci pro Glassfish Server v2.1. Aplikace se skládá z několika EARů, které vždy obsahují WAR, EJB a JAR knihovny. JAR knihovny jsou většinou stejné ve všech EARech (a ve stejných verzích). Můj problém spočívá v tom, že takhle koncipovaná aplikace spotřebovává příliš mnoho paměti aplikačního serveru. Nedalo by se nějak ubrat paměťové náročnosti tím, že bych změnil deployment aplikací? Např.: bych vytvořil jeden velký EAR, který by vše obsahoval, nebo bych všechny knihovny dal do lib adresáře, tak aby nemusely být v EARech, nebo vůbec nepoužít EARy a provádět deploy přímo EJB komponent a WARů? Díky Martin Václavík