Monthly Archives: June 2014

Testable Java EE 7 Maven Archetype, using Arquillian (Tech Tip #34)

javaee, techtip, wildfly, , ,

There is a Maven archetype to create Java EE 7 application:

It generates a simple “pom.xml” with Java EE 7 API <dependency>. It does the job to get started with building the application. But how do you test this app ?

Of course, you write unit and integration tests. But how do you run these tests, especially in a container-independent manner ?

That’s where Arquillian comes in!

Arquillian guides explain how to write real tests, but you still need to figure out Maven dependencies, create profiles, figure out container dependencies, and more. That’s still too much work :)

Meet a new Maven archetype that generates a Java EE 7 app, with profiles pre-configured for WildFly and GlassFish.

The four profiles are:

  1. wildfly-remote-arquillian
  2. wildfly-managed-arquillian
  3. glassfish-remote-arquillian
  4. glassfish-embedded-arquillian

The first profile is the most natural to start with. It requires to download WildFly 8.1, unzip and start using ./bin/standalone.sh. Then you can run the test as:

to see the result as:

This is useful if tests need to be executed multiple times on the same WildFly instance.

The second profile is the easiest to start with, and does not require any manual downloading. Using the profile downloads WildFly (8.0.0 at this time) to Maven repository, installs it in the “target” directory, starts the server, deploys the WAR file, runs the test, and stops the server.

“glassfish-remote-arquillian” profile is like “wildfly-remote-arquillian” where an instance of GlassFish is started externally and tests are run in the usual manner. This profile does not work at this moment because of ARQ-1596.

“glassfish-embedded-arquillian” is like “wildfly-managed-arquillian” where GlassFish container is downloaded transparently using the Maven dependencies, starts the container, deploys the app, runs the test, and stops the container.

Archetype source code is at: github.com/javaee-samples/javaee7-archetypes/tree/master/javaee7-archetype and the archetype is published at search.maven.org/#search%7Cga%7C1%7Cjavaee7-arquillian-archetype.

Many thanks to @aslakknutsen for publishing this archetype!

A complete working sample can be checked out from github.com/arun-gupta/wildfly-samples/tree/master/arquillian.

Let us know if you find this useful and how would you use it.

Java EE 7 Hands-on Lab on WildFly and OpenShift (Tech Tip #33)

javaee, techtip, wildfly,

Thanks to @dmueller for inspiring this blog entry and @FarahJuma for keeping WildFly cartridge continuously updated!

Java EE 7 hands-on lab has been delivered at several conferences, meetups, Java User Groups, and other venues around the world. It provides instructions for a typical 3-tier application using several technologies in the Java EE 7 platform, such as WebSocket 1.0 (JSR 356), Batch Applications (JSR 352), JSON-P 1.0 (JSR 353), JAX-RS 2.0 (JSR 339), JMS 2.0 (JSR 343), CDI 1.1 (JSR 346), JPA 2.1 (JSR 338), and many more. The self-paced instructions allows the attendees to learn the design patterns in Java EE 7, and be productive right away.

This lab can be built using NetBeans, JBoss Tools/Eclipse, or IntelliJ. The deployment can be done on WildFly or GlassFish.

Do you want to get a taste of the application without trying out all the steps ? You can download the solution and deploy on application server of your choice.

Don’t have time for downloading and installing your application server ? OpenShift is your answer!

OpenShift provides an open source hybrid cloud application platform by Red Hat. It enables polyglot applications to be deployed on a public, private, and a hybrid cloud very easily. It provides an extensible cartridge-based architecture that allows a wide range of functionality such as frameworks, databases, monitoring services, or connectors to external backends to be easily added. WildFly cartridge allows you to start a WildFly instance in OpenShift Online.

This Tech Tip shows how to deploy Java EE 7 hands-on lab solution easily on WildFly cartridge on OpenShift.

  1. Register for a free OpenShift account.
  2. Login to OpenShift Console.
  3. Create a new WildFly application using the quickstart. Take the defaults, or change the name to whatever you want, and click on “Create Application”. The following page is shown:techtip33-app-created-credsThe default application page looks like:techtip33-wildfly-default-output
  4. Clone the workspace using the credentials shown for your application.
  5. Delete the generated “src” directory and copy the “src” from solution.
  6. Commit and push the changes to restart the cartridge:

Refreshing the page at javaee7lab-milestogo.rhcloud.com now shows the application deployed successfully:

techtip33-javaee7lab-default-output

Simple, isn’t it ?

Try it and let us know your feedback!

Tech Tip #21 also talks about how to get started with WildFly in OpenShift and JBoss Developer Studio.

 

JBoss Tools Community Acceptance Testing (JBoss Tools CAT)

jboss, ,

JBoss Tools is a set of plugins for Eclipse that complements, enhances and goes beyond the support that exists for JBoss and related technologies in the default Eclipse distribution.

Until now, early builds of JBoss Tools were released at a regular cadence leading up to the release of a particular version. Anybody could download, integrate the plugins in Eclipse, test, and provide feedback. JBoss Tools Community Acceptance Testing (CAT) seeks to obtain feedback from the community on early builds of JBoss Tools.

So what’s different ?

  • Allows JBoss Tools team to engage with individuals who can look at the release schedule and features coming in a particular release, test them, and provide feedback
  • JBoss Tools team will be paying close attention to the bugs filed by CAT members and ensuring they are responded/reacted to
  • Your name will be included in the JBoss Tools release notes
  • Help us decide if JBoss Tools is ready for release

Any feedback is relevant ? Stability, performance, usability, regression, RFE, anything literally.

Ready to get started ?

The simple process and other details are available at tools.jboss.org/cat/.

Learn more about the motivation behind all of this in a short interview with Max Andersen:

You might also wonder the name looks very familiar! Having actively participated in NetCAT and driven FishCAT, this was a very natural choice. All the more relevant because Red Hat truly believes in community powered innovation.

Max also blogged about it here.

And in case you are wondering, JBoss Developer Studio (JBDS) is a fully bundled Eclipse distribution which not only includes the majority of JBoss Tools but also all its needed dependencies and 3rd party plugins allowing for an easy one-click and no-fuss installation. JBDS is released along with the GA version of JBoss Tools. So if you are participating in JBoss Tools CAT, you are helping us test JBoss Developer Studio as well.

Tech Tip #5 shows how to get started with JBoss Tools and WildFly!

DeltaSpike 1.0 – Extend #JavaEE beyond #JavaEE (Tech Tip #32)

javaee, techtip, wildfly,

Do you want @Transactional and @TransactionScoped-like features introduced in Java EE 7 in JBoss EAP 6.x or any other Java EE 6 compliant application server ?

Need a CDI scope for window/tab for a JSF application ?

Simplified JPA Criteria API ?

How about boot and shutdown CDI container in a Java SE application ?

Simplified annotation-based security in Java EE ?

This is not a wish list for Java EE 8, but is possible today using DeltaSpike. All of this is possible by using the power of CDI portable extensions to unleash the power of a Java EE application server beyond what is defined in the existing specifications.

deltaspike-logo

DeltaSpike consist of a number of portable CDI extensions that provide useful features for Java application developers.

What are CDI portable extensions ?

CDI portable extensions extend the functionality of the container using an Service Provider Interface (SPI). A portable extension may integrate with the container by:

  • Providing its own beans, interceptors, and decorators to the container
  • Injecting dependencies into its own objects using the dependency injection service
  • Providing a contextual implementation for a custom scope
  • Augmenting or overriding the annotation-based metadata with metadata from some other source

DeltaSpike also ensure true portability! They are tested on different CDI implementations like JBoss Weld and Apache OpenWebBeans, and also on different Java EE servers like Apache Tomcat and TomEE, JBoss AS7, WildFly 8, Oracle GlassFish 3.1+ and 4.x+, IBM WebSphere 8.x, Oracle WebLogic Server 12c, Jetty, and others.

DeltaSpike has a core API and Impl module. The extensions themselves are available in different modules:

  • Security: Intercept and check security
  • Java Persistence API: @Transactional, @TransactionScoped, Extended persistence context, and more
  • Java Server Faces: Multi-window handling, New scopes, Type-safe view configs
  • Bean Validation: Add CDI support in Bean Validation
  • Servlet: Injection of common Servlet objects, propagation of Servlet events to the CDI event bus
  • Data: provides enhanced JPA experience with declarative queries, reducing boilerplate to a minimum.
  • Test Control: Allows to write CDI based tests easily
  • Scheduler: Simple integration with Quartz v2 (per default) or any other scheduler which supports cron-expressions for job-classes.
  • Container Control: Allows to boot and shutdown the CDI container in SE applications, control the life-cycle of the built-in contexts of the CDI container

You may realize that some of the functionality is already available in Java EE 7 so this would certainly be lot more relevant to Java EE 6 compliant application server. But there are still several features that can be used in Java EE 7 compliant app servers, like WildFly. And then it has the potential to be the playground for new features that are being discussed in Java EE 8!

Getting started is easy if you are using Maven. Add core and impl <dependency>s to “pom.xml”:

And then configure one of the modules as explained here.

Complete documentation for all the modules is available here.

One of the frequently needed features is accessing ServletRequest in a CDI bean. With DeltaSpike, this can be easily achieved using the following annotation:

A complete sample showcasing this functionality is available at github.com/arun-gupta/wildfly-samples/tree/master/deltaspike.

DeltaSpike 1.0 was recently announced and the complete list of JIRA tickets fixed is here.

There are usual ways to connect with the team:

Let us know what would you like to see in DeltaSpike!

WildFly plugin integrated in NetBeans (Tech Tip #31)

techtip, wildfly

WildFly tooling is available in JBoss Developer Studio (Eclipse), NetBeans, and IntelliJ. While JBoss Developer Studio and IntelliJ provided in-built support for WildFly, and an extra plugin had to be installed for NetBeans. Not a big deal but NetBeans is more known for a seamless out-of-the-box experience. Starting with today’s nightly, WildFly community is a step closer to that now!

This means if you download the latest NetBeans nightly, WildFly plugin is now integrated in NetBeans. You still need to download WildFly and configure it though.

netbeans-wildfly-techtip31

Tech Tip #18 shows screencasts on how to do Java EE 7 development with NetBeans.

Many thanks to Emmanuel Hugonet (@ehsavoie) for providing the plugin and NetBeans team for guiding through the process.

I’d like to have a NetBeans co-bundle with WildFly for a complete seamless experience. Would you ?

When you think of Java EE 7, think about WildFly. That is the only open source application server that will be commercially supported with JBoss EAP!

Java EE BoF at DevoxxUK Notes

conferences, javaee

2014-06-12 19.45.54

The usual Java EE BoF at DevoxxUK was another chance for community members to meet and discuss the past, present, and future of Java EE. The gathering happened on the first anniversary of Java EE 7 and so allowed us to focus on what happened in the past year and start focusing on what’s expected from Java EE 8.

Here are some notes:

  • Meetup started with the usual pet peeve of no official Java EE logo. @Java_EE is the “official” twitter handle which tweets about technology, compliant application servers, and competitive analysis that favor Oracle 😉 This handle has an image but there were personal opinions about its usage, with no clear consensus or statement from JCP or Oracle, on whether this is the official logo of Java EE as well.
  • Another constant running pet peeve is how the information around Java EE is scattered in different websites. There is official Java EE 7 tutorial by Oracle and 200+ samples/tests (with 33 contributors from the community), and Adam Bien’s samples. These are good for somebody who has a basic understanding of the technology already. But there is nothing for a newbie to Java EE. No single website that shows Java EE design patterns, how the technology has evolved over the years, comparison with Spring, why choose one over another, different application servers and their compliance level, relevance of production support in an open source world, tool set, and the list goes on. Antonio Goncalves (@agoncal) raised the point that if somebody registers javaee.io, then would Oracle send their lawyers after the person who registered the domain ? David Delabassee (@delabassee) mentioned that there might be some announcement to that effect at JavaOne, so wait and watch.
  • Antonio talked about how Java EE platform consists of a profile, and a profile can consists of multiple specs. He proposed a further granularity where a spec could be divided into multiple parts, such as CDI could be divided into core, injection, interceptors, etc. Different specs (existing or new) can then define what pieces of the spec they depend upon. This does rely upon modular platform. As we know, modularity is not coming to Java SE in the near future. So if this needs to be achieved then Java EE platform will have to define some mechanism of its own. David Blevins (@dblevins) particularly brought a good point that just because CDI is a good specification, that should not mean that everything should be added to CDI and make it a bloatware. We need to protect JSRs that are good and keep them light.
  • Nigel Deakin announced that JMS 2.x is getting planned. Some of the key focus there is to simplify Message Driven Beans, leverage connectors (this is David Blevins’s favorite topic ;), and allow messaging dispatching using JAX-RS-fashioned APIs. It was highly recommended that no new bean type should be introduced. Nigel is looking for supporters of the JSR.
  • David also mentioned that JAX-RS.next and Servlet.next are getting planned as part of Java EE 8. There is a already a flurry of activity on MVC support in JAX-RS. Similarly should support for Server-Sent Events be included in JAX-RS, or outside it ? There was as a suggestion that JAX-RS should expose an SPI and other specs should be able to leverage that SPI to add features to JAX-RS, instead of making it part of the core spec itself.
  • Anatole (@atsticks) talked briefly about the Configuration JSR which should likely be filed before Java EE 8 as well.
  • There was interest on having an embedded Java EE server. The user should be able to deploy the WAR file and the runtime should be able to detect dependencies and load the right set of containers.
  • There was still no urgency to provide a standards-based PaaS platform. However even though JSR 88 is formally deprecated but there were discussions about bringing a Devops-style API. This was also discussed during JavaOne 2013 as well.
  • Another constant pet peeves is the different styles of Logging API. There is no standard API in Java EE to log and each application server picks their favorite framework. This makes the job of application developer challenging.
  • JMX 2 might be revised as part of Java EE 8. There was a brief discussion on exposing JMX beans as REST endpoints.
  • There was also discussion around that there should be a separate Java Community Process track at JavaOne. This would provide beginner to advanced sessions on JCP, and hopefully encourage more members to join JCP and contribute.

Please leave a comment on the blog for any updates.

JUDCon Boston 2014 and History/Future

conferences, jboss

judcon-boston-2014

JUDCon is JBoss User Developer Conference and an event where JBoss users, developers, and community members meet to talk about anything and everything on JBoss technologies.

JUDCon India concluded earlier this year and JUDCon Boston is coming later this month. However the two events differ in their format. The first one was like a normal conference with a 2 day event, multiple tracks, multiple talks on different JBoss technologies per tracks, each talk being given by a speaker. There were usual hands-on labs, networking, etc.

JUDCon Boston is different, its a one day only event and focuses only on mobile technologies. And instead of talks where the user is mostly in a listen-only mode or sometimes swiping-through-my-phone mode depending upon the talk/speaker/time, it will be a structured hackfest with some micro-presentations to provide the background. Participants will come with their laptops and be able to build a mobile application using JBoss technologies such as AeroGear, Apache Cordova, KeyCloak, and OpenShift.

And the price point is just unimaginable, just $20 for full day of geekgasm!

When ? Jun 28, 2014
Where ? Boston, MA
Register ? Eventbrite

Without giving away too much details, lets hear it from Andrew Rubinger who is driving JUDCon Boston 2014.

If you are interested in a particular topic, jump to the timeline as shown below:

00:20: Introduction
01:29: History of JUDCon
03:09: How DevNation was formed and how are they different
06:18: JUDCon Boston
07:44: Who are the speakers
09:25: Future plans
11:34: How much networking opportunities ?
13:32 Where do you register ?

Also read Mark Little’s blog for more details.

Register for JUDCon Boston here. Lets build an app together :-)

Adding Java EE 7 Batch Addon to JBoss Forge ? – Part 4 (Tech Tip #30)

jboss, techtip,

This is the fourth part (part 1, part 2, part 3) of a multi-part video series where Lincoln Baxter (@lincolnthree) and I are interactively building a Forge addon to add Java EE 7 Batch functionality.

Part 1 showed how to get started with creating an addon, add relevant POM dependencies, build and install the addon using Forge shell, add a new command batch-new-jobxml, and add --reader, --processor, --writer parameters to the newly added command.

Part 2 showed how to identify classes for each CLI parameter that already honor the contract required by the Batch specification.

Part 3 showed how parameters can be made required, created templates for reader, processor, and writer, validated the specified parameters.

This part shows:

  • Fixed the issues from part 3 and generates new JobXML when reader, processor, and writer are specified
  • Added a new test to test the command
  • How Forge can be used in debug mode to debug add ons

Enjoy!

As always, the evolving source code is available at github.com/javaee-samples/forge-addons. The test code debugging will continue in the next episode.

Patch WildFly in Offline and Online Modes (Tech Tip #29)

techtip, wildfly

wildfly-8.1-flash

WildFly 8.1 was released recently. This release includes a few minor enhancements and 247 bug fixes. Several components were updated and all the details are available in Release Notes.

This is the first time patching infrastructure introduced in WildFly 8.0.0 can be used to update WildFly. So you can either download a full install of WildFly 8.1.0, or just the update to 8.0.0. This video explains how to install the update in offline mode (server not running) and online mode (server running).

UPDATE: The patching mechanism is supposed to be used for our products (JBoss EAP etc.) to deliver a stream of bug fixes, while the community projects (WildFly) will be used to primarily deliver feature updates (and fixes of course, but the emphasis is on the updates).  So WildFly will provide “patches” and future versions of JBoss EAP will provide “patches”.

Download WildFly and let us know your feedback!