sobota 15. listopadu 2003

Singleton a problém ClassLoaderu

Používáte návrhový vzor Singleton a používáte jej v Jave? Pro ty méně znalé osvětlím, že Singleton je takový objekt, který má v celé aplikaci pouze jedinou instanci. Používá se tam kde chceme, zaručit jediněčnost objektu například v implementaci Cache.

Pěkných pár dní jsem pracoval na implementaci XML konfigurace aplikačního serveru,k tomuto účelu jsem využil projekt Jakarta Apache jehož součástí je komponenta Commons Digester hojně využívaná v projektech pod Jakartou.Digester slouží pro namapování XML na javovské objekty.

Digester umožňuje nastavit objekt, který je volán(událostní model SAXu) při zpracování dokumentu. Tímto mechanismem jsem vždy získal jméno aktuálně zpracovávaného elementu a toto jméno jsem dále využíval v jiném objektu, který pracoval z obsahem elementu. Měl jsem tedy dva objekty jeden, který vždy zpracoval obsah elementu a jeden, který byl pověšen na zpracování dokumentu. Objekt, který zpracovával obsahy elementu vždy potřeboval znát jméno aktuálně zpracovávaného elementu, aby mohl jeho obsah korektně uložit(jméno elementu tvořilo klíč v mapě). Právě objekt, který čmuchal jména elementů byl Singletonem.

Tento model fungoval dobře v kontextu našeho aplikačního serveru, ovšem pokud jsem zkoušel přenést aplikace do jiného servletového kontejneru nastala potíž. Najednou nebyl objekt jediněčný, ale vznikaly instance dvě a to mělo za následek chybnou funkčnost. Přitom Singleton byl thread-safe, metoda vracející instanci byla synchronizovaná.

 
 	public class RuleWatcher{
		private static RuleWatcher watcher = null;
		
		private RuleWatcher(){
			// soukromý konstruktor
		}
		
		public static synchronized Rulewatcher getInstance(){
			if(watcher == null){
				watcher = new RuleWatcher();
			}
			return watcher;		
		}		
		.
		.
		.atd.
		.
	}   

 

Tento kód je v pořádku, přesto nemusí zaručit očekávanou funkčnost. Na otázku proč odpovím ClassLoader. Jak Digester tak většina servletových kontejnerů používa vlastní ClassLoader, pokud tedy vznikne instance RuleWatcher v kontextu ClassLoaderu aplikačního serveru a posléze je vytvořen objekt v kontextu jiného ClassLoaderu(v našem případě Digester) a volána metoda getInstance() je podmínka true neboť třídní instance watcher je alokována v jiném kontextu a proto vznikne další instance.

Nálsedující zjištění mi trvalo přibližně den, oprava už nebyla složitá. Naštěstí komponenta či spíše objekt Digester umožňuje nastavení ClassLoaderu proto stačila jediná řádka, která nastavila původní ClassLoader a bylo po problémech.

 
   ClassLoader c = Thread.currentThread().getContextClassLoader();
   digester.setClassLoader(c);
 

čtvrtek 13. listopadu 2003

Tunelujeme přes HTTP proxy

Trocha plků na začátek určitě nikoho nezabije - tak tedy: po skončení civilky na Pedagogické fakultě, která byla připojena optikou téměř až k mé 10/100Mbit síťovce, jsem se vrátil do nejmenované firmy. Jako závislý na Internetu jsem překousl tu skutečnost, že ve firmě mám pouze omezený přístup na Internet a to přes protokol HTTP a to pouze na některé servery/porty. Respektive - máme zde dvě http proxy - první je s autentifikací a hlídá se zde data/čas. Druhá je pro všechny volná, ale jsou zde pouze vybrané servery (domény) na které je možno přistupovat. Seznam serverů se dá měnit, ale je omezen cca na 100 domén. Situace mizerná pro člověka zvyklého na irc/icq/ssh... Jal jsem se tedy tunelovat spojení směrem ven. Jako správný tunelář jsem nechal na free proxy přidat jednu doménu, na které má kamarád počítač (a ten je samozřejmně bez omezení připojen k Internetu). Idea byla asi taková: tunelovat přes HTTP požadavky až k počítači připojenému k Internetu a zpět. Data mezi mým počítačem v intranetu putují přes protokol HTTP na "volný" proxy server a dále v nezměněné podobě k počítači v Internetu, který je dále zpracuje a něco udělá... A tím se dostáváme do fáze realizace.

Výborným pomocníkem mi byl program napsaný v Jave jménem "Socks via http", který funguje tak, že u klienta (počítač v intranetu) je vytvořena socks proxy, data se tunelují přes http k serveru (počítač v Internetu se serverovou částí tohoto programu) a zpět. Samozřejmně, že jsem zkoušel i jiné programy, ale osvědčil se pouze výše uvedený (vyplinulo to z restrikcí http proxy, která měla defaultně nastaven port 80 a jiný neakceptovala - při manuálním zadání portu 80 do url mi byl vrácen kód 403 - takže většina programů na této chybě vyhořela). Kamarád nahodil serverovou část (vůbec nebyl vesel z toho, že kvůli prográmku cca 30KB velkému musí tahat i JRE) na vyšším portu a tuneloval moje požadavky pomocí iptables z portu 80 - takže jeho web server běžel pro zbytek světa stále jako by se nic nestalo. Tak tedy začal jsem tunelovat - program zahlásil "checking version - OK" a já byl v suchu :). První co jsem vyzkoušel bylo IRC - všechno běhalo nádherně rychle. Rozběhal jsem si ICQ, web (takže mě už netrápilo žádné omezování) a dokonce i SSH. To byl asi muj nejšťastnější den ve firmě...

Tady příběh končí a koho nudil, tak ani nemusí číst dál - následují jen špatné zprávy :].

A teď ta špatná zpráva - asi po týdnu surfování si admin proxy serveru všiml, že na jeden "server" je nezvykle moc requestů a tak se rozhodl konat - dnes je moje ip v blacklistu a na tunelování můžu na nějakou dobu zapomenout. Nejsem žádné ořezávátko, takže změnit ip není problém, ale to situaci nevyřeší. Situaci by vyřešil hack dané proxy :), ale AIX není mým oblíbencem... surfuji tedy přes proxy (další javovský program - jde pouze o forward portu na jinou ip/port), která je na jiném počítači (ten není v blacklistu :) ) a tudíž jsem v "suchu". Ještě mě napadlo sniffnout hesla uživatelů, kteří se hlási na proxy s autentizací - věřte mi - funguje to, ale dřív nebo později se to proflákne...

Smutné na tom všem je, že jsme společnost s "moc moc" zaměstnanci a jsou zde restrikce u něčeho tak svobodného jako je Internet. Dnes jsem se bavil s adminem z i.cz - řekl, že u nich je Internet pro všechny neomezený. No vida.. někde to jde a jinde zase....

středa 12. listopadu 2003

DocBook - dokumentace v hrsti

Pokud jste někdy vytvářeli jakýkoliv typ dokumentu nebo se na to chystáte, tak pravděpodobně v průběhu narazíte čí jste spíše již narazili na některý z následujících problémů.

Potřeba srozumitelného(otevřeného) formátu
Dokument byl vytvořen v editoru, který produkoval soubor v proprietárnim formátu.
Nezávislost či spíše snadná změna výstupu
Dokument byl vytvořen pro určitý typ média(elektronické publikování), ale Vy jej potřebujete šířit i jinou cestou(tištěná podoba,hlasový výstup atd.) .
Snadná práce s dokumentem
Dokument byl vytvořen a Vy ho potřebujete dále upravovat, sdílet, rozšiřovat

Výše uvedené problémy souvisí s jakýmkoliv druhem dokumentu který si umíte představit, lhostejno jestli se jedná o článek pro místní noviny, vědeckou publikaci, knihu, dokumentaci k hardwaru nebo softwaru či uživatelskou příručku. Všechny výše uvedené problémy mají něco společného, jsou důsledkem míchání toho co dokument vyjadřuje s tím jak to má být prezentováno.

V důsledku potřebujeme jazyk nepopisující prezentaci informace, ale její význam a strukturu. Právě pro strukturování informací se dobře hodí jazyk XML. Nyní už stačí pouze definovat značky popisující danou strukturu a to je právě úkol DocBooku.

DocBook je ve své podstatě pouze DTD, které určuje strukturu XML dokumentu. DocBook tak má tak stejný význam jako XHTML. Jak XHTML tak DocBook vyjadřuje pouze jaký element a kde můžete použít. Pokud píšeme dokument v DocBooku, tak produkujeme XML data popsaná jazykem DocBook.

Na jedné straně výhody XML a na druhé dobrá sémantika(rozuměj vyjadřovací schopnost) dělají z DocBooku jednu z nejpoužívanějších aplikací SGML/XML(Podle J.Koska dokonce druhou za jazykem HTML). O DocBooku se již dále budeme bavit pouze jako o systému neboť XML a DTD je pouze jádro, na které se nabalily a nabalují nástroje umožňující jeho zpracování.

DocBook nabízí úžasnou vlastnost, kterou bych charakterizoval jako jednou naspat a mnoha způsoby prezentovat. Pokud v DocBooku napíšeme článek o Matějovi z Horní dolní, můžeme jej velice snadno přetransformovat na HTML pro web a také do RTF pro redakci místního novinového plátku využívající nelegální kopii kancelářského balíku. Stejně tak můžeme napsat knihu, kterou předáme tiskaři v PostScriptu a její elektronickou podobu umístíme ve formátu PDF na FTP server.

Z historie do současnosti

DocBook spatřil světlo světa v roce 1991 a u jeho zrodu stála firma HaL Computers a nakladatelství O’Reilly. V průběhu let se hojně využíval ve velkých firmách jako Hewlett-Packard, SCO, Fujitsu atd. V roce 1999 přešel DocBook pod křídla sdružení OASIS a neustále se vyvíjí.

Původně byl DocBook vyžíván k tvorbě dokumentace k systému Unix, v současnosti byl použit například pro dokumentaci k Linuxu, PHP, FreeBSD a používá se ve firmách jako Sun nebo ve zmíněném nakladatelství O’Reilly.Dnešní možnosti DocBooku ovšem daleko přesahují původní účel dokumentace, bez problémů můžeme napsat článek, knihu či jiný typ dokumentu. DocBook také nabízí možnosti generování rejstříků a jiných vlastností, které jsou pro daný typ dokumentu obvyklé.

Výstupní formáty DocBooku

Právě výstupní formáty jsou jedním z toho nejcennějšího co může DocBook nabídnout. Mezi ty nejznámější patří

  • Web - HTML, XHTML
  • Tisk - Rtf, Pdf, PostScript, LaTex
  • Nápověda - HTMLHelp, JavaHelp

Výstupních formátu je samozřejmě více a podpora dalších se rozšiřuje. K tolika rozličným formátům pomáhá XSL transformace produkující přímo daný formát(HTML,XHTML) nebo transformace do XSL-FO objektu, které jsou patřičným FO procesorem zpracovány na daný formát. Třetí možností je použití DSSL stylů, které jsou již trochu zastaralejší.

Valná většina nástrojů, které budete pro generování příslušného formátu potřebovat je šířena pod licencemi, které umožňují jejich svobodné používání i pro komerční účely. Konfigurace těchto nástrojů a jejich použití je i s DocBookem popsáno ve volně dostupné elektronické knize DocBook:The Definitive Guide.

Další informace jsou k nalezení na oficiálních stránkách DocBooku a hlavně na domovských stránkách Jiřího Koska, který se na DocBooku intenzivně podílí a můžeme u něj najít i neocenitelnou příručku k DocBooku trochu skromě nazvanou DocBook - Stručný úvod do tvorby a zpracování dokumentů, kde se dozvíté mnohem více. Jiří Kosek dokonce připravil i instalační balíček DocBooku pro Windows.

Nevýhoda DocBooku nastane v případě vytváření XML. Pro začátek se budete muset naučit základním pravidlům XML a osvojit si několik základních strukturálních značek. V případě jedince chápajícího, alespoň zlomek toho co nabízí DocBook to neni problém. Vysvětlete ovšem sekretářce, že zápisy z porad nebude psát tak jak je doposud zvyklá ve WYSIWYG textovém editoru typu Word, ale že se bude pohybovat ve světě špičatých závorek. Samozřejmě existují i WYSIWYG editory produkující DocBook XML ovšem jejich cena je vysoká.

Aktualizováno 14.11.2003 v 12:30

Zdenek Bohdanecky Jr. mě upozornil na editor AUTHENTIC 2004 firmy Altova, který by měl DocBook také podporovat. Na stránkách editoru jsem našel zajímavou informaci cituji "authentic™ 2004 is offered under a free software licensing model. (Yes, completely free).".

Aktualizováno 13.11.2003 v 7:20

Tak i použitelný editor s integrovaným DocBookem a dokonce i s českým rozhraním je k dispozici, jak mi napsal Jiří Kosek

otrlejší sekretářka by možná zvládla následující editor: XMLmind (http://www.xmlmind.com/xmleditor/) Editor se nainstaluje rovnou i s DTD a XSL styly pro DocBook, takže stačí v menu vybrat New -> DocBook Document a začít psát. Rozhraní editoru je dokonce počeštěné.

úterý 11. listopadu 2003

Co je co - Open Source, Free software, GPL, LGPGL..?

Na problematiku vztahu Free Software a Open source jsem již několikrát narážel, ale až dnes se mi do rukou dostal starší článek Milana Zamazala (zamazal.org) s trochu krkolomným názvem Free software, Open Source, FSF, OSI, RMS, ESR, GPL, LGPL... Zmatek?. Autor vysvětluje základní rozdíl mezi Free Software a Open source, dotýká se otázek licencí(GPL, LGPL, BSD) a naráží na problematiku spolupráce svobodného a proprietárního softwaru. Pokud v těchto termínech plavete nebo Vám nejsou úplně jasné pak je článek dobrým místem pro začátek.

Související články:

pondělí 10. listopadu 2003

Java Tiger v hledáčku

Pokud jste ještě nic neslyšeli o připravované Jave 1.5 s kódovým označeným Tiger, pak je čas to napravit. Článku a komentářů se objevilo opravdu hodně. Ten nejnovější má na svědomí Petr Sickboy Hejl pod názvem Novinky v Javě aneb Tygří spáry .

Nemá cenu si zastírat, že změny jsou minimální ba naopak, evidentně se přesouvá část práce na kompilátor(generické typy, boxing), který nedělá na rozdíl od programátorů chyby a to je posun jedině k lepšímu. Java dále přebírá některá specifika C#(metadata) a C++(výčtové typy), uvidíme jak tyto "cizí" vlastnosti přijme komunita.

Související články: