So, I recently upgraded from Java 8 and Wildfly 26 to Java 21 and Wildfly 38. Everything seemed fine… except for some weird stack traces that appeared a few times a day: This exception comes from Java’s deserialization filtering, introduced in newer Java versions and enforced more strictly in JDK 21. WildFly 38 may also […]
So, the Renovate Bot created a PR about the Wildfly version update to 38.0.1.Final from 38.0.0.Final. Business-as-usual, like hundreds of PR before, the Gitlab’s pipeline started, and, its failed: Okay, it is also business-as-usual, there are changes that cause code that used to work to not work anymore, but it usually happens when a breaking
What do we want? To query how many messages (and scheduled messages) are in a JMS queue. How can we achieve this? The JMS API does not provide the ability or tools to do this, but we can query this data from Wildfly/JBoss CLI, so that, the information is present on runtime: However, if it
Finally, I’ve just upgraded the Wildfly v26.0.1 (released on January 21, 2022) to Wildfly v38.0.0 (released on October 16, 2025), under the hood of the Power of Planets project. There was a big and significant technical debt in the files that I’d been carrying for months – what months?! – years. The main reason was
Huh… I’m working with Android’s OpenGL ES 2.0 on the map, it is nearly hopeless after the HTML5’s Canvas. Creating, compiling and linking low level pixel fragment shader programs is more difficult than writing a simple 2D drawings… :/
Tegnap este jó pár órát töltöttem azzal a tevékenységgel, amelyekkel a kezdő (és sokszor a haladó) fejlesztő nem számol, amikor egy feladatra becslést ad: rejtélyes hibának az okát keresi. Nem kell komoly dologra gondolni, egyszerűen elő fogok adni egy Java konferencián Android és JavaEE: légy REST! témában, ezért szokásomhoz híven viszonylag korán nekiálltam az előadás anyagát elkészíteni. A peremfeltételek
Próbálok haladni a korral és egy új projektet megpróbálok Git alapokon verzió kezelni, merthogy majd lesz benne sok refaktorálás, létre is hoztam szépen a Git repository-t, tettem fölé HTTP protokollt, éppen kötném be a Jenkins alá, amikor rájöttem arra a nem túl reklámozott korlátozásra, hogy egy repository az nagyjából egyben kezelendő fordítási egység vagy projekt.
Adjunk hozzá egy új felhasználót: Ha költöztetünk vagy frissítünk, akkor mentsük le a régi példány adatait, majd a jenkins.war felülírása után indítsuk el az új verziót: …és ellenőrizzük a futását:
Hozzuk létre a nexus felhasználót, majd töltsük le a Nexus egy friss példányát: Ha frissítünk vagy költöztetünk, akkor mentsük el a sonatype-work könyvtárat: Majd indítsuk el az új Nexus verziót:
Adjunk hozzá egy felhasználót és töltsünk le egy friss Sonar verziót és indítsuk el: Állítsuk be a virtuális szervert: Állítsuk be az adatbázis elérést és töltsük vissza az előző adatbázist, ha költöztetjük vagy frissítjük a példányt: Állítsuk be a Sonar példányt a megfelelő JDBC paraméterekkel: Majd nézzük meg, hogy működik-e: