Tag: microbean

MicroBean Launcher

This is the eleventh 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 Commons CLI.

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

MicroBean Launcher lets you run a Java SE CDI 2.0 application from the command line by specifying Maven artifact coordinates to other bean archives, transitively resolving them and their dependencies, using MicroBean Maven CDI, to your local Maven repository.

To install MicroBean Launcher, place it (and its minimal dependencies) on your classpath.

Here is an example of its usage, assuming it and its dependencies are on your classpath already:

java org.microbean.launcher.main.Main --artifactPath com.foobar:frobnicator:1.0,com.foobar:caturgiator:2.0

This command will download, if necessary, com.foobar‘s frobnicator jar artifact at version 1.0 and com.foobar‘s caturgiator jar artifact at version 2.0.  These files and their transitive compile- and runtime-scoped dependencies will be placed in the current user’s local Maven repository (~/.m2/repository by default, but the user’s ~/.m2/settings.xml file, which can dictate where the local repository is, is honored).  (If the artifacts already exist, then no download happens.)  A classpath will be built out of all of these artifacts and effectively appended to the current classpath, and MicroBean Main will be invoked.

Why is this useful?  For one, specifying a classpath can now be done in terms of Maven artifact coordinates instead of local filesystem references.  Because MicroBean Maven CDI is in charge of dependency resolution using Maven’s own resolution machinery under the covers, you don’t need to be aware of whether the artifacts in question were downloaded or already present.

But more than this, note that in the last ten blog posts the installation instructions have been the same: you place whatever bean archive is being described on your classpath.  This is one of the nice things about CDI: CDI archives are loosely coupled modules that can be discovered.

This means you can compose a Java SE CDI 2.0 application together by simply referring to Maven artifacts.

Specifically, assuming you have MicroBean Launcher and its dependencies on your CLASSPATH, if you write, say, a JAX-RS Application and a root resource class that it exposes, and place them on your classpath, then you can run that application immediately, downloading only what you need and only what you don’t already have, by running a command line similar to the following:

java org.microbean.launcher.main.Main --artifactPath org.microbean:microbean-jersey-container-grizzly2-http-cdi-extension,org.microbean:microbean-jersey-container-grizzly2-http-cdi,org.microbean:microbean-grizzly-http-server-cdi

Note in particular that your application remains standards-compliant, and you selected the server you wanted to use to run it dynamically from the command line.  You wrote only the code you needed to and none other.

Note that the second time you run this all of the artifacts will already be present on your system.

These are early days for these personal projects and I’ll have plenty more to say about them in the future.  Thanks for reading!

Advertisement

MicroBean Commons CLI

This is the tenth 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 Maven CDI.  The next post covers MicroBean Launcher.

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

MicroBean Commons CLI provides a CDI portable extension that sets up a producer method that produces a CommandLine if there is an Options CDI bean instance in the current CDI container, and if something somewhere makes the command-line arguments available as a String[] qualified with @Named("commandLineArguments") (it just so happens that MicroBean Main does this).

To install MicroBean Commons CLI, place it (and its dependencies) on your classpath.

This means that if your application has a producer method in it that returns an Options, and MicroBean Commons CLI is on the classpath, then you can @Inject a CommandLine anywhere you like, which gives you access to command line option processing.  This, in turn, means that your CDI bean can process command line options easily and intelligently, even though in all likelihood you probably didn’t write the public static void main(String[]) method.  See my post on MicroBean Main for more on this general pattern.

The next post covers MicroBean Launcher, which allows you to link and run a CDI 2.0 Java SE application together out of Maven-addressible artifact coordinates.

MicroBean Maven CDI

This is the ninth 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 Jersey Container Grizzly2 HTTP CDI Extension.  The next post covers MicroBean Commons CLI.

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

MicroBean Maven CDI adapts the inner workings of the Maven Artifact Resolver project so that it can be exposed in a CDI 2.0 environment.

To install MicroBean Maven CDI, place it on your classpath.

The Maven Artifact Resolver project is the Maven-as-build-tool-independent “guts” inside of Maven responsible for transitive dependency resolution and management.  (I’ve written before on this topic.)  MicroBean Maven CDI makes this tooling available inside a CDI 2.0 environment (including Java SE CDI 2.0 applications), along with the common Maven conventions of user-specific settings.xml files and local Maven repositories.  Any interesting magic that it performs is really confined to the translation of Plexus annotations such as Component and Requirement to CDI injection points, which it does by virtue of the power of the CDI portable extension SPI.

There are many ways this could be useful.  Consider—from within your CDI bean—taking in a Maven-style groupId:artifactId:version String identifier and having it resolve to a local file automatically if that file is not already present in exactly the same way that Maven resolves it (jokes about “downloading the Internet” are hereby routed to /dev/null, as usually these indicate an ignorance of the (well-documented) updatePolicy element).  As we’ll see, there are even more powerful things you can do with these capabilities.  I’ve touched on some of them earlier.

In the next post, we’ll touch on the integration of the Apache Commons CLI project with CDI 2.0 by way of MicroBean Commons CLI.

MicroBean Jersey Container Grizzly2 HTTP CDI Extension

This is the eighth 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 Grizzly HTTP Server CDI Integration.  The next post covers MicroBean Maven CDI.

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

MicroBean Jersey Container Grizzly2 HTTP CDI Extension (another mouthful) uses MicroBean CDI Utilities and Jersey and Grizzly classes to provide an AbstractBlockingExtension that starts up a Jersey server on a configurable port inside a CDI container if an Application instance is found in the same CDI container.

To install MicroBean Jersey Container Grizzly2 HTTP CDI Extension, place it on your classpath.

MicroBean Jersey Container Grizzly2 HTTP CDI Extension does exactly nothing if there is not an HttpServer instance in the CDI container.  You can cause an HttpServer to exist in the CDI container in any way that you like.  One particularly useful way is to use MicroBean Jersey Container Grizzly HTTP CDI Integration (just place it, too, on your classpath).

If there is an HttpServer instance in the CDI container (or actually any number), then MicroBean Jersey Container Grizzly2 HTTP CDI Extension starts it in such a way that the CDI container is politely and legally blocked.  (I’ve written before on the topic of politely blocking the CDI container.)  See the documentation for the AbstractBlockingExtension class for more information.

The net effect of all this is that if you place the following projects on your classpath (and their minimal dependencies) together with your Application instance, you will have an executable Java SE CDI program serving your JAX-RS application on a port of your choosing via Jersey’s GrizzlyHttpServerFactory without having had to write any code other than that of your Application class:

The next post covers MicroBean Maven CDI.  I promise this will continue to be relevant, despite the Maven reference. 😀

MicroBean Grizzly HTTP Server CDI Integration

This is the seventh 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 Jersey Container Grizzly HTTP CDI Integration.  The next post will cover MicroBean Jersey Container Grizzly2 HTTP CDI Extension.

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

MicroBean Grizzly HTTP Server CDI Integration is a simple, small CDI-related project that provides producer methods for two simple things:

That’s it.

To install MicroBean Grizzly HTTP Server CDI Integration, place it on your classpath.

This project on its own is, of course, not very interesting.  But it arranges for some of the raw materials of Grizzly to be made available to CDI injection points, mostly with the assumption that they will be used byMicroBean Jersey Container Grizzly HTTP CDI Integration.  Obviously, if you want to go about supplying instances of these objects in some other way, simply do not put MicroBean Grizzly HTTP Server CDI Integration on the classpath and use your own producer methods instead.

In the next post, we’ll look at MicroBean Jersey Container Grizzly2 HTTP CDI Extension, which will tie several of the MicroBean libraries together.

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 Extension, MicroBean Jersey Container Grizzly HTTP CDI Integration, MicroBean Grizzly HTTP Server CDI Integration, MicroBean CDI Utilities, MicroBean Configuration CDI, MicroBean Configuration, MicroBean 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.