jAbLoK

Kdyz si prohlédnete nějaký RMI příklad, najdete v něm pravděpodobně něco podobného:

LocateRegistry.createRegistry(myPort);

Kde myPort je port, na kterém spouštíte RMI registry. Jiný port v příkladech nepotkáte. Na první pohled se tedy zdá, že stačí na firewallu povolit příslušný myPort, vytvořit nějaký tunel nebo proxy na server do vnitřní sítě a aplikace bude fungovat.

Což ovšem není pravda. První na co narazíte je, že se po připojení k registry a vyžádání remote interface k vašemu vyexportovanému objektu pokusí klient připojit přímo do vnitřní sítě. Tomu se vyhneme snadno, spustíme náš server s parametrem "-Djava.rmi.server.hostname=adresa.firewallu.cz".

Další problém je ošemetnější. Klient se připojí k registru, vyžádá si remote interface … a nic se nestane. Klient neukončí svůj běh, neobjeví se žádná výjimka, server nezahlásí žádný problém. Prostě se nestane nic (tedy nelze vyloučit, že po dlouhé době dojde k někde timeoutu).

Zakopaného psa najdeme v exportu našich vzdáleně přístupných objektů. Buď jsme pouze podědili UnicastRemoteObject a víc se o nic nestarali, nebo jsme použili metodu UnicastRemoteObject.exportObject(Remote obj).

V obou případech se pro export použil anonymní port. Přesnou definici neznám (ani nevím, jestli takový termín existuje) v praxi je to nějaký vysoký volný port. Teď už je myslím pes zcela vykopán. Klient dostal od registru instrukce kde najde vyexportovaný objekt a pokusil se na daný stroj a port připojit. Firewall pokus o připojení zahodil, klient ani server se nedozvěděli nic a tak oba čekají.

Řešení je již také zřejmé — místo anonymního portu použijeme port, který si sami zvolíme a ten také povolíme na firewallu. Pokud jsme dědili UnicastRemoteObject, závoláme v našem konstruktoru explicitně rodičovský konstruktor: "super(dalsiPort);", pokud exporujeme objekt "ručně", použijeme metodu UnicastRemoteObject.exportObject(Remote obj, int port).

K dalšímu studiu doporučím tutoriál Using a Custom RMI Socket Factory, který se sice tímto tématem přímo nezabývá, ale je zdrojem zábavy i poučení.

K výsledkům zde prezentovaným jsem se dobral šamanským postupem "pokus, omyl, Google", neváhejte mě doplnit či upřesnit.

Po dlouhé době konečně vyšla ostrá verze J2EE aplikačního serveru JBoss ve verzi 4.0. V prvé řadě je třeba zmínit, že se jedná o verzi oficiálně vyhovující standardu J2EE 1.4. Srdcem serveru je JMX mikrojádro a vlastní JBossím AOP framework. Díky tomuto přístupu a integraci Hibernate má notně našlápnuto i k nedávno prezentovanému standardu EJB 3.0.

Mimochodem EJB 3.0, kterou má implementovat chystaná verze JBoss 4.2, můžeme podle JBoss Roadmap očekávat v prvním čtvrtletí roku 2005.

Odkazy:

• Oznámení na Infoworld.Com
• Diskuse na TheServerSide
• http://www.jboss.org/
• JBoss Roadmap

P.S. včera taky vyšly Struts 1.2.4, ale uznejme, že to není až tak zajímavá informace

Pokud (jako já) nepoužíváte žádné IDE, možná oceníte následující minitrik.

Každé spuštění ANTa bere čas — než vůbec naběhne JVM, mohla být potřebná práce dávno hotová. Typickým stresujícím příkladem je například ladění JSP souborů: upravit, deploynout, otestovat. Mezi "upravit" a "deploynout" si vložte 10 sekund čekání a je na světě 100x nic, které vás umořní bez ohledu na vaši zoologickou příslušnost.

Řešení je poměrně snadné. Vytvořte target, který před spuštěním vlastní potřebné operace (deploy, compile) posečká na stisk enteru.

<target name="quick">
    <input>Press any Return to compile ...</input>
    <antcall target="compile"/>
</target>

Na první pohled to jako urychlení nevypadá, že? Pointa teprve příjde:

[vy@stroj work]$ while true; do ant quick; done;

Updated: Tak já to raději dovyprávím. Samo o sobě to žádné zrychlení nepřinese. Výhodu to má ale takovou, že během toho co pracujete, se spustí ant, načte build.xml a pak se jen čeká na váš enter. Target compile se pak provede okamžitě, vy se přesouváte do svého editoru a dál pracujete (testujete, ladíte, …). Během vaší práce se opět spustí ant, načte build.xml, …

Před časem proběhly nějaké úvahy v tuzemské konferenci@java.cz, nějaké pokusy tuším prezentoval Petr Toman na Dione, první dotazy nováčků v konferencích jsou "není ta Java moc pomalá"… zkrátka neutuchající téma.

Zajímavé úvahy najdete ve starším povídání nazvaném Performance of Java versus C++.

Článek obsahuje:

• několik benchmarků
• zajímavou úvahu o tom, proč teoreticky může být Java ještě rychlejší než C++
• obecné povídání o "benchmarkování programovacích jazyků"
• zamyšlení nad důvody, proč je tvrzení "Java je pomalá" stále tak populární

Zajímavé čtení.

Před časem jsem se rozepsal o tom, jak fungují a k čemu jsou dobré anotace, které přináší blížicí se Java 5 (mimochodem od začátku září máme release candidate).

Úplně jsem opomněl anotace, které jsou nově součástí vlastního jazyka. Více o nich najdete v prvním díle článku Annotations in Tiger na IBM developerWorks.

Ve stručnosti:

• Override — upozorňuje kompilátor, že takto anotované metody musíme v případných potomcích přetížit (typicky se může hodit u metod jako toString či hashCode)
• Deprecated — totéž, jako stávající stejnojmenná javadoc značka
• SurpressWarnings — potlačí varování kompilátoru daného typu

Protože se pánům do včera zmíněné verze Struts 1.2.2 vplížilo pár mušek, rovnou vyšla i opravná verze 1.2.3. To to najednou lítá…

Aktualizace: přesnější by bylo mluvit o předběžném buildu 1.2.3 — "opravdová" 1.2.3 by nás měla čekat koncem příštího týdne.