Category Archives: java

Log your miles and community runs: Java EE 7 Real World Experience

September 24, 2014javaee, wildflyjavaee7, running, wildflyarungupta

miles2run.org is an easy way to track your running activities and share with friends and families. Day-based or distance-based goals can be created and then tracked. It also allows to create community run goals and have multiple runners participate and track their activities towards that goal. You can also find out local runners and connect with them.

The project was started to help track running activities for #JavaOneStreak. The goal was to run at least a mile every day all the way until JavaOne and use this website to track the runs. There are tons of sophisticated applications and websites that allow you to track running activity. Most of them provide integration with your GPS watch, phone GPS, and other fancy features. Some of them even allow creating a group but none of them is based on Java

The application is hosted as a website and built using HTML5 and Java EE 7. The landing page provides a summary of total runners, their city/country, miles, and hours logged so far.

The website can be viewed on a desktop, tablet, or a cell phone. The runners can login to the website using common social brokers such as Facebook, Google, and Twitter.

Any body can click on “Community Runs” on the top-right corner to see what all group runs have been created so far. These can only be created by an administrator. The group run page for JavaOne shows how many runners have joined this run and other statistics.

Each runner is presented with a dashboard showing how much distance they’ve run so far and total/completed/remaining/missed days.

A visual representation of the progress and a heat map of the activity calendar is shown:

miles2run-javaone-dashboard2

A line chart of mileage over the days is shown:

And then a summary of activities over the past months is shown as well:

Runners also have the opportunity to follow other runners and track their activities.

Here is a conceptual view of the application:

And here is a technology view of the application:

Here is a brief description of the technology stack:

Presentation
- Thymeleaf template engine views rendered by JAX-RS
- Social brokering using native APIs for Facebook, Google, Twitter
Middle Tier
- @Stateless EJB for all transactional JPA interactions, @Asynchronous for posting status to social networks
- JAX-RS for exposing REST endpoints. ContainerRequestFilter and ContainerResponseFilter for security for cross-cutting concerns like authentication, injecting profile, and CORS.
- Bean Validation constraints in JAX-RS resources.
- Bean discovery mode=”all”
Backend
- CDI producers for creating EntityManagers and other configuration objects like Redis connection pool objects or MongoDB configuration object. All NoSQL services are created @ApplicationScoped.
- Using native drivers for Redis and MongoDB. Jedis is being used for Redis and MongoDB Java driver is used for MongoDB. CDI services wrap these driver API and expose business functionalities that other layers could use.
- JPA + Bean Validation. Database scripts are generated from JPA model, added to source control, manually applied to the database. Using @Index and Entity Graph.
- Servlets are used for callback URLs for social brokers.
- Error pages are configured using <error-page>.
- MySQL is used for all business entities like Activity, Goal, User Profile etc. Redis is used for storing counters and timeline data. MongoDB is used for location-based user recommendations and follower/following recommendations.

Technologies from outside the platform:

JavaScript
- D3.js and C3.js for visually appealing graphs
- AngularJS for views
- Cal Heatmap for calendar heatmap
- jQuery
Google Geocoding API to convert Location Text to latitude and longitude
Jadira usertype for storing dates in UTC
Joda-Time for working with dates
Thymeleaf was used instead of JavaServer Faces because:
- Allows JAX-RS to be used as an MVC framework to render server side HTML pages and exposing REST services.
- This application is a Single Page application built using AngularJS. So, we needed a lightweight approach to render server side pages. JAX-RS along with Thyemleaf render the main HTML 5 page and then we use AngularJS to render different partials/views on that page. For example, the main home page is rendered by JAX-RS and Thymeleaf. When you work with different sections of this page all of them are part of a SPA managed by AngualarJS.
- Thymeleaf documents are valid HTML 5 documents so you can work with them offline for static prototyping.
Redis is used for storing all the counters like number of runners, cities, counters specific to goal like total distance covered in a goal etc. To avoid lots of read/write from the database, an an in-memory database is used so all the write and read operations are very performant. Redis counters are atomic, which means there are no concurrency issues associated with it. INCR andINCRBY Redis operations are used to update counters.
MongoDB is used for location data.

Toolset

JDK 8
IntelliJ 13.1 with Maven
Wildfly 8.1.0.Final – Development was done using a local WildFly instance and then pushed to scalable WildFly instances on OpenShift for deployment. HA Proxy is used as the load balancer.The advantage of working with OpenShift is that there is no OpenShift specific code in your application. So, it’s the same application that work locally that is deployed to test and production environment. You just have to use environment variables to abstract out environment specific configuration.
Github

Planned updates

Use Jenkins for Continuous Integration and manage deployments
JPA 2.1 converter instead of Jadira
Keycloak instead of native social broker
Opensource the application

Wish list for Java EE 8

Integration with OAuth providers
A real MVC framework with support for pluggable template engines
Seamless working with NoSQL databases

Download WildFly 8.1 today, learn the technology by reading/trying Java EE 7 samples, browse through Java EE 7 resources.

Or if you want to be on the bleeding edge, check out WildFly 9.0.

Many thanks to Shekhar Gulati (@shekhargulati) for authoring the application and providing all the answers!

Are you using Java EE 7 and WildFly to deploy your projects ? Would love to feature you here! Send me an email or leave a comment on the blog.

Java EE 7, JBoss, WildFly, Devoxx4Kids, and Parties at JavaOne 2014

September 19, 2014conferences, javaee, jboss, redhat, wildflyjavaonearungupta

JavaOne 2014 is about a week away, although some of festivities will start next Friday! This is going to be my 16th JavaOne in as many years and I’ve really enjoyed participating in each one of them. As always, there is great content lined up with rockstar speakers. This conference is a confluence of movers and shakers in the Java world and provides plenty of opportunities to engage with them. This is going to be my first year as Red Hatter and looking forward to catching up with friends and colleagues.

And in case you are wondering, and care about it, here are my engagements for that week:

Saturday, Sep 27

Devoxx4Kids Day
7pm – 11:30pm: NetBeans Party

Sunday, Sep 28

8am – 9:30am, Java Champions Brunch
7pm – 8:30pm: Duke Choice Awards
8pm – 11pm: Java EE Appreciation Event

Monday, Sep 29

8:30am – 10:30am Java EE 7 Soup to Nuts Tutorial [TUT1952]
11:30pm – 12:30pm Meet the Experts on Java EE and HTML5 Enterprise Application Development
1:30pm – 2:00pm Java EE 7 Essentials book signing at O’Reilly Booth

Tuesday, Sep 30

8:30am – 10:30am: Devoxx4Kids for Parents Tutorial [TUT1878]
12:30pm – 1:30pm: Lessons learned from real-life Java EE 7 Deployments [CON2450]
2:30pm – 4pm: Java EE Hackergarten
6pm – 9pm: Oracle Authors Appreciation Party
7pm – 9pm: JavaOne IGNITE
7pm – 10pm: PartyOne
7pm – 9:30: Java Champions Social
8pm – 8:45pm: Technology Evangelists Gathering [BOF12166]

Wednesday, Oct 1

1pm – 1:30pm: Book signing on Java EE and HTML5 Enterprise Application Development book (OOW bookstore in Moscone South, Upper Hall Lobby)
4pm – 6:30pm: #JavaOneStreak meetup, Hilton San Francisco Union Square, Sutter

Thursday, Oct 2

11:50: Broadening JCP Program Participation [CON9775]

I’ll also be running my own “hallway track” and so feel free to meet there. Of course, you can catch me at Red Hat booth as well!

There are lots of Red Hat speakers and sessions at the conference as well. And if you are not able to attend a Red Hat session then you can check out the mini-sessions in the exhibit hall.

See ya there!

Java EE 6 Sample, with HTML5, jQuery, Hybrid mobile: aka Ticket Monster (Tech Tip #44)

August 21, 2014javaee, jboss, techtipjavaee, openshiftarungupta

Java EE 7 was released last year, Java EE 8 preparations have already started, so what tempts me to write a blog about Java EE 6 ?

A few reasons …

Even though Java EE 5 was the first version where some of the specs were updated to simplify the platform, Java EE 6 is where higher productivity became the primary focus and kicked into high gear.
All commercially available application servers are still Java EE 6 compliant.
Java EE 7 is pretty cool and provide an awesome bunch of new technologies like WebSocket, Batch, JSON, and Concurrency. But customers are still sticking around with older version of the platform because these applications, servers, and environments cannot change overnight.

So if you are looking for a real-world Java EE 6 sample application that:

Use Eclipse for building a Java EE 6 application
Build persistence layer with JPA2 and Bean Validation
Build business services with JAX-RS
Building the User Interface with HTML5
Building Administration UI with JBoss Forge
Building statistics dashboard using HTML5 and JavaScript
Hybrid mobile version of the app using Apache Cordova

In addition, it also shows:

Deploy your application on a local instance or a remote instance running in OpenShift
Run tests against your JBoss instance

Ticket Monster is your ultimate source. It not only shows how the key Java EE 6 technologies can be used together but also integrate jQuery, HTML5, and mobile version of the application as well.

The video below gives a quick preview of the application:

An instance of Ticket Monster can be previewed at ticketmonster-jdf.rhcloud.com or timo-milestogo.rhcloud.com.

So how do you get started ?

Download Ticket Monster 2.6.0 (with tutorials). Corresponding source code is at github.com/jboss-developer/ticket-monster/tree/2.6.0.Final-with-tutorials.
Set up Red Hat Maven repositories as explained here. If you don’t care reading through the instructions, overwrite .m2/settings.xml with this settings.xml.

Build the WAR of your application

mvn clean package

mvn clean package

To run on local JBoss instance:

Download JBoss EAP 6.3

Unzip and start as

./bin/standalone.sh

./bin/standalone.sh

Deploy the application as

mvn package jboss-as:deploy

mvn package jboss-as:deploy

This will also build the application again.

The application is now accessible at localhost:8080/ticket-monster.

To run on JBoss instance in OpenShift

Create a JBoss EAP 6 application in OpenShift
Add PostgreSQL cartridge for this application

Create an archive as

mvn clean package -Ppostgresql-openshift

mvn clean package -Ppostgresql-openshift

This will use the installed PostgreSQL cartridge for persistence.

Clone the git workspace from OpenShift

git clone ssh://XXXXXXXXXXXXXX@timo-milestogo.rhcloud.com/~/git/timo.git/

git clone ssh://[email protected]/~/git/timo.git/

The actual git url will be specific to your application.

Copy generated WAR file to git workspace and rename to ROOT.war

cp target/ticket-monster.war &lt;openshift-git-workspace&gt;/deployments/ROOT.war

cp target/ticket-monster.war <openshift-git-workspace>/deployments/ROOT.war

Remove existing source and pom.xml from git workspace, add WAR, and push

git rm -rf src
git rm pom.xml
git add deployments/ROOT.war
git commit . -m"deploying TicketMonster"
git push

git rm -rf src

git rm pom.xml

git add deployments/ROOT.war

git commit . -m"deploying TicketMonster"

git push

Access the application at htp://<appname-domainname>.rhcloud.com.The following video shows the steps for running TicketMonster on OpenShift:

Ask your questions about Ticket Monster at .
Enjoy!

Java EE 7 Javadocs Download, Online, Tutorial, Samples (Tech Tip #42)

August 16, 2014javaee, techtipjavaee7arungupta

I was surprised when Google could not find Java EE 7 Javadocs download link clearly on the first page. StackOverflow was helpful here again, but even that was the last link on first page.

Now, I do know the location and can find my ways around. But this needs to be simplified and made more accessible for developers around the world.

So here are some usual Java EE 7 references:

Java EE 7 Javadocs Download Full Platform (bit.ly/ee7-javadocs), Web Profile
Java EE 7 Javadocs Online
Java EE 7 Tutorial
Java EE 7 Whitepaper
Java EE 7 Samples

Javadocs can also be installed on Dash as explained in Antonio’s blog.

And as usual, you can download WildFly or GlassFish to get started with Java EE 7!

Enjoy!

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

July 14, 2014javaee, redhat, techtipforge, javaee7, jbossarungupta

This is the fifth part (part 1, part 2, part 3, part 4) 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.

Part 4 added a new test for the command and showed how Forge can be used in debug mode.

This part shows:

Fix a bug reported by a community member
Started work another issue to make processor validation optional

Enjoy!

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

Defaults in Java EE 7 (Tech Tip #37)

July 10, 2014javaee, wildflyjavaee7, wildflyarungupta

Java EE 7 platform added a few new specifications to the platform:

Java API for WebSocket 1.0
Batch Applications for Java 1.0
Java API for JSON Processing 1.0
Concurrency Utilities for Java EE 1.0

This is highlighted in the pancake diagram shown below:

Several of the existing specifications were updated to fill the gaps and provide a more cohesive platform. Some small, but rather significant additions, were made to the platform to provide defaults for different features. These defaults would lower the bar for application developers to build Java EE applications.

Lets take a look at them.

Default CDI: Java EE 6 required “beans.xml” in an archive to enable CDI. This was mostly a marker file. So you could bundle a completely empty “beans.xml” in the archive and that would enable injection. Of course, you could specify a lot of other elements in this file such as interceptors, decorators, alternative but the basic dependency injection was enabled by just the mere inclusion of this file.This was one of the biggest source of confusion of why beans were not getting injected in a Java EE 7 archive, and was asked on several forums and other channels.
Java EE 7 made that “beans.xml” optional and provided a default behavior. Now if this file is not bundled, all CDI-scoped beans are available for injection. So any bean with an explicitly specified scope is available for injection. Scopes defined by the CDI specification are listed at docs.oracle.com/javaee/7/api/javax/enterprise/context/package-summary.html. Specifically, here are the scopes defined by CDI:
- @ApplicationScoped
- @ConversationScoped
- @Dependent
- @NormalScope
- @RequestScoped
- @SessionScoped
In addition, two new scopes are introduced in Java EE 7:
- @FlowScoped
- @TransactionScoped
So, any bean with these scopes will be available for injection, in other beans only, without the presence of “beans.xml”.

Check it out in action at github.com/javaee-samples/javaee7-samples/tree/master/cdi/nobeans-xml.

Default data source: A Java EE runtime, a.k.a application server, requires to package a database with it. If you are building a Java EE application, you likely will need some sort of data store or RBDMS to store the data. So this makes perfect sense.For example, WildFly bundles in-memory H2 database.Now, you can certainly use another JDBC-compliant database but bundling a database makes it convenient to start with. However, in order to get started, Java EE 6 still required to create JDBC resources in an application server-specific way. This would mean understanding app server-specific tools.

Java EE 7 simplified it by providing a default data source with a pre-defined JNDI name.This mean you can inject a data source as:

@Resource
DataSource ds;

@Resource

DataSource ds;

Also, your persistence.xml can look like:

&lt;?xml version="1.0" encoding="UTF-8"?&gt;
&lt;persistence
  version="2.1"
  xmlns="http://xmlns.jcp.org/xml/ns/persistence"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/persistence 
   http://xmlns.jcp.org/xml/ns/persistence/persistence_2_1.xsd"&gt;
 &lt;persistence-unit name="myPU" transaction-type="JTA"/&gt;
&lt;/persistence&gt;

<?xml version="1.0" encoding="UTF-8"?>

<persistence

version="2.1"

xmlns="http://xmlns.jcp.org/xml/ns/persistence"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/persistence

http://xmlns.jcp.org/xml/ns/persistence/persistence_2_1.xsd">

<persistence-unit name="myPU" transaction-type="JTA"/>

</persistence>

Note, no <jta-data-source>.

In both of these circumstances, a default data source with JNDI name java:comp/DefaultDataSource is bound to your application-server specific JDBC resource.

The exact data source in WildFly can be verified using jboss-cli script as:

wildfly-8.1.0.Final&gt; ./bin/jboss-cli.sh --connect --command="/subsystem=datasources:read-resource"
{
    "outcome" =&gt; "success",
    "result" =&gt; {
        "data-source" =&gt; {"ExampleDS" =&gt; undefined},
        "jdbc-driver" =&gt; {"h2" =&gt; undefined},
        "xa-data-source" =&gt; undefined
    }
}

wildfly-8.1.0.Final> ./bin/jboss-cli.sh --connect --command="/subsystem=datasources:read-resource"

{

"outcome" => "success",

"result" => {

"data-source" => {"ExampleDS" => undefined},

"jdbc-driver" => {"h2" => undefined},

"xa-data-source" => undefined

}

Check it out in action at github.com/javaee-samples/javaee7-samples/tree/master/jpa/default-datasource.

Create JMS connection factory, queues, and topics: An application using JMS topics and queues in Java EE 6 would require a deployment script to create Connection Factory and Queues/Topics. These would again be done in an application server-specific way.Java EE 7 provide annotations @JMSConnectionFactoryDefinition and @JMSConnectionFactoryDefinitions that are read by the Java EE 7 runtime and ensures that the ConnectionFactory specified by these annotations is provisioned in the operational environment.
Similarly, @JMSDestinationDefinition and @JMSDestinationDefinitions can be used to create Topics/Queues as part of application deployment.So no more deployment scripts, just include annotation in your code ?

Check it out in action at github.com/javaee-samples/javaee7-samples/tree/master/jms/send-receive.

Default JMS connection factory: Just like default data source, a default JMS resource allows you to avoid creating a JMSConnectionFactory in an appserver-specific way to deploy the application using JMS resources.Injection of a JMS Producer or Consumer in Java EE 6 required to get an instance of application-managed or container-managed JMSConnectionFactory. This factory had to be manually created in an application-server specific way.Providing a default JMSConnectionFactory simplifies this step further.

JMS 2.0 also introduced JMSContext as entry point to the simplified API, and it can be injected simply as:

@Inject
JMSContext context;

@Inject

JMSContext context;

Not specifying a ConnectionFactory means the default one will be used. And it has the JNDI name of jms/DefaultJMSConnectionFactory.

The JNDI name may be mapped to the appserver-specific JMS provider. For example, in case of WildFly it is defined as:

./bin/jboss-cli.sh -c --command="/subsystem=messaging/hornetq-server=default/pooled-connection-factory=hornetq-ra:read-resource"
{
    "outcome" =&gt; "success",
    "result" =&gt; {
        "auto-group" =&gt; false,
        "block-on-acknowledge" =&gt; false,
        "block-on-durable-send" =&gt; true,
        "block-on-non-durable-send" =&gt; false,
        "cache-large-message-client" =&gt; false,
        "call-failover-timeout" =&gt; -1L,
        "call-timeout" =&gt; 30000L,
        "client-failure-check-period" =&gt; 30000L,
        "client-id" =&gt; undefined,
        "compress-large-messages" =&gt; false,
        "confirmation-window-size" =&gt; -1,
        "connection-load-balancing-policy-class-name" =&gt; "org.hornetq.api.core.client.loadbalance.RoundRobinConnectionLoadBalancingPolicy",
        "connection-ttl" =&gt; 60000L,
        "connector" =&gt; {"in-vm" =&gt; undefined},
        "consumer-max-rate" =&gt; -1,
        "consumer-window-size" =&gt; 1048576,
        "discovery-group-name" =&gt; undefined,
        "discovery-initial-wait-timeout" =&gt; undefined,
        "dups-ok-batch-size" =&gt; 1048576,
        "entries" =&gt; [
            "java:/JmsXA",
            "java:jboss/DefaultJMSConnectionFactory"
        ],
        "failover-on-initial-connection" =&gt; false,
        "failover-on-server-shutdown" =&gt; undefined,
        "group-id" =&gt; undefined,
        "ha" =&gt; false,
        "initial-connect-attempts" =&gt; 1,
        "initial-message-packet-size" =&gt; 1500,
        "jndi-params" =&gt; undefined,
        "max-pool-size" =&gt; -1,
        "max-retry-interval" =&gt; 2000L,
        "min-large-message-size" =&gt; 102400,
        "min-pool-size" =&gt; -1,
        "password" =&gt; undefined,
        "pre-acknowledge" =&gt; false,
        "producer-max-rate" =&gt; -1,
        "producer-window-size" =&gt; 65536,
        "reconnect-attempts" =&gt; -1,
        "retry-interval" =&gt; 2000L,
        "retry-interval-multiplier" =&gt; 1.0,
        "scheduled-thread-pool-max-size" =&gt; 5,
        "setup-attempts" =&gt; undefined,
        "setup-interval" =&gt; undefined,
        "thread-pool-max-size" =&gt; 30,
        "transaction" =&gt; "xa",
        "transaction-batch-size" =&gt; 1048576,
        "use-auto-recovery" =&gt; true,
        "use-global-pools" =&gt; true,
        "use-jndi" =&gt; undefined,
        "use-local-tx" =&gt; undefined,
        "user" =&gt; undefined
    }
}

./bin/jboss-cli.sh -c --command="/subsystem=messaging/hornetq-server=default/pooled-connection-factory=hornetq-ra:read-resource"

{

"outcome" => "success",

"result" => {

"auto-group" => false,

"block-on-acknowledge" => false,

"block-on-durable-send" => true,

"block-on-non-durable-send" => false,

"cache-large-message-client" => false,

"call-failover-timeout" => -1L,

"call-timeout" => 30000L,

"client-failure-check-period" => 30000L,

"client-id" => undefined,

"compress-large-messages" => false,

"confirmation-window-size" => -1,

"connection-load-balancing-policy-class-name" => "org.hornetq.api.core.client.loadbalance.RoundRobinConnectionLoadBalancingPolicy",

"connection-ttl" => 60000L,

"connector" => {"in-vm" => undefined},

"consumer-max-rate" => -1,

"consumer-window-size" => 1048576,

"discovery-group-name" => undefined,

"discovery-initial-wait-timeout" => undefined,

"dups-ok-batch-size" => 1048576,

"entries" => [

"java:/JmsXA",

"java:jboss/DefaultJMSConnectionFactory"

"failover-on-initial-connection" => false,

"failover-on-server-shutdown" => undefined,

"group-id" => undefined,

"ha" => false,

"initial-connect-attempts" => 1,

"initial-message-packet-size" => 1500,

"jndi-params" => undefined,

"max-pool-size" => -1,

"max-retry-interval" => 2000L,

"min-large-message-size" => 102400,

"min-pool-size" => -1,

"password" => undefined,

"pre-acknowledge" => false,

"producer-max-rate" => -1,

"producer-window-size" => 65536,

"reconnect-attempts" => -1,

"retry-interval" => 2000L,

"retry-interval-multiplier" => 1.0,

"scheduled-thread-pool-max-size" => 5,

"setup-attempts" => undefined,

"setup-interval" => undefined,

"thread-pool-max-size" => 30,

"transaction" => "xa",

"transaction-batch-size" => 1048576,

"use-auto-recovery" => true,

"use-global-pools" => true,

"use-jndi" => undefined,

"use-local-tx" => undefined,

"user" => undefined

}

Check it out in action at github.com/javaee-samples/javaee7-samples/tree/master/jms/send-receive.

Default executors: Concurrency Utilities for Java EE introduced four different managed objects:

ManagedExecutorService
ScheduledManagedExecutorService
ContextService
ManagedThreadFactory

These objects allow user to create application threads that are managed by the Java EE server runtime. Once again, a default and pre-configured managed object, with a well-defined JNDI name, is made available for each one of them.

This allows a user to inject a ManagedExecutorService as:

@Resource
ManagedExecutorService myExecutor;

@Resource

ManagedExecutorService myExecutor;

instead of:

@Resource(lookup="myExecutorJNDI")
ManagedExecutorService myExecutor;

@Resource(lookup="myExecutorJNDI")

ManagedExecutorService myExecutor;

Default ManagedExecutorService in WildFly can be found as:

./bin/jboss-cli.sh -c --command="/subsystem=ee/managed-executor-service=default:read-resource"
{
    "outcome" =&gt; "success",
    "result" =&gt; {
        "context-service" =&gt; "default",
        "core-threads" =&gt; 5,
        "hung-task-threshold" =&gt; 60000L,
        "jndi-name" =&gt; "java:jboss/ee/concurrency/executor/default",
        "keepalive-time" =&gt; 5000L,
        "long-running-tasks" =&gt; false,
        "max-threads" =&gt; 25,
        "queue-length" =&gt; 0,
        "reject-policy" =&gt; "ABORT",
        "thread-factory" =&gt; undefined
    }
}

./bin/jboss-cli.sh -c --command="/subsystem=ee/managed-executor-service=default:read-resource"

{

"outcome" => "success",

"result" => {

"context-service" => "default",

"core-threads" => 5,

"hung-task-threshold" => 60000L,

"jndi-name" => "java:jboss/ee/concurrency/executor/default",

"keepalive-time" => 5000L,

"long-running-tasks" => false,

"max-threads" => 25,

"queue-length" => 0,

"reject-policy" => "ABORT",

"thread-factory" => undefined

}

Similarly other default managed objects can be found.

Check out different executors in action at github.com/javaee-samples/javaee7-samples/tree/master/concurrency.

With so many simplifications, why would you not like to use Java EE 7 platform ?

And WildFly is a fantastic application server too

Download WildFly now, and get started!

Schedule Java EE 7 Batch Jobs (Tech Tip #36)

July 8, 2014javaee, techtip, wildflyarungupta

Java EE 7 added the capability to perform Batch jobs in a standard way using JSR 352.

&lt;job id="myJob" xmlns="http://xmlns.jcp.org/xml/ns/javaee" version="1.0"&gt;
  &lt;step id="myStep"&gt;
    &lt;chunk item-count="3"&gt;
    &lt;reader ref="myItemReader"/&gt;
    &lt;processor ref="myItemProcessor"/&gt;
  &lt;writer ref="myItemWriter"/&gt;
&lt;/chunk&gt;

</chunk>

This code fragment is the Job Specification Language defined as XML, a.k.a. Job XML. It defines a canonical job, with a single step, using item-oriented or chunk-oriented processing. A chunk can have a reader, optional processor, and a writer. Each of these elements are identified using the corresponding elements in the Job XML, and are CDI beans packaged in the archive.

This job can be easily started using:

BatchRuntime.getJobOperator().start("myJob", new Properties());

BatchRuntime.getJobOperator().start("myJob", new Properties());

A typical question asked in different forums and conferences is how to schedule these jobs in a Java EE runtime. Batch 1.0 API itself does not offer anything to be schedule these jobs. However Java EE platform offers three different ways to schedule these jobs:

Use the @javax.ejb.Schedule annotation in an EJB.
Here is a sample code that will trigger the execution of batch job at 11:59:59 PM every day.

@Singleton
public class MyEJB {
  @Schedule(hour = "23", minute = "59", second = "59")
  public void myJob() {
    BatchRuntime.getJobOperator().start("myJob", new Properties());
  }
}

@Singleton

public class MyEJB {

@Schedule(hour = "23", minute = "59", second = "59")

public void myJob() {

BatchRuntime.getJobOperator().start("myJob", new Properties());

}

Of course, you can change the parameters of @Schedule to start the batch job at the desired time.

Use ManagedScheduledExecutorService using javax.enterprise.concurrent.Trigger as shown:

@Stateless
public class MyStatelessEJB {
    @Resource
    ManagedScheduledExecutorService executor;

    public void runJob() {
        executor.schedule(new MyJob(), new Trigger() {

            public Date getNextRunTime(LastExecution lastExecutionInfo, Date taskScheduledTime) {
                Calendar cal = Calendar.getInstance();
                cal.setTime(taskScheduledTime);
                cal.add(Calendar.DATE, 1);
                return cal.getTime();
            }

            public boolean skipRun(LastExecution lastExecutionInfo, Date scheduledRunTime) {
                return null == lastExecutionInfo;
            }

        });
    }

    public void cancelJob() {
        executor.shutdown();
    }
}

@Stateless

public class MyStatelessEJB {

@Resource

ManagedScheduledExecutorService executor;

public void runJob() {

executor.schedule(new MyJob(), new Trigger() {

public Date getNextRunTime(LastExecution lastExecutionInfo, Date taskScheduledTime) {

Calendar cal = Calendar.getInstance();

cal.setTime(taskScheduledTime);

cal.add(Calendar.DATE, 1);

return cal.getTime();

}

public boolean skipRun(LastExecution lastExecutionInfo, Date scheduledRunTime) {

return null == lastExecutionInfo;

}

});

}

public void cancelJob() {

executor.shutdown();

}

Call runJob to initiate job execution and cancelJob to terminate job execution. In this case, a new job is started a day later than the previous task. And its not started until previous one is terminated. You will need more error checks for proper execution.

MyJob is very trivial:

public class MyJob implements Runnable {

    public void run() {
        BatchRuntime.getJobOperator().start("myJob", new Properties());
    }

}

public class MyJob implements Runnable {

public void run() {

BatchRuntime.getJobOperator().start("myJob", new Properties());

}

Of course, you can automatically schedule it by calling this code in @PostConstruct.

A slight variation of second technique allows to run the job after a fixed delay as shown:

public void runJob2() {
    executor.scheduleWithFixedDelay(new MyJob(), 2, 3, TimeUnit.HOURS);
}

public void runJob2() {

executor.scheduleWithFixedDelay(new MyJob(), 2, 3, TimeUnit.HOURS);

}

The first task is executed 2 hours after the runJob2 method is called. And then with a 3 hours delay between subsequent execution.

This support is available to you within the Java EE platform. In addition, you can also invoke BatchRuntime.getJobOperator().start("myJob", new Properties()); from any of your Quartz-scheduled methods as well.

You can try all of this on WildFly.

And there are a ton of Java EE 7 samples at github.com/javaee-samples/javaee7-samples.

This particular sample is available at github.com/javaee-samples/javaee7-samples/tree/master/batch/scheduling.

How are you scheduling your Batch jobs ?

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

June 30, 2014javaee, techtip, wildflyarquillian, glassfish, javaee7, wildflyarungupta

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

mvn --batch-mode -DarchetypeGroupId=org.codehaus.mojo.archetypes -DarchetypeArtifactId=webapp-javaee7 -DgroupId=org.javaee7.sample -DartifactId=javaee7-sample -Dpackage=org.javaee7.sample archetype:generate

mvn --batch-mode -DarchetypeGroupId=org.codehaus.mojo.archetypes -DarchetypeArtifactId=webapp-javaee7 -DgroupId=org.javaee7.sample -DartifactId=javaee7-sample -Dpackage=org.javaee7.sample archetype:generate

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.

mvn --batch-mode archetype:generate -DarchetypeGroupId=org.javaee-samples -DarchetypeArtifactId=javaee7-arquillian-archetype -DgroupId=org.samples.javaee7.arquillian -DartifactId=arquillian

mvn --batch-mode archetype:generate -DarchetypeGroupId=org.javaee-samples -DarchetypeArtifactId=javaee7-arquillian-archetype -DgroupId=org.samples.javaee7.arquillian -DartifactId=arquillian

The four profiles are:

wildfly-remote-arquillian
wildfly-managed-arquillian
glassfish-remote-arquillian
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:

mvn test -Pwildfly-remote-arquillian

mvn test -Pwildfly-remote-arquillian

to see the result as:

Running org.wildfly.samples.javaee7.arquillian.EmployeeResourceTest
Jun 29, 2014 9:32:57 PM org.xnio.Xnio &lt;clinit&gt;
INFO: XNIO version 3.2.0.Beta2
Jun 29, 2014 9:32:57 PM org.xnio.nio.NioXnio &lt;clinit&gt;
INFO: XNIO NIO Implementation Version 3.2.0.Beta2
Jun 29, 2014 9:32:57 PM org.jboss.remoting3.EndpointImpl &lt;clinit&gt;
INFO: JBoss Remoting version (unknown)
Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 3.137 sec

Running org.wildfly.samples.javaee7.arquillian.EmployeeResourceTest

Jun 29, 2014 9:32:57 PM org.xnio.Xnio <clinit>

INFO: XNIO version 3.2.0.Beta2

Jun 29, 2014 9:32:57 PM org.xnio.nio.NioXnio <clinit>

INFO: XNIO NIO Implementation Version 3.2.0.Beta2

Jun 29, 2014 9:32:57 PM org.jboss.remoting3.EndpointImpl <clinit>

INFO: JBoss Remoting version (unknown)

Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 3.137 sec

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.

[INFO] --- maven-dependency-plugin:2.8:unpack (unpack) @ arquillian ---
[INFO] Configured Artifact: org.wildfly:wildfly-dist:8.0.0.Final:zip
Downloading: http://repo.maven.apache.org/maven2/org/wildfly/wildfly-dist/8.0.0.Final/wildfly-dist-8.0.0.Final.zip
Downloaded: http://repo.maven.apache.org/maven2/org/wildfly/wildfly-dist/8.0.0.Final/wildfly-dist-8.0.0.Final.zip (151090 KB at 1684.3 KB/sec)
[INFO] Unpacking /Users/arungupta/.m2/repository/org/wildfly/wildfly-dist/8.0.0.Final/wildfly-dist-8.0.0.Final.zip to /Users/arungupta/workspaces/wildfly-samples/arquillian/target with includes "" and excludes ""

. . .

T E S T S
-------------------------------------------------------
Running org.wildfly.samples.javaee7.arquillian.EmployeeResourceTest
Jun 30, 2014 1:35:46 PM org.jboss.as.arquillian.container.managed.ManagedDeployableContainer startInternal
13:35:53,105 INFO  [org.hibernate.validator.internal.util.Version] (MSC service thread 1-1) HV000001: Hibernate Validator 5.0.3.Final
13:35:53,176 INFO  [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor] (MSC service thread 1-1) JNDI bindings for session bean named EmployeeRepository in deployment unit deployment "3c82ea4b-5638-4902-8896-cbc08ed6895e.war" are as follows:
java:global/3c82ea4b-5638-4902-8896-cbc08ed6895e/EmployeeRepository!org.wildfly.samples.javaee7.arquillian.EmployeeRepository
java:app/3c82ea4b-5638-4902-8896-cbc08ed6895e/EmployeeRepository!org.wildfly.samples.javaee7.arquillian.EmployeeRepository
java:module/EmployeeRepository!org.wildfly.samples.javaee7.arquillian.EmployeeRepository

. . .

13:39:33,622 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-1) JBAS017506: Undertow 1.0.0.Final stopping
13:39:33,639 INFO  [org.jboss.as] (MSC service thread 1-15) JBAS015950: WildFly 8.0.0.Final "WildFly" stopped in 22ms

Results :

Tests run: 6, Failures: 0, Errors: 0, Skipped: 0

[INFO] --- maven-dependency-plugin:2.8:unpack (unpack) @ arquillian ---

[INFO] Configured Artifact: org.wildfly:wildfly-dist:8.0.0.Final:zip

Downloading: http://repo.maven.apache.org/maven2/org/wildfly/wildfly-dist/8.0.0.Final/wildfly-dist-8.0.0.Final.zip

Downloaded: http://repo.maven.apache.org/maven2/org/wildfly/wildfly-dist/8.0.0.Final/wildfly-dist-8.0.0.Final.zip (151090 KB at 1684.3 KB/sec)

[INFO] Unpacking /Users/arungupta/.m2/repository/org/wildfly/wildfly-dist/8.0.0.Final/wildfly-dist-8.0.0.Final.zip to /Users/arungupta/workspaces/wildfly-samples/arquillian/target with includes "" and excludes ""

. . .

T E S T S

-------------------------------------------------------

Running org.wildfly.samples.javaee7.arquillian.EmployeeResourceTest

Jun 30, 2014 1:35:46 PM org.jboss.as.arquillian.container.managed.ManagedDeployableContainer startInternal

13:35:53,105 INFO [org.hibernate.validator.internal.util.Version] (MSC service thread 1-1) HV000001: Hibernate Validator 5.0.3.Final

13:35:53,176 INFO [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor] (MSC service thread 1-1) JNDI bindings for session bean named EmployeeRepository in deployment unit deployment "3c82ea4b-5638-4902-8896-cbc08ed6895e.war" are as follows:

java:global/3c82ea4b-5638-4902-8896-cbc08ed6895e/EmployeeRepository!org.wildfly.samples.javaee7.arquillian.EmployeeRepository

java:app/3c82ea4b-5638-4902-8896-cbc08ed6895e/EmployeeRepository!org.wildfly.samples.javaee7.arquillian.EmployeeRepository

java:module/EmployeeRepository!org.wildfly.samples.javaee7.arquillian.EmployeeRepository

. . .

13:39:33,622 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) JBAS017506: Undertow 1.0.0.Final stopping

13:39:33,639 INFO [org.jboss.as] (MSC service thread 1-15) JBAS015950: WildFly 8.0.0.Final "WildFly" stopped in 22ms

Results :

Tests run: 6, Failures: 0, Errors: 0, Skipped: 0

“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)

June 25, 2014javaee, techtip, wildflyopenshift, wildflyarungupta

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.

Register for a free OpenShift account.
Login to OpenShift Console.
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:The default application page looks like:
Clone the workspace using the credentials shown for your application.

Delete the generated “src” directory and copy the “src” from solution.

javaee7lab&gt; <strong>git rm -rf src</strong>
rm 'src/main/java/.gitkeep'
rm 'src/main/resources/.gitkeep'
rm 'src/main/webapp/images/jbosscorp_logo.png'
rm 'src/main/webapp/index.html'
rm 'src/main/webapp/snoop.jsp'
javaee7lab&gt; <strong>cp -r ~/Downloads/movieplex7/src .</strong>

javaee7lab> git rm -rf src

rm 'src/main/java/.gitkeep'

rm 'src/main/resources/.gitkeep'

rm 'src/main/webapp/images/jbosscorp_logo.png'

rm 'src/main/webapp/index.html'

rm 'src/main/webapp/snoop.jsp'

javaee7lab> cp -r ~/Downloads/movieplex7/src .

Commit and push the changes to restart the cartridge:

javaee7lab&gt; <strong>git add src</strong>
javaee7lab&gt; <strong>git commit src -m"updating source directory with Java EE 7 lab contents"</strong>
[master f6f24ec] updating source directory with Java EE 7 lab contents
 53 files changed, 3955 insertions(+), 584 deletions(-)
 delete mode 100644 src/main/java/.gitkeep
 create mode 100644 src/main/java/org/javaee7/movieplex7/batch/SalesBean.java
 create mode 100644 src/main/java/org/javaee7/movieplex7/batch/SalesProcessor.java
 . . .

 create mode 100644 src/main/webapp/chat/websocket.js
 create mode 100644 src/main/webapp/client/addmovie.xhtml
 create mode 100644 src/main/webapp/client/movie.xhtml
 create mode 100644 src/main/webapp/client/movies.xhtml
 delete mode 100644 src/main/webapp/images/jbosscorp_logo.png
 delete mode 100644 src/main/webapp/index.html
 create mode 100644 src/main/webapp/index.xhtml
 create mode 100644 src/main/webapp/points/points.xhtml
 create mode 100644 src/main/webapp/resources/css/cssLayout.css
 create mode 100644 src/main/webapp/resources/css/default.css
 delete mode 100644 src/main/webapp/snoop.jsp
javaee7lab&gt; <strong>git push</strong>
warning: push.default is unset; its implicit value is changing in
Git 2.0 from 'matching' to 'simple'. To squelch this message
and maintain the current behavior after the default changes, use:

  git config --global push.default matching

To squelch this message and adopt the new behavior now, use:

  git config --global push.default simple

See 'git help config' and search for 'push.default' for further information.
(the 'simple' mode was introduced in Git 1.7.11. Use the similar mode
'current' instead of 'simple' if you sometimes use older versions of Git)

Counting objects: 81, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (65/65), done.
Writing objects: 100% (76/76), 25.06 KiB | 0 bytes/s, done.
Total 76 (delta 38), reused 0 (delta 0)
remote: Stopping wildfly cart
remote: Sending SIGTERM to wildfly:146819 ...
remote: Building git ref 'master', commit f6f24ec
remote: Found pom.xml... attempting to build with 'mvn -e clean package -Popenshift -DskipTests'
remote: Apache Maven 3.0.4 (r1232336; 2012-12-18 14:36:37-0500)
remote: Maven home: /usr/share/java/apache-maven-3.0.4
remote: Java version: 1.7.0_55, vendor: Oracle Corporation
remote: Java home: /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.55/jre
remote: Default locale: en_US, platform encoding: ANSI_X3.4-1968
remote: OS name: "linux", version: "2.6.32-431.20.3.el6.x86_64", arch: "i386", family: "unix"
remote: [INFO] Scanning for projects...
remote: [INFO]                                                                         
remote: [INFO] ------------------------------------------------------------------------
remote: [INFO] Building javaee7lab 1.0
remote: [INFO] ------------------------------------------------------------------------
remote: Downloading: http://mirror1.ops.rhcloud.com/nexus/content/groups/public/org/apache/maven/plugins/maven-clean-plugin/2.4.1/maven-clean-plugin-2.4.1.pom
. . .

remote: Downloaded: http://mirror1.ops.rhcloud.com/nexus/content/groups/public/xpp3/xpp3_min/1.1.4c/xpp3_min-1.1.4c.jar (25 KB at 204.8 KB/sec)
remote: Downloaded: http://mirror1.ops.rhcloud.com/nexus/content/groups/public/org/codehaus/plexus/plexus-utils/3.0.8/plexus-utils-3.0.8.jar (227 KB at 2077.0 KB/sec)
remote: [INFO] Packaging webapp
remote: [INFO] Assembling webapp [javaee7lab] in [/var/lib/openshift/53ab65bee0b8cdf9d1000354/app-root/runtime/repo/target/javaee7lab]
remote: [INFO] Processing war project
remote: [INFO] Copying webapp resources [/var/lib/openshift/53ab65bee0b8cdf9d1000354/app-root/runtime/repo/src/main/webapp]
remote: [INFO] Webapp assembled in [508 msecs]
remote: [INFO] Building war: /var/lib/openshift/53ab65bee0b8cdf9d1000354/app-root/runtime/repo/deployments/ROOT.war
remote: [INFO] ------------------------------------------------------------------------
remote: [INFO] BUILD SUCCESS
remote: [INFO] ------------------------------------------------------------------------
remote: [INFO] Total time: 51.727s
remote: [INFO] Finished at: Wed Jun 25 22:23:46 EDT 2014
remote: [INFO] Final Memory: 10M/152M
remote: [INFO] ------------------------------------------------------------------------
remote: Preparing build for deployment
remote: Deployment id is 026b1012
remote: Activating deployment
remote: Deploying WildFly
remote: Starting wildfly cart
remote: Found 127.11.132.129:8080 listening port
remote: Found 127.11.132.129:9990 listening port
remote: CLIENT_MESSAGE: Could not connect to WildFly management interface, skipping deployment verification
remote: -------------------------
remote: Git Post-Receive Result: success
remote: Activation status: success
remote: Deployment completed with status: success
To ssh://53ab65bee0b8cdf9d1000354@javaee7lab-milestogo.rhcloud.com/~/git/javaee7lab.git/
   75b5640..f6f24ec  master -&gt; master

javaee7lab> git add src

javaee7lab> git commit src -m"updating source directory with Java EE 7 lab contents"

[master f6f24ec] updating source directory with Java EE 7 lab contents

53 files changed, 3955 insertions(+), 584 deletions(-)

delete mode 100644 src/main/java/.gitkeep

create mode 100644 src/main/java/org/javaee7/movieplex7/batch/SalesBean.java

create mode 100644 src/main/java/org/javaee7/movieplex7/batch/SalesProcessor.java

. . .

create mode 100644 src/main/webapp/chat/websocket.js

create mode 100644 src/main/webapp/client/addmovie.xhtml

create mode 100644 src/main/webapp/client/movie.xhtml

create mode 100644 src/main/webapp/client/movies.xhtml

delete mode 100644 src/main/webapp/images/jbosscorp_logo.png

delete mode 100644 src/main/webapp/index.html

create mode 100644 src/main/webapp/index.xhtml

create mode 100644 src/main/webapp/points/points.xhtml

create mode 100644 src/main/webapp/resources/css/cssLayout.css

create mode 100644 src/main/webapp/resources/css/default.css

delete mode 100644 src/main/webapp/snoop.jsp

javaee7lab> git push

warning: push.default is unset; its implicit value is changing in

Git 2.0 from 'matching' to 'simple'. To squelch this message

and maintain the current behavior after the default changes, use:

git config --global push.default matching

To squelch this message and adopt the new behavior now, use:

git config --global push.default simple

See 'git help config' and search for 'push.default' for further information.

(the 'simple' mode was introduced in Git 1.7.11. Use the similar mode

'current' instead of 'simple' if you sometimes use older versions of Git)

Counting objects: 81, done.

Delta compression using up to 8 threads.

Compressing objects: 100% (65/65), done.

Writing objects: 100% (76/76), 25.06 KiB | 0 bytes/s, done.

Total 76 (delta 38), reused 0 (delta 0)

remote: Stopping wildfly cart

remote: Sending SIGTERM to wildfly:146819 ...

remote: Building git ref 'master', commit f6f24ec

remote: Found pom.xml... attempting to build with 'mvn -e clean package -Popenshift -DskipTests'

remote: Apache Maven 3.0.4 (r1232336; 2012-12-18 14:36:37-0500)

remote: Maven home: /usr/share/java/apache-maven-3.0.4

remote: Java version: 1.7.0_55, vendor: Oracle Corporation

remote: Java home: /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.55/jre

remote: Default locale: en_US, platform encoding: ANSI_X3.4-1968

remote: OS name: "linux", version: "2.6.32-431.20.3.el6.x86_64", arch: "i386", family: "unix"

remote: [INFO] Scanning for projects...

remote: [INFO]

remote: [INFO] ------------------------------------------------------------------------

remote: [INFO] Building javaee7lab 1.0

remote: [INFO] ------------------------------------------------------------------------

remote: Downloading: http://mirror1.ops.rhcloud.com/nexus/content/groups/public/org/apache/maven/plugins/maven-clean-plugin/2.4.1/maven-clean-plugin-2.4.1.pom

. . .

remote: Downloaded: http://mirror1.ops.rhcloud.com/nexus/content/groups/public/xpp3/xpp3_min/1.1.4c/xpp3_min-1.1.4c.jar (25 KB at 204.8 KB/sec)

remote: Downloaded: http://mirror1.ops.rhcloud.com/nexus/content/groups/public/org/codehaus/plexus/plexus-utils/3.0.8/plexus-utils-3.0.8.jar (227 KB at 2077.0 KB/sec)

remote: [INFO] Packaging webapp

remote: [INFO] Assembling webapp [javaee7lab] in [/var/lib/openshift/53ab65bee0b8cdf9d1000354/app-root/runtime/repo/target/javaee7lab]

remote: [INFO] Processing war project

remote: [INFO] Copying webapp resources [/var/lib/openshift/53ab65bee0b8cdf9d1000354/app-root/runtime/repo/src/main/webapp]

remote: [INFO] Webapp assembled in [508 msecs]

remote: [INFO] Building war: /var/lib/openshift/53ab65bee0b8cdf9d1000354/app-root/runtime/repo/deployments/ROOT.war

remote: [INFO] ------------------------------------------------------------------------

remote: [INFO] BUILD SUCCESS

remote: [INFO] ------------------------------------------------------------------------

remote: [INFO] Total time: 51.727s

remote: [INFO] Finished at: Wed Jun 25 22:23:46 EDT 2014

remote: [INFO] Final Memory: 10M/152M

remote: [INFO] ------------------------------------------------------------------------

remote: Preparing build for deployment

remote: Deployment id is 026b1012

remote: Activating deployment

remote: Deploying WildFly

remote: Starting wildfly cart

remote: Found 127.11.132.129:8080 listening port

remote: Found 127.11.132.129:9990 listening port

remote: CLIENT_MESSAGE: Could not connect to WildFly management interface, skipping deployment verification

remote: -------------------------

remote: Git Post-Receive Result: success

remote: Activation status: success

remote: Deployment completed with status: success

To ssh://[email protected]/~/git/javaee7lab.git/

75b5640..f6f24ec master -> master

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.

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

June 23, 2014javaee, techtip, wildflycdi, wildflyarungupta

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 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”:

&lt;dependency&gt;
    &lt;groupId&gt;org.apache.deltaspike.core&lt;/groupId&gt;
    &lt;artifactId&gt;deltaspike-core-api&lt;/artifactId&gt;
    &lt;version&gt;${deltaspike.version}&lt;/version&gt;
    &lt;scope&gt;compile&lt;/scope&gt;
&lt;/dependency&gt;

&lt;dependency&gt;
    &lt;groupId&gt;org.apache.deltaspike.core&lt;/groupId&gt;
    &lt;artifactId&gt;deltaspike-core-impl&lt;/artifactId&gt;
    &lt;version&gt;${deltaspike.version}&lt;/version&gt;
    &lt;scope&gt;runtime&lt;/scope&gt;
&lt;/dependency&gt;

<groupId>org.apache.deltaspike.core</groupId>

<artifactId>deltaspike-core-api</artifactId>

<version>${deltaspike.version}</version>

<scope>compile</scope>

</dependency>

<groupId>org.apache.deltaspike.core</groupId>

<artifactId>deltaspike-core-impl</artifactId>

<version>${deltaspike.version}</version>

<scope>runtime</scope>

</dependency>

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:

@Inject @DeltaSpike
private ServletRequest request

@Inject @DeltaSpike

private ServletRequest request

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:

@DeltaSpikeTeam
irc://irc.freenode.net/deltaspike
Mailing lists
Issue Tracker

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

Java EE BoF at DevoxxUK Notes

June 17, 2014conferences, javaeedevoxxukarungupta

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.

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

May 17, 2014javaeejavaee8, jcp, jsrarungupta

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 …

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.

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:

&lt;configuration&gt;
    &lt;stage name=“development”&gt;
        &lt;jms-destination-factory&gt;
            . . .
        &lt;jms-destination-factory&gt;
        &lt;data-source&gt;
            . . .
        &lt;data-source&gt;
        . . .
    &lt;/stage&gt;
    &lt;stage name=“test”&gt;
        . . .
    &lt;/stage&gt;
    &lt;stage name=“production”&gt;
        . . .
    &lt;/stage&gt;
 &lt;/configuration&gt;

<jms-destination-factory>

. . .

<jms-destination-factory>

<data-source>

. . .

<data-source>

. . .

</stage>

. . .

</stage>

. . .

</stage>

</configuration>

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.

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.
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.
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.
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.
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.
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.
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.

A typical EAR file may look like:

META-INF/
META-INF/MANIFEST.MF
EnterpriseApplication1-ejb.jar
  org/javaee8/
  org/javaee8/samples/
  org/javaee8/samples/wildfly/
  org/javaee8/samples/wildfly/MyTestBean.class
EnterpriseApplication1-war.war
  WEB-INF/
  WEB-INF/classes/
  WEB-INF/classes/org/
  WEB-INF/classes/org/javaee8/
  WEB-INF/classes/org/javaee8/samples/
  WEB-INF/classes/org/javaee8/samples/wildfly/
  WEB-INF/classes/org/javaee8/samples/wildfly/MyTestServlet.class
  WEB-INF/lib
  WEB-INF/lib/myLibrary.jar
    META-INF/
    org/
    org/javaee8/
    org/javaee8/samples/
    org/javaee8/samples/wildfly/
    org/javaee8/samples/wildfly/MyLibrary.class
  index.html

META-INF/

META-INF/MANIFEST.MF

EnterpriseApplication1-ejb.jar

org/javaee8/

org/javaee8/samples/

org/javaee8/samples/wildfly/

org/javaee8/samples/wildfly/MyTestBean.class

EnterpriseApplication1-war.war

WEB-INF/

WEB-INF/classes/

WEB-INF/classes/org/

WEB-INF/classes/org/javaee8/

WEB-INF/classes/org/javaee8/samples/

WEB-INF/classes/org/javaee8/samples/wildfly/

WEB-INF/classes/org/javaee8/samples/wildfly/MyTestServlet.class

WEB-INF/lib

WEB-INF/lib/myLibrary.jar

META-INF/

org/

org/javaee8/

org/javaee8/samples/

org/javaee8/samples/wildfly/

org/javaee8/samples/wildfly/MyLibrary.class

index.html

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 ?

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.
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.
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.
CDI events for different stages may be generated. This would allow different parties to listen, and react to them.
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.
Reload of configuration information should be possible, without deploying the archive.
A REST schema of all the configuration information handled by the JSR will really simplify how vendors can easily build custom tools on it.
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 …

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.
+1 on not defining a new archive format and Anatole has explained it well in the blog.
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.
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.

PicketLink: Simplified Security and Identity Management for Java

May 9, 2014javaee, jbossjboss, securityarungupta

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.

Getting Started with WildFly in OpenShift and JBoss Developer Studio (Tech Tip #21)

April 29, 2014javaee, techtip, wildflyeclipse, javaee7, openshift, wildflyarungupta

[Republishing from http://wildfly.org/news/2014/04/25/Getting-Started-WildFly-OpenShift/]

JBoss Developer Studio provide comprehensive tooling around Java EE, HTML5, Mobile, and many other technologies needed for modern web application development. The latest 7.1.1 release provide support for Eclipse Kepler SR2, the latest Eclipse release.

This blog contains a video tutorial that explains how to get started with WildFly in OpenShift and JBoss Developer Studio. Specifically, it shows:

Create an OpenShift application using WildFly cartridge
Access the WildFly administration console using port forwarding
Import the created application in JBoss Developer Studio
Make changes to the application and view them in the deployed application
Add a simple Java EE 7 component to the application

Enjoy!

WildFly 8 Launch Presentations in 40+ JUGs in 6 continents

April 28, 2014java, redhat, wildflycommunity, jugarungupta

40+ Java User Groups from 6 continents have participated in WildFly 8 Launch so far, and a few more are still lined up. This has truly been a global participation so far, and truly reflects the spirit of Java community.

Several of these were delivered virtually primarily using G+ hangout, and then some in person during the travel by WildFly team. Lots of interesting conversations and feedback from developers all around the world, many thanks for that!

Enjoy a collage of the pictures captured so far …

wildfly8-40jugs-apr25

And a complete album available on facebook.com/wildfly

Post by WildFly.

Is your JUG interested in learning all the cool features of WildFly ? Just drop a comment on this blog or ping at @WildFlyAs.

#WeAreOpen

Miles to go 2.0 …

Arun Gupta is a technology enthusiast, avid runner, author of a best-selling book, globe trotter, a community guy, Java Champion, JavaOne Rockstar, JUG Leader, Minecraft Modder, NetBeans Dream Teamer, Devoxx4Kids-er, and a Red Hatter.

Category Archives: java

Log your miles and community runs: Java EE 7 Real World Experience

Java EE 7, JBoss, WildFly, Devoxx4Kids, and Parties at JavaOne 2014

Java EE 6 Sample, with HTML5, jQuery, Hybrid mobile: aka Ticket Monster (Tech Tip #44)

Java EE 7 Javadocs Download, Online, Tutorial, Samples (Tech Tip #42)

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

Defaults in Java EE 7 (Tech Tip #37)

Schedule Java EE 7 Batch Jobs (Tech Tip #36)

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

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

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

Java EE BoF at DevoxxUK Notes

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

PicketLink: Simplified Security and Identity Management for Java

Getting Started with WildFly in OpenShift and JBoss Developer Studio (Tech Tip #21)

WildFly 8 Launch Presentations in 40+ JUGs in 6 continents