Monthly Archives: May 2014

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.

Help shape the future of EAP 7: Feedback on Admin Console

jboss, redhat,

The JBoss Enterprise Application Platform (EAP) Admin Console is a browser-based management tool for the applications and resources deployed on EAP. The latest JBoss EAP (6.2 final and 6.3 alpha as of this release) can be downloaded from www.jboss.org/products/eap. Admin Console is accessible at localhost:9090 after the app server is started.

JBoss EAP 7 will be based on a future version of WildFly. So if you want to see how Admin Console is improving then you can download the latest WildFly (8.0 final and 8.1 CR2) and take a look there. Here is a quick snapshot:

wildfly-8.1cr2-admin-console-snapshot

Would you like to help shape the future of EAP 7 ? If you are interested, and have a few minutes to share your experience, this is your opportunity!

If you are an existing user of JBoss EAP and/or AS/WildFly, we are interested in learning your top 7-10 tasks that are performed regularly using the Admin Console. Based upon the results, we’ll decide on featuring the most common set of tasks using an easily accessible page in Admin Console.

More details on format, logistics, and how to share are explained at community.jboss.org/wiki/AdminConsoleCommonTasks.

Help us help you be more productive!

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

jboss, techtip,

This is the second part (part 1) of a multi-part video series where Lincoln Baxter (@lincolnthree) and I are interactively building a Forge addon to adding 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, and add parameters to the addon. This part shows how to add some meaningful semantics to those parameters.

Java EE 7 Batch define item-oriented processing where an item is read, optionally processed, and then written. Items could be read from an input source, CSV file, JMS destination, REST endpoint, database, or any other source. Similarly items can be written to an output stream, database, or some where else. This logic of reading, processing, and writing is captured in beans that are packaged in your WAR file. These beans need to either extend from a specific interface or extend an abstract class. For example item reader needs to either implement ItemReader interface or extends AbstractItemReader abstract class. Similarly item writer needs to either implement ItemWriter interface or extend <code<AbstractItemWriter abstract class. Item processor need to implement ItemProcessor interface.

Part 1 showed how to add --reader, --processor, --writer parameters to the newly added batch-new-jobxml command. This part will show how to identify classes for each CLI parameter that already honor the contract required by the Batch specification.

Enjoy!

As earlier, the evolving source code is available at github.com/javaee-samples/forge-addons.

The timing for the next recording is unknown at this time because of my travel schedule, but sometime next week.

PicketLink: Simplified Security and Identity Management for Java

javaee, jboss,

picketlink_logo_600x

PicketLink is an umbrella project for security and identity management for Java Applications. It provides:

  • Java EE Application Security
    • Authentication API
    • Authorization and Permission API
    • Session Based Identity
    • Fully Integrated With CDI
  • Identity Management
    • Built-in Identity Stores for Databases and LDAP
    • Supports Java EE and Java SE Platform
    • Rich and Extensible API
    • Multi-Tenancy
    • Ideal for Cloud and SaaS applications
  • Federation
    • SAML (v2.0 and v1.1)
    • OAuth2
    • XACML v2
    • OpenID
    • WS-Trust based Security Token Server (STS)
  • Social Login
    • Facebook Connect
    • Twitter Login
    • Google+ Login
  • Mobile Applications Security
  • REST Applications Security

Want to learn all about PicketLink ? Look at deep dive sessions part 1 and part 2.

Peter Skopek (@pskopek) works on the PicketLink team at Red Hat and gave a presentation at London JBUG a few days ago. The slides and the video recording are now available:

Lot more information at picketlink.org.

WebSocket in JBoss EAP 6.3 (Tech Tip #23)

jboss, techtip,

JBoss EAP (Enterprise Application Platform) is the commercially supported version of community supported JBoss AS 7.x. JBoss EAP 7 is scheduled to be released next year and will provide full compliance with Java EE 7. In the meanwhile, JBoss EAP 6.3 is getting ready to be released later this year.

Download JBoss EAP 6.3 Alpha, or this is also linked from the main downloads page.

A quick summary of JBoss EAP 6.3 is:

Features an updated administrative console that includes a new homepage and exposes the new JBoss EAP 6.2 patching features.  Also includes domain discovery and recovery improvements and support for WebSockets.

WebSocket ?

Yes, JBoss EAP 6.3 provides support for WebSocket using JSR 356 API. However this feature needs to be explicitly enabled by adding the following WEB-INF/jboss-web.xml to your .war file:

A wide variety of WebSocket samples are available here. Try these samples on EAP 6.3 Alpha, and we are looking forward to your feedback.

I tried the canonical chat sample and the output from Chrome and Firefox looked like:

tip22-websocket-chat-eap6.3

Bug #1083038 provide more details on this feature.

Which WebSocket sample are you going to try ?

 

Adding Java EE 7 Batch Addon to JBoss Forge – Part 1 (Tech Tip #22)

jboss, techtip,

JBoss Forge is the fastest way to build your Java EE applications, and not even tied to a particular IDE or an Application Server. Tech Tip #17 explained how to build a simple Java EE application rapidly, and deploy it on WildFly. JBoss Developer Studio provide a very neat integration with Forge as well. The instructions from the video are also explained in a text-based script here.

Forge is built with an extensible architecture where third-party addons can be easily installed to enable new functionality that does not exist in the Forge itself. A large variety of addons (nee plugins) are already available such as Arquillian, RichFaces, JRebel, OpenShift, Spring, TomEE, AngularJS, Netty, and a lot more.

Now, you’ve used Forge, found some functionality missing, fortunately somebody already created a addon and so could use that. But now you need some functionality and there is no addon available for that. So you’ll need to create an addon. How do you start ?

Lincoln Baxter (@lincolnthree) and I are starting a multi-part video series where we are going to interactively build a addon for adding Java EE 7 Batch functionality to Forge. The first video is available and shows:

  • Get started with creating a plugin basic structure
  • Add relevant dependencies
  • Build and install the addon
  • Add parameters to the addon

We plan to record the next session next Friday-ish. Let us know if you’d like to join us on G+ hangout and will share the coordinates.

The evolving source code is available at github.com/javaee-samples/forge-addons.

Enjoy!