Koodihommia

When OSGi modules are fabricated so that they have limited dependencies to other modules, the development process is a breeze. Changes to any single module reflect to a limited set of other modules which enables easy deployment and update of the running software. In the Karaf based project I'm working on, this is mostly the case: updating for example a bundle which is responsible for a certain UI view, only the corresponding view goes down for a couple of milliseconds and the page is automatically refreshed after that. We started seeing exceptions to this on places where there should not have been any "core" dependencies. When upgrading for example a bundle which exports message/model classes which are part of the Akka communication between the bundles, sometimes the whole karaf seems to go down. The message classes can be used by multiple bundles including the core ones but we started seeing this behavior happening when deploying also non-core Akka message bundles. Wha...

It is not uncommon to have ClassNotFound exceptions thrown when developing applications inside OSGi world. LinkageErrors can be even seen as "normal" exceptions which can have minor effects on how the application works. Akka actors other hand really don't like linkage errors, more specifically, during message handling. If a linkage error is thrown, it will result to the whole actor system going down. Supervision strategies don't help here either, the linkage errors pass right through. To combat the problem, there are some options. The most obvious one is to wrap the actors receive method with try-catch clauses. You either do this is in every actor or create a superclass which delegates the receive to a safe method. Another option is to use compile-time weaved aspects. The actor library can be wrapped and the compiled classes can be then weaved. If using OSGi then the manifest entries need to be set correctly so that the actor classes are exported and for the ser...

Switching to English... Using the Java API with Akka might result in somewhat ugly code, especially if using the UntypedActor classes. If an actor has many types of messages it can receive, it may result in long "if instanceof" chains. The situation can be improved by using AbstractActors or even TypedActors in some cases. There might be an alternative though. To make the code a bit prettier, one solution can be to loan the idea of traits from Scala. Java interfaces with default methods can be used to achieve similar behavior. Let's say we have an Actor A  with some messages [ B, C, D ] it expects. Instead of writing a long handleMessage method with all kinds of if statements, we can set the A to implement interface CTrait . The CTrait has a default method handleC which then handles the C typed message. The CTrait may also force the A to expose some methods so it can do it's job. Finally we need such a setup that handleC is called from A , preferably without ...

Apache Karaf on OSGi standardin täyttävä valmis paketti valikoituja OSGi bundleja. Näppärinä ominaisuuksina mainittakoon mm. Felix gogo shell ja feature filet. Feature fileillä voidaan määritellä mitkä bundlet asennetaan missäkin järjestyksessä. Olemme määrittäneet itse muutamia eri konfiguraatioita omaa softaa varten. Myös osasta karafin omista bundleista olemme hankkiutuneet eroon. Karafissa on myös hyödyllinen maven-plugin jolla voi tehdä kustomisoidun karaf paketin. Käytämme tätä ominaisuutta, jotta saamme rakennettua paketin joka sopii aina testiympäristöistä tuontantoon. Kaikki konfiguraatiot, bundlet ja itse ympäristö on yhdessä tar-paketissa jonka voi purkaa ja ajaa missä vaan Java 8 koneessa. Feature tiedostot ovat hyödyllisiä, mutta aiheuttavat myös harmaita hiuksia. Karaf parsiessaan ja asentaessaan bundleja (featureita) ei välttämättä anna kovin informatiivisia viestejä mikä on pielessä. Tämä tuli erityisen selväksi päivitettäessä karafia kolmosversiosta neloseen. M...

Eräässä projektissa pääasiallinen asiakkaalle näkyvä käyttöliittymä on tehty Liferayn päälle. Käyttöliittymän lisäksi pidämme käyttäjät ja näiden oikeudet liferayn hallinnassa. Asiakkaille on olemassa omat Liferay instanssinsa eri teemoituksineen. Testiympäristöissä on tuotannon tilaa vastaavia referenssiinstansseja. Uudet sivut ja näiden oikeudet siirretään LAR tiedostoissa tuotantoon. Olemme myös käyttäneet Liferaytä piilottamaan tai näyttämään jotain ominaisuuksia vain tietyille käyttäjille. Ongelmana on että emme ole testanneet ikinä automaattisesti LAR-tiedostoja. Tästä on seurannut useita huolimattomuusvirheitä. Haluamme että esimerkiksi vain tietyt käyttäjät näkevät jonkun portletin, mutta se onkin näkynyt kaikille Olemme nykyään varautuneet deploymentteihin sekä testaamalla itse LAR-tiedostot, että ajamalla muutamia SQL-skriptejä tuotannon tietokantaa vasten. LAR-tiedostot ovat pakattuja XML-tiedostoja, joissa on mm. sivujen urlit ja hierarkiat pääsyoikeuksineen. Kun nämä l...

Ohjelmisto on jaettu useaan OSGi bundleen. Bundlet ovat karkeasti jaettavissa viiteen kategoriaan. Näkymätyyppiset bundlet ovat itsenäisiä osia käyttöliittymää. Taustajärjestelmäbundlet toimivat fasadina taustajärjestelmille, joihin otetaan yhteyttä esimerkiksi  SOAPilla. Jaetut bundlet tarjoavat yhteistä koodia jota käytetään useissa eri bundleissa. Core-bundlet sisältävät perustoiminnallisuutta kuten Vaadin UI:n, aktorisysteemin ja navigoinnin. Domain-bundlet sisältävät sen bisneslogiikan jota käyttöliittymä tarvitsee. Presenterit lähettävät viestejä muille OSGi bundleille, jotka ottavat yhteyttä mm. SOAPilla taustajärjestelmiin. Tämä fasadina toimiva middle-layer voi pyöriä sekä samassa että eri OSGi containerissa. Ajatuksena on että näkymät lähettävät pelkästään Akka-viestejä tietämättä, mikä bundle hoitaa nämä eteenpäin. SOAP taustapalveluihin otetaan yhteyttä Akka-Camelilla. Käytössä on pieni klusteri Producereita ja Consumereita. Akka-viestit saapuvat klusteriin, jo...

Sain tehtäväksi tehdä käyttöliittymän tabletille. Valitsimme toteutukseksi AngularJS kirjaston. Se on saanut ristiriitaisen arvion, ainakin mikäli lukee keskustelupalstoja.[1] Tilastojen mukaan sen käyttö on kuitenkin lisääntynyt tasaisesti. [2] Vaikka olin tehnyt pienempiä kokeiluja Angularilla jo ennenkin, ensimmäisenä lähdin etsimään hyvää guideline miten Angularilla tehdään hyvää koodia. Yksi suositumpia guidelineja on John Papan, josta löytyy jopa oma kurssi Pluralsightista. Päätin ottaa sen käyttöön. Huomioitavaa siinä on mm. controllerAs tyylin käyttäminen sekä kaiken ylimääräisen (mm. taustapalvelukutsujen) siirtäminen pois controllereista. Käytin myös jonkin verran directivejä. Directiveillä voi tehdä DOM puusta helpommin luettavaa semanttisessa mielessä. Huomioita piti kiinnittää siihen, että nämä toimivat kontekstista riippumatta jos käyttää useita templateja. AngularJS sanotaan myös verrattain hitaaksi johtuen clienttipuolen HTML templatejen parsimisesta ja digest s...