And if you also enjoy working with Quarkus, it is only logical that you want to combine the two of them. So I did.

I’ve crafted an extension for Quarkus for Wicket. This enables injection of CDI beans into your Wicket components, behaviors and sessions. It also configures Wicket based on the Quarkus profile (prod, dev, …).

Getting started with the extension

As the extension is as of yet not officially released, you have to mvn install it into your local repository after checking out the source.

gh repo clone dashorst/quarkus-wicket && cd quarkus-wicket && mvn install
cd ..
mvn io.quarkus.platform:quarkus-maven-plugin:3.23.0:create \                                                                                                                                                     ─╯
    -DprojectGroupId=com.martijndashorst.quarkus \
    -DprojectArtifactId=wicket-getting-started \
    -Dextensions='io.quarkiverse.wicket:quarkus-wicket:999-SNAPSHOT,jdbc-h2,hibernate-orm-panache' \
    -Dcode \
    -Djava=21
cd wicket-getting-started

This generates a project with the following structure:

pom.xml
src/main/java/com/martijndashorst/quarkus/
    MyApplication.java
    MyEntity.java
    MyPage.java
src/main/resources/
     application.properties
     import.sql
src/main/resources/META-INF/
    web.xml

The MyApplication class is the Wicket Application you use to configure Wicket and provide the home page to Wicket, which is the default page that gets rendered when the user hits your application. The codestart defines that the MyPage class is the home page and is automatically generated for you. The MyEntity class is a Panache ORM entity generated by the codestart. The web.xml file defines the servlet filter that directs traffic to Wicket. The file import.sql is the sql script generated by Panache to provide an initial filling for your database.

[!NOTE]
you should uncomment the lines in the import.sql script to get an initial database filling.

When you start the application using quarkus the following happens:

quarkus dev
2025-05-28 21:27:04,440 INFO  [io.qua.hib.orm.dep.dev.HibernateOrmDevServicesProcessor] (build-13) Setting quarkus.hibernate-orm.database.generation=drop-and-create to initialize Dev Services managed database
********************************************************************
*** WARNING: Wicket is running in DEVELOPMENT mode.              ***
***                               ^^^^^^^^^^^                    ***
*** Do NOT deploy to your live server(s) without changing this.  ***
*** See Application#getConfigurationType() for more information. ***
********************************************************************

__  ____  __  _____   ___  __ ____  ______ 
 --/ __ \/ / / / _ | / _ \/ //_/ / / / __/ 
 -/ /_/ / /_/ / __ |/ , _/ ,< / /_/ /\ \   
--\___\_\____/_/ |_/_/|_/_/|_|\____/___/   
2025-05-28 21:27:04,550 INFO  [io.qua.wic.run.arc.ArcInjector] (Quarkus Main Thread) ArcComponentInjector initialized

2025-05-28 21:27:04,556 INFO  [org.apa.wic.Application] (Quarkus Main Thread) [wicket.wicket-quarkus] init: Wicket core library initializer
2025-05-28 21:27:04,556 INFO  [org.apa.wic.pro.htt.WebApplication] (Quarkus Main Thread) [wicket.wicket-quarkus] Started Wicket version 10.5.0 in DEVELOPMENT mode
2025-05-28 21:27:04,598 INFO  [io.quarkus] (Quarkus Main Thread) wicket-getting-started 1.0.0-SNAPSHOT on JVM (powered by Quarkus 3.19.4) started in 0.300s. Listening on: http://localhost:8080
2025-05-28 21:27:04,598 INFO  [io.quarkus] (Quarkus Main Thread) Profile dev activated. Live Coding activated.
2025-05-28 21:27:04,598 INFO  [io.quarkus] (Quarkus Main Thread) Installed features: [agroal, cdi, hibernate-orm, hibernate-orm-panache, jdbc-h2, narayana-jta, servlet, smallrye-context-propagation, vertx, wicket]
2025-05-28 21:27:04,599 INFO  [io.qua.dep.dev.RuntimeUpdatesProcessor] (vert.x-worker-thread-1) Live reload total time: 0.656s 

And when you open the browser and go to http://localhost:8080, you get this image

Getting data into and from the database

So the import script takes care of getting the first data into the database. Now we want to show that on the page in a list, so the MyPage class gets the following code:

import java.util.List;

import org.apache.wicket.markup.html.WebPage;
import org.apache.wicket.markup.html.basic.Label;
import org.apache.wicket.markup.html.list.ListItem;
import org.apache.wicket.markup.html.list.ListView;
import org.apache.wicket.model.LoadableDetachableModel;

public class MyPage extends WebPage {
    private static final long serialVersionUID = 1L;

    public MyPage() {
        add(new ListView<MyEntity>("entities", LoadableDetachableModel.of(this::getEntities)) {
            private static final long serialVersionUID = 1L;

            @Override
            protected void populateItem(ListItem<MyEntity> item) {
                item.add(new Label("field", item.getModel().map(MyEntity::getField)));
            }
        });
    }

    private List<MyEntity> getEntities() {
        return MyEntity.listAll();
    }
}

This creates a ListView and adds a Label component for each entity found in the database. I had to add a getter/setter to MyEntity in order to bind the getter to the label.

This also needs some markup to go with it:

<!DOCTYPE html>
<html xmlns:wicket="http://wicket.apache.org" lang="en" dir="ltr">
<head>
    <meta charset="UTF-8">
    <title>My Page</title>
</head>
<body>
    <h1>My Page</h1>
    <ul>
        <li wicket:id="entities"><span wicket:id="field"></span></li>
    </ul>
</body>
</html>

So if you refresh the page now, this will show the 3 entities that have been added to the database using the import script as shown in the following screen shot.

Conclusion

In this article I presented you with the Quarkus Wicket extension. I showed how to use that to generate a Quarkus + Wicket + Hibernate + Panache application to display a list of entities on a Wicket page.

The Quarkus Wicket extension is a very young technology, and comes with some limitations you can read in the project’s documentation.

Now go ahead and try Wicket and Quarkus yourself!

It is easy to just give up and start drinking. But you can make the stack traces a bit more palatable by just filtering the stack trace such that only the method calls from your own classes remain.

A typical stack trace in one of our applications has 3 caused by’s and counts 127 lines. After my trick, which keeps the ERROR line (the log level), all lines with our company’s package name and all Caused By’s, the remaining line count is 17.

Going from 127 lines of stack trace to just 17…

This simple one-liner for macOS cleans your stack trace into something readable:

pbpaste | grep -i -E 'nl.topicus.|ERROR|caused' | pbcopy

For linux users:

xsel --clipboard --output | grep -i -E 'nl.topicus.|ERROR|caused' | xsel --clipboard --input

For Windows users (“it’s complicated”):

powershell.exe -Command "Get-Clipboard" | grep -i -E 'nl.topicus.|ERROR|caused' | clip

You have to substitute nl.topicus. with your own package name of course, but for our company this works really well.

An example of its use in a template:

{#if cdi:htmx.isHtmxRequest}
<small hx-swap-oob="outerHTML" id="lastUpdated">{lastUpdated}</small>
{/if}

The example above will include the <small> HTML fragment to be swapped out-of-bounds in the response when the request was performed using HTMX, and omit the <small> fragment when the Qute template is rendered using a normal, non-HTMX request.

HTMX will set the HX-Request: true header in the request to your server when it issues a request. Using the JAX-RS @HeatherParam("XX-Request) annotation we can retrieve this value for use in our detector.

The following CDI producer that ensures the proper HTMX headers are retrieved and made available through a request scoped Htmx object.

Design considerations:

• Htmx can’t be a Java record, as those are final and CDI requires beans not to be such
• Htmx must be a top level class, or a static one as CDI requires a default constructor
• you can’t just produce a boolean or Boolean as those are not subclasseable (because CDI)
• because Quarkus uses ARC as the CDI implementation, they advise (require?) injections to be package private
• to retrieve CDI beans in your Qute template, the bean must be @Named
• you can’t use @HeaderParam annotations because those are unknown to CDI

import jakarta.enterprise.context.RequestScoped;
import jakarta.enterprise.inject.Produces;
import jakarta.inject.Named;
import jakarta.inject.Singleton;
import jakarta.ws.rs.HeaderParam;

@Singleton
public class HtmxHeaderProducer {
    public static class Htmx {
        private boolean htmxRequest;

        private boolean htmxBoosted;

        Htmx(boolean htmxRequest, boolean htmxBoosted) {
            this.htmxRequest = htmxRequest;
            this.htmxBoosted = htmxBoosted;
        }

        public boolean isHtmxRequest() {
            return htmxRequest;
        }

        public boolean isHtmxBoosted() {
            return htmxBoosted;
        }
    }

    @Inject
    HttpHeaders headers;

    @Produces
    @Named("htmx")
    @RequestScoped
    public Htmx getHtmx() {
        var hxRequest = headers.getHeaderString("HX-Request");
        var hxBoosted = headers.getHeaderString("HX-Boosted");

        return new Htmx("true".equals(hxRequest), "true".equals(hxBoosted));
    }
}

If you want provide more HTMX-header functionality, it should be fairly easy to implement those in this CDI producer. Enjoy!

The following oneliner bash script below will check if the branch name exists in the log of the current branch (usually main) and generate corresponding delete branch git calls.

git for-each-ref --format='%(refname:short)' refs/heads | grep -v main | while IFS= read -r branch; do
    if [[ $(git log -1 --grep "$branch") ]]; then
        echo "git branch -D $branch"
    fi
done

So given a local branch with name JIRA-banana, and a commit with a message like JIRA-banana fixed NPE in FooBar which was rebased and merged with main, so the local head commit(s) don’t match with what was merged, this will show the branch as merged.

In a single line command:

git for-each-ref --format='%(refname:short)' refs/heads | grep -v main | while IFS= read -r branch; do if [[ $(git log -1 --grep "$branch") ]]; then echo "git branch -D $branch" ; fi ; done

Output:

git branch -D JIRA-banana

The video can be watched below, or when you follow this link. Enjoy my Dunglish!

I was honored to be able to present at the conference and my presentation “HTMX: Web 1.0 with the benefits of Web 2.0 without the grift of Web 3.0” was selected. In this post I’m giving you the cliff notes of the presentation and the slides, as we eagerly await the upload of the recorded video.

These are the slides:

What is HTMX?

HTMX is a client side javascript library that extends HTML using attributes to enable interactivity and dynamic web pages.

Why does HTMX exist?

Current web architecture focusses on oodles of JavaScript and SPA’s to work around the limitations of HTML as a client side application platform:

• HTML only provides GET and POST, and
• only and <form> tags provide client-server communication

Effectively HTML is stuck in 1995. SPA’s solve the “stuck in 1995” problem by working around HTML. HTMX solves the problem by extending HTML

How does HTMX work?

HTMX provides the following to extend HTML, augment the client-server communication and allow you to provide rich user experiences.

• attributes on elements
• request and response headers to give server a way to respond to and direct HTMX
• classes for animations and indicators
• events for hooking into the various stages of HTMX and provide additional interactivity
• javascript functions for configuring HTMX and working with classes, finding and working with elements, and adding extensions
• extensions to provide more functionality like websockets, server-sent events and various DOM morphing algorithms

In the presentation I gave some examples for each of these HTMX additions, and then I proceeded to give a live demo.

A live demo

The live demo consisted of two parts:

• HTMX core functionality htmx-jfall
• A websocket multiplayer flag guessing game Fun with Flags

You can find the code at github (see the links).

Conclusions

With HTMX a backend developer can now make HTML pages more dynamic without having to switch to a full client-side application build. You just render out HTML and progressively enhance the application with HTMX tags and such to make a rich application.

I heartily recommend checking out HTMX and give it a 9/10.

Hypermedia Systems

The revolutionary ideas that empowered the Web

A simpler approach to building applications on the Web and beyond with htmx and Hyperview

Enhancing web applications without using SPA frameworks

To check if the signature is (in)valid you can use this Terminal command:

$ pkgutil --check-signature /Applications/Eclipse\ 2023.09.app 
Package "Eclipse 2023.09":
   Status: package is invalid (checksum did not verify)

When the signature is invalid, you need to recalculate the signature:

$ codesign --force --deep --sign - /Applications/Eclipse\ 2023.09.app 
/Applications/Eclipse 2023.09.app: replacing existing signature

And voilà! your Eclipse will start again.

If you use React right, it’s gonna work out… Just like communism, agile and being a Scotsman

What is HTMX in a nutshell?

It is a JavaScript library that enables Hypertext As The Engine Of Application State (HATEOAS) in the browser by using attributes to declaritively specify what actions need to be taken and which element needs to be replaced by the HTML response of the action. HTMX issues mostly AJAX requests and integrates with the history API. It is fully HTML driven, no additional JavaScript is necessary, only if you want pure clientside functionality.

<div hx-get="/banana" hx-target="#strawberry">Click me</div>

<div id="strawberry">gets replaced by the HTML that is returned after the AJAX GET</div>

Clicking the Click me text inside the first div element will issue an AJAX GET request to the /banana endpoint on the server. The request should respond with a HTML fragment that will replace the strawberry div. HTMX takes care of all the plumbing.

My notes

• Quarkus: it is rather easy to get started and add new plugins
• For this project I needed Qute templates and JAX-RS (so rest-easy)
• Including HTMX is just using a <script> tag
• Using HTMX is just using the proper hx-XYZ attributes on your DOM elements
• Most uses for rich clients are present in the HTMX API: updating multiple elements in one go, events, history, etc.
• Rethinking how to do templating and setting up HTML endpoints for the UI is challenging coming from a Wicket history

As you might know I have a pretty strong Wicket background. So the serverside rendering component of HTMX and low-JavaScript usage appeals to me considerably. I have to re-learn some stuff to actually get good in the HTMX and HATEOAS mindset, and to combine multi-element updates instead of relying on full page refreshes (which HTMX takes good care of!)

I have created an already quite complicated UI with:

• a sidebard menu containing our projects,
• a row of tabs containing the contents of each project,
• a list of (SQL) files and a SQL previewer,
• a previewer that syntax highlights the TSQL files
• a link to github to directly edit the SQL file

And all these items are linked together already, with a minimum of Java code, HTML and no JavaScript of my own.

Tally for now:

• 94 lines of HTML templates
• 173 lines of Java code (sloccount)
• bootstrap 5.3 (and bootstrap icons)
• highlightjs + highlight-tsql
• HTMX

Next up

• securing the thing with OIDC + Topicus Keyhub
• connecting the project to a local git checkout of our project(s)
• making the scripts runnable against a database

In conclusion

The fun part when compared to writing Wicket pages is that you can easily edit the HTML templates to add functionality. It is further enhanced by the quick reloading of my currently 3 Java classes by Quarkus’ development mode.

The hardest part for me is to figure out how to make this all maintainable and discoverable. The Qute templating engine is nice, and Quarkus has some decent defaults, so probably I need to adhere to those standards more.

The next weeks will be fun and filled with learning!