Kuidas ma WebLogicut skriptisin

Olen möödunud paari nädala jooksul vaikselt build automationiga tegelenud. Teatud põhjustel (millest ehk kunagi tulevikus) ketserlikult MS Windowsi platvormil. Aga mitte ketserlusest ei kavatsenud ma teile täna kirjutada. Mõtlesin, et kirjutaks õpitust WebLogic Serveri taskide skriptimisel.

Ultimate eesmärk oli automaatse buildi ühe osana deployda (ja ka undeployda) WL serverile aplikatsioon, ning selle vastu teste jooksutada. Nii esmapilgul vaadates pole selles ju midagi keerulist – WL on developeridele skriptiga deploymiseks valmis teinud omad Ant-i taskid (weblogic.ant.taskdefs.management.WLDeploy), mida kasutades saab väikese proovimise peale aplikatsiooni ilusti deploytud. Kuna mu eesmärgiks oli ka peale õnnestunud deployd serveril ka teste jooksutada oli mul vaja teada, millal deploy on lõppenud ning kas see ka õnnestus. WLDeploy-d saab parameetri nowait seadmisega just sedasi käituma panna. Siiski on asjal üks nüanss.

Nimelt toimib WLDeploy erinevalt olenevalt sellest, millisele serveri konfiguratsioonile aplikatsiooni deployda. Meil kasutavad developerid reeglina WL Serveri konfiguratsiooni, kus WL admin server ja application server töötavad ühe instancena (ehk siis ilma eraldiseisva admin serverita). Nagu peale korduvat proovimist selgus tagastab WLDeploy task sellise konfiguratsiooni puhul alati peale seda, kui deploy õnnelikult alanud (ehk siis aplication on prepared olekus ja mitte fully running nagu mul vaja oli).

Kus häda kõige suurem seal Google kõige lähem. Veidi mööda internetti kolades selgus, et WL management API-t kasutades saab ka ise analoogilise deployment taski kirjutada. Egas midagi, üsna täpselt kopi-paste kood siit andis juba paremaid tulemusi…aga ka kõrvaltulemusi.

Nimelt kaasnesid selle kasutamisega täisesti reeglipäratud taski rippuma jäämised, mis arusaadavalt ei ole automationi seisukohalt aktsepteeritav lahendus. Ant ise pakub välja optional taskina ServerDeploy nimelise, mille abil peaks ka olema võimalik WL serverisse deploy-da. Kuna mul see peale mõningast mängimist mingit positiivset tulemust ei andnud loobusin.

Olukord ei tundunud kuigi roosiline. Mõtlesin juba perioodilise pollimise skripti kirutamisele kui proovisin WLDeploy-d kasutavat skripti sellisel serveri konfil, mis sisaldas eraldi admin serverit ning eraldi managed application serverit. Üllatuslikult töötas WLDeploy sellisel konfiguratsioonil nagu dokumentatsioon kirjeldas – anti task tagastas peale deploymendi lõppu. Läbi jäi proovimata weblogic.Deployer utiliit.

Nii kaugele jõudnud lasin CruiseControli käima ja märkisin taskide list ristikese. Aga ennatlikult. Nagu peatselt selgus, ei talu WLi väga mitut järjestikust deploy/undeploy tskükklit – iga järgmine ring võtab järjest kauem ja kaaauuueeeem ja kaaaaaaaaaauuuuuuuuueeeeeem kuni OutOfMemoryException meid külastab. Noh mis seal siis ikka – restardime serverit.

Ka selleks pakub WL meile mitut võimalust. Googeldades statute ilmselt esmalt weblogic.ant.taskdefs.management.WLServer võimaluse aga see on vale tee. See anti task võimaldab WLi serverit startida vaid konkreetse taski töötamise ajaks (ilmselt siis mõttega, taski käigus startida server, seal midagi konfida ja pärast server jälle shutdownida). Töötava lahenduse pakub weblogic.Admin nimelise utiliidi kasutamine. Ehk siis serveri startimiseks sain ma ligikaudu sellise anti-targeti:

<path id="weblogic.path">
<pathelement location="${weblogic.home}/server/lib/weblogic.jar" />
<pathelement location="${weblogic.home}/server/lib/webservices.jar" />
</path>

<target name="StartManagedServer" description="Starts a managed server">
<echo level="info" message="${ant.project.name} - Starting server ${server.name}" />
<java classname="weblogic.Admin" failonerror="false" fork="true">
<arg line="-url ${deploy.target}" />
<arg line="-username ${deploy.userid}" />
<arg line="-password ${deploy.password}" />
<arg line=" START" />
<arg line=" ${server.name}" />
<classpath>
<path refid="weblogic.path" />
</classpath>
</java>
</target>

Olgu veel öeldud et ka selle utiliidi kasutamine eeldab eraldiseisvat admin serverit – selleks, et managed serverit startida peab admin server kättesaadav olema. Samuti (kui ma nüüd õigesti mäletan) eeldas see vist, et managed server ja admin server asusvad samas masinas. Seega WebLogicut build automationi juures kasutades eraldiseisva admin serveri konfimisest ei pääse.

Leave a Reply

Your email address will not be published. Required fields are marked *