MicroBean Jersey Container Grizzly HTTP CDI Integration

This is the sixth of a series of posts on some of the personal projects I’ve been working on.  As I hope you’ll see, they all fit together.  The previous post covered MicroBean Main.  The next post will cover MicroBean Grizzly HTTP Server CDI Integration.

This post covers MicroBean Jersey Container Grizzly HTTP CDI Integration.  Its website is here, its source code is here and its binaries are available from Maven Central.

MicroBean Jersey Container Grizzly HTTP CDI Integration (what a mouthful) provides CDI producer methods that produce two things:

Jersey’s GrizzlyHttpServerFactory uses a GrizzlyHttpContainer to build an HttpServer.  A GrizzlyHttpContainer can be produced by a ContainerFactory if it is supplied with GrizzlyHttpContainer.class and an Application.

To install MicroBean Jersey Container Grizzly HTTP CDI Integration, place it on the classpath.

By itself, this project doesn’t do much.  As mentioned, it installs some producer methods that integrate some Jersey and Grizzly raw materials, but they themselves don’t do anything unless someone else asks for, say, an HttpServer or a GrizzlyHttpContainer.  You are not likely to ask for these things directly in your own code (via @Inject).  And even if you do, you won’t get anything useful unless you have also placed an Application bean into the same CDI environment.

So merely placing this project on the classpath won’t do anything.

But when it is combined with MicroBean Jersey Container Grizzly2 HTTP CDI Extension, the subject of the next post, things get more interesting.  Specifically, as we’ll see, this combination allows you to simply supply an Application, and thanks to the interaction of MicroBean Jersey Container Grizzly2 HTTP CDI ExtensionMicroBean Jersey Container Grizzly HTTP CDI Integration, MicroBean Grizzly HTTP Server CDI IntegrationMicroBean CDI UtilitiesMicroBean Configuration CDIMicroBean ConfigurationMicroBean Main and MicroBean Configuration API, you can have a Jersey server running on a configured port as part of a CDI container started by a public static void main(String[]) method you didn’t write, simply by placing projects on the classpath.  I’ve written previously on this topic.

(I told you this would all start coming together.)

In the next post, we’ll look at MicroBean Grizzly HTTP Server CDI Integration, another supplier of raw materials for running Jersey inside CDI.

MicroBean Main

This is the fifth of a series of posts on some of the personal projects I’ve been working on.  As I hope you’ll see, they all fit together.  The previous post covered MicroBean CDI Utilities.  The next post covers MicroBean Jersey Container Grizzly HTTP CDI Integration.

This post covers MicroBean Main.  Its website is here, its source code is here and its binaries are available from Maven Central.

MicroBean Main provides a public static void main(String[]) method that you can use in your CDI 2.0 Java SE applications.  It is staggeringly simple.  It starts a CDI container, making the command line arguments available to the CDI environment in a portable fashion, and then stops the container.

To install MicroBean Main, place it on the classpath.

That doesn’t sound like much, but as I’ve written previously, that, coupled with the event mechanism that CDI defines that notifies CDI beans when the container is started and stopped, provides a very useful mechanism for integration.  Basically, you don’t have to write your own public static void main(String[]) method or rely on an application server for a CDI environment to be made available to your CDI bean.  If your CDI bean observes the initialization of the application scope context, like, perhaps, this:

private final void onStartup(@Observes @Initialized(ApplicationScoped.class) final Object event) {
  // Here is your "main" code.
}

…then when MicroBean Main‘s Main#main(String[]) method is run your observer method will be invoked.  See my prior post on eager startup for more.

In the next post, we switch gears slightly and talk about Jersey and Grizzly.

MicroBean CDI Utilities

This is the fourth of a series of posts on some of the personal projects I’ve been working on.  As I hope you’ll see, they all fit together.  The previous post covered MicroBean Configuration CDI.  The next post covers MicroBean Main.

This post covers MicroBean CDI Utilities.  Its website is here, its source code is here and its binaries are available from Maven Central.

MicroBean CDI Utilities is a small project as of this writing, but I anticipate that it will grow over time.  Its purview contains general CDI utilities that will no doubt be useful—to me, primarily 😀—for general CDI-related situations, particularly those that arise while making use of the CDI 2.0 Java SE APIs.

To install MicroBean CDI Utilities, place it in your classpath.

The most notable class that it contains as of this writing is AbstractBlockingExtension.  Subclasses will be Extensions that are capable of politely and legally blocking the main CDI container thread in a CDI 2.0 Java SE application.

I’ve written previously about blocking the CDI container from shutting down while still permitting CDI beans to go about their business.  This capability is particularly useful when you want to run a server of some kind from within a CDI environment.

We’ll look at another useful CDI project next: MicroBean Main.

MicroBean Configuration CDI

This is the third of a series of posts on some of the personal projects I’ve been working on.  As I hope you’ll see, they all fit together.  The previous post covered MicroBean Configuration.  The next post covers MicroBean CDI Utilities.

This post covers MicroBean Configuration CDI.  Its website is here, its source code is here and its binaries are available from Maven Central.

MicroBean Configuration CDI is a CDI 2.0 portable extension that adapts MicroBean Configuration API together with a backing implementation (such as MicroBean Configuration) to a CDI 2.0 environment.  In practical terms, this means users can inject configuration values into their CDI beans:

@Inject
@ConfigurationValue("fred")
private Integer fred;

To install MicroBean Configuration CDI, place it in your classpath.  Make sure that you have a MicroBean Configuration API implementation, such as MicroBean Configuration, in your classpath as well.

In this respect, MicroBean Configuration CDI is no different from many other CDI-centric configuration frameworks, such as MicroProfile Config or DeltaSpike Configuration or Apache Tamaya’s CDI extension.

MicroBean Configuration CDI differs from these frameworks in its first-class surfacing of configuration coordinates (for more on configuration coordinates and the API that supports them, see my prior post on MicroBean Configuration API).  It also delegates the actual work of looking up configuration values to the underlying MicroBean Configuration API implementation (see MicroBean Configuration for one such implementation), so in itself is really just a thin layer that calls the API for you.

I hope you can see that these three projects—MicroBean Configuration API, MicroBean Configuration and MicroBean Configuration CDI—taken together or separately allow for easy usage of configuration values in your Java SE applications, including standalone CDI 2.0 applications.  These give us a helpful starting point for some of the other projects we’ll cover next in this series.

The next post covers MicroBean CDI Utilities, a tiny project at the moment that helps with a few simple CDI 2.0 tasks.

MicroBean Configuration

This is the second of a series of posts on some of the personal projects I’ve been working on.  As I hope you’ll see, they all fit together.  The previous post covered MicroBean Configuration API.  The next post covers MicroBean Configuration CDI.

This post covers MicroBean Configuration.  Its website is here, its source code is here and its binaries are available from Maven Central.

MicroBean Configuration is a concrete implementation of MicroBean Configuration API.  Users of MicroBean Configuration API need to know about this project only because it is one possible implementation of the API.  Once it is installed, they do not need to call it.

To install MicroBean Configuration, place its jar file in your classpath.  A call to MicroBean Configuration API‘s Configurations#newInstance() will now succeed.

MicroBean Configuration implements MicroBean Configuration API by providing an implementation of the Configurations class, and by defining a raftload of converters, together with an SPI for defining more.

MicroBean Configuration is written assuming that there will be several, disparate individual configuration systems that it will “front”.  Each is treated as a configuration—that is, a collection of configuration values.  Each is required—when asked for a named configuration value—to not only return the value, but some configuration coordinates for which it is suitable.  This then lets the Configurations class select the maximally specific configuration value from those returned.  I’ve written extensively about configuration coordinates and their importance elsewhere in this blog.

One area worth calling out explicitly is MicroBean Configuration‘s support for resolving configuration disputes.  A configuration dispute arises when two Configurations provide different configuration values with the same specificity, but different configuration coordinates.  For example, one Configuration might return a value suitable for the test environment and the experimental phase (I am making up these axes).  Another might return a value suitable for the experimental phase and the current user.  Both are equally specific given a set of application configuration coordinates that includes the current user, the test environment and the experimental phase.  Which should be chosen?  MicroBean Configuration allows pluggable Arbiters whose job is to resolve disputes such as this.

By default, MicroBean Configuration ships with a Configuration that represents Java system properties.  Other Configuration implementations are planned to front other popular configuration frameworks.

In the next post, we’ll see how MicroBean Configuration API, backed by an implementation such as MicroBean Configuration, can be exposed in a CDI 2.0 environment.

MicroBean Configuration API

This is the first of a series of posts on some of the personal projects I’ve been working on.  As I hope you’ll see, they all fit together.  The next post in the series covers MicroBean Configuration.

This post covers MicroBean Configuration API.  Its website is here, its source code is here and its binaries are available from Maven Central.

MicroBean Configuration API is a Java SE API that abstracts over collections of configuration values.  In this regard it is no different from many other Java configuration APIs.  Like many other configuration frameworks, configuration values are always Strings and can be converted.

Where perhaps it is different is: it expresses configurations—collections of configuration values—in terms of their location in configuration space as determined by configuration coordinates.  Other systems tend to use hierarchies of configuration values, but of course configuration space is not hierarchical so there are always problems with the hierarchical approach.

(Also, other systems use configuration coordinates whether they are fully cognizant of what they’re doing or not—one only has to look at the separation of “user” from “system” values in systems like the Java Preferences API.)

Configuration space as an abstract concept is the universe of all configurations.  Some configurations are suitable for certain application deployments and many are not.  Usually there’s one that is suitable for nearly all application deployments of a particular kind, but that one is generally very “defaultish” (one step away from hard-coded values).  For a given application deployment, you want, of course, the maximally specific configuration to apply to it.  To pick this configuration out from all others, you supply configuration coordinates that locate your application deployment in configuration space, and then MicroBean Configuration API finds the most specific or suitable configuration that exists for it.

Sometimes an application is aware of its own configuration coordinates, or the configuration coordinates that it wants to use when seeking a configuration value.  Other times—the vast majority of times—it is not (they are specified “outside” of it, as in the case of other Java configuration frameworks where you “pass in” notions of a “project stage” or other means of locating configuration values suitable for the deployment).  MicroBean Configuration API offers two fundamental flavors of the getValue() method (with convenience overrides) for these two cases: one for getting a configuration value when the configuration coordinates are known, and one for when they are supplied implicitly.

To make MicroBean Configuration API work, you’ll need a concrete implementation of it. Currently there is one implementation—MicroBean Configuration—which is two things: one, a concrete implementation of MicroBean Configuration API, of course, and two, a multiplexing variant of it (i.e. it can front many other configuration systems).  We’ll cover MicroBean Configuration in the next post.

A Blog Post A Day

I’ve got some interesting things cooking in the personal projects department related to Java, CDI 2.0, configuration and Maven and I am going to blog about them with (I hope!) a post (or several!) a day for a little bit.

We’ll start with configuration.

You may recall my earlier posts on the subject.

Now my ramblings have code behind them!  See MicroBean Configuration API, MicroBean Configuration and MicroBean Configuration CDI.

MicroBean Configuration API is the Java API that defines an API around my notion of configuration coordinates.

MicroBean Configuration is a Java SE implementation of that API.

MicroBean Configuration CDI is a CDI extension that uses MicroBean Configuration to expose configuration values to CDI environments.

I’ll have more to say about these (early days!) projects and others over the coming days.  Thanks for reading.