Ioannis Canellos iocanel

Intro

A couple of weeks ago I came across Roberto Carratalla’s blog post on Function calling on OpenShift AI. At the time I was preparing for RedHat Summit Connect Zurich 2025 where I was meant to run a workshop on Quarkus and Langchain4j with Kyra Goud, Dimitris Andreadis and Codrin Bucur. We had an issue however, related to enabling functions on OpenShift AI.

Roberto pointed us to the blog post, but I couldn’t spot what I was doing wrong. So, I decided to port the examples in the blog post to Java to make sure that I was comparing apples to apples.

Introduction

Kubernetes is around for almost 7 years now! Ever since the beggining there have been efforts to make consuming / binding to services simpler. And while discovering the actual service is not so much of an issue (if you employ a set of conventions), getting the credentials etc is slightly trickier.

The Service Catalog has been an effort that promised to simplify provisioning and binding to services, but it seems that it has lost its momentum. The lack of uniformity between providers, the differences in how each service communicated the binding information and the fact that people tend to favor operators for provisioning services made it pretty hard to use in practice.

Prologue

ap4k is a collection of java annotations and processors for generating, customizing and testing kubernetes and openshift manifests.

The idea of using java annotations for customizing kubernetes and openshift manifests is not something entirely new. In 2015 fabric8 provided an artifact called `kubernetes-generator` (not to be confused with other generators under the fabric8 umbrella) that allowed developers to hook into the compilation process code that customized these manifests. The way the code was hooked into the compilation processors was via java annotations. The idea was nice but did required developers to write actual code, and thus was soon abandoned as in favor of the fabric8-maven-plugin which was rewritten at the same time by Rolland Huss.

Prologue

As I am approaching my 40s its becoming harder and harder to get really excited with a new framework. There are of course some exception to this rule and micronaut is such an exception. I won’t get into details here, but in many ways I feel that micronaut is a framework I would like to have written myself…

So, this post is going to be a first look at micronaut. It will include:

Prologue

I recently came across micronaut one of the many java micro-frameworks that gain a lot of interest lately. This particular framework was being installed locally using a tool that I haven’t come accross before: sdkman.

This will be a really short post about sdkman.

What is sdkman?

Even if you only use a computer for playing games, sooner or later you are going to have to manage multiple versions of the same piece of software. Now, if you are into development then its possible that you’ve either have a handcrafted solution or using one provided by the operating system.

Introduction

This is the second post in my series about the service catalog. If you haven’t done already please read the first post: service catalog: introduction.

In this second post I’ll create from scratch a spring boot application that exposes a JPA crud via rest. This application will use a service catalog managed microsoft sql server database and I will demonstrate how you can automagically connect to it using the service catalog connector.

The spring cloud connector

There is a spring cloud project called spring cloud connectors. This project is all about connecting to cloud managed services. I have been working on an implementation specific to the service catalog. The idea is that you can use the service catalog to manage the services and use the service catalog connector to transparently connect to it.

Prologue

Lately I keep hearing about “how much software development has changed over the last half of the decade”. This usually refers to the adoption of containers, cloud etc. I would like to focus on an other factor of the change and that is the plethora of development related systems and services.

So its typical for a team to have:

• version control
• code review systems
• code analysis systems
• project management
• issue trackers
• continuous integration
• chat / messaging

Add email to that and you realize that most of development related tasks now days take place in the browser. Unfortunately, browsers by nature are unaware of the content they serve, so its not trivial to automate your workflow in the browser. So, if the browser is not going to play the role of ‘Swiss army knife’ for development then what?

Prologue

Yesterday I was having a talk with Adrian Cole and during our talk he had an unpleasant surprise. He found out that he forgot a node running on his Amazon EC2 for a couple of days and that it would cost him a several bucks.

This morning I was thinking about his problem and I was thinking of ways that would help you avoid situations like this.

My idea was to build a simple project that would notify you of your running nodes in the cloud via email at a given interval.

Prologue

I am currently returning home from JavaOne 2011. I am at the airport of Munich waiting for my connecting flight to Athens. Once again the flight my flight is delayed and its a great chance to blog a bit about JavaOne.

Apache Karaf Cellar at JavaOne 2011

I had the chance to make a BOF about Karaf Cellar last Tuesday night. Even though the presentation was really late (20:30) and there were a lot of parties going on at this time (actually I was at the Jboss party right before my presentation) there were quite a few people that attended. The best part was that most of the people who attended were really eager to hear about Karaf & Cellar and I received a lot of great “straight to the point” questions. So I really enjoyed the talk and had a lot of fun.

Prologue

In some previous blog post, I designed and implemented Cellar (a small clustering engine for Apache Karaf powered by Hazelcast). Since then Cellar grew in features and eventually was accepted inside Karaf as a subproject.

This post will provide a brief description of Cellar as it is today.

Cellar Overview

Cellar is designed so that it can provide Karaf the following high level features

• Discovery
  • Multicast
  • Unicast
• Cluster Group Management
  • Node Grouping
• Distributed Configuration Admin
  • per Group distributed configuration data
  • event driven distributed / local bridge
• Distributed Features Service
  • per Group distributed features/repos info
  • event driven distributed / local bridge
• Provisioning Tools
  • Shell commands for cluster provisioning

The core concept behind cellar is that each node can be a part of one ore more groups, that provide the node distributed memory for keeping data (e.g. configuration, features information, other) and a topic which is used to exchange events with the rest group members.

OSGi in the clouds

The last couple of years OSGi and Cloud Computing are two buzz words, that you don’t see go hand in hand that often. JClouds is going to change that, since 1.0.0 release is OSGi ready and it also provide direct integration with Apache Karaf.

jclouds in the Karaf

The last couple of weeks I have been working with the jclouds team in order to improve the OSGification of jclouds and also to provide integration with Apache Karaf. I will not go into much detail in this post, since there is a [[wiki. I will add however a small demo that shows how easy it is.

Presented on OSGi and Apache Karaf on Java Hellenic User Group.

It was a great event with very interesting presentations. The full list of presentations can be found here.

Regarding my presentation, I was a bit nervous at first, since I hadn’t practiced my “presentation” skills for a while, but things got better as time went by. I’ve had the chance to meet a lot of interesting people and discuss about OSGi, Apache Karaf & Apache ServiceMix. The slides of the presentation can be found at: Slide Share.

EDIT: The project “cellar” has been upgraded with a lot new features, which are not described by this post. A new post will be added soon.

Prologue

I have been playing a lot with Hazelcast lately, especially pairing it with Karaf. If you haven’t done already you can read my previous post on using Hazelcast on Karaf.

In this post I am going to take things one step further and use Hazelcast to build a simple clustering engine on Karaf.

Prologue

The last months Hazelcast caught my attention. I first saw the JIRA of the camel-hazelcast component, then I read about it, I run some examples and eventually I fell in love with it.

If you are not already familiar with it, Hazelcast is an opensource clustering platform, which provdies a lot of features such as:

• Auto discovery
• Distributed Collection
• Transactions
• Data Partitioning

You can visit the Hazelcast Documentation for more information. In this blog post I will show how to run hazelcast on Apache Karaf or Apache ServiceMix and I will provide an example application that creates a hazelcast instance, deploys the hazelcast monitoring web application and adds a couple of shell commands on Apache Karaf.

I just returned home from Java ONE and Oracle Develop 2010 (which was also my first ONE) and I thought that it would be a good idea to take 5 minutes and share the experience.

Intro

The city of San Francisco was awesome and I couldn’t find any other place in the world that could be best for the job. The weather, the size and the facilities where exactly what such event required. The organization was good enough and there were tons of sessions that I found exciting.

Prologue

Karaf 2.1.0 has been just released! Among other new features, it includes a major revamp in the JAAS module support:

• Encryption support
• Database Login Module
• Role Policies

This post will use all 3 features, in order to create a secured Wicket application on Karaf, using Karaf’s JAAS modules and Wicket’s auth-roles module.

Introduction

The application that we are going to build is a simple wicket application. It will be deployed on Karaf and the user credentials will be stored in a mysql database. For encrypting the password we will use Karaf’s Jasypt encryption service implementation, to encrypt passwords using MD5 algorithm in hexadecimal format.

1 week after my vacation and still suffering from “post vacation depression”, this Monday seemed like a nightmare.

I went to the office and I was feeling the urge to go get my self a huge Carafe of coffee (cups have long been proven inefficient), when an icoming email draw my attention.

It was an invitation to join Apache Karaf team as a committer.

This is the first open source project I join and I’m very thrilled (if not overreacting) about it and that’s why I decided to blog about it.

EDIT: Hibernate is now OSGi ready so most of those stuff are now completely outdated.

The full source for this post has moved to github under my blog project on branch: wicket-spring-3-jpa2-hibernate-osgi-application-on-apache-karaf.

Prologue

Recently I attempted to modify an existing crud web application for OSGi deployment. During the process I encountered a lot of issues such as

Lack of OSGi bundles. Troubles wiring the tiers of the application together. Issues on the OSGi container configuration. Lack of detailed examples on the web. So, I decided to create such a guide & provide full source for a working example (A very simple person crud application).

EDIT: I am more than happy that this post is now completely obsolete. Hibernate is now OSGi ready, Yay!

Prologue

I was trying to migrate an application that uses JPA 2.0 / Hibernate to OSGi. I found out that hibernate does not provide OSGi bundles. There are some Hibernate bundles provided in the Spring Enterprise Bundle repository, however they are none available for Hibernate 3.5.x which implements JPA 2.0. So I decided to create them myself and share the experience with you.

Prologue

This is the first from a series of posts that demonstrate how to extend ServiceMix management using Spring’s jmx and aop features. The version of SerivceMix that is going to be used will be 3.3.3-SNAPSHOT but I’ve been using this technique since 3.3 and it will probably can be applied to 4.x.

Problem

One of the most common problems I had with servicemix was that even the most simple changes in the configuration (e.g. changing the name of the destination in a jms endpoint) required editing the xbean.xml of the service unit and redeployment. Moreover this affected the rest of the service units contained in the service assemblies, which would be restarted too.