Enterprise grade Java.
You'll read about Conferences, Java User Groups, Java, Integration, Reactive, Microservices and other technologies.

Thursday, December 31, 2015

Goodbye 2015, Hello 2016! - Happy New Year.

00:00 Thursday, December 31, 2015 Posted by Unknown No comments:
, ,
It has been an amazing year for me. With 31 trips to 13 countries and a total of 110k miles traveled, I have seen a lot of places and spoken at many conferences and user groups. I had the pleasure to talk to many many people and learned a lot about technology and community. The main topics in my past year have been the Red Hat JBoss middleware integration technologies. Mixing those with my Java EE knowledge and also look into new topics like microservices made this a very fast paced year.

84 Blog Posts
Here are the top 5 posts on my blog this year. It's always interesting to see, what helps my readers the most. Thank you for all the visits and comments on the overall 84 blog posts (including this one) this year.

1) NoSQL with Hibernate OGM - Part one: Persisting your first Entities
2) JDBC Realm and Form Based Authentication with WildFly 8.2.0.Final, Primefaces 5.1 and MySQL 5
3) SSL with WildFly 8 and Undertow
4) My Book: Modern Java EE Design Patterns
5) Java EE, Docker, WildFly and Microservices on Docker

3381 Tweets
Social Media is a significant part of my daily life. Mostly because of the many inspirations and I think that it is a very quick and convenient way to catch up with latest happenings and developments. Beside tweeting from @myfear I also look after the @jbossdeveloper handle. And help run the @vjbug. Feel free to catch up with any of them and stay updated with latest happenings and rumblings in the Java/Java EE ecosystem.

One (mini) Book
I did it. Found some time to write a little more than just a blog post. And the feedback I got was pretty amazing. The Modern Java EE Design Pattern mini book can be downloaded for free from the developers.redhat.com website. Just register, benefit from all the free content available there and get a great overview about how DevOps, Microservices, Containers and PaaS influence the way we design and developer applications tomorrow. If you don't have time for the complete book, register and re-watch the accompanying O'Reilly webcast.

And The Best Wishes For The New Year
Beside the already mentioned events and happenings, a lot more was going on over the turn of the year. And I can't wait to start over in 2016. Le't all take some precious offline hours with friends, kids and loved ones and prepare for the new challenges. I am really looking forward to meet a lot of you next year. The first conferences have already been announced and you can follow my schedule on my blog page.

“We spend January 1st walking through our lives, room by room, drawing up a list of work to be done, cracks to be patched. Maybe this year, to balance the list, we ought to walk through the rooms of our lives...not looking for flaws, but for potential.”
― Ellen Goodman

Wednesday, December 23, 2015

Getting Started With The JBoss EAP 7 Quickstarts

16:48 Wednesday, December 23, 2015 Posted by Unknown No comments:
, , ,
Now, that the beta of latest Red Hat JBoss Enterprise Application Platform7 is out, it is about time to explore the available Java EE 7 quickstarts and deploy your first application with JBoss Developer Studio (JDBS).
The quickstarts demonstrate JBoss EAP, Java EE 7 and a few additional technologies. They provide small, specific, working examples that can be used as a reference for your own project.

To make it a quick start for you, I recorded a little 6 minute screencast about how to use JDBS to deploy the HelloWorld quickstart.

The quickstarts cover a lot more. So. make sure to check all of them and read the documentation before you start working with them.

Developers can download JBoss EAP 7 with a jboss.org account. They also need to accept the terms and conditions of the JBoss Developer Program which provides $0 subscriptions for development use only. Find out more about the JBoss Developer Program.

And while you're downloading, here are some more resources to get your started:

Tuesday, December 22, 2015

A Refresher - Top 10 Java EE 7 Backend Features

07:53 Tuesday, December 22, 2015 Posted by Unknown No comments:
,
This is the second part in my little Java EE 7 refresher series. After a first introduction with a brief overview, I decided to ask Arjan Tijms to write about his favorite new backend features in Java EE 7. You will know Arjan if you're following the Java EE space. He is a long time Java EE developer, JSF and Security EG member and he created OmniFaces together with Bauke Scholtz (aka BalusC) and helps building zeef.com.

1. App Provided Administrative Objects

Java EE has long had the concept of an “administrative object”. This is a kind of resource that is defined on the application server instead of by the application. For some classes of applications using these is a best practice, for others it’s not such a good practice.
Java EE 6 started a small revolution with the introduction of @DataSourceDefinition, which lets an application define its own data source. Java EE 7 expands on this with @MailSessionDefinition (JavaMail 1.5), @ConnectionFactoryDefinition & @AdministeredObjectDefinition (JCA 1.7) and @JMSConnectionFactoryDefinition & @JMSDestinationDefinition (JMS 2.0).
In practice, many applications already used the programmatic API of JavaMail to create mail sessions, and JCA usage is relatively rare. JMS is much more widely used though and lacked an (EE compatible) programmatic API to create destinations (queues and topics).
The importance of this seemingly small feature is that for the first time in the history of JMS it can be used in a fully standard way, without requiring  vendor specific xml files in the application archive or vendor specific configuration in the application server.
Note that none of these application provided resource definitions strongly tie the rest of the application code to these. That application code still only sees a JNDI name, and doesn’t depend on whether the resource is put in JNDI by a standard annotation, standard XML file, proprietary XML file or with proprietary config on the application server.

Further reading:
Automated provisioning of JMS resources in Java EE 7

2. Default resources

Closely related to app provided administrative objects, Java EE also introduced the notion of several default resources.
In the case of a default resource, the Java EE platform provides a ready to use resource of a specific type. Java EE 7 introduced defaults for a data source, the platform’s default JMS connection factory, and the default thread pool.
What characterizes these defaults is that they can’t be further configured in any standardized way. You have to do with whatever is provided by your server.
In the case of a data source, this means you get “something” to which you can send SQL, but there are no further guarantees with respect to performance or even durability (the data base the data source accesses could be fully memory based, although it practice it’s almost always a file in a server specific directory).

For the JMS connection factory, you get a connection to the default JMS provider of the server. Since JMS, unlike a SQL database, is a mandated part of Java EE you usually have a very good idea of what you get here. E.g. if the server in question is a production ready server, the default JMS provider is practically always a production ready one either.

Finally several actual resources such as a ManagedExecutorService gives you access to what is essentially the system’s default thread pool. Such thread pool can be used in much the same way as you would use the @Asynchronous annotation from Java EE 6. You don’t exactly know how many threads are in the pool or whether the ManagedExecutorService is backed by the same pool as @Asynchronous, but for simple ad-hoc multi-threaded work the defaults are typically good enough.

A particular nice aspect of the default resources is that in several situations you don’t even have to say that you want the default. The default data source that a JPA persistence unit for instance uses if you don’t specify any is well, the default data source.

Further reading:
Default DataSource in Java EE 7: Lesser XML and More Defaults 
Defaults in Java EE 7

3. App provided and portable authentication mechanisms

Next to the administrative objects mentioned above, another thing that traditionally had to be defined and configured on the application server side are authentication mechanisms and identity stores (both known by many alternative names).

The Servlet spec does define 4 standardised authentication mechanisms that an application can choose from via its web.xml deployment descriptor (FORM, BASIC, DIGEST, CLIENT-CERT), but did not standardise the actual classes or interfaces for these and subsequently didn’t standardise any API/SPI for custom authentication mechanisms. Furthermore, there’s nothing in the spec about the actual location where caller names/credentials/groups are stored.

Just like with @DataSourceDefinition, Java EE 6 started a small revolution by standardising an API/SPI for authentication mechanisms as well as a programmatic API to register these from within the application: JASPIC 1.0.

Unfortunately, the Java EE 6 version of JASPIC had a few critical omissions that made it hard to actually use those portable authentication mechanisms. The most important of those were addressed in Java EE 7.

Just as with the app provided administrative objects, an app provided authentication mechanism does not tie the rest of the application code to these and they can be transparently swapped out for container provided ones.

Further reading:
What's new in Java EE 7's authentication support?

4. CDI based @Transactional

Before Java EE 7, high level declarative transactions were the domain of EJB. In this model, EJB was intended as a universal facade for a lot of functionality that the platform offers. While EJB evolved from an arcane heavyweight spec in J2EE 1.4 to something that’s actually quite lightweight in Java EE 6, the model of one spec functioning as a facade was not seen as ideal anymore.

While Java EE 6 brought the biggest change with if of actually introducing CDI, Java EE 7 started another small revolution where other specs starting to depend on CDI instead. With this the model of one bean type being a facade started to change to the competing model of one bean type functioning as a base and other specs providing extensions on top of that.

Specifically setting this in motion was JTA 1.2 with the introduction of @Transactional and @TransactionScoped. These are based on an interceptor from the Interceptors spec and a scope from the CDI spec. Both are mainly applicable to CDI beans. The way that this turns the model around is that with EJB, JTA was invisibly used under the hood, while with CDI, JTA (somewhat less invisibly) uses CDI under the hood.

Further reading:
JTA 1.2 - It's not your Grandfather's Transactions anymore!
JTA 1.2 on Arjan's ZEEF page

5. Method validation

Perhaps one of the most versatile and cross layer spec in Java EE is the bean validation spec. Bean validation makes it possible to put validation constraints on various beans, such as CDI beans and JPA entities.

But, those validation constraints only worked at the field level and by extension of that on the class level (which effectively validates multiple fields).

In Java EE 7 the applicability of bean validation took a huge leap by the ability of placing such constraints on methods as well, aptly called method validation. More precisely, constraints can now be put on the input parameters of a method as well as on its return value, and the input constraints can be on individual parameters as well as on multiple parameters.

Whereas field level constraints are validated at a specific moment, e.g. when the JPA entity manager persists an entity or after a postback in JSF, method validation takes place every time a method is called by arbitrary code.In Java EE this works when the method is in a (proxied) CDI managed bean, and the method is indeed accessed via the proxy.

Further reading:
Bean Validation 1.1 Feature Spotlight - Method validation
Bean Validation 1.1 on Arjan's ZEEF page

6. Expression language can be used everywhere

Expression language is a mini script language that’s used within Java EE. It has a long history, from being specifically to JSTL, to being natively incorporated in JSP, natively incorporated in JSF and later on unified between JSP and JSF.

In Java EE 7 this expression language took its biggest leap ever and became a totally independent spec that’s fully usually outside JSP and JSF, and even outside Java EE.

This means that expression language can be used in things like annotations, email templates, configuration files and much more. Just as with the introduction of CDI in Java EE 6, the introduction of a separately usable expression language has the potential to be used by many other specs in the future.

Further reading:
Standard Deviation: An Illustration of Expression Language 3.0 in Servlet Environment
EL 3.0 on Arjan's ZEEF page

7. Greatly simplified JMS API

One of the older specs in Java EE is JMS, which is about (asynchronous) messaging. JMS is also one of the specs that hadn’t been updated for a very long time (not since 2002!), and although still surprisingly usable its age did begin to show a little.

With JMS 2.0 Java EE 7 brought one of the biggest changes to JMS ever; a thoroughly and greatly simplified API. Part of these simplifications piggy back on the default resources mentioned above, but it also takes advantage of Java SE 7’s auto closeable feature and many smart defaults to minimize the amount of objects a user has to manage and juggle with for simple things like sending a message.

Further reading:
What's New in JMS 2.0, Part One: Ease of Use
JMS 2.0 on Arjan's ZEEF page

8. Entity graphs in JPA

Arguably one of the most important specs next to CDI in Java EE is JPA. Whether a Java EE application is a JSF based MVC one, or a JAX-RS based web-service, they pretty much always have some persistence requirements.

One of the difficulties in persistence is determining what is just the right amount of data to be fetched. This should obviously not be too little, but also not be too much since that typically comes with great performance implications.

An important tuning parameter of JPA has always been the eager and lazy loading of specifically relations. This choice is primarily structurally and hard coded on the entities itself. The problem with this is that in different situations the same entity may be required with more or less data. E.g. in an overview of all users you may only want to display the user name, while in a detail view also the address and other contact details.

Before Java EE 7 this could be done without fetching too little or too much data for each case by means of writing separate queries. While this solves the problem it’s not optimal, especially not when it concerns large queries and the only difference is how much associated data is fetched for some entity.

With JPA 2.1, Java EE 7 introduced the concept of entity graphs for this. Via a (named) graph, it’s now possible to determine exactly what data needs to be fetched in a graph style notion. These graphs are defined separately and can be associated at runtime with many different queries.

Further reading
JPA 2.1 Entity Graph – Part 1: Named entity graphs
JPA 2.1 on Arjan's ZEEF page

9. Access to managed thread pools

Briefly mention above when the default resources were discussed is that in Java EE 7 access is provided to the default thread pool.

The support actually goes a bit further than just that and Java EE 7 introduced an entire specification behind this; the concurrency utils for Java EE spec. With this spec you can not just get that default thread pool, but also obtain and work with separate thread pools. This is important for QoS use cases, and specifically to prevent a number of dead locking cases if work that depends on each other is scheduled to the same pool.

Unfortunately the practical usability of these additional pools is somewhat limited by that fact that it’s not possible to actually define those pools in a standard way. This somewhat contradicts the “App provided administrative objects” item in the beginning of this overview.

Despite that issue, for somewhat lower level asynchronous and parallel programming this spec opens up a world of options.

10. Etc; CDI tuning, Interceptors spec, Batching

In Java EE 7 the Interceptors spec was split off from CDI paving the road for CDI to focus more on being the core bean model of Java EE, while simultaneously making interceptors more generally reusable throughout the platform.

CDI itself didn’t get a major overhaul or a really major new feature, but instead got an assortment of smaller but very welcome features such as a (much) easier way to programmatically obtain bean instances, and events that fire when scopes are activated and de-activated.

Automatic enablement of CDI (CDI activated without needing a beans.xml) should have been a major feature, but appeared to be of rather limited use in practice. Without a beans.xml file only beans with so-called “bean defining annotations” are scanned, and especially for beginning users this is not always clear.

Java EE traditionally deals mostly with requests and responses that are generally rather short running. There’s a timer service available for background jobs, but that’s a relatively basic facility. There’s hardly any notion of job management, check-pointing or restarting.

In Java EE a brand new spec was introduced that specifically addresses these concerns; the Batch Applications for Java Platform 1.0 spec. This resolves around XML files in which jobs are specified, which themselves contains so-called steps that perform the actual sequential application logic.

Further reading
CDI 1.1
Interceptors 1.2
Batch 1.0

Thank you Arjan for taking the time to compile all of this. The next post is going to cover the top 10 features of the fronted technologies and will also feature a prominent guest blogger. Until then, there is plenty of time to play around with Java EE 7. Here are some resources to get you started with JBoss EAP 7 and WildFly:

Monday, December 21, 2015

Red Hat JBoss Enterprise Application Platform 7 Beta Released!

08:30 Monday, December 21, 2015 Posted by Unknown No comments:
, ,
Red Hat JBoss Enterprise Application Platform 7 Logo
A little over a month after we made the alpha version available, the Red Hat JBoss Enterprise Application Platform 7 Beta - Early Access was released last Friday.

For a complete list of new features, refer to my older blog-post and the official release-notes.
JBoss EAP 7  is a significant release in every respect; the last major EAP release (EAP 6.0) was back in June, 2012 and after 4 minor feature releases and numerous patch releases, EAP 6 is now just 8 months away from entering its long-term maintenance phase. While EAP 6 will be fully supported for many years to come – all new development and new features will target EAP 7 and beyond.

Developers can download JBoss EAP7 with a jboss.org account. They also need to accept the terms and conditions of the JBoss Developer Program which provides $0 subscriptions for development use only. Find out more about the JBoss Developer Program.

There are some known issues in this release, if you find others, please make sure to file an issue in the JBoss EAP Jira tracker.

And while you're downloading, here are some more resources to get your started:


Friday, December 18, 2015

Java EE Microservices Architecture - O'Reilly Webcast

08:09 Friday, December 18, 2015 Posted by Unknown No comments:
, , ,
Just a few days ago I had the chance to give a webcast with O'Reilly. This webcast is now available on demand and you can watch it for free after registration.

Java EE Architectures - Evolving the Monolith
Evolving monolithic Java EE applications
With the ascent of DevOps, microservices, containers, and cloud-based development platforms, the gap between state-of-the-art solutions and the technology that enterprises typically support has greatly increased. But some enterprises are now looking to bridge that gap by building microservices-based architectures on top of Java EE.

In this webcast, Red Hat Developer Advocate Markus Eisele explores the possibilities for enterprises that want to move ahead with this architecture. However, the issue is complex: Java EE wasn't built with the distributed application approach in mind, but rather as one monolithic server runtime or cluster hosting many different applications. If you're part of an enterprise development team investigating the use of microservices with Java EE, this webcast will guide you to answers for getting started.


Don't forget to download my free eBook about Modern Java EE Design Patterns - 
Building Scalable Architecture for Sustainable Enterprise Development.

Thursday, December 3, 2015

A Java EE 7 Application on OpenShift 3 With JBoss Tools

14:22 Thursday, December 3, 2015 Posted by Unknown No comments:
, , ,
You can create and manage OpenShift applications in Eclipse with the latest version of the OpenShift Plugin for JBoss Tools. They are either pre-bundled with the latest JBoss Developer Studio (9.0.0.GA) or you can install them into an existing Eclipse Mars. This post walks you through deploying the Java EE 7 Hands-On-Lab in OpenShift with the JBoss Developer Studio.

OpenShift 3 Tooling Overview
The OpenShift 3 tooling is included as a TechPreview. It will allow you to connect to OpenShift 3 servers using OAuth or Basic authentication, manage your OpenShit 3 Projects, deploy new applications in the Cloud, using pre-defined (or your own) templates, or even Docker images. You will be able to import existing applications in your workspace, monitor them via remote log streaming directly into your local console, or enable Port-Forwarding and access their data as if it was local.

Get Started
Install the OpenShift 3 all-in-one VM and start your local instance with vagrant. Login via the oc command-line tool with admin/admin and get your OAuth token:
oc login https://localhost:8334
oc whoami -t
And while we're at the command line, let's create a new OpenShift project for this example.
oc new-project javaeehol --display-name="Java EE 7 HOL w/ WildFly MySql"

Install and fire up your JBoss Developer Studio. If you want to get started with the JBoss Tools in an existing Eclipse distribution use this package from the Eclipse marketplace.

Create a new OpenShift Project. Select OpenShift 3 as server type, change the server to https://localhost:8443 and enter the token you gathered from the cli into the token field. When you click next, the credentials are verified and you need to accept a warning about an unsigned certificate when using the all-in-one vm.

Select the project from the first drop down list in the next dialogue. The dialogue also lists all available templates on your server.A complete list can befound on github. We want to use our own template in this case. The Java EE 7 Hands-On-Lab has been converted into a Kubernetes template by Ben Pares. So, we're going to use this. Download it from Ben's Github repository and save it locally.
Open it with a text editor and change the "apiVersion" value from v1beta3 to "v1". And in line 47 is a host entry which says: "www.example.com", change that to "jee-sample.openshiftdev.local". And while you are in a text-editor make sure to add an entry to your hosts file which maps the loopback interface to the changed domain name.
127.0.0.1 jee-sample.openshiftdev.local
Now back to JBDS.
Select "Use a template from my local file system" and browse to the place you saved it.
After clicking next you see another dialogue which allows you to change the template parameter values for the various passwords. Leave everything as it is and click "next" again.
The following dialogue will let you add additional labels. Just click "Finish" now.
The final dialogue gives you an overview about the executed actions and generated passwords. Make sure to write them down in case you need them later.

You can also access the github web-hook secrets and URLs. After clicking "ok" a last wizard clones the application from github into a folder of your choice locally. It get's opened in JBDS and you can browser through the various resources and explore the example a bit. While you're doing that, OpenShift actually triggered a build of the sample application. When you point your browser to the web-console at http://localhost:8443/ and login with admin/admin and select the javaee project, you can see the mysql service running and a build job:


After a couple of minutes, this one finishes and you see the running frontend-service. Let's briefly look into the build logs:
oc get builds #Shows the one successful build
oc build-logs  jee-sample-build-1  #Shows the log output for the build
Everything looks good. You can see, that the maven dependencies are downloaded and looking at the various image streams with:
oc get is
you can see, that there are two:
NAME         DOCKER REPO                                TAGS      UPDATED
jee-sample   172.30.236.154:5000/javaeehol/jee-sample
wildfly      openshift/wildfly-90-centos7               latest    57 seconds ago
OpenShift actually build a new docker image with the javaee-hol in it and deploys the result as a new pod. Time to see everything in action. Point your browser to http://jee-sample.openshiftdev.local:1080/movieplex7-1.0-SNAPSHOT/ and see the Movieplex application in action.


Are you wondering about the weird port? 1080 is actually a specialty of the OpenShift all-in-one-VM. Because, we assume that you already have a service running on port 80 and because of that, the NAT mapping in VirtualBox assigns port 1080 to port 80 on the OpenShift master. Unfortunately this makes some things in the OpenShift Eclipse tooling a little unhandy. But, it's a local installation and has this one drawback. Let's explore the tooling features a little bit more

OpenShift Explorer View - The embedded Web Console.
The OpenShift Explorer View lets you connect to OpenShift 3 instances, create new applications, manage domains or projects, execute action such as Port-Forwarding and Tail Files (Log Streaming). Specific actions are available, depending on the version of the OpenShift instance you’re connected to. For OpenShift 2 connections, you can configure cartridges, for OpenShift 3, you can access Pods, Routes, Services and deploy Docker images. Just expand the tree and right click on the resource you're interested in. For example, like in the following screenshot to access the frontend logs.



You can find even more details about the Docker Tooling and other features in the detailed feature description.

Learn Even More
Learn more about OpenShift Origin and how to get started with the All-In-One-VM. Take the Java EE 7 Hands-On-Lab and follow the individual steps to get a refresher in Java EE 7. Follow @OpenShift on Twitter and stay up to date with latest news. Feel free to reach out to me in the comments or via Twitter @myfear.

Tuesday, December 1, 2015

Microservices, DevOps and PaaS - The Impact on Modern Java EE Architecture

11:00 Tuesday, December 1, 2015 Posted by Unknown No comments:
Just a short information about an interview I did with Daniel Bryiant at Devoxx Belgium. We set together and talked about the recent microservices hype and how enterprises will be able to adopt it. This interview touches some basics from my recent O'Reilly mini-book and explores the organizational changes a little more.

InfoQ Article Screenshot


If you have a minute, read it and let me know what you think. A big thank you to Daniel for hosting this interview.

And you can download my free book from developers.redhat.com.

Monday, November 30, 2015

A Refresher - Java EE 7 At A Glance

10:34 Monday, November 30, 2015 Posted by Unknown No comments:
,
As the Red Hat JBoss Enterprise Application Platform 7 (EAP 7) is looming on the horizon and even the WebLogic server just recently got Java EE 7 certified, I thought it might be about time to give you a little refresher about the Java Enterprise Edition 7 features and point you towards further resources.

Java EE 7 - Developer Productivity, HTML 5 and Enterprise Demands
The Java Enterprise Edition 7 offers new features for enhanced HTML5 support,
helps developers being more productive and further helps meeting enterprise demands. As a developer you will write a lot less boilerplate code and have better support for the latest Web applications and frameworks.

Main Topics Of Java EE 7


There are a couple of new features in Java EE 7 and Arun compiled a list of the top ten most prominent ones a while ago already and you can see the complete slide-deck as part of the Java EE 7 samples project on GitHub. This is a quick recap of them:

Java API for WebSocket 1.0 (JSR 356)
There is first class support for creating and deploying WebSocket endpoints. There is a standard W3C JavaScript API that can be used from browsers but this API also introduces a client endpoint.
The reference implementation is Tyrus.

Batch Applications for the Java Platform (JSR 352)
In-built support for Batch applications allows to remove dependency on third-party frameworks. Also see the Batch Applications tutorial on WildFly for further information.

JSON Processing (JSR 353)
Native support for JSON processing allows to make the application light-weight and getting rid of third party libraries.

Concurrency Utilities for Java EE (JSR 236)
Concurrency Utilities extends JSR standard Java SE Concurrency Utilities and add asynchronous capabilities to Java EE application components.

Simplified JMS API (JSR 368)
JMS API has been extremely simplified by leveraging CDI, Autocloseable, and other features of the language.

@Transactional and @TransactionScoped (JSR 907)
Deliver transactional applications with choice and flexibility, use @Transactional to enable transactions on any POJO.

JAX-RS Client API (JSR 339)
JAX-RS added a new Client API to invoke a REST endpoint using a fluent builder API.

Default Resources (JSR 342)
Default resources like JDBC DataSource, JMS ConnectionFactory, etc are added to simplify OOTB experience.

More annotated POJOs
More annotations have been added to simplify devops experience such as @JMSDestinationDefinition that automatically creates a JMS destination.

Faces Flow (JSR 344)
JSF added Faces Flow that allows to create reusable modules to capture a flow of pages together.

Pruned Technologies
While many new features have been added in Java EE 7, others have been made optional. Those are: Java EE Management (JSR-77); Application Deployment (JSR-88); JAXR, for interfacing with UDDI registries (JSR-93); JAX-RPC, for XML-based RPC (JSR-101); and EJB 2.x Container Managed Persistence, which is effectively replaced by the Java Persistence API (JSR-338). These specifications, while removed from the current release, remain optional for vendors in the event that demand for them persists among customers. They will, however, be removed in Java EE 8.

Further Reading
Java EE 7 API Documentation
Oracle Java EE SDK
Java EE 7 Tutorial
Java EE 7 Samples On Github
Application Server Migration: Java EE 5 to JBoss Wildfly Java EE7
Getting Started With EAP 7 Alpha and Java EE 7
Java EE 7 Essentials by Arun Gupta
Beginning Java EE 7 by Antonio Goncalves
Java EE Bootstrap Course by JBoss Champion Adam Bien
Arjan Tijm's ZEEF Page about Java EE 7

Thursday, November 19, 2015

HTTP/2 With JBoss EAP 7 - Tech Preview

12:42 Thursday, November 19, 2015 Posted by Unknown No comments:
, ,
Just a couple of days ago, the new JBoss EAP 7 ALPHA version was released.  And I already blogged about how to get started with it. One very interesting part is the HTTP/2 support which has been added as a technical preview. It is provided by the new webserver Untertow.  HTTP/2 reduces latency by compressing headers and multiplexing many streams over the same TCP connection. It also supports the ability for a server to push resources to the client before it has requested them, leading to faster page loads.

Tech Preview Components
A short remark about what technology preview actually means. Some features in JBoss EAP are provided as technology preview. This means that while these components have been included in JBoss EAP but they're not considered functionally complete and are not suitable for production use. So they're supported in development  but not recommended or supported for production use. But they help us to get wider exposure and feedback. So, if you encourage something that does not work as expected or have ideas about the future direction of this feature, feel free to reach out to us.
Red Hat intends to fully support technology preview features in a future release.

Prepare Your EAP Installation
The Application Layer Protocol Negotiation (ALPN) is an extension for the SSL protocol that helps to make HTTPS connections faster. It was defined together with HTTP/2 and this uses ALPN to create HTTPS connections. As most browsers implement HTTP/2 only over HTTPS, The OpenJDK implements SSL in the sun.security.ssl package. The current implementations in Java 7 and Java 8 do not support ALPN. With Java 9,there will (hopefully) be native support for ALPN (JEP 244). EAP requires you to use Java 8. You can't run the HTTP/2 example on Java 7 at all, because of missing cyphers.
Since HTTP/2 is also a goal for Java EE8, it is also expected to be made available in a future Java SE 8 update, likely after Java 9 is released.

To get around this limitation today on Java 8 we need to add a library that provides ALPN support to the JVM’s boot class path. The version of the jar file that you need is tied to the JVM version in use, so you must make sure you are using the correct version for you JVM. Jetty provides a ALPN implementation for java. Go to the jetty website and find the correct version for your JDK. In this example, I'm using JDK 1.8.0u60 which needs ALPN version: "8.1.5.v20150921".
Switch working folder to your JBOSS_HOME and download the alpn library to the /bin folder.
curl http://central.maven.org/maven2/org/mortbay/jetty/alpn/alpn-boot/8.1.5.v20150921/alpn-boot-8.1.5.v20150921.jar >bin/alpn-boot-8.1.5.v20150921.jar
The library now needs to be added to the server's bootclasspath. Add the following lines to the standalone configuration files
//standalone.conf on Linux
JAVA_OPTS="$JAVA_OPTS  -Xbootclasspath/p:$JBOSS_HOME/bin/alpn-boot-8.1.5.v20150921.jar"

//standalone.conf.bat on Windows
set "JAVA_OPTS=%JAVA_OPTS% -Xbootclasspath/p:%JBOSS_HOME%/bin/alpn-boot-8.1.5.v20150921.jar"

The next step is to install certificates for the https connector. For testing purposes you can download the ones from the Undertow test suite. Learn how to generate and run your own SSL certificates in an older blog-post of mine.
curl https://raw.githubusercontent.com/undertow-io/undertow/master/core/src/test/resources/server.keystore >standalone/configuration/server.keystore
curl https://raw.githubusercontent.com/undertow-io/undertow/master/core/src/test/resources/server.truststore >standalone/configuration/server.truststore

When you're done with that, start the server and add a https connector via the command-line tool (connect to your running server and issue the commands highlighted in the following):
$>jboss-cli.bat|sh

You are disconnected at the moment. Type 'connect' to connect to the server or 'help' for the list of supported commands.

[disconnected /] connect

[standalone@localhost:9990 /] /core-service=management/security-realm=https:add()

{"outcome" => "success"}

[standalone@localhost:9990 /]  /core-service=management/security-realm=https/authentication=truststore:add(keystore-path=server.truststore, keystore-password=password, keystore-relative-to=jboss.server.config.dir)

{
    "outcome" => "success",
    "response-headers" => {
        "operation-requires-reload" => true,
        "process-state" => "reload-required"
    }
}

[standalone@localhost:9990 /] /core-service=management/security-realm=https/server-identity=ssl:add(keystore-path=server.keystore, keystore-password=password, keystore-relative-to=jboss.server.config.dir)

{
    "outcome" => "success",
    "response-headers" => {
        "operation-requires-reload" => true,
        "process-state" => "reload-required"
    }
}

[standalone@localhost:9990 /] /subsystem=undertow/server=default-server/https-listener=https:add(socket-binding=https, security-realm=https, enable-http2=true)

{
    "outcome" => "success",
    "response-headers" => {"process-state" => "reload-required"}
}
[standalone@localhost:9990 /]
Shutdown and re-start your EAP instance.

Testing The Connection
When the server is up again, point your browser to https://localhost:8443. After clicking through the security warning about the self signed certificate you see the normal EAP 7 welcome page.
But how do you find out, that the connection is actually using HTTP/2? You can do this in various ways. If you're using Chrome, you can enter "chrome://net-internals" in the browser bar and select "HTTP/2" in the dropdown. If you re-load the EAP homepage and come back to the network page in chrome, you can see the HTTP/2 session with all headers and information.

Network Connection Properties in Chrome


Another option is to use a little JavaScript and deploy it in your application:

<p style="font-size: 125%;">You are currently connected using the protocol: <b style='color: darkred;' id="transport">checking...</b>.</p>
<p id="summary" />
<script>
    var url = "/";
    var xhr = new XMLHttpRequest();

    xhr.onreadystatechange = function(e) {
        if (this.readyState === 4) {
            var transport = this.status == 200 ? xhr.getResponseHeader("X-Undertow-Transport") : null;
            transport = transport == null ? "unknown" : transport;
            document.getElementById("transport").innerHTML = transport;
            var summary = "No HTTP/2 Support!";
            if (transport.indexOf("h2") == 0) {
                summary = "Congratulations! Your client is using HTTP/2.";
            }
            document.getElementById("summary").innerHTML = summary;
        }

    }
    xhr.open('HEAD', url, true);
    xhr.send();
</script>
Congratulations! You just upgraded your EAP installation to HTTP/2! Don't forget to give feedback and learn more about JBoss EAP 7: And please keep in mind:  just like with any Alpha release, please anticipate issues. If you find any please report them in the corresponding JIRA.

Tuesday, November 17, 2015

Getting Started With EAP 7 Alpha and Java EE 7

16:34 Tuesday, November 17, 2015 Posted by Unknown No comments:
, ,
Red Hat JBoss Enterprise Application Platform 7 (JBoss EAP 7) is a middleware platform built on open standards and compliant with the Java Enterprise Edition 7 specification. Built on top of innovative and proven open source technologies like WildFly, it will make Java EE 7 development a lot easier. Here is a quick guide on how to get started with the latest ALPHA release.

Prerequisites and Preface
JBoss EAP 7 provides two operating modes for JBoss EAP 7 instances: standalone server or managed domain. The standalone server operating mode represents running JBoss EAP as a single server instance. The managed domain operating mode allows for the management of multiple JBoss EAP instances from a single control point. The available version as of today is EAP 7 ALPHA. Just like with any Alpha release, please anticipate issues. If you find issues, feel free to file them in the corresponding JIRA. You need to have a supported JDK installed. EAP 7 requires Java SE 8.
You can test-drive EAP 7 under the Red Hat JBoss Developer Program. All you need to do is to register with jboss.org right after you click download on the EAP product page.

Download And Install JBoss EAP 7
Open a web browser and navigate to http://www.jboss.org/products/eap/. Click the green "download" button on the upper right of the page. If you have not yet done so, you will be prompted to review and accept the terms of the Red Hat JBoss Developer Program. Alternatively, just log-in and wait for the download to begin. Attention: This will download the 6.4.0-installer. We just want to download a ZIP file of the ALPHA release! You need to follow the link to all downloads and select the 7.0.0.Alpha ZIP Download (172mb). When finished, unzip into a folder of your choice. We call this folder "EAP_HOME" from now on. The installation is finished.

Startup And Basic Administration
Start the server in standalone mode via the following command:
$ EAP_HOME/bin/standalone.bat|.sh
If successful, you will see the following last lines of the output:
09:46:50,789 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: EAP 7.0.0.Alpha1 (WildFly Core 2.0.0.CR8) started in 15482ms - Started 259 of 489 services (314 services are lazy, passive or on-demand)
You must create a management user in order to access the web-based management console and remote instances of the management CLI. Execute the script:
$ EAP_HOME/bin/add-user.bat|.sh
and fill in the required information. Make sure to select the option "a) Management User" when offered. I am using the highly unsecure combination of admin/admin as username/password. If you added the user, you can check in your browser if the server is up and running. Redirect your browser to http://localhost:9990/ and login with the admin-user. You will be presented with the revamped admin-console.

New EAP 7 Admin Console

Now it is time to setup your development environment and get you started with a first Java EE 7 application.

Setup The Development Environment
The natural choice for EAP 7 based applications is the JBoss Developer Studio (JBDS). Download the latest version 9.0 from the jboss.org product pages and install as described there. Start it after installation and go to the "servers tab" to add a new EAP 7 server.


Expand Red Hat JBoss Middleware and choose JBoss Enterprise Application Platform 7.0 (Experimental). Enter a server name, for example, "JBoss EAP 7.0", then click Next to create the JBoss runtime and define the server. The next time you define a new server, this dialog displays a Server runtime environment selection with the new runtime definition. Create a Server Adapter to manage starting and stopping the server. Keep the defaults and click Next. Enter a name, for example "JBoss EAP 7.0 Runtime". Under Home Directory, click Browse and navigate to your JBoss EAP install location. Then click Next.

Create Your First Java EE 7 Application
Now all the bits and pieces are in place and you can start to create your first Java EE 7 application. Right click into the project explorer in JBDS and select "new", select "other", scroll down to Maven and select "New Maven Project". Accept the standards in the next dialogue and type "javaee7" into the filter text.box. Select the "com.airhacks.javaee7-essentials-archetype" and click next.


Enter a group- and artifact-id and click "finish". Maven is downloading the archetype and instantiating a project from that template. Expand the project and navigate to the source package com.airhacks and right click. Select "new", "other", "WebServices" and select "JAX-RS Resource". Enter source folder and package and name the resource "HelloResource". Click "Finish". Open the newly created class and change it to this:

package net.eisele;

import javax.enterprise.context.RequestScoped;
import javax.ws.rs.GET;
import javax.ws.rs.Path;
import javax.ws.rs.Produces;

@RequestScoped
@Path("")
public class HelloService {

 @Produces("application/json")
 @GET
 public String sayHello(){
  return "{\"name\" : \"Hello\"}";
 }
}

Last step is to actually deploy and run the application on EAP 7. Right click the project and select "Run As..." and "Run On Server" and select the existing EAP 7 server. You can see, that our demo project is configured in the next dialogue. Click "Finish" and switch to the "Console" view to see the server starting. And as you can see, the demo.war file is also deployed. When you now visit http://localhost:8080/demo/resources with your browser, you see the json output:

{"name" : "Hello"}

Congratulations! That has been your first Java EE 7 example on JBoss EAP 7 ALPHA. Now you might want to check out the quickstarts or the documentation:

Sunday, November 15, 2015

Red Hat JBoss Enterprise Application Platform 7.0 ALPHA released!

16:30 Sunday, November 15, 2015 Posted by Unknown No comments:
, , ,
Red Hat JBoss Enterprise Application Platform 7 (JBoss EAP 7) is a middleware platform built on open standards and compliant with the Java Enterprise Edition 7 specification. It integrates WildFly Application Server 10 with high-availability clustering, messaging, distributed caching, and other technologies. The latest JBoss EAP 7.0 Alpha release is now available to download!

JBoss EAP 7.0 Alpha is the product of years of hard work by WildFly 8, 9, 10 community and EAP Engineering teams. Congratulations!

Summary of new features in this release
With JBoss EAP 7, everyone gets what they need to become more productive and efficient.  Whether you are a newbie developer, a veteran Java EE expert, or a staff member on an operations, testing, or administration team, JBoss EAP 7 gives you that extra edge needed to build, deploy, and maintain robust, web-scale, high-impact applications at DevOps speeds.

Java EE 7 Support
JBoss EAP 7.0 implements the Java EE 7 Full Platform and Web Profile standards.
Batch 1.0, JSON-P 1.0, Concurrency 1.0, WebSockets 1.1, JMS 2.0, JPA 2.1, JCA 1.7, JAX-RS 2.0, JAX-WS 2.2, Servlet 3.1, JSF 2.2, JSP 2.3, EL 3.0, CDI 1.1, CDI Extensions, JTA 1.2, Interceptors 1.2, Common Annotations 1.1, Managed Beans 1.0, EJB 3.2, Bean Validation 1.1

Java SE 8
JBoss EAP 7.0 requires Java SE 8 and EAP 7.0 Alpha has been tested with Open JDK 8, Oracle JDK 8 so far.

Highly Scalable Web Server (Undertow)
We have switched the web server and servlet implementation from JBoss Web to Undertow. Undertow is a modern NIO web server that is designed for maximum throughput and scalability. It supports non-blocking and blocking handlers, traditional and asynchronous servlets, and JSR-356 web socket handlers.

Port Reduction
By utilizing HTTP upgrade, EAP 7 has moved nearly all of its protocols to be multiplexed over two ports: a management port (HTTP/JSON Management, HTTP Upgraded Remoting - Native Management & JMX, Web Administration Console), and an application port (HTTP Servlet, JAX-RS, JAX-WS, Web Sockets, HTTP Upgraded Remoting-EJB Invocation-Remote JNDI)

Messaging Consolidation and Backwards Compatibility with EAP 6
EAP 6’s HornetQ codebase was donated to the Apache ActiveMQ project, and the HornetQ community joined to build a next-generation messaging broker. This was materialized in the first major release of the ActiveMQ Artemis project. ActiveMQ Artemis includes many new features, and also retains protocol compatibility with the HornetQ broker. EAP 7 includes this new exciting project as its JMS broker, and due to the protocol compatibility, it fully replaces the HornetQ project.

Offline CLI
In both standalone and domain modes you can now manage the server using CLI commands, without having a running server. This works similar to the admin-only mode, but does not require launching the server, and using a TCP port. Instead the CLI embeds the server and launches it directly in admin-only mode.

IIOP Implementation
We have switched our IIOP implementation from JacORB to a downstream branch of the OpenJDK ORB. This change should lead to better interoperability with the JVM ORB and the Java EE RI

Server Suspend Mode / Graceful Shutdown
The new server suspend mode in EAP 7, once activated rejects new requests but allows old ones to complete. Once the suspension process has completed the server can either be stopped without aborting in-flight transactions, left in suspended state while maintenance is performed, or returned back to running state where new requests are once again allowed. (Excluding JMS and Transactions, Including Web, EJB, EE Concurrency, mod_cluster, Naming)

Built-in Front End Load Balancer (Tech. Preview)
EAP 7 (using Undertow) can now be configured to function as a multi-platform intelligent load balancer, proxying requests to backend EAP 7 nodes using HTTP and AJP/mod_cluster protocols.

Clustering
New optimized session replication and Single Sign On implementation using Undertow. New/optimized @Stateful EJB caching implementation. HA Singleton Deployments (for failover usecase same as EAP 5 e.g. EJB deployments enabled in one node in cluster) and Singleton MDBs (Technical Preview).

JCA & DataSources
EAP 7 supports a DistributedWorkManager implementation based on the JGroups project, and the JCA connection manager has been enhanced with the lazy connection manager extensions. The data sources and resource adapters subsystems allow setting capacity policies and additional flush strategies as well.

Migration CLI Operations for the discontinued subsystems of EAP 6 Series
To help users migrating from old subsystems in EAP 6 such as jbossweb, jacorb, and hornetq, we have introduced a set of management operations that can convert old configuration over to the new respective subsystem equivalent. Since these operations migrate the underlying management resource model, old CLI scripts or custom provisioning systems can also take advantage of these.

HTTP/2 Server Push (Technical Preview)
Undertow, the web server in WildFly, has added support for the new HTTP/2 standard. HTTP/2 reduces latency by compressing headers and multiplexing many streams over the same TCP connection. It also supports the ability for a server to push resources to the client before it has requested them, leading to faster page loads. Tech. Preview support is provided via a tested 3rd party alpn.jar for http(S) until JDK 9 is released/supported.

Modern Enterprise Web Applications with Server Side JavaScript on JVM (Technical Preview)
EAP 7 now allows you to write server side JavaScripts (using JDK 8 Nashorn capabilities) to quickly develop REST endpoints which can pull in CDI beans, perform JNDI lookups and and invoke JPA Entity Beans.  This capability is provided by Undertow project

Pruning
The following technologies that are no longer required in Java EE 7 were removed:
  • CMP - JPA offers much more performant and flexible API. 
  • JAX-RPC - JAX-WS offers a much more accurate and complete solution.
  • JSR-88 - Very little adoption. 

Learn More About EAP 7 With The Following Resources
And please keep in mind:  just like with any Alpha release, please anticipate issues. If you find issues, feel free to file them in the corresponding JIRA.

Monday, November 9, 2015

More Java EE from Red Hat Engineers at Devoxx

10:12 Monday, November 9, 2015 Posted by Unknown No comments:
, ,
Red Hat At Devoxx - Game Changing DevOps
It is Devoxx Belgium time! Finally. Everything kicks off today with the University Sessions and the conference itself starts tomorrow morning. We're all pretty excited, as this is the major event in Europe. And Red Hat is proud to be a sponsor again this year. We will be onsite with 14 sessions, a booth - with beer, books and more. Visit the Red Hat booth to see OpenShift by Red Hat in action, join the new Red Hat Developers program, get your complimentary copy of my new book - Modern JavaEE Design Patterns (while supplies last), and learn how you can get involved with Red Hat. Did I mention we will have free beer on Tuesday, Wednesday and Thursday at 17:00?
Meet our engineers and talk to us about our products or community projects.

Java EE With Red Hat At Devoxx
One thing I want to highlight in particular are the Java EE sessions and activities by our engineers. We will have five sessions about Java EE and OpenShift (including Docker and Kubernetes) and I highly encourage you to also look at all the other Java EE related activities which have been posted on the Aquarium Blog.

Monday at 17:25 - 17:55 - Room 4
Roland Huß (@ro14nd) will be talking about "Fabric8 - Java developer tools for Kubernetes and OpenShift". This talk gives you an overview about the various components and introduces you to the contained tools which will make your life as a Java developer a lot easier.

Monday at 18:05 - 18:35 - Room 5
Xavier Coulon (@xcoulon) talks about "Docker Tooling for Java EE Developers". In this talk you will get a quick introduction on how to use Docker effectively, especially for Java EE development.

Wednesday at 21:00 - 22:00 - Room BOF1
Dimitris Andreadis (@dandreadis ) will lead the "WildFly Community BOF and V10 update" which is the place to be, where the developer community meets to discuss (over beer!) the present and future of the WildFly Application Server Project (formerly known as the JBoss Application Server) with members of the WildFly Core Development Team.

Thursday at 14:00 – 15:00 - Room 8
Antoine Sabot-Duran (@antoine_sd) talks about "CDI 2.0" The work on JSR 365 (Context and Dependency Injection for Java) started one year ago. Expert group already added interesting features like asynchronous events or Java SE bootstrap. Thanks to early draft and alpha version of CDI 2.0 implementation we can already experiment the future CDI 2.0. In this talk we will show the top new features in CDI 2.0 thru code examples (when possible) and presents expert group serious leads for the end of this first totally open source Java EE specification.

Thursday at 13:25 - 13:30 - Room BOF 1
Jorge Morales Pou is one of the OpenShift evangelists and gives an ignite talk titled "Please Fail".

Wednesday at 12:00 - 13:00 - Room 4
And last but not least, there is another interesting talk about Open Source and how to contribute. Charles Nutter (@headius) will give you a great overview about how to get started and learn about the inner workings of real OSS projects, and learn how to be a better OSS user and producer.

Theft-Proof Java EE - Securing Your Java EE Enterprise Applications

07:27 Monday, November 9, 2015 Posted by Unknown No comments:
,
An overview about the holistic approach to application security
Øredev is just a couple of days away, and I was invited to give two presentations. One of them is about my favorite topic: Security and Java EE. It is designed to fulfill two goals. On the one side to introduce the typical Java EE developer to the overall application security process and main objectives. But also to look at the details about what Java EE has to offer when it comes to typical requirements. Those are two different things and the first has been addressed before in my presentation about "Developer Security Awareness". This talk is meant to do a match between today's security requirements and the features available in the platform as of the Java EE 7 release.

Securing Applications Isn't Just About Secure Code
All the common attacks we've known about for a very long time are still out there, and people still regularly make mistakes regarding them. If you want to write secure Java EE code and use the technology securely, you're on the right track. But there is a lot more to learn and know about securing your applications. There are also people and processes and how they best work together to build a suitable secure system. Derived from practice for use with everyday development such a system can make the Java EE space a little more secure.


Application Security Needs A Holistic Approach
To build a secure Java EE application, a holistic approach to application security is required and security must be applied at all layers and services. Even if everything else beside our own applications typically does not bother developers at all it becomes more important. Last but not least with the advent of DevOps. So, it doesn't hurt to be at least aware of everything that is going on around us. Let's start with the layer the farthest away. Secure applications rely on secure networks first of all. This includes everything from routeres, switches, firewalls or even application level firewalls. They need to be patched and correctly configured. Watch out for standard ports and passwords for admin consoles. Next is the operating system layer. Every part of your applications runs on a separate host eventually (Applicationserver, Database, Message Brokers), so you will have to watch out for latest patches and updates for all of them. But shared filesystems and possibly risky daemon processes are also something to watch out for. When you're done with that it is time to look at the platform services. This is where the JDK base-install fits in but also the application-server. Check policy files and default passwords for remote connections and web-based admin consoles.

From Here On, Application Security Starts 
When the infrastructure is taken care of, we can look into application security. And it is typically divided up into six components: Authentication, Authorization, Auditing, Confidentiality, Integrity, Availability. All those components prevent your system from being exploited. A threat is a potential event that may affect your system. An attack exploits a vulnerability in your system. And ultimately this is what we want to prevent. Always adhere to the best practices for designing secure applications:
  • Compartmentalize
  • Use least privilege
  • Apply defense in depth
  • Do not trust user input
  • heck at the gate
  • Fail securely
  • Secure the weakest link
  • Create secure defaults
  • Reduce your attack surface
Get Started With Java EE Security
Watch the full talk on Vimeo to learn what Java EE has to offer around application security. And make sure to provide feedback in the comments and let me know, if there is anything else, you'd like me to talk about in the future.


Further Reading

Wednesday, November 4, 2015

Promoting Docker Images Across Environments

16:00 Wednesday, November 4, 2015 Posted by Unknown No comments:
, , ,
I got off the stage at WJAX in Munch just a couple of minutes ago. And while my co-worker Jan was talking about this amazing customer success story AMADEUS, I had the pleasure to base his thoughts and ideas a bit and talk about how DevOps can be done with OpenShift and Docker Images from a developers perspective.

Microservices and DevOps
If you have hundreds or even more container running in production everything isn't any longer just an operations problem. Not only because everybody is part of the DevOps movement today, but mainly, because we have to build our applications differently if we want to be able to profit from the synergies provided by immutable and stateless containers. The example I was using in the keynote was pretty much the same, that has been used on my blog before. A single WidlFly Swarm JAX-RS service, which does little more than printing out some JSON which contains an environment variable and a timestamp. The thing, that the series was missing is the staging across environments. And while there are some great blogs by Veer Muchandi over at OpenShift, they all assume that you use the OpenShift way of building images and applications.

Let's Stick To Plain Docker
I wanted to show, how easy it is while using plain Docker Images. So, assuming that you have a very straight forward environment setup:
Environment Setup (Dev, QA, Production)
We have a dev environment which the developers use to just push their updated images. And another QA environment where the testers go crazy and probably many others. The example I showed just used the two mentioned. It will be pretty much the same for every other env you add. Let's see how this works with Maven, Docker and OpenShift

Preparations
I used the fabric8 vagrant image in this case behind the scenes. Only because they always pull in the latest OpenShift builds and I wanted to show the new visualizations that are already in HEAD. So, install vagrant and the OpenShift binaries and fire up the openshift vagrant machine. I tweaked the memory and cpu settings a bit to 8 GB and 4 cores. Make sure to expose the internal Docker Registry as shown in the earlier blogpost. If you set your DOCKER_HOST variable accordingly you can start the walk-through. The recording of the demo gives you the complete show in about 10 minutes. And yes, there's no audio in this one.



The Individual Steps
Sometimes it is easier to just follow the individual steps yourself. Here they are:
Login to OpenShift as admin with password admin
oc login https://vagrant.f8:8443 --insecure-skip-tls-verify=true

Build your Maven based project (maybe just git clone my example and use that)
mvn clean install

Run the Local WildFly Swarm fat-jar
java -jar target/swarm-sample-0.0.1-SNAPSHOT-swarm.jar

Point your browser to http://localhost:8080/api/v1/service and verify everything is working as expected

Before you build the Docker Image from your application, make sure to pull the jboss/base-jdk:8 image. I don't know exactly why, but the plugin seems to have an issue with resolving it.
docker pull jboss/base-jdk:8 

Now build your Docker image
mvn clean install docker:build 

Look at the resulting Dockerfile
cat target/docker/development/swarm-sample/latest/build/Dockerfile

Create a new development project in OpenShift. At this point it doesn't matter, if it is a project in the same instance or another environment. As I was going to demo this locally on my laptop, the decision was easy. Compare Veers post from above, if you want to learn how to stage across physical environments.
oc new-project development --display-name="WildFly Swarm Development Project"

Add rights to view and edit for both users dev1 and test1
oc policy add-role-to-user edit dev1
oc policy add-role-to-user view test1

Create a QA project in OpenShift
oc new-project test --display-name="WildFly Swarm QA Project"

Give the test1 user the edit rights:
oc policy add-role-to-user edit test1

Add roles to system accounts to be able to pull images from QA out of the development environment
 oc policy add-role-to-group system:image-puller system:serviceaccounts:test -n development

Login as dev1 with password dev1 and get your access token
oc login https://vagrant.f8:8443 -u dev1
oc whoami -t

Change the token in the authConfig section of your pom.xml. Now, you're ready to push your WildFly Swarm Docker Image to the OpenShift Docker registry
mvn docker:push

Create an app from the image
oc new-app --docker-image=development/swarm-sample:latest

Expose a route for the newly created route. And make sure to have your hosts file updated with the correct mappings before accessing it via your browser.
oc expose service swarm-sample --hostname=wildfly-swarm.vagrant.f8

Check http://wildfly-swarm.vagrant.f8/api/v1/service and see, if everything works.

Get the OpenShift image streams from the image
oc get is
oc describe is 

Tag a new image from latest to promote
oc tag  172.30.238.11:5000/development/swarm-sample@sha256:6a53f0d875d75459eca6192e83cf4f8d879bb7cf9260e2a8addf412745b434fc development/swarm-sample:promote

Login as user test1 with password test1 and switch to the test project
oc login -u test1
oc project test

Create an application from the promoted image
oc new-app development/swarm-sample:promote

Expose the service as a route
oc expose service swarm-sample --hostname=wildfly-swarm-test.vagrant.f8

Check, if you can access: http://wildfly-swarm-test.vagrant.f8/api/v1/service

If you now login as dev1 again, go full development cycle and change the app, build a new image and push it again, you can see, that only the development environment gets updated, while the QA environment still stays on the promoted tag. When developers feel like updating QA again, you can just promote the "new" latest version of the image and the test environment will get updated, too.

Tuesday, November 3, 2015

Red Hat JBoss Engineers about Java EE, Container, Microservices and Testing

10:07 Tuesday, November 3, 2015 Posted by Unknown No comments:
, ,
JavaOne has been a blast for all of us. The biggest community gathering for all Java ecosystem enthusiasts. And there's been a lot of networking plus great content. Red Hat had a packed schedule for the mini theater sessions on the booth and I wanted to point you to the available recordings on the Red Hat Developers event page. There's been a great coverage around all recent topics. Especially around Java EE 7, Microservices, Testing, Containers and WildFly Swarm.

This is a perfect match for a little break in-between the next conferences. So, sit back, relax and get a cup of coffee and learn about the latest news in just a couple of short sessions.

Jason Porter (@lightguardjp)
Standardized Extension-Building in Java EE with CDI and JCA

Aslak Knutsen (@aslakknutsen), Alex Soto (@alexsotob) & Bartosz Majsak (@majson)
Taming Microservices Testing with Arquillian

Rafael Benevides (@rafabene) & Markus Eisele (@myfear)
Docker for Java EE Developers

Ken Finnigan (@kenfinnigan)
Java EE 7 Applications as a Microservice with WildFly Swarm

Monday, November 2, 2015

How Would ESBs Look Like, If They Were Done Today?

16:24 Monday, November 2, 2015 Posted by Unknown No comments:
, , ,
If They Were Done Today? My JavaOne Presentation
JavaOne 2015 just came to an end and it was a great community event again. I gave two sessions and a HOL with Rafael. One of the sessions actually is my favorite: The talk about how ESBs would look like, if they were done today.

What? ESBs? I thought that is the past?
That is what I usually tend to also say. But, system integration has come a long way, from point-to-point connections between individual systems towards the first integration solutions that helped in standardizing those connections. And in the advent of a much more business-centered design—and the broader shift into more service-oriented organizations—the Enterprise Service Bus (ESB) evolved from a pattern to a variety of products. They all promised to deliver re-usability and ex-changeability by standing up as a centralized and managed infrastructure component. With the next technology evolution—Microservices—the need to manage even more potentially-polyglot and distributed services became overwhelming.

Everybody Microservice-wash Their Solutions?
Vendors have already started to “microservice-wash” their tools and platforms to get your attention. And the segment architecture approach is still too new to give recommendations. For a while, it will still be your responsibility to understand the capabilities you need by doing your own research. Some promising candidates are evolving out of the open-source think tank at this very moment. First and foremost, projects like OpenShift Origin, WildFly Swarm, Fabric8, and APIMan will help you put together most of the puzzle pieces in your microservices-based architecture.

And There Are Some More Thoughts Here
My presentation abstract was: Looking past former hype topics such as enterprise application integration, ESBs, and SOA, the fact is that the need for reliable integration solutions that are manageable and scalable is growing. More devices and datasources, combined with new and upcoming use cases and exciting wearables in a cloudified and heterogeneous infrastructure, require more bits and pieces than just a central ESB with some rules and point-to-point connections. What would that look like? And how can we keep the resultant solutions manageable? Looking forward to your feedback!



Modern Java EE Design Patterns 
And if you're still stuck in Java EE and want to know how to build scalable architectures for sustainable enterprise development, you have to download my latest book. It gives you a complete overview about all the new trends and topics and helps you to check back, if you're still on track.
With the ascent of DevOps, microservices, containers, and cloud-based development platforms, the gap between state-of-the-art solutions and the technology that enterprises typically support has greatly increased. But as Markus Eisele explains in this O’Reilly report, some enterprises are now looking to bridge that gap by building microservice-based architectures on top of Java EE.