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!

WildFly Cluster on Raspberry Pi (Tech Tip #28)

techtip, wildfly, ,

Tech Tip #25 showed how to configure WildFly on Raspberry Pi. Tech Tip #27 showed how to setup WildFly on two Raspberry Pis in managed domain mode. This tech tip will show how to setup a WildFly cluster over those two hosts.

WildFly supports mod_cluster out of the box. There are several advantages of mod_cluster:

  • Dynamic configuration of httpd workers
  • Server-side load balance factor calculation
  • Fine-grained web app lifecycle control

However there is no ARM build available for it, yet. So we’ll use mod_proxy instead that gets pre-installed as part of Apache2. The Domain Controller and HTTP server need not be on the same host and that’s the configuration we’ll use for our setup. So effectively, there will be three Raspberry Pis:

  • Domain Controller
  • Host Controller
  • Web Server

raspi-cluster-techtip28

Lets get started!

  1. Before installing any modules, including Apache, on Raspbian, the system needs to be fully updated:
    Trying to install Apache without updating the system will give weird errors:
    Now install Apache HTTP as:
    The log messages show that server’s name could not be determined, and 127.0.1.1 is instead used for ServerName. This can be fixed by editing “/etc/apache2/apache2.conf” and adding the following line:
  2. After Apache is installed, “mod_proxy” modules already exists in the “/usr/lib/apache2/modules” directory, and just need to enabled.Create “/etc/apache2/mods-enabled/mod_proxy.load” as:
    This file will be picked up via a direcinve in “/etc/apache2/apache2.conf”.

    Restart the server:

    If there are any errors, then you can see them in “/var/log/apache2/error.log” directory.

    The list of modules loaded can be seen using:

    The newly loaded modules are highlighted in bold.

  3. Provide convenient host names for each of the Raspberry Pis. The names chosen for each host is shown in the table below:
    IP Address Role Host Name
    10.0.0.27 Domain Controller raspi-master
    10.0.0.28 Host Controller raspi-slave
    10.0.0.29 Web Server raspi-apache

    This is enabled by editing “/etc/hostname” on each Raspberry Pi and changing “raspberrypi” to the given name.

    In addition, “/etc/hosts” on each Raspberry Pi need to make two entries of the following format:

    Here <IP Address> and <Host Name> for each host needs to be used from the table above.

    Finally, added the following entries on “/etc/hosts” on my local Mac:

    This ensures that any cookies are set from the same domain.

    Flush the DNS using:

    Now raspi-master.example.com:8330 in the browser shows:

    raspi-master-defaultoutput-techtip28

    And similarly raspi-slave.example.com:8330 shows:

    raspi-slave-default-output-techtip28

  4. Configure mod_proxy load balancer by editing “/etc/apache2/apache2.conf” and add the following lines at the end of the file:

    This directive provide load balancing between “master” and “slave”. “Header” and “ProxySet” directive provides sticky session.

Now accessing raspi-apache.example.com/http-1.0-SNAPSHOT/index.jsp shows:

raspi-apache-default-output-techtip28

And so in three parts (part 1 and part 2), we learned how to setup a WildFly cluster on Raspberry Pi!

WildFly Managed Domain on Raspberry Pi (Tech Tip #27)

techtip, wildfly, ,

Tech Tip #25 showed how to configure WildFly on Raspberry Pi. This tech tip will show how to setup a WildFly managed domain over two hosts running on Raspberry Pi.

Lets understand some basic concepts first.

WildFly can run in two modes:

  • Managed Domain allows you to run and manage a multi-server domain topology
  • Standalone allows to run a single instance of server

Multiple standalone instances can be configured to form a highly available cluster. It is up to the user to coordinate management across multiple servers though.

Servers running in managed domain mode are referred to as the members of a “domain”. A single Domain Controller acts as the central management control point for the domain. A domain can span multiple physical or virtual hosts, with all WildFly instances on a given host under the control of a Host Controller process. One Host Controller instance is configured to act as the Domain Controller. The Host Controller on each host interacts with the Domain Controller to control the lifecycle of the application server instances running on its host and to assist the Domain Controller in managing them.

It is important to understand that administration of servers (standalone or managed domain) is orthogonal to clustering and high availability. In the managed domain mode, a server instance always belong to a Server Group. A domain can have multiple Server Groups. Each group can be configured with different profiles and deployments.

wildfly-clustering-architecture-techtip27

For example, default WildFly installation comes with “main-server-group” and “other-server-group” as shown:

“main-server-group” has two servers: “server-one” and “server-two”. “other-server-group” has one server: “server-three”.

default-server-group-techtip27

By default, these are all configured on a single machine (localhost) with Host Controller and Domain Controller co-located. This is defined in “domain/configuration/host.xml”.

Each Server Group is configured with a profile. These profiles are defined, and associated with a Server Group, in “domain/configuration/domain.xml”. Default WildFly installation comes with two profiles: “full” and “full-ha”.

“main-server-group” is configured with “full” profile and “other-server-group” is configured with “full-ha” profile.

server-group-profiles-techtip27

Profile is a named set of subsystem configurations that adds capabilities like Servlet, EJB, JPA, JTA, etc. The “full-ha” profile also enable all subsystems needed to establish cluster (infinispan, jcluster, and mod_cluster).

OK, enough explanation, lets get into action!

Make sure to install WildFly on each of the Raspberry Pi following Tech Tip #25.

docs.jboss.org/author/display/WFLY8/WildFly+8+Cluster+Howto explain in detail on how to setup Domain Controller and Host Controller on two hosts and enable clustering. This tech tip follows these instructions and adapt them for WildFly. This tech tip will show how to configure WildFly managed domain over two Raspberry Pis.

raspi-cluster-techtip27

A subsequent blog will show how to configure cluster over this managed domain.

Here is what we’ll do:

  • Call one host as “master” and another as “slave”.
  • Both will run WildFly 8.1 CR2, master will run as Domain Controller and slave will run under the domain management of master
  • Deploy a project into domain, and verify that the application is deployed on both master and slave hosts.

Each WildFly was connected to a display to obtain the IP address and enable SSH access. It can be enabled by invoking

Scroll down to the SSH option and enable it. Then the two Raspberry Pis were configured to run in headless mode (no keyboard, mouse, or monitor).

raspi-wildfly-setup-techtip27

  1. Domain Configuration – Configure master and slave “host.xml”
    1. Master configuration
      1. Login to the master Raspberry pi:
        The default password is “raspberry”.
      2. By default, WildFly is configured to run in server VM. As mentioned in Tech Tip #25, this is not support on JDK bundled on Raspbian. This needs to be updated at two places. Edit “bin/domain.sh”:
        and remove the lines marked 80 through 110.
      3. Edit host.xml
        Remove “-server” option by removing lines 75 through 77 as shown below:
         
      4. The default setting for <interfaces> in this file looks like:
        Change this to:
        10.0.0.27 is master’s IP address.
    2. Slave configuration
      1. Login to the slave Raspberry pi:
        The default password is “raspberry”.
      2. Edit “domain.sh” and remove the lines as done for server. This will ensure that non-server, or client, JVM is used for running the domain.
      3. Edit “host.xml”
      4. Set the host name by changing
        to
      5. Remove “-server” option by removing lines 75 through 77 as explained above.
      6. Modify <domain-controller> such that slave can connect to master’s management port. Change
        to
        10.0.0.27 is master’s IP address.
      7. Change the default <interfaces> from:
        to:
        10.0.0.28 is slave’s IP address.
  2. Security Configuration
    1. Master
      1. Using “add-user.sh” script, create a user in Management Realm for master.
      2. Using “add-user.sh” script, create a user in Management Realm for slave. The username must be equal to the name given in the slave’s <host> element in “host.xml”.
        The answer to the last question is “yes” as this slave will be connecting to master.

        Note that output’s last line contains a <secret …> element. Copy this string as this will need to be used in slave’s “host.xml”.

    2. Slave
      1. Configure “domain/configuration/host.xml” for authentication by changing the security-realms element from:

        to

        The <secret …> element added here is obtained when “add-user.sh” is invoked for slave in the previous step. Slave’s host name is “slave”, master has a username by “slave”, and adding <secret …> element (base64 code for the password) allows the slave to connect to master.

  3. Change the default username/password for HornetQ otherwise it will throw a pesky warning in the server log as:

    Edit “domain/configuration/domain.xml” in master and change:

    to

    Make this change in “domain/configuration/domain.xml” for slave as well.

  4. Disable the firewall on master and slave by giving the following command on each host.

  5. Start the master first as:

    The last message in the log will look like:

    After the master has completely started, start the slave as:

    The last message in the log will look like:

    The server log for master will also show a message indicating that the slave is now a registered host with master:

  6. Deploy the application
    1. Check out a simple application that puts/gets some HTTP session data.

      This workspace has other samples related to WildFly. But the one that we care about it is in “clustering/http” directory. Change to that directory and build the sample as:

      This will generate a WAR file in the “target” directory.

    2. “jboss-cli” is a Command Line management tool for standalone and managed domains. It is bundled as a script in the “bin” directory. It can connect to remote servers as well. Now that we’ve Domain Controller running on master and Host Controller running on slave, lets connect it from your local machine as:

      10.0.0.27 is IP address of the master. The generated WAR file can now be deployed as:

      This shows the following output in master’s log:

      And slave’s log shows:

Accessing the application on master (http://10.0.0.27:8330/http-1.0-SNAPSHOT/index.jsp) shows:

master-default-output-techtip27

Accessing the application on slave (http://10.0.0.28:8330/http-1.0-SNAPSHOT/index.jsp) shows:

slave-default-output-techtip27

So we could easily deploy a Java EE application to multiple WildFly instances, running on RaspberryPi, in managed domain mode, with a single command. How cool ?

Next blog will explain how to setup cluster on these multiple instances.

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

jboss, techtip,

This is the third part (part 1, part 2) 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. This part shows how:

  • Parameters can be made required
  • Add an attribute to accept jobXML name
  • Check that the reader, processor, and writer are annotated with @Named
  • Create templates for reader, processor, writer, and jobXML
  • Use templating language to replace the name of chosen reader, processor, writer

Enjoy!

As earlier, the evolving source code is available at github.com/javaee-samples/forge-addons. The source code is compiling fine but not serving the intended purpose yet. It will be further debugged in the next episode, coming later this week.

JBoss User Group Worldwide: Learn JBoss Technologies using G+ Hangout

conferences, jboss, redhat, ,

jbug-worldwide-logo

A JBoss User Group (JBUG) is a group of people who share a common interest in JBoss technologies. They are organized and supported by the community and meet on a regular basis to discuss new technologies, development methodologies, interesting use cases, and other technical topics. The common goal is to provide education, help, and social events for the community and to promote open source. There are several JBUGs around the world and you can always start a new one in your local community.

JBUG Worldwide is like any other JBUG but the events will mostly take place virtually, using a Google Hangout. This allows us to reach to a broader set of audience, the presentations are recorded, and available for replay on the youtube channel. To our audience, it provides access to world-class speakers from Red Hat and rest of the JBoss community, which otherwise may not be easily accessible. This effort is initiated by JBUG Newcastle and so sometimes the meeting may coincide with a physical meeting at that JBUG.

You may find stark similarity with vJUG, and that is indeed true! However vJUG will continue to focus on broader Java topics and may feature some widely used JBoss technologies. But JBUG Worldwide will cover a wider range of JBoss technologies, and some of the niche ones as well.

The first session was on LiveOak: Is that a mobile backend as a service in your pocket ? and the recording is available:

Several other sessions are already lined up for this year, and more are in the pipeline:

  • Code-driven introduction to Java EE 7 (Jun 17)
  • What’s new in WildFly 8 ? (Jul 8)
  • Testing the Enterprise layers, with Arquillian (Oct 21)
  • Cast studies in Testable Java EE Development (Nov 18)

We would love hear to your feedback about speaker/topics, streamlining the process, or any thing else. We need you to make this successful!

Ping @Pfrobinson or myself (@arungupta) for any questions/comments.

WildFly on Raspberry Pi (Tech Tip #25)

techtip, wildfly, ,

WildFly is a lightweight, extremely flexible, highly manageable, Java EE 7 compliant, open source Application Server. Raspberry Pi (a.k.a. Raspi) is a credit-card sized computer that plugs into a computer monitor or TV, and uses a standard USB keyboard and mouse. It was created with the intention of promoting teaching of basic computer science in schools.

raspi-wildfly

This tech tip will show how you can get WildFly running on Raspberry Pi.

The latest model of Raspi is Model B that consists of:

  • 512 MB RAM
  • Two USB ports
  • One ethernet port

Raspi does not come with a storage device, not even for the operating system. But there is a slot for SD card that can be used for booting and persistent storage.

So, what else do you need to get going ?

  • One 8GB SD card
  • SD card writer so that you can burn the operating system on the card, typically in-built on Macs
  • Power supply to the unit, a 5V micro-USB connector
  • HDMI cable for connecting to a monitor/TV. You may need an adapter depending upon what is being used for display
  • USB mouse and keyboard. A wireless mouse and keyboard with a common USB dongle would be better (uses only one of the two USB ports)
  • Wifi dongle or Ethernet cable
  • Optionally, USB hub depending upon how many USB connections are made to Raspi

The original intention of Raspi was to promote teaching of basic computer science in schools. But people have all sorts of fun things with Raspi, including a super computer.

Lets get started!

  1. Easiest way to get started with Raspi is using New Out Of The Box Software (NOOBS). on SD card. The installation instructions are clearly documented here.
  2. Insert the prepared SD card, plugin the dongles and cables as shown. Make sure that the cable to laptop is connected after all others have been connected.raspi-setup
  3. The display flashes with lovely rainbow colors and then reads the card as shown:1
  4. The list of operating systems that can be installed are shown. Choose Raspbian, the first and recommended option. Change the default language and keyboard to whatever is appropriate, US in my case. Click on “Install”.2This warns that all the data on the card will be overwritten:

    3

    Clicking on “Yes” will start the Raspbian installation.

    4

    56

    The following message is shown when operating system is completed installed:

    7

    Or a more close up view:

    8

  5. Clicking on “OK” shows the following configuration menu:9Use arrow keys to go through the menu until “Finish” is selected as shown:

    10

    This will bring you to the shell. Type “startx” to start the GUI which looks like as
    shown:

    11

  6. First step here is to configure Wi-Fi. Click on “Wifi Config” icon on the desktop to see the window as shown:12
  7. Click on “Scan” to scan the list of network SSIDs that can be connected to. Another window pops up, click “Scan” again to see the list of network ids as:13Double-click on the SSID that you can connect to see a window as:14

    I had to manually change the value of Authentication from “WPA2-Personal (PSK)” to “WPA-Personal (PSK)”. Enter the wireless password and click on “Add”. The following window should be shown:

    15

  8. Open a terminal by clicking on “Terminal” on the desktop and check your network configuration looks good. Raspbian comes bundled with JDK 7 and you can check the version for that as well as shown:16
  9. Download WildFly 8.1 CR2 (latest release as of today) by giving the following command in the shell:

    Unzip WildFly as:

  10. By default WildFly is configured to run in the server VM. Trying to run the default WildFly installation gives the following error:

    This can be easily worked around by editing “wildfly-8.1.0.CR2/bin/standalone.sh” as:

    And removing line 214 and 215 which looks like:

    WildFly can now be easily started by giving the command “”wildfly-8.1.0.CR2/bin/standalone.sh” and shows the output as:

    17

  11. NetSurf is the default browser that can be started by clicking on the start bar on bottom left, selecting Internet, and then “Net Surf Web” as shown:18The browser looks like:

    19

  12.  Finally access the WildFly default home page at http://127.0.0.1:8080:20

That’s it!

What crazy thing are you going to use WildFly and Raspberry Pi for now ? :-)

JBoss/WildFly: Top Java EE Application Server for 5 years in ZeroTurnaround Reports

jboss

Zero Turnaround (the company behind JRebel and other Java productivity tools) has released their fifth edition of Java Tools and Technologies Landscape. This report started in 2009 as the speed of Java application server restarts, and has evolved into a lot more comprehensive report over the past 5 years. Oliver White (@theotown) and rest of Rebel Labs have really invested a lot of effort in making it a comprehensive and an inclusive report.

Several Red Hat projects/products are being mentioned in this report ranging from JBoss/WildFly, Hibernate, Ceylon, JBoss Developer Studio/Eclipse, Arquillian, and others.

In all these years, JBoss has consistently stayed at the top amongst all the commercially supported application servers. 2009 report showed JBoss as the most widely used application server:

Another result from Java EE Container Redeploy & Restart Time report in 2010:

And from Java EE Productivity Report 2011:

And Developer Productivity Report from 2012:

And Great Java Application Server Debate in 2013 (amazingly results are same ;):

And now in 2014, once again:

84% of respondents are using Java EE 6 or Java EE 7.

If you need a Java EE 6 commercially supported application server, then get started with JBoss EAP. If you need a Java EE 7 compliant application server that will be commercially supported, get started with WildFly.

Download the complete report here!

Configuration JSR in Java EE 8 – What should be covered ?

javaee, ,

GeeCON 2014 was very inspiring! A really greet feeling from the Polish Java community, awesome bunch of organizers (Andrej (@ags313), Adam (@maneo), Konrad (ktosopl), Adrian (@adrno), rest of the gang is just super nice), great technical content, courteous and helpful volunteers, lots of socializing space/opportunities, and most importantly fun! This was my second GeeCON and would love to go back there next year.

During speakers’ dinner, Anatole (@atsticks) and I were talking about the Configuration JSR (scheduled to be part of Java EE 8) and he shared the proposal. Instead of reading the proposal, I decided to put my thoughts down first so as not to be tainted by it. So this blog describe the use cases that I think this JSR should address. This by no means is a comprehensive list, or in any particular priority order. It is solely intended as input to the JSR and Expert Group based upon Anatole’s request, Laird Nelson (@chuggid) is the other spec lead on this.

Here goes the list …

  1. Application-wide configuration may be provided using XML-based configuration (application.xml ?), Annotations, and a programmatic Java API. A graphical web-based tool may simplify generation of these artifacts as well.
  2. One of the primary concerns during devops is the ability to take the same WAR file from development, to testing, and finally to production. Unzipping the archive and bundling a different deployment descriptor to point to different databases/servers is used as a workaround, but not recommended. If configuration is specified using a XML configuration file, then there should be the ability to specify configuration for all of these stages. Each stage could point to a different JMS destination, JNDI reference for data source, port numbers, etc.For example:
    In addition, a mechanism to trigger a particular stage would need to be defined. An external configuration tool that can trigger a particular environment may be one way to achieve this. Relying upon environment variables does is not a good idea.

    Custom stages should be permitted as this would allow to target different environments for stress, performance, regression, integration, and different sorts of testing.

    All of this, of course, would work for Java EE components only.

  3. Configuration may not be restricted to only Java EE components. It may include the max amount of memory that the application could use on the server, whether high availability is enabled or not, min/max number of servers in a cluster, etc. This would require to specify the configuration outside of Java EE context.
  4. Stages may inherit from other stages. This would allow a production environment to point to the test database rather easily. In this case, inheritance rules would need to be defined.
  5. Application configuration may be specified exclusively outside the application. This could be done using the graphical tool, and stored in a persistent store. This would allow a system administrator to easily pick a particular configuration.
  6. Reasonable defaults should be defined for the entire application, such as more logging/debugging during development stage. This will allow containers to spit out more detailed and useful information during different stages. For example, JSF displays an error message on XHTML page, even if there is no place holder for it, during development phase but hides it during the production stage.
  7. A mechanism to store all the configuration information in a variety of persistent stores would be useful. One of the common ways could be “application.xml” as a file, typically bundled in the archive itself. Storing this information in a relational database could be useful as well. This would allow developers to focus on application configuration during development, possibly using annotations or “application.xml”. And then retrieve a testing/production configuration from a database when targeting those stages.
  8. An archive would typically have a “persistence.xml” and a “web.xml”. Explicit rules on how the values defined in those individual files are overridden by application-wide configuration needs to be defined. These rules would need to be defined amongst the different ways configuration is enabled, for example “application.xml” overriding the values set by annotations.
  9. Going a step further, it may be relevant to even provide a standard schema on how this information is persisted. Vendors may provide their extensions to it, but at least a basic schema would ensure some level of portability.A development database bundled with the application server would work during development stage. But typically a more enterprise and reliable database would be used during production. So one more step further, a standard way to connect to these databases would be useful.
  10. A typical EAR file may look like:

    The scope of how/where an annotation is defined needs to be clearly specified. Whether “application.xml” can be defined in a JAR file bundled in WEB-INF/lib in an EAR file ?

    If so, what are the overriding rules ?

    Can it only be specified on the top-level archive ?

    What happens if there is a conflict ?

  11. JSR 236 did not specify how different managed objects can be configured, and this is a gap in the existing specification. If JSR 236.next is not being planned or not planning to address it during Java EE 8 timeframe, then this JSR should attempt to address that.
  12. Different application servers have their own means to deploy multiple versions of an application. This allows multiple versions to be deployed but only one version to be enabled at a given time. It would be nice if application versioning can be addressed by this JSR.
  13. Pre/post hooks for deployment, and other stages, should be made available. These can be used by sysadmins to provision resources required during deployment/runtime.
  14. CDI events for different stages may be generated. This would allow different parties to listen, and react to them.
  15. A Java EE 8 application may not need any deployment descriptors of the past. Bundling either just this “application.xml”, or specifying the configuration information externally should be enough.
  16. Reload of configuration information should be possible, without deploying the archive.
  17. A REST schema of all the configuration information handled by the JSR will really simplify how vendors can easily build custom tools on it.
  18. Other frameworks like Ruby-on-Rails and Grails allow application-wide configuration and we should learn from them, and adopt their best practices.

Now that my own thoughts are listed here, here are some additional ones after reading the proposal …

  1. There is no mention in the JSR for an XML-based deployment descriptor. Even though non-Java EE components will be specified outside the scope of Java EE, but I think having a descriptor to specify the configuration for Java EE components is useful.
  2. +1 on not defining a new archive format and Anatole has explained it well in the blog.
  3. I strongly prefer the second approach integrate this new functionality with all existing JSRs as that keeps the approach simple, and scalable to any future specs as well. This JSR should define an overall framework, and how other JSRs would specify the configuration. Individual component JSRs then should leverage that and define the exact configuration points. Ideally, each component specification should have an explicit chapter dedicated for configuration.
  4. KISSing is good and I like the proposed simplistic approach of using a Map to store all this information.

What do do you think should be the scope of this JSR ?

Added a calendar reminder to revisit this blog in a year, and another one in +1 year, and see how many of these points actually make it in the spec.

JBoss EAP 6.3 Beta Released: WebSockets, Domain recovery, New console homepage, Improved Security

jboss, redhat,

JBoss EAP 6.3 Beta is released!

jboss-eap-logo

This release brings continued progress on the road to making EAP the most manageable and secure Java EE 6-compliant Application Server for traditional and cloud based workloads.

Where to download ?

For current customers with active subscriptions, the Beta can be downloaded from the customer support portal and support tickets can be logged on the Beta.

For community users developing applications that will be deployed on a supported EAP, the Beta can be downloaded from www.jboss.org/products/eap under development terms & conditions, and questions can be posed to the EAP Forum.

Where are docs ?

Complete documentation is available on customer support portal, and here are quick links:

  • Release Notes
  • Administration and Configuration Guide
  • Development Guide
  • Getting Started Guide
  • Installation Guide
  • Migration Guide
  • Security Guide

What’s new ?

  • New console homepage featuring a view restricted according to the user’s role and permissions and allowing easy access to:
    • Common tasks and actions within EAP
    • Useful support information within the Red Hat Customer Portal
    • Developer links to tutorials and forums on jboss.org
  • Use the console and patching wizard to easily apply, rollback and view patches.
  • Domain recovery allows users to:
    • Manage multiple servers from a single point with domain mode
    • Configure slave hosts with multiple options to connect to a master host
    • If the primary master host fails, slave hosts may be promoted to become backup master host
    • Remaining slave hosts will automatically search for and connect to a backup master
  • Support for WebSockets implementation, a protocol allowing for full-duplex bi-directional, real-time communication between the client and server
  • Security Vault Enhancements including custom vault implementation and ability to store system-properties and CLI SSL password
  • Kerberos authentication for Datasources for selected databases
  • Management subsystems for PicketLink IDM and Federation allowing you to create and apply security configurations for application(s) from within the container. This is more efficient and less risky than having to maintain separate xml security configuration files within each application, forcing you to redeploy those applications if any changes were made.

If you are looking for a Java EE 7-compliant Application Server, then download WildFly.