Review of JBoss 7.1.1, JSF 2.0, JPA 2.0, CDI 2.0, Maven 3.0.4, Hibernate, Eclipse & Rackspace

Version 40

Created by perrierax on Feb 27, 2014 10:43 AM. Last modified by perrierax on Feb 27, 2014 10:26 PM.

Overview

For the most part I am personally very comfortable using the JBoss technologies that have matured over the years. Never before have I seen the ability to write Java business applications with such ease and with a well defined and supported persistence engine thanks to the people that have put together open source JBoss, JSF 2.0, JPA 2.0, CDI, Maven, Hibernate based on the lessons learned from previous approaches like J2EE, JSP & JDBC alone. Since the introduction of POET back in the 90's many of us have been looking for a means by which to map objects to a relational database and back again with relatively few complications. It's a technology that saves you a lot of redundancy and my colleagues & I really appreciate not having to spend all our time maintaining huge changes in code just to cover minor changes in evolving business requirements in a typical business enviroment.

That being said...

There seems to be a *glitch* in the current implementation of Maven and EclipseLink that I'd like to point out!

At present I have a web project and my approach to trouble-shooting remotely it is to have the local server and the remote server utilize nearly identical development tools and software. Both servers are using Java based JBoss software and tools as follows;

Technologies employed:

Ubuntu 12.04.04 LTS (64bit)

Linux ubuntu 3.11.0-15-generic #25~precise1-Ubuntu SMP Thu Jan 30 17:39:31 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux (workstation)

Linux osiris-01 3.2.0-58-generic #88-Ubuntu SMP Tue Dec 3 17:37:58 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux (server)

OpenJDK Runtime Environment (IcedTea6 1.12.6) (6b27-1.12.6-1ubuntu0.12.04.4)

OpenJDK 64-Bit Server VM (build 20.0-b12, mixed mode)

Apache Maven 3.0.4

Maven home: /usr/share/maven

Java version: 1.6.0_27, vendor: Sun Microsystems Inc.

Java home: /usr/lib/jvm/java-6-openjdk-amd64/jre

Default locale: en_US, platform encoding: UTF-8

OS name: "linux", version: "3.11.0-15-generic", arch: "amd64", family: "unix"

mysql Ver 14.14 Distrib 5.5.35, for debian-linux-gnu (x86_64) using readline 6.2

JBoss Bootstrap Environment

JBOSS_HOME: /home/perry/achievagoal/jboss/jboss-as-7.1.1.Final

JAVA: java

JAVA_OPTS: -server -XX:+UseCompressedOops -XX:+TieredCompilation -Xms64m -Xmx1024m -XX:MaxPermSize=256m

-Djava.net.preferIPv4Stack=true -Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true -Djboss.server.default.config=standalone.xml

I'll attach a pom file at the end of this article for trouble shooting purposes.

Description

Here is the *glitch* that has slowed me down for at least two weeks; When I compile locally the persistence.xml file is copied from src/main/java/META-INF directory to the target/classes/META-INF directory compliments the Eclipse environment. If you rely solely on mvn (mvn clean install jboss-as:deploy) alone the persistence.xml file WILL NOT BE COPIED! Simply manually copying the persistence.xml fixes the issue. But it shouldn't be this way.

This is the only difference between the local Eclipse workstation development environment and the remote web site environment and I managed to isolate this *discrepancy* after much trouble-shooting and isolating the problem!

The JBoss server reported this very *obscure* message;

11:59:37,423 INFO [org.jboss.weld.deployer] (MSC service thread 1-2) JBAS016009: Stopping weld service for deployment

as oppose to;

12:07:37,244 INFO [org.jboss.as.jpa] (MSC service thread 1-3) JBAS011401: Read persistence.xml

alerted me to check on the presence of the persistence.xml file (or lack of) between the two environments!

So, I don't know if this is a bug in the mvn software, something that has to be specified in the pom file or anything else. All I know is that this issue has been quite a time consumer. To be so close to a most excellent development experience and cool project with tools like JSF, JPA, CDI and JBoss and to have something like this disable their ability to do their job is an oversight that needs to be corrected. I am quite surprised this has gone unnoticed for so long.

Hot code swapping via a Remote System Development link from inside the Eclipse IDE to the web site is not practical due to bandwidth limitations. So copying the myproject/pom.xml file and ONLY the myproject/src folder up to the server via ftp to recompile via mvn works wonders. As it allows the remote web server to download (via a much higher bandwidth) whatever packages it needs from there before composing a war file to publish to the JBoss server. Rather than me trying to upload all the jar files almost every time back up to web server. The only glitch was mvn not copying the persistence.xml file from the src folder to the target folder for some reason.

Interim Solution:

ssh user@123.456.789.0

rm -rf myproject

mkdir myproject

ftp pom.xml file and src folder ONLY to myproject

cd myproject

mvn clean

mvn install

copy the persistence.xml from the src/main/java/META-INF folder to the target/classes/META-INF folder

mvn jboss-as:deploy

server updated

Special thanks to Francesco Marchioni, Mike Keith and Merrick Schincariol for their most excellent resources on JBoss, JSF 2.0, JPA 2.0, CDI, Maven, Hibernate technologies. Special thanks to Rackspace for their most excellent tools for web server management and their most professional, most knowledgeable and most helpful 24/7 online live chat support.

JBoss AS7 Development

Pro JPA 2

Thanks for listening,

Perry

Perry S. Anderson

Unified Objects Incorporated.

http://www.unifiedobjects.net/

perry.anderson@gmail.com

Ps.

pom file attached;

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

and/or its affiliates, and individual contributors by the @authors tag. See

the copyright.txt in the distribution for a full listing of individual contributors.

Licensed under the Apache License, Version 2.0 (the "License"); you may not

use this file except in compliance with the License. You may obtain a copy

of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required

by applicable law or agreed to in writing, software distributed under the

License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS

OF ANY KIND, either express or implied. See the License for the specific

language governing permissions and limitations under the License. -->

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">

<groupId>com.myproject</groupId>

<artifactId>myproject</artifactId>

<version>0.0.1-SNAPSHOT</version>

<name>myproject</name>

<url>http://maven.apache.org</url>

<id>oss.sonatype.org</id>

<name>OSS Sonatype Staging</name>

<url>https://oss.sonatype.org/content/groups/staging</url>

</repository>

</repositories>

<!-- Explicitly declaring the source encoding eliminates the following

message: -->

<!-- [WARNING] Using platform encoding (UTF-8 actually) to copy filtered

resources, i.e. build is platform dependent! -->

<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>

<version.jboss.bom>1.0.4.Final</version.jboss.bom>

<version.jboss.maven.plugin>7.3.Final</version.jboss.maven.plugin>

<!-- Define the version of the JBoss BOMs we want to import. The JBoss

BOMs specify tested stacks. -->

<!-- Alternatively, comment out the above line, and un-comment the line

below to use version 1.0.0.Final-redhat-1 which is a release certified to

work with JBoss EAP 6. It requires you have access to the JBoss EAP 6 maven

repository. -->

<version.compiler.plugin>2.3.1</version.compiler.plugin>

<version.surefire.plugin>2.4.3</version.surefire.plugin>

<version.war.plugin>2.1.1</version.war.plugin>

<maven.compiler.target>1.6</maven.compiler.target>

<maven.compiler.source>1.6</maven.compiler.source>

<org.richfaces.bom.version>4.1.0.Final</org.richfaces.bom.version>

</properties>

<!-- JBoss distributes a complete set of Java EE 6 APIs including a Bill

of Materials (BOM). A BOM specifies the versions of a "stack" (or a collection)

of artifacts. We use this here so that we always get the correct versions

of artifacts. Here we use the jboss-javaee-6.0-with-tools stack (you can

read this as the JBoss stack of the Java EE 6 APIs, with some extras tools

for your project, such as Arquillian for testing) and the jboss-javaee-6.0-with-hibernate

stack you can read this as the JBoss stack of the Java EE 6 APIs, with extras

from the Hibernate family of projects) -->

<groupId>org.richfaces</groupId>

<artifactId>richfaces-bom</artifactId>

<version>${org.richfaces.bom.version}</version>

<scope>import</scope>

</dependency>

<groupId>org.jboss.bom</groupId>

<artifactId>jboss-javaee-6.0-with-tools</artifactId>

<version>${version.jboss.bom}</version>

<scope>import</scope>

</dependency>

<groupId>org.jboss.bom</groupId>

<artifactId>jboss-javaee-6.0-with-hibernate</artifactId>

<version>${version.jboss.bom}</version>

<scope>import</scope>

</dependency>

<groupId>org.eclipse.persistence</groupId>

<artifactId>eclipselink</artifactId>

<groupId>org.eclipse.persistence</groupId>

<artifactId>commonj.sdo</artifactId>

</exclusion>

</exclusions>

</dependency>

</dependencies>

</dependencyManagement>

<groupId>org.richfaces.ui</groupId>

<artifactId>richfaces-components-ui</artifactId>

</dependency>

<groupId>org.richfaces.core</groupId>

<artifactId>richfaces-core-impl</artifactId>

</dependency>

<!-- Import the CDI API, we use provided scope as the API is included in

JBoss AS 7 -->

<groupId>javax.enterprise</groupId>

<scope>provided</scope>

</dependency>

<!-- Import the Common Annotations API (JSR-250), we use provided scope

as the API is included in JBoss AS 7 -->

<groupId>org.jboss.spec.javax.annotation</groupId>

<artifactId>jboss-annotations-api_1.1_spec</artifactId>

<scope>provided</scope>

</dependency>

<!-- Import the JPA API, we use provided scope as the API is included in

JBoss AS 7 -->

<groupId>org.hibernate.javax.persistence</groupId>

<artifactId>hibernate-jpa-2.0-api</artifactId>

<scope>provided</scope>

</dependency>

<!-- Import the EJB API, we use provided scope as the API is included in

JBoss AS 7 -->

<groupId>org.jboss.spec.javax.ejb</groupId>

<artifactId>jboss-ejb-api_3.1_spec</artifactId>

<scope>provided</scope>

</dependency>

<groupId>org.hibernate</groupId>

<artifactId>hibernate-validator</artifactId>

<scope>provided</scope>

</exclusion>

</exclusions>

</dependency>

<!-- Import the JSF API, we use provided scope as the API is included in

JBoss AS 7 -->

<groupId>org.jboss.spec.javax.faces</groupId>

<artifactId>jboss-jsf-api_2.1_spec</artifactId>

<scope>provided</scope>

</dependency>

<groupId>org.jboss.logging</groupId>

<artifactId>jboss-logging</artifactId>

<version>RELEASE</version>

</dependency>

<!-- Annotation processor to generate the JPA 2.0 metamodel classes for

typesafe criteria queries -->

<groupId>org.hibernate</groupId>

<artifactId>hibernate-jpamodelgen</artifactId>

<scope>provided</scope>

</dependency>

<!-- Annotation processor that raising compilation errors whenever constraint

annotations are incorrectly used. -->

<groupId>org.hibernate</groupId>

<artifactId>hibernate-validator-annotation-processor</artifactId>

<scope>provided</scope>

</dependency>

<groupId>org.hibernate</groupId>

<artifactId>hibernate-core</artifactId>

</dependency>

<groupId>org.eclipse.persistence</groupId>

<artifactId>eclipselink</artifactId>

</dependency>

<groupId>org.eclipse.persistence</groupId>

<artifactId>javax.persistence</artifactId>

</dependency>

</dependency>

</dependencies>

<build>

<!-- Maven will append the version to the finalName (which is the name

given to the generated war, and hence the context root) -->

<finalName>${project.artifactId}</finalName>

<groupId>org.jboss.as.plugins</groupId>

<artifactId>jboss-as-maven-plugin</artifactId>

<version>${version.jboss.maven.plugin}</version>

<filename>${project.build.finalName}.war</filename>

</configuration>

</plugin>

</plugins>

</build>

</project>

JBossDeveloper

Review of JBoss 7.1.1, JSF 2.0, JPA 2.0, CDI 2.0, Maven 3.0.4, Hibernate, Eclipse & Rackspace

Comments