This articles continues a series on declarative services in OSGi. We started with a basic OSGi bundle, then discussed architecting a multi-bundle application. Then we looked closer at declarative services and how to register them. All of this is fully demonstrated in an example application on GitHub. With the last article, we left off with a service interface, and implementation, and a few ways to tell the service registry about it.

In two previous articles, I introduced building an OSGi bundle and the architecture of a multi-bundle OSGi solution. One of the key features of that multi-bundle solution in its associated GitHub repository is the use of OSGi declarative services. OSGi declarative services are the OSGi way to handle the instantiation problem: the fact that we want to code to interfaces, but we need some way to instantiate classes and some way to provide some concrete instance of an interface in order for the parts of our modular application to work together.

So with our previous article and with a sample application, we made it all the way to an OSGi bundle that we can install in a Karaf container. However, so far we just build the bundle for our interfaces project, which just contains a single Java class. And that raises an important question: in a project with only five total Java classes, why did I go to the trouble to have four separate OSGi bundles, plus a separate Maven project for the Karaf feature repository XML file?

After finishing a pair of articles last week on Karaf features, I felt that I had done a poor job of explaining the context in which all of this bundling and featurizing was taking place. Instead I pretty much started in the middle, assuming the existence of OSGi bundles with proper manifests, all snug in their Maven repositories. So I’m going to correct that and at the same time illustrate another cool OSGi technology: declarative services.

I’ve worked on multiple teams that have successfully used Apache Karaf as an OSGi container. In addition to the usual need to understand OSGi bundles and class resolution in the context of multiple class loaders (which deserves at least one article all by itself), Karaf adds the concept of a “feature” on top of OSGi bundles. While there is detailed documentation on features, I’ve found that they can be confusing for new users, especially when they are resolved from Maven, since there seems to be so much behind the scenes magic involved.

In a previous article I provided an introduction to how Apache Karaf uses “features” to simplify adding OSGi bundles to a container, including handling dependencies. As discussed in that article, Karaf has its own XML format for a “feature repository”, an XML file that lists one or more features. Each feature lists features or bundles that it relies on, with support for versioning. The whole thing works because Karaf can retrieve both the feature repository XML files and the OSGi bundles from a variety of sources, including Maven.

layout: post title: “Suggested Zone: DevOps” description: "" category: articles tags: [] TLDR: Extreme Programming appears to be at odds with traditional software engineering processes. But there are some interesting parallels. Like over two thousand others at DZone, I recently read Grzegorz Ziemoński’s article on Test Driven Development (TDD). I always enjoy Grzegorz’s articles and appreciate his bold willingness to state opinions. I especially respect any author who takes on the challenge to write about things they’ve done wrong.

Early in my career, someone explained to me why “ping” is such a natural first test when something goes wrong with an application or service. It’s not just because it’s a basic test with a quick yes/no answer. It’s also because it bisects the standard network stack. If “ping” works, the issue is usually above the IP layer; if not, the issue is usually below (firewalls being the exception). Similarly, when I recently spent some time creating a “smoke test” for an application deployment, I wanted something that would check if the application was up and running, without checking any complex behavior.

It might be having a child in Spanish this year, or maybe it’s the fact that I’ve been switching from Java to Ruby to Go to Python over the past couple months, but I’ve been giving some thought to how different languages are “flavored”. One of my favorite things about the Go programming language is that the second thing you read while learning it is a whole book on “writing clear, idiomatic Go code”.

Vagrant has built-in support for running Puppet in either “apply” mode, where the Puppet manifests and modules are provided from the host running Vagrant, or in “server” mode, where Puppet on the VM connects to some shared Puppet server. The latter choice has the advantage of requiring less setup for new users and of being closer to a typical production environment. However, there is one major issue with using Puppet this way.

I just finished reading an interesting article here on DZone about the benefits of Java EE in contrast to microservices. In my opinion, it’s always salutary to see an argument like this that goes against the prevailing trend, because it helps us to remember that one of the most important rules of architecture is the one defined by Robert Heinlein: There Ain’t No Such Thing as a Free Lunch (TANSTAAFL).

I was reading Martin Fowler’s well-known paper on architecture as a result of the reading and thinking I’ve been doing about the work of an architect (as exemplified in a few recent articles). I very much like the idea of thinking about architecture as “things which are hard to change”. As he points out, in software there is no particular reason why anything should be hard to change. For anything we can think of: interfaces, database schema, even programming language, someone has come up with a scheme to make it easy to change.

It’s been a while since I did a lot of work with Mockito, but I like to cover it when I teach unit testing for a couple reasons. First, it encourages students to think about writing for testability by showing what kinds of designs are easy to test and what kinds are very challenging. I believe this encourages more modular code. Second, it encourages students to write smaller, more focused unit tests.

In a previous article I introduced using Mockito to mock a database by mocking all the classes involved in the JDBC API. However, that simple example didn’t include any complex cases, like wanting the mocks to respond differently to different kinds of inputs. Argument Matchers Mockito argument matchers are very powerful. We saw a simple example in the last article: when(rs.getString(2)).thenReturn(p.getFirstName()); This creates a rule in the mock object that is only invoked when the getString() method is called with an argument of 2.

Recently I wrote several articles on The Case for Lean. In that context I was writing about lean agile methods, specifically a class of agile methods that do not include “sprints” but instead use a continuous flow system with limits on work-in-progress. In those articles I tried to show why you might choose continuous flow over sprints to fit certain situations. By contrast, you might call this article “The Limits of Lean”, since I intend to write about something that can get overlooked when using lean techniques.