jTechnics

Munkák és napok

Wednesday, January 14th, 2009 | Uncategorized | No Comments

Az úgy van, hogy én igyekszem mindig pozitívan hozzáálni a világhoz, csak sajnos mikor konkrétan használni akarom a dolgokat valahogy mindig kiderül, hogy nem úgy hajlik, ahogy én szeretném. Ma bent ismét előjött, hogy egy kritikai attitűdű Java-s blogot kéne írni, ami nem kertel, hanem kitér a termékek és szoftverek minden problémájára: valós képet fest a világról. Kedves blog lenne, olyan igazán megkeseredett hangvételle, és kerülné még a látszatát is, hogy valamit pozitívan méltasson.

Csak hogy kicst érzékeltessem a dolgot szeretnék két momentumot leírni a napomból:

Délelőtt felmerült egy kérdés a Glassfish loadbalancing tulajdonságát illetően, aminek jó lett volna utána nézni. Egyikünk a nyílt forrást, a másikunk a decompileolt változatot nézte, kinek mi akad hamarabb a kezeügyébe, míg meglett a válasz. De ezen folyamat alatt kiderült, hogy Build instructions tényleg nem viccel, a Glassfish 2 tényleg csak Maven 1.0.2-vel forgatható. Nem elég hogy Maven 1, de abból is az a változat, amit már le se lehet tölteni az Maven oldalról (az aktuális az 1.1-es), hanem az archive.apache.org-kell kibányászni, hogy menjen.

A délután nevezetes eseménye meg az volt, hogy Oracle SOA Suite-et telepítettem (próbáltam), hogy kicsit kipróbáljam, és rajta keresztül még inkább átérezzem az élet nagyszerűségét. Le is töltöttem a röpke 700 megás telepítőt (az Oracle telepítők mindig 700 megásak, bármit is akarsz letölteni, ha nincs akkora a szoftver, akkor melléraknak nullákat meg egyeket, hogy kijöjjön a CD). A telpítőt a nagyszerű cpio-val csomagolták be, hogy még azt is meg kelljen keresni, hogy milyen kapcsoló kell ahoz, hogy rendesen kicsomagolódjon, mert a cpio alapból könyvtárakat nem tömörít ki, csak fájlokat, de azt meg csak akkor, ha megvan a könyvtár, amibe a fájlnak kerülnie kell. Szóval elindítom a telepítőt, ami némi kattogás után közli, hogy ez a linux (Ubuntu) nem a Linux, mert ő csak Red Hat Enterprise izén hajlandó futni és esetleg Susén, de abból 9esen (a világ OpenSUSE 11.1-nél tart.)  és különben meg szevasz.

Mit mondhatnék, alja egy világban élünk. Tényleg kéne az a blog.

(Ha lesz időm holnap már tényleg leírom a Gradle-s tapasztalataimat a múlt hétről, és lesz benne (valamennyi) pozitív (is). Köszönöm, hogy meghallgattak.)

Tags: glassfish, hétköznap, oracle

JMX és JBI

Sunday, January 4th, 2009 | Uncategorized | No Comments

Ott hagytam abba múltkor, hogy milyen jó, hogy a JBI specifikáció beszél a deployolás és menedzsment témaköréről is, és ANT taskokat valamint JMX bean-eket definiál. (Vesd össze EJB specifikációt, ahol minden menedzsment funkció gyártófüggő).

Nagy örömömben akartam is írni egy egyszerű eszközt, ami alapműveleteket tud elvégezni bármilyen JBI konténeren. Beleástam magam a JBI és a JMX bugyraiba, és rögtön jöttek is a gondolok:

A JBI specifikáció definiálja az MBean interface-eket, amiket implementálni kell, de azt nem, hogy az MBean-eket milyen domain alá kell regisztrálni, így mindenki a saját domain alá regisztrálja a JMX fában a szabvány szerint implementált MBean-jeit. Az lenne a jó, ha lenne egy olyan JMX metódus, amivel egy adott interface-t megvalósító MBean-eket kérem le, de ezt a funkciót sehogyan sem sikerült életre keltenem.

Elvileg van egy isInstanceOf metódus az MBeanServerConnection osztályon (amit a Query API is használ), de ennek a dokumentációja elég körmönfont:

Returns true if the MBean specified is an instance of the specified class, false otherwise.

If name does not name an MBean, this method throws InstanceNotFoundException.

Otherwise, let
X be the MBean named by name,
L be the ClassLoader of X,
N be the class name in X’s MBeanInfo.

If N equals className, the result is true.

Otherwise, if L successfully loads both N and className, and the second class is assignable from the first, the result is true.

Otherwise, the result is false.

Azaz ClassLoader-től függ, hogy mit ad vissza. OpenESB-nél úgy néz ki, hogy a szabványos MBean interface-t leszármaztatja egy com.sun-s interface és annak van implementációja. A com.sun-os interfacre működik az isInstanceOf alapú keresés de ami lényeg lenne a javax.jbi.management-re nem lehet, úgy tűnik azért mert különböző ClassLoader-ek töltik be a com.sun és a javax.jbi osztályokat.

Elvileg találtam utalásokat, hogy a Java 7-ben ez meg lesz jobban oldva (heló 2010). Láttam nyomait továbbá egy valaha létezett JBI Maven pluginnek (forrását nem sikerült elérni), ami deployolni is tudott. Nagyon érdekelne, hogy ott hogy sikerült megoldani a problémát. A ServiceMix-hez szállított ANT taskok forrását megnéztem, ott hardcode-olva vannak a ServiceMix-es MBean-ek címei.

Tags: jbi, jmx

JBI 1.0

Thursday, January 1st, 2009 | Uncategorized | No Comments

Olvasgatom a Java Business Integration specifikációt, nem egy könnyű olvasmány: pl. az EJB specifikáció véleményem szerint sokkal olvasmányosabb (annak ellenére könnyebb átlátni, hogy háromszor annyi oldal).

Akik nem ismernék, annak tájolásképpen: egy SOA-s szabványról van szó, ami az Enterprise Service Bus (ESB) mintát valósítja meg. Lényegileg egy közös üzenetet közvetítő busz köré lehet komponenseket telepíteni. Ebből logikailag két fajta van: Binding Component (BC) és Service Component (SC). A BC-k tipikusan a külvilágból jövő kéréseket konvertálják belső XML-es üzenetekké (tipikus BC-k: SOAP, REST, Email, FTP, XMPP,…), az SC-k pedig általában e buszon szaladgáló üzeneteket alakítgatják vagy a business processt irányítják (tipikus SC-k: XSLT, BPEL, EJB, Scripting). Ezeket lehet össze drótozni a busz mentén, sőt a komponensekbe még lehet deployolni további adatokat (pl. XSLT processorba XSLT-t, BPEL motorba BPEL fájlt, stb).

Számomra a jelenleg problémás részek (én ezeket olvastam ki, de javítsatok ki, ha nincs izagazam).

1. Ha jól értem, akkor a komponensek routolása egyáltalán nem található ki sehonnan. Bár lehet a jbi.xml-ekben routing adatokat megadni, ez egyáltalán nem kötelező. Sok helyen láttam, hogy a a BC-kbe és SC-kbe amikor beledeployolunk akkor egy WSDL-t is deployolunk (A fent elmlített XSLT, BPEL, stb.-k mellett), és ebben a WSDL-ben definiáljuk, hogy milyen endpointot hív meg a komponenes / milyen címen hívható meg. Ez a deployolás azonban teljesen komponenes függő, semmilyen API nincs, amiből utaná kideríthető lenne a routolás.

2. ESB-ről van szó, tehát egy közös buszon közlekednek az üzenetek. Az üzenetet fel lehet küldeni a buszra, valamit ki lehet róla olvasni az üzenetet, de a kiolvasás nem valami listener jellegű interface-en keresztül megy, hanem pollozással. Emiatt ha több szálon szeretnénk feldolgozni az üzeneteket jó eséllyes valami saját thread pooling megoldást kell implementálnunk.

Message reception always follows the “pull” model: the JBI component MUST pull the message exchange instance from the DeliveryChannel, using its own thread of execution. Components MAY use more than one such thread, allowing concurrent message reception by the component. The JBI implementation MAY satisfy multiple accept() requests from a single component in arbitrary order.
(JBI 1.0 spec, 44. oldal)

Továbbá a Future Directions fejezetből (205. o.):

Adoption of a work manager (from another JSR) to allow components to not have to manage their own threads.

Erre persze az a megoldás, hogy minden JBI gyártó csinál saját könyvtárat, ami a JBI nagyon alacsony szintje fölött még egy kényelmesebb absztrakciós szintet ad. (Pl. az OpenESB-nél ezt nevezik Component Toolkit-nek).

Mindent összevetve a JBI mint specifikáció még nem győzött meg. Ha nem lenne adottság lehet, hogy alaposabban megismerkednék az előző bejegyzésekben ajánlott Mule-val, ami szabványt nem implementál, de cserébe okos és egyszerű eszköznek tűnik.

Bár az is lehet, hogy ha tovább elmélyedek a JBI-ben nég változik a véleményem. Az például nagyon jó benne, hogy JMX alapú management API-t ad komponenesek telepítéséhez, deployolásához, stb.

Tags: jbi

JBI próbákozások

Saturday, December 27th, 2008 | Uncategorized | 3 Comments

Régebben egyszer már volt egy ESB-s/JBI-s korszakom, de most úgy tűnik, hogy a munkám is erre fog kanyarodni a jövőben. Elkezdtem hát nézegetni újra az OpenESB-t és más alternatív JBI implementációkat.

(Figyelmeztetés: a következő megjegyzések nem tükrözik az egyes szoftverek minőségét, csupán olvasónapló szerű megjegyzések találkozásokról.)

OpenESB: előszőr evvel próbáltam gyorsan képbe kerülni. Ha jól értem GlassfishESB-néven fut kitüntetett és terjesztett változat, és most van belőle RC. Régen volt egy olyan vonulat, hogy command line-ból is futtatható legyen, ennek aktuális változatát nem találtam. Gondolom a következő generációs OSGIre épülő változat, majd tudni fogja, és addig már nem nagyon. A Fuji viszont ha jól értem a 2009-es J1-re lesz csak Technology Preview, tehát nem lesz aktuális a kövekező időszakokban.

Nemrég tanuja voltam, ahogy valaki próbál konzolból forgatni egy OpenESB-s alkalmazást (alapból ezt a hozzá kapott NetBeans-szel lehet). Hát a szokásos ANT-os library varázslatok kellettek hozzá, csak a Jar filok egy része ráadásul a NetBeans része volt, és onnan kellett volna előbányászni. A mai világban, amikor a CI már elég alap dolognak számít, azért elvárnám, hogy ne kelljen vért pisálni a konzolos fordításhoz.

Még -1: NetBeans 6.1-et adnak alapból az ESB-hez, mert ahhoz vannak jól meg a pluginek (nem NB hívőknek: 6.5 az aktuális verzió)

ServiceMix: Apache projekt. Ehhez már nem kell alkalmazás szerver, futtatható konzolból is. A 3-as verziójú család támogatja a JBI szabványt, a 4-es az OSGi-t. A 4.1-es fogja mindkettőt. Tehát egyelőre a 3-asnál maradok.

Elfog a kisördög, és megpróbálom tesztelni a JBI kompatibilitását úgy, hogy az OpenESB-be deployolom a részeit. Sajnos a shared library komponens nem tartalmaz mindent (a ServiceMix classpath-ában benne van a commons-logging, de ez nem várható el minden JBI konténertől), ezért nem futnak a BC-k OpenESB-n. Egy minusz pont. A legegyszerűbb példa alkalmazás szintén nem JBI kompatibilis, mert a jbi.xml leíró nincs rendesen legenerálva: -2.

Ezekel a kellemetlen dolgokat leszámítva nem néz ki rosszul a dolog, van hozzá pl. sok barátságos Maven plugin, és elég részletes dokumentáció.

PEtALS, ez meg OW2 projekt. Erre jutott még a legkevesebb idő, (=ezzel foglalkozom éppen most) de ez is kedves kis cuccnak tűnik. A komponenesek általában tartalmazzás az összes függőségüket is, simán sikerült depoyolnom az OpenESB-be egyet. Van hozzá webes konzol és onnan is lehet deployolni.

Következő feladat: újra átfutni a JBI speckót. (Illetve utánanézni, hogy mikor lesz már JBI 2.0).

Tags: esb, jbi, openesb, petals, servicemix

Unitils EJB3 modul

Monday, December 22nd, 2008 | Uncategorized | No Comments

Az Unitils-ről szerintem már volt szó itt is: egy nagyon szimpatikus teszt keretrendszer, ami a JUnit és a TestNG tesztek írását tudja nagyon kellemesen megtámogatni. Különböző modulok vannak hozzá (dbunit, Hibernate, JPA EasyMock, Spring) és ezek teszteléséhez egy nagyon használható környzetet ad, ahol annotációk könnyítik meg az életünket.

Most az egyik projektünk a vége felé jár, amiben ezt használtuk EJB3 tesztelésre, és mivel ez a része a projektnek általánosabb a többinék kifaktoráltunk open sourcenak.

A lényege a modulnak, hogy a teszt osztályokat nagyjából úgy lehet használni, mint egy EJB osztályt. Lehet bennük használni a @EJB-t, a @PersistenceContext-stb. és a modul elintézi, hogy az EJB-k ott is legyenek beleinjektálva a teszt lefutása előtt.

A projekt státusza stabil béta: kb. egy éve használjuk egy projektben nagy megelégedéssel: ami implementálva van az stabilan működik, ami nincs implementálva benne (pl. tranzakciós annotációk) azok stabilan nem működnek.

Unitils EJB module a google code-on.

Tags: ejb3. test, junit, unitils

Devoxx 2008

Sunday, December 14th, 2008 | Devoxx | 2 Comments

1. Devoxx

A konferenciának vége, most már az itthon  billentyűzet előtt ülök. Olvasgatom át a bejegyzéseket (és helyesírási hibákat javítgatok, amiből szerintem még most is rengeteg maradt). Ahogy számoltam ~40 bejegyzés ~60 tweet a konferenciáról.

((Kicsit mindig rossz érzésem van, amikor régi bejegyzéseimet olvasom vissza: hajlamos vagyok nagyképűen fogalmazni, és nagyon megmondós lenni az olyan dolgokkal kapcsolatban, amik nem tetszenek. Szeretném ezt azzal árnyalni, hogy hangsúlyozom amit leírtam az mind a szubjektív véleményem volt. És teljes tisztelettel gondolok azokra, akik rengeteg időt és energiát beleöltek egy prezentáció elkészítésébe, mégha az előadás megtekintése engem (bennem rejlő okok miatt is) nem hozott annyra lázba.))

A konferenciát leginkább a TSS Java Symposium Europával tudom összevetni, amin egy jó másfél éve vettem részt. Ahhoz képest ez egy sokkal nagyobb szabású rendezvény (6 párhuzamos előadás 3-hoz képest és 3200 résztvevő a kb 5-600 képest). Az ellátás volt talán egy kicsit a TSS-en jobb, de összességében ez se biztos, ha belevesszók a Devoxx esti filmvetítését (patogatott kukoricával), vagy a sörös-sültkrumplis találkozós estet. A Devoxx általában véve is élőbbnek tűnt sokkal inkább a Java-val foglalkozó fejlesztők, mérnökök, architektek részére szólt. A TSS (látszatra úgy tünt) kicsit a céges nagy embereket akarta megfogni.

Ha valaki választani akar, hogy hova menjen (e kettő közül), mindenképpen a Devoxx-ot ajánlom. Relatív olcsó, relatív közel van, és igazi nagy konferencia.

2. Kütyük. Mindenképpen írni akartam róluk, de sehová se sikerült eddig beilleszteni. Szóval a gépek/alkalmazások, amik a legtöbbet segítettek rajtam:

• bodzasfanta laptopja nélkül semmire nem mentem volna, aligha fogom tudni eléggé meghálálni azt, hogy kölcsönadta. Még akkor is így van, ha elég sok problémám volt a wlan kártyával (heló intrepid, heló kernel).
• A wlan képes (3g modemként is működő) telefon is nagy segítség volt. Eddig azt gondoltam, hogy luxus egy ilyen kütyű, de most sokat segített a wlan problémák debugolásánál, képek posztolásásnál, és backup internet elérésként. Örülök hogy ilyenem lett.
• ScribeFire, az Eszköz: blogíró firefox kiterjesztés. Legnagyobb haszna, hogy offline is lehet vele írni bejegyzéseket (kategóriákkal és tegekkel együtt), és amikor újra megy a wifi egy gombnyomásra elküldi a posztokat. Automatikusan menti a piszkozatokat, és amikor félrenyomok akkor se veszik el a szöveg.

3. előadások Néhány előadást azért kiemelek, amik valami miatt emlékezetesek maradtak. Nem biztos, hogy ők a legjobb előadók (ha valamilyen téma kevésbé érdekel, akkor ott sokkal profibb előadást kell tartani, hogy ugyanannyira megfogjon), de mindegyik valami miatt olyan, ami jobban megragadott mint a többi.

• Giovanni Asproni: Fingers in the Air, a gentle introduction to software estimation — Mert egy buzzword gyanús témában tudott izgalmas előadást tartani.
• Stephan Janssen and friends: The next versions of Parleys.com — Mert komoly munka van mögötte és az eredmény (és ennek bemutatása) késtségkívül látványos.
• Szczepan Faber: Mockito in Action — Visszafogott előadás, sok kódolással. Talán leginkább a stílusa volt, ami megfogott.
• Martin Brehovsky: Bringing Designers and Developers Together with JavaFX and Project Nile — leginkább a BOF-ja volt jó, ott viszont tényleg át tudta adni, hogy mi az egészben a truváj.
• Joris Kuipers: Introduction to the SpringSource dm Server — Mert a szkepticimusom ellenére kis híján rábeszéltek. (Majd ha OSGi-konténerfüggetlen lesznek).

Hát ennyi. Most újfent fordítunk egyet varázssapkánkon és konferenciablogból visszavedlünk a szürke hétköznapokat megéneklő hétköznapi blogba.

Tags: kütyü, összefoglalás

Phil Zoio: Impala – a dymanic module framework for java web development

Friday, December 12th, 2008 | Devoxx | No Comments

Nem mondhatjuk, hogy üres a piac, ha egy új webframework fel akarja magára hívni a figyelmet, akkor nagyon bele kell húznia.

Impala:

• moduláris
• a modulokat dinamikusan tölti be
• tud projektet generálni (ANT szkript)
• depdendencyt kezel (egy ANT target letölti a fájlokat a maven repo-ból)
• Spring alapú (más frameworkoket is támogat, pl. volt demó, hogy egy Wicket oldalt is berakott egy modulba)
• Classpath varázslatokat csinál az OSGi-hez hasonlóan, de nem alapból OSGi modul formátumot használ (azzal indokolja, hogy így egyszerűbb. és hogy így nem kell OSGizálni a 3rd party librarykat). Viszont most már OSGi bundle-okat is be tud tölteni a barátság jegyében.

Voltak benne ügyes ötletek, de azért nem úgy álltam fel, hogy végre láttam a Megoldást.

Tags: impala, modularizáció

Doug Tidwell: Java + XSLT 2.0

Friday, December 12th, 2008 | Devoxx | 3 Comments

Előre kell bocsátanom, hogy hard XSLT ellenes vagyok. Az XSLT-ről az a véleményem, hogy – sarkosan fogalmazva – butaság megpróbálni egy programozási nyelvet XML-ben implementálni. Na jó, egyszerűbb feladatokat meg lehet vele könnyen csinálni, de egyszerűbb feladatokat bármiben meg lehet csinálni .
A többi előadás azonban  semmitmondóbbnak tűnt, hát beültem.

Java toolok: Xalan: XSLT 1.0, XPath 1.0; Saxon XSLT 2.0 XPAth 1.0 XQuery 1.0, viszont a Saxon-SA a schema-aware változat már kereskedelmi (Saxon-B ingyenes, de ez nincs benne). Ezeket láttuk működni, meg JAXR-t, Apache FOP-ot, XSLTC (XSLT kód fordítása java kóddá).

Ami új volt, hogy az XSLT kiterjeszthető:

• Extension elements: olyan elemekkel, amiket XML utasításnak értelmez (pedig alapból nem azok)
• Extension functions: funkciókkal, amik az alap XSLT-ben nincsenek benne, de mi használni akarjuk. pl. xalan-java:com.packageClass paraméter

Xalan támogatja a Bean Srcipting Frameworkot is (BSF), amivel az extension function-t más nyelvbe is meg lehet írni (pl. JavaScript, Jytthon, JRuby).

Vannak még XSLT 2.0-ban custom collation-ok, amikkel String összehasonlítások definiálhatók, és ezáltal saját rendezéseket lehet pl. kitalálni.

Sok eget verő dolog nem hangzott el, de ez az előadó is olyan volt, akinek egyrészt nagyon okosan összerakott fóliái voltak, másrészt a maga az előadó is olyan volt, aki a maga sajátos stílusában végig fent tudta tartani az érdeklődést. Konkrétan úgy tudott beszélni, hogy már-már meggyzőzött, hogy az SVG nem csak egy okos dolog, hanem a világ egyik legkellemesebb dolga. és ezt bármilyen XML/XSLT barát technológiáról. Az egyetlen, ami hiányzott, hogy általában a demónak csak a bemenetét és a kimenetét láttuk, és az XSLT-t pont nem.

Tags: jaxp, saxon, xalan, xml, xslt

Simone Brunozzi, Jerome Bernard: Amazon Web Services

Friday, December 12th, 2008 | Devoxx | No Comments

Az első fele az előadásnak főleg marketing szempontú felsorolása volt az Amazon Service-eknek (S3, EC2, ColoudFront, Simple DB, SQS). Aki nem ismerné: nagyon elosztott nagyon virtuális szolgálltatásokat kínálnak: file hosting, virtuális szerverek futattása, stb. pay-per use alapon.

A második fele az előadásnak kicsit gyakorlatiasabb volt, de sajnos ott se volt elég demó (egy rövid ElasticFox bemutató, amibe bele is fagyott majdnem teljesen a laptopjuk

Szerintem a legjobb információ a témában szantog blogja: http://szantog.com/. Ott az Amazon szolgálltatásai még részletesebb (és főleg felhasznállói szempontú) bemutatásai olvashatóak.

Mivel én nem nagy szolgálltató vagyok, nekem nem az a kérdés, hogy hogy tudok megspórolni 500000$-t azzal, hogy nem építek szerverparkot (példa volt a slide-okon), hanem az a kérdés, hogy olcsóbb tud-e lenni nekem, mint egy hazai szerverhosting. Egyszer régen már elkezdtem utána számolni, és az jött ki, hogy talán. De az biztos, hogy nem drágább nagyságrendlieg. Ki kéne próbálni. Igaz, a mi hosztingunk elég kedvezményes árú.

Javahoz egyébként annyi köze volt az előadásnak, hogy az utolsó példában Spring Source dm Server szerepelt. Kicsit.

Tags: amazon, ec2, s3

Stephan Janssen and friends: The next versions of Parleys.com

Thursday, December 11th, 2008 | Devoxx | No Comments

Aki nem tudja, hogy mi az a parleys.com, az most gyorsan kattintson át, és nézze meg. Számomra az egyik azon kevés szoftvernek, amiről sugárzik, hogy egy termék. Hogy össze van rakva. Hogy használható. (Egy másik ilyen egyébként a Hudson).

Az előadás első fele szerintem hasonló, mint mi a JavaOne-on is lehetett (annyit tudok, hogy ott is sikeresen demóztak, a tartalomnak nem néztem utána). Itt mostani Flex+AIR oldalt mutatták meg különböző barátok más technológiákkal megvalósítva: JavaFX-ben, GWT-ben, Silverlight-ban (ezt nem láttuk), és natív iPhone app is volt. Elég vicces, amikor egymásután látjuk ugyanazokat az effekteket egyszer JavaFX-el, másszor pedig GWT-vel (GWT-FX). Na jó, a JavaFX kicsit szebb volt, de különben tényleg ugyanazok az effektek voltak.

A második fele pedig az új Parleys-ről szólt: lesznek rajta spacek és csatornák. JUG-oknak ingyen, másokknak díjért. Lesz hozzá (hosszasan demózták) varázsalkalmazás, amivel tényleg egyszerű a meglévő előadások feltöltése (bele lehet tölteni a demózó számítógép videójelét, a perezentációt, és az előadóról készélt felvételt, és automatikusan megkeresi a számítógép videójában a demókat, ahol fóliák vannak, ott a prezentációt használja, különben meg a demó videóját, stb.) Használható cucc.

Akarnak belőle pénzt is: pl. a Devoxx videók is előszőr csak fizetős módban lesznek fent, és 1-2 hónap késéssel ingyen, vagy intranetre is lehet rendelni cégeknek stb.

Lesz róla majd még egy BOF, hogy JUG-oknak hogy lehet beszállni, fél óra múlva kezdődik.

Tags: parleys