Coming Up for Air

2018

October

  • Getting Started with Eclipse MicroProfile, Part 8: The Conclusion

    Many times, one of the hardest parts of getting started with a particular piece of technology is figuring out how to get started. :) In this series, I’ve used an extremely simple project to show how to do just that with a number of MicroProfile implementations. Obviously, a real application will have many more concerns than we dealt with in this application, but what this effort gave us is working, runnable, and testable build for six different MicroProfile implementations. What I’d like to do in this final installment in the series, is give some closing thoughts.

  • Getting Started with Eclipse MicroProfile, Part 7: Helidon

    Up next in our series comes an offering from, to me, a somewhat surprising source, Oracle, and that offering is Helidon. I first heard about in September 2018, and while it’s still pre-1.0, it looks extremely promising.

  • Getting Started with Eclipse MicroProfile, Part 6: Hammock

    This time around, we’re going to start looking at a slightly different take on MicroProfile implemenations. Whereas Payara Micro, Thorntail, OpenLibery, and TomEE are all based on application servers (albeit stripped down versions), our implementation in this post, Hammock, is based on a CDI container. Rather than start what amounts to an app server under which a web is deployed, we’ll be spinning up a plain ol' CDI container, which will look for CDI beans to load/start/etc. That may sound weird, and I may not be describing it clearly, so let’s just jump in to the code and take a look.

  • Getting Started with Eclipse MicroProfile, Part 5: TomEE

    In this installment of our series, we’re going to take a look at the last of what I think of as the more traditional, app-server-based/-spawned implementations, TomEE. TomEE is a fully Java EE-enabled distribution of the venerable workhorse Tomcat, and comes with support for creating MicroProfile applications, so let’s see what that looks like.

  • Getting Started with Eclipse MicroProfile, Part 4: OpenLiberty

    Having looked at Thorntail last time, we’ll take a look at OpenLiberty this time. OpenLiberty is the open source project under which, as I understand the state of things, IBM’s WebSphere Liberty is developed. In this installment, we’ll give its MicroProfile support a quick spin.

  • Getting Started with Eclipse MicroProfile, Part 3: Thorntail

    In the last installment, we talked about Payara Micro. In this, we’re going to look at Thorntail. Thorntail, née WildFly Swarm, is based on WildFly from Red Hat and is said to be "just enough app-server". Much like Payara Micro, Thorntail exposes a battle-tested application server platform, stripped down for microservices usage. Let’s a take a look at what it takes to deploy our application on Thorntail.

  • Getting Started with Eclipse MicroProfile, Part 2: Payara Micro

    Payara Micro is a MicroProfile implementation from the good folks at Payara, based on Payara Server, which is itself based on GlassFish. Whew! If you’re familiar with either GlassFish or Payara, you should feel right at home with Payara Micro.

  • Getting Started with Eclipse MicroProfile, Part 1: the Application

    To start our investigation, we need an application to work with. Part of the problem with getting started applications is making sure that your example is complicated enough to be interesting, but not so complicated that the greater message is lost in the details of the app. MicroProfile 2.0 is made up of a number of components:

    • MicroProfile Config 1.3

    • MicroProfile Fault Tolerance 1.1

    • MicroProfile Health Check 1.0

    • MicroProfile JWT Authentication 1.1

    • MicroProfile Metrics 1.1

    • MicroProfile OpenAPI 1.0

    • MicroProfile OpenTracing 1.1

    • MicroProfile Rest Client 1.1

    • CDI 2.0

    • Common Annotations 1.3

    • JAX-RS 2.1

    • JSON-B 1.0

    • JSON-P 1.1

    To include all of those in this would probably be a bit too much technical weight for a getting started effort, so, for this example, I’ve leaned (probably too far) toward simple. Our application will have a single JAX-RS resource, into which is injected a single CDI bean. The point is to have a working REST endpoint, with an inject "service layer", to show a MicroProfile in action, allowing us to verify that our basic environment is configured and working correctly. From there you are free to load on all the complexity you find you need. That’s exactly what I’ll be doing in a separate project. :)

  • Getting Started with Eclipse MicroProfile, Part 0

    microprofile logo The Eclipse MicroProfile is a community-driven profile initially developed by Red Hat, IBM, TomiTribe, Payara and the London Java Community (LJC). Launched in 2016, it was intended to sit alongside Java EE’s Web and Full profiles, offering Java EE developers a smaller, lighter set of standards with which they could build microservices. Today, MicroProfile lives as an Eclipse project, and is being supported and actively developed by its creators as well as many more, including both corporations and individuals, giving us an embarassment of riches, if you will, when it comes to implementations.

    By my count, there are at least 6 implementations from which to choose, leading to the question: Which one do I choose? While there are many aspects that factor in to such a decision, it is not my intent here to answer those questions. Rather, what I’d like to do is provided some small "getting started" projects to help you kick off your own investigation. With that in mind, here are the implementations (in no particular order) that we’re going to look at:

    In Part 1, we’ll cover the (admittedly absurdly basic) application, and in subsequent parts, we’ll see what it takes to deploy that application using each of these MicroProfile implementations.

2014

October

August

  • Can I Use Dropwizard for This?

    I’ve been toying with using DropWizard as my…​ deployment platform for a personal project, but I need/want JAX-RS 2 and CDI, which is a problem for the the stable DW. There is a branch that is migrating to JAX-RS 2 (and Jersey 2.9), and it sort of works, but trying a simple injection is causing a failure I can’t quite figure out:

    Caused by: A MultiException has 1 exceptions.  They are:
1. org.glassfish.hk2.api.UnsatisfiedDependencyException: There was no object available for injection at Injectee(requiredType=SayHelloService,parent=HelloWorldResource,qualifiers={}),position=-1,optional=false,self=false,unqualified=null,288169102)

    at org.jvnet.hk2.internal.ThreeThirtyResolver.resolve(ThreeThirtyResolver.java:74)
    at org.jvnet.hk2.internal.Utilities.justInject(Utilities.java:838)
    at org.jvnet.hk2.internal.ServiceLocatorImpl.inject(ServiceLocatorImpl.java:890)
    at org.jvnet.hk2.internal.ServiceLocatorImpl.inject(ServiceLocatorImpl.java:880)
    at org.glassfish.jersey.server.ApplicationHandler.initialize(ApplicationHandler.java:517)
    at org.glassfish.jersey.server.ApplicationHandler.access$500(ApplicationHandler.java:163)
    at org.glassfish.jersey.server.ApplicationHandler$3.run(ApplicationHandler.java:323)
    at org.glassfish.jersey.internal.Errors$2.call(Errors.java:289)
    at org.glassfish.jersey.internal.Errors$2.call(Errors.java:286)
    at org.glassfish.jersey.internal.Errors.process(Errors.java:315)
    at org.glassfish.jersey.internal.Errors.process(Errors.java:297)
    at org.glassfish.jersey.internal.Errors.processWithException(Errors.java:286)
    at org.glassfish.jersey.server.ApplicationHandler.<init>(ApplicationHandler.java:320)
    at org.glassfish.jersey.server.ApplicationHandler.<init>(ApplicationHandler.java:285)
    at org.glassfish.jersey.servlet.WebComponent.<init>(WebComponent.java:310)
    at org.glassfish.jersey.servlet.ServletContainer.init(ServletContainer.java:170)
    at org.glassfish.jersey.servlet.ServletContainer.init(ServletContainer.java:358)
    at javax.servlet.GenericServlet.init(GenericServlet.java:244)
    at org.eclipse.jetty.servlet.ServletHolder.initServlet(ServletHolder.java:540)
    ... 36 more
Caused by: org.glassfish.hk2.api.UnsatisfiedDependencyException: There was no object available for injection at Injectee(requiredType=SayHelloService,parent=HelloWorldResource,qualifiers={}),position=-1,optional=false,self=false,unqualified=null,288169102)
    ... 55 more

    If I create the Weld runtime and request the beans specifically, I get to good objects (instances of both A and B, with B having an injected instance of A), but once I tell DW to fire things, the app dies:

     1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

            Weld weld = new Weld();
        WeldContainer container = weld.initialize();
        container.instance().select(SayHelloService.class).get();
        SayHelloService service = WeldContext.INSTANCE.getBean(SayHelloService.class);
        final HelloWorldResource resource = container.instance().select(HelloWorldResource.class).get();
        resource.setTemplate(configuration.getTemplate());
        resource.setDefaultName(configuration.getDefaultName());

        final TemplateHealthCheck healthCheck
                = new TemplateHealthCheck(configuration.getTemplate());
        environment.healthChecks().register("template", healthCheck);
        environment.jersey().register(resource);

    It seems, then, my deployment environment will be, at least for now, a Java EE app server. They’re small enough these days that it really shouldn’t matter. I was just curious to see if DW might be viable for me, and it appears that the answer is "not yet".

    I’ll check back later.

May

  • File Uploads with JAX-RS 2

    If you search for how to upload a file to a JAX-RS 2 endpoint, most suggestions will point you to implementation-specific approaches. While that works, it defeats one of the purposes of a spec: portability. There are some posts out there that will point you in the right direction, though. What I’ll do here, then, is present a clear, portable solution to the problem.

March

2013

September

August

  • Gradle, 'provided' scope, and Java EE 7

    Maven has a dependency scope, provided, that indicates that the dependency should not be in the archive. Gradle does not provide such a scope out of the box, but it’s easy enough to add. The following Gradle build demonstrates a very bare-bones Java EE 7 web application setup:

    build.gradle
     1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

    apply plugin: 'war'

repositories {
    mavenCentral()
    mavenLocal()
}

configurations {
    provided
}
sourceSets {
    main { compileClasspath += configurations.provided }
}

dependencies {
    provided 'javax:javaee-api:7.0'
}

July

  • A Simple OAuth2 Client and Server Example: Part II

    In the last post, we took a look at the server side of our OAuth2 system. In this post, we’ll take a quick look at the unit tests that will act as TheUser.

  • A Simple OAuth2 Client and Server Example: Part I

    When implementing web site security, OAuth2 almost always comes up. We’ve had requests to implement OAuth2 in the GlassFish REST interface, and, it turns out, I have a similar need on a personal project. Looking at the spec, though, OAuth2 can be pretty daunting. Fortunately, you don’t need to understand it all, and Apache has a project, Oltu (nee Amber) that handles most of the implementation.

April

2012

December

  • Using Server Sent Events and the GlassFish REST Interface

    Wikipedia defines Server-Sent Events as "a technology for providing push notifications from a server to a browser client in the form of DOM events. The Server-Sent Events EventSource API is now being standardized as part of HTML5 by the W3C." It’s a great alternative to polling the server for updates. Long story short, thanks to the work of the Jersey team, we have "easy" access to this in GlassFish, and we’ve added support for it to our RESTful administration interface. Let’s take a look at a quick sample.

July

  • Writing Pluggable Java EE Applications, The Explanation

    I recently posted the slides and the source code from the presentation I gave at JAXConf San Francisco. While that’s helpful for those who were in my session, it’s probably less so for those who weren’t. What I’ll do in this post, then, is discuss the slides and code in detail, skipping over the introductory slides, and getting right to the heart of the matter.

  • Writing Pluggable Java EE Applications
    jaxlogo

    I just finished giving my session at JAXConf San Francisco 2012, "Writing Plugged-In Java EE Apps". I think it went pretty well, though I guess I’ll find out how it really went when the reviews come in. :) Either way, I had a great time. As promised, here is a tar ball that includes the code we looked at during the session, as well as the accompanying slides. Hopefully I’ll be able to get this code put in a proper public repository (such as java.net or GitHub, or both) soon. For now, feel free to play with the code. Fix bugs. Extend it. Whatever comes to mind. :) If you make changes or use it in something, I’d love to hear about it. Thanks to all who attended!

February

  • Comparing JVM Web Frameworks - A Critique

    Recently, Matt Raible again presented his Comparing JVM Web Frameworks, this time at JFokus 2012. The intent of the presentation, as best as I can gather from half a world away, is to prevent some of the major JVM-based web frameworks, showing the various strengths and weaknesses, which will allow the audience to choose a framework more easily. While the goal is laudable, I’m just not sure how well executed the attempt was.

  • CDI @OKCJUG

    I had the opportunity today to present an introduction to CDI at the Oklahoma City Java Users Group. It was a smaller crowd, but they had great questions nonetheless. After a rough start in a workspace that wasn’t quite as clean as it should have been, I think the went fairly well. I had a good time at least. : )

    Thanks to all those that came out and asked questions during and after. If you’d like to play with the code (WARNING: for those of that weren’t there, these examples are 100% creativity free :), you can download the project here.

January

  • A Jersey POJOMapping Client/Server Example

    JAX-RS is the specification that describes how to build RESTful interfaces in a Java EE environment. Jersey is the reference implementation of that spec, and, like many implementations, offers features above and beyond what spec does. One feature that I’ve been working with recently is the POJOMapping feature, which makes writing services and clients much easier, as well as typesafe.

2011

November

February

  • GlassFish 3.1 Is Now Available

    image::http://glassfish.java.net/image/sparky_3.1_orange.gif[style="float: right; padding: 0px 0px 10px 10px;"] For those that may not have noticed, today the GlassFish team officially released version 3.1. This new release brings in a myriad of features, the most significant of which is probably clustering and high availability. The Aquarium is the best place to find links to blogs, screencasts etc. from various GlassFish engineers (though Markus Eisele has a nice run down of the new features here as well). The Aquarium’s list is pretty extensive, so certainly check it out, but I’d like to highlight a few that I found interesting from teammates of mine:

    People often ask what the difference is between the free GlassFish and the commercially-supported version. The answer really is "not much" in terms of the core server itself (pretty much just branding changes). The commercial version, though, has some nice value-add features, such as the Performance Tuner, amongst others.

    I’m really, really pleased with how GlassFish 3.1 has turned out. We still (and will always) have more work to do, but this is a solid release that finally fills in some enterprise holes that v3 didn’t have time to fill. Download it, install it, kick the tires a bit, and tell us what you what you think. In the meantime, we’re going to go ahead and get started on 3.2.

  • Java EE's Buried Treasure: the Application Client Container

    From time to time, I’m asked about accessing various EE artifacts (EJBs, etc) from a standalone client. Almost invariably, the user is having trouble getting the environment setup, grabbing an InitialContext, etc. Also almost invariably, my answer to them is "use the application client container", which is as far as I can take them. The topic of application client container, or ACC, came up again recently when I was asked on Twitter about an issue with ACC and GlassFish in a clustered environment. While this user (hi, Markus! : ) figured out his issue before I could be of much help, I took this opportunity finally to learn exactly what the ACC is and how to use it. Thanks to Oracle’s Tim Quinn for his patient and tireless help, here’s what I learned…​

2010

December

  • The Value of the Stack

    This morning on twitter, I saw an announcement that Mollom has a new backend, one based on GlassFish. I have to be honest. I don’t know much of anything about Mollom beyond this, nor do I know anything about their previous backend other than it was Java-based. The blog post, though, immediately made me think of dynamic languages.

    These days, it’s hot to be dynamic, whether it’s Ruby, Python, Groovy, or something else. There’s no denying that they have some very compelling features. One of the quotes in the blog post, though, really stood out to me:

    With our move to GlassFish, we’ll have to worry a lot less about memory management, REST handling, XML parsing, database connection pooling, and all the other ancillary things that make big systems work. That frees us up to focus on the domain-specific problems — the actual moving parts of Mollom itself — and will help both support our growth and allow us to implement new features and improve the old ones.

    As I’ve noted, their former architecture was Java-based, but the same idea applies to the typical deployment of projects based on dynamic languages. While readily admitting I’ve done precious little with dynalang projects in the enterprise, from what I’ve read and have heard people discuss, it seems the most common deployment scenario is, for example, Apache httpd with mod_foo installed. There might even be a cluster of these httpd instances (or some other web server that a language or framework suggests) behind a load balancer or two, and that seems to work for a lot of people. While effective, though, it seems that such a configuration leaves a lot of grunt infrastructure work up to the development or production support team.

    Enter the Java EE stack. As the Mollom engineer noted, using an application server like GlassFish gives the developer and support teams quite a bit of infrastructure for free. In addition to what he listed, a full EE stack can also give you clustering/high-availability, monitoring, server management, etc. (Note: GlassFish v2 support all of these. GlassFish v3 does not support clustering, but GlassFish 3.1, which is just about ready to ship, will). Many of the "ancillary things that make big systems work" are provided for you. It’s not free, of course. The system demands are typically higher, and those "ancillary things" have to be configured, tuned and monitored, but they don’t have to be developed, which makes the systems that run on them a fair bit simpler.

    It is possible, of course, to get the best of both worlds. Some dynamic languages, like Groovy, already run on the JVM, while projects like JRuby and Jython allow running those languages in a Java EE container, all while still reaping the benefits that dynamic languages offer. For shops that using those languages, or would like to, this is a very compelling option.

    Dynamic languages do offer a lot that we Java developers would love to use, but users of those dynamic languages would be well-served to take a good look at the Java EE stack and see if perhaps Java can add value to their deployment.

June

2009

December

  • GlassFish v3 Virtual Conference

    This is a little late notice, but we at Sun are holding a "virtual conference" covering GlassFish v3, Java EE 6, etc. You can find details here. It starts in 30 minutes (10:00 CST, 8:00 PST). :)

2008

December

  • Interested in Servlet 3.0?

    If so, you might be interested in the latest webinar from The Aquarium covering Java EE 6 and Servlet 3.0. Spec leads Roberto Chinnici and Rajiv Mordani will be leading the next session covering these two topics. Eduardo has the details.

Search

    Quotes

    Sample quote

    Quote source

    About

    My name is Jason Lee. I am a software developer living in the middle of Oklahoma. I’ve been a professional developer since 1997, using a variety of languages, including Java, Javascript, PHP, Python, Delphi, and even a bit of C#. I currently work for Red Hat on the WildFly/EAP team, where, among other things, I maintain integrations for some MicroProfile specs, OpenTelemetry, Micrometer, Jakarta Faces, and Bean Validation. (Full resume here. LinkedIn profile)

    I am the president of the Oklahoma City JUG, and an occasional speaker at the JUG and a variety of technical conferences.

    On the personal side, I’m active in my church, and enjoy bass guitar, running, fishing, and a variety of martial arts. I’m also married to a beautiful woman, and have two boys, who, thankfully, look like their mother.

    My Links

    Publications

    © Copyright Jason Lee, 2005-2023. All rights reserved.