Help

The goal of this blog post is to walk you through an Java EE 6 application from a simple, static web page until we have a full blown stack that consist of the stuff in the list below. I'm calling this stack Summer because after a long, hard winter Spring may be nice but boy, wait until Summer kicks in ;-)

  • CDI (Weld)
  • JSF 2 (facelets, ICEfaces 2)
  • JPA 2 (Hibernate, Envers)
  • EJB 3.1 (no-local-view, asynchronous, singletons, scheduling)
  • Bean Validation (Hibernate Validator)
  • JMS (MDB)
  • JAX-RS (RESTEasy)
  • JAX-WS
  • Arqullian (incontainer-AS6)

We will pack all this in a single WAR. Just because we can (spoiler: in part IV). Noticed that apart from the component and testing frameworks, they are all standards? That's a lot of stuff. Fortunately, the appserver already provides most of the stuff so you're app will still be reasonably small.

As for the environment I'm using

  • Eclipse (Galileo SR2)
  • JBoss 6.0 M3
  • Maven 3 (beta1)
  • Sun JDK 6
  • m2eclipse 0.10

This will not be your typical blog post where everything goes well - we will hit bugs. There will be curses, blood and guts and drama and we will do workarounds and rewrites as we move along. Pretty much the same as your average day as a software developer probably looks like. I'm also no expert in the technologies I use here so there are probably things that could be done better. Consider this more of a write-down of my experiences in EE6-land that will probably mirror what others are going through. I will also not point you to links or additional information, I assume that if I say RESTEasy, you can google up more information if you are interested.

And I almost forgot: don't panic.

In the beginning: Project setup

So, lets start things off - go and download the stuff mentioned in the environment if you don't already have it. I'm not going to insult your intelligense by walking you through that (remind me to insult it later). Besides, it's pretty straightforward.

Let's make a new Maven project (File -> New -> Project... -> Maven -> Maven Project. We skip the archetype selection and just make a simple project with group id com.acme, artifact id Greetings of version 1.0.0-SNAPSHOT packed as a WAR. Now finish the wizard and now you should have a nice, perfect project. It will never be this perfect again as our next step is adding code to it.

Maven tip-of-the-day for Windows users. Google up on how you change the path to your local repo as it might be somewhere under Documents And Settings which has two effects: classpath gets huge and there could be problems due to the spaces. Change it to something like c:\java\m2repo

The first thing we notice that m2eclipse has J2SE-1.4 as default. How 2002. Besides, that will make using annotations impossible so lets change that. Edit the pom.xml and throw in

<build>
	<plugins>
		<plugin>
			<groupId>org.apache.maven.plugins</groupId>
			<artifactId>maven-compiler-plugin</artifactId>
			<version>2.3.1</version>
			<configuration>
				<source>1.6</source>
				<target>1.6</target>
			</configuration>
		</plugin>
	</plugins>
</build>

Save and right-click the project root and go Maven -> Update Project Configuration. Aah, that's better

JSF

Let's wake up JSF. We create a folder WEB-INF in src/main/webapp and throw in a web.xml because no web app is complete without it (enforced by the maven war plugin). OK, actually this can be configured in the plugin but let's keep the web.xml since we'll need it later.

<?xml version="1.0" encoding="ISO-8859-1"?>
<web-app version="3.0" xmlns="http://java.sun.com/xml/ns/javaee"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"/>

and an empty faces-config.xml next to it

<faces-config xmlns="http://java.sun.com/xml/ns/javaee"
              xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
              xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-facesconfig_2_0.xsd"
              version="2.0"/>

and in webapp we add a greeting.xhtml like

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
	xmlns:h="http://java.sun.com/jsf/html"
	xmlns:ui="http://java.sun.com/jsf/facelets">
	<h:head>
		<title>
			Greetings
		</title>
	</h:head>

	<h:body>
		<h:outputText value="Hello world"/>
	</h:body>
</html>

Will it blend? I mean, will it deploy? Do a mvn clean package and you should have a Greetings-1.0.0-SNAPSHOT in your projects target directory. Throw it into the AS server/default/deploy directory and start up the server and go to

http://localhost:8080/Greetings-1.0.0-SNAPSHOT/faces/greetings.xhtml

The url is not pretty, but the server port, web context root, welcome files and JSF mappings can all be tuned later, let's focus on technologies and dependencies for now. But wait - at which point did we define the JSF servlet and mappings in web.xml? We didn't. It's automagic for JSF-enabled applications.

EJB and CDI

Next step is bringing in some backing beans, let's outsource our greeting. We make a stateless EJB and use it in CDI

package com.acme.greetings;

@Stateful
@Model
public class GreetingBean 
{
	public String getGreeting()
	{
		return "Hello world";
	}
}

The @Stateful defines a stateful session EJB (3.1 since it's a POJO) and the @Model is a CDI stereotype that is @RequestScoped and @Named (which means the lifecycle is bound to a single HTTP request and it has a name that can be referenced in EL and defaults to greetingBean in this case). But we have a problem - the annotations don't resolve to anything. So we need to pick them up from somewhere(tm). Fortunately we can have all the APIs picked up for us by adding the following to our pom.xml

<dependencies>
	<dependency>
		<groupId>org.jboss.spec</groupId>
		<artifactId>jboss-javaee-6.0</artifactId>
		<version>1.0.0.Beta4</version>
		<type>pom</type>
		<scope>provided</scope>
	</dependency>
</dependencies>

Sun Java API artifacts are a bit amusing since getting hold of them can be a bit tricky. First they publish them in the JSR:s and then they treat them like they're top secret. Fortunately Glassfish and now JBoss have started making them available in their repositories (although under their own artifact names, but still)...

We also need to make sure we have set up the JBoss repositories for this according to http://community.jboss.org/wiki/MavenGettingStarted-Users. Have a look at what happened in the projects Maven Dependencies. Good. Now close it and back away. It's getting hairy in there so better trust Maven to keep track of the deps from now on.

The imports should now be available in our bean so we import

import javax.ejb.Stateful;
import javax.enterprise.inject.Model;

and EL-hook the bean up with

<h:body>
	<h:outputText value="#{greetingBean.greeting}"/>
</h:body>

in greetings.xhtml.

Just as no web application is complete without web.xml, no CDI application is complete without beans.xml. Let's add it to WEB-INF

<?xml version="1.0" encoding="ISO-8859-1"?>
<beans xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="
      http://java.sun.com/xml/ns/javaee 
      http://java.sun.com/xml/ns/javaee/beans_1_0.xsd" />

Package and redeploy. We get a warning about encoding when compiling so lets add this to our pom.xml

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

Back to http://localhost:8080/Greetings-1.0.0-SNAPSHOT/faces/greetings.xhtml SUCCESS! No. Wait. Huge stack trace hits you for 300 points of damage. Let's back up on our EJB, there are still some issues with 3.1 style EJBs in WAR-only-packaging on AS 6 M3. Remove the @Stateful annotation and it becomes a normal CDI managed POJO. Repackage. Redploy. Recoyce.

Testing

Testing is hip nowadays so let's bring in Arquillian. Arquillian is the latest and greatest in EE testing (embedded or incontainer). Start using it now. In a year or so when everone else catch up you can go I've been using it since Alpha. Add the following property to pom.xml:

<arquillian.version>1.0.0.Alpha2</arquillian.version>

and these deps

<dependency>
	<groupId>org.jboss.arquillian</groupId>
	<artifactId>arquillian-junit</artifactId>
	<version>${arquillian.version}</version>
	<scope>test</scope>
</dependency>
<dependency>
	<groupId>junit</groupId>
	<artifactId>junit</artifactId>
	<version>4.8.1</version>
	<scope>test</scope>
</dependency>

and this profile

<profiles>	
	<profile>
		<id>jbossas-local-60</id>
		<dependencies>
			<dependency>
				<groupId>org.jboss.arquillian.container</groupId>
				<artifactId>arquillian-jbossas-local-60</artifactId>
				<version>1.0.0.Alpha2</version>
			</dependency>
			<dependency>
				<groupId>org.jboss.jbossas</groupId>
				<artifactId>jboss-server-manager</artifactId>
				<version>1.0.3.GA</version>
			</dependency>
			<dependency>
				<groupId>org.jboss.jbossas</groupId>
				<artifactId>jboss-as-client</artifactId>
				<version>6.0.0.20100429-M3</version>
				<type>pom</type>
			</dependency>
		</dependencies>
	</profile>
</profiles>

Maven will probably now download the entire internet for you.

Let's write our first test and place it in the test source folder:

package com.acme.greetings.test;

import javax.inject.Inject;

import org.jboss.arquillian.api.Deployment;
import org.jboss.arquillian.junit.Arquillian;
import org.jboss.shrinkwrap.api.ArchivePaths;
import org.jboss.shrinkwrap.api.ShrinkWrap;
import org.jboss.shrinkwrap.api.spec.JavaArchive;
import org.jboss.shrinkwrap.impl.base.asset.ByteArrayAsset;
import org.junit.Assert;
import org.junit.Test;
import org.junit.runner.RunWith;

import com.acme.greetings.GreetingBean;

@RunWith(Arquillian.class)
public class GreetingTest 
{
	@Inject
	GreetingBean greetingBean;

	@Deployment
	public static JavaArchive createTestArchive() 
	{
		return ShrinkWrap.create("test.jar", JavaArchive.class).addClass(
				GreetingBean.class).addManifestResource(
				new ByteArrayAsset("<beans/>".getBytes()),
				ArchivePaths.create("beans.xml"));
	}

	@Test
	public void testInjection() 
	{
		Assert.assertEquals("Hello World", greetingBean.getGreeting());
	}

}

and then we try it out with mvn test -Pjbossas-local-60. If we have the AS running we can save some time, otherwise the manager will start it automagically. Setting the JBOSS_HOME env helps. What happens here is we use Shrinkwrap to create a deployment which consist of our GreetingBean and an empty beans.xml file (for CDI) and the bean is then injected for use in our tests.

This concludes Part I. In part II we will set up ICEfaces and expand our application and in part III we'll set up JPA. Part IV is for MDB and EJB and part V for adding JAX-RS and JAX-WS for importing and exporting stuff.

32 comments:
 
05. Jun 2010, 16:12 CET | Link
seb

Is there no better way to define a stateless bean? Using @Stateful for something that should be stateless seems strange..

 
05. Jun 2010, 16:51 CET | Link
seb wrote on Jun 05, 2010 10:12:
Is there no better way to define a stateless bean? Using @Stateful for something that should be stateless seems strange..

Sure, I was merely demonstrating the @Model on an EJB at this point (and that's a @Named @RequestScoped that couldn't co-exist on a stateless EJB)...

 
05. Jun 2010, 19:57 CET | Link

You may also run AS as Embedded (in the same JVM as the test) to take advantage of pass-by-reference, shared concurrency locks, etc. Check out the configuration profile jbossas-embedded-60 in:

http://anonsvn.jboss.org/repos/common/arquillian/tags/1.0.0.Alpha2/examples/junit/pom.xml

S, ALR

 
06. Jun 2010, 10:04 CET | Link
Sakuraba | saku(AT)raba.jp
play new my-app

done. ;)

 
06. Jun 2010, 11:47 CET | Link
Sakuraba wrote on Jun 06, 2010 04:04:
play new my-app
done. ;)

No raining on my EE parade, please. Sure, scala-type training wheels are convenient until you want to take them off and notice they are welded (no pun intended) to the structure and you can't ;-)

 
06. Jun 2010, 15:17 CET | Link

Hello Nicklas,

thank you very much for your great tutorial. It helped alot, someone should put this directly at the Weld/Seam page!!!

I have one addition. It seems m2eclipse does not work well when figuring out the JDK. For me, the information you provided in installing the maven-compiler plugin and setting source and target are not enough. It still complains about not finding the right JDK and falling back to 1.4. I debugged m2eclipse and found out, that with the current code base it can only work, if in addition to the configuration a valid execution and at least one goal is set, like in the following example. It is weired that this problem seems to happen for me only, but if I add it this way, it works perfectly:

<build>
        <plugins>
                <plugin>
                        <groupId>org.apache.maven.plugins</groupId>
                        <artifactId>maven-compiler-plugin</artifactId>
                        <version>2.3.1</version>
                        <configuration>
                                <source>1.6</source>
                                <target>1.6</target>
                        </configuration>
                        <executions>
                            <execution>
                                <id>default</id>
                                <goals>
                                        <goal>
                                                compile
                                        </goal>
                                </goals>
                            </execution>
                        </executions>
                </plugin>
        </plugins>
</build>

The code in the plugin only continues to search for source and target for all executions and goals, but if there are none set, it simply ignores this.

Best regards,

Heiko

 
06. Jun 2010, 17:06 CET | Link
Markus Meine

Hello Nicklas,

I'm having trouble following your tutorial, because I'm unsure which repositories contain the artifacts you use. I currently use the maven central as well as the jboss repository. However, it seems the Arquillian JUnit version 1.0.0.Alpha2 is not included. Have you a hint for me to find out why?

Best regards,

Markus

 
06. Jun 2010, 19:53 CET | Link
Grzegorz Grzybek | gr.grzybek(AT)gmail.com

Hello

I'm only wondering why:

<dependencies>
	<dependency>
		<groupId>org.jboss.spec</groupId>
		<artifactId>jboss-javaee-6.0</artifactId>
		<version>1.0.0.Beta4</version>
		<type>pom</type>
		<scope>provided</scope>
	</dependency>
</dependencies>

and not

<groupId>javax</groupId>
<artifactId>javaee-api</artifactId>

?

That's what I don't like about JavaEE 6. It is standard, however everyone has its own maven artifacts and sources of standard APIs.

The most important (for me) specification is Java Servlets. With pre JEE6 there was

<groupId>javax.servlet</groupId>
<artifactId>servlet-api</artifactId>
<version>2.5</version>

However - for Servlets 3.0 there is ...

<groupId>org.glassfish</groupId>
<artifactId>javax.servlet</artifactId>
<version>3.0</version>

And don't tell me that javax:javaee-api:6.0 has it all. I don't want to depend on all JEE6 just to write a Servlets 3.0 based application.

I just hope that JBoss will not create its own org.jboss:javax.servlet:3.0 artifact... I respect JBoss for its contribution into JEE6 - just please add more order into it

regards Grzegorz Grzybek

 
06. Jun 2010, 21:02 CET | Link
Andon

Your howto is cool! Thank you. All the best tech out there. Only glitch I see is using junit instead of testgn. See why testng rocks http://www.mkyong.com/unittest/junit-4-vs-testng-comparison/

 
06. Jun 2010, 21:49 CET | Link
Markus Meine wrote on Jun 06, 2010 11:06:
I'm having trouble following your tutorial, because I'm unsure which repositories contain the artifacts you use. I currently use the maven central as well as the jboss repository. However, it seems the Arquillian JUnit version 1.0.0.Alpha2 is not included. Have you a hint for me to find out why?

Please use the instructions from http://community.jboss.org/wiki/MavenGettingStarted-Users (as hinted in the blog)

 
06. Jun 2010, 21:52 CET | Link
That's what I don't like about JavaEE 6. It is standard, however everyone has its own maven artifacts and sources of standard APIs.

I'm with you on this one. Personally, I think a part of a spec going final would be to post the apis under a standard name to the central repositories. Perhaps someone with more insight (political or technical) could enlighten us in this matter?

 
06. Jun 2010, 21:54 CET | Link
Your howto is cool! Thank you. All the best tech out there. Only glitch I see is using junit instead of testgn. See why testng rocks http://www.mkyong.com/unittest/junit-4-vs-testng-comparison/

I recall the setup is easier with Arqullian (@RunWith) for JUnit so I went with that. Both work, though. Perhaps some Arqullian-dev can shed some more light on the matter so I don't have to read the refdocs ;-)

 
06. Jun 2010, 23:36 CET | Link
Nicklas Karlsson wrote on Jun 06, 2010 15:52:
That's what I don't like about JavaEE 6. It is standard, however everyone has its own maven artifacts and sources of standard APIs.
I'm with you on this one. Personally, I think a part of a spec going final would be to post the apis under a standard name to the central repositories. Perhaps someone with more insight (political or technical) could enlighten us in this matter?

Yes, we at JBoss totally agree with you Nik and Gregorz - and have been pushing the JCP to add this the exit conditions for a spec. We've also been pushing Sun to put out the relevant javax.xyz spec artifacts to Maven central for all the Java EE 6 specs they are responsible for, but so far, no joy :-( People, email the JCP on this one - as always, more voices lend credibility to our arguments.

We also agree completely that the javax:javae-api isn't that useful (for a start, it breaks a load of stuff because it can't work with an embedded container), and we also think that it's more useful (if you work with a dependency management system like Maven etc.) to have be able to pull in a stack POM for Java EE which in turn transitively depends on the other artifacts (if you look at both the POM Nik mentions, and how we designed the CDI API POM, you can see this at work).

However, I do disagree with Gregorz, that JBoss shouldn't create it's own org.jboss.spec artifacts for Java EE 6. As I've outlined, the javax.xyz artifacts are

  • not being provided by the spec lead for most of the Java EE spec
  • are not being put in Maven central

As the Maven rules allow you to publish to your own namespace, we can't rectify this in the javax. space, leaving the only course of action to be creating the org.jboss.spec group to which we can bring order. Or, to put it another way, we believe that bringing order to the space (far) outweighs the cost of splintering the APIs.

 
07. Jun 2010, 07:00 CET | Link
Grzegorz Grzybek | gr.grzybek(AT)gmail.com

Pete

However, I do disagree with Gregorz, that JBoss shouldn't create it's own org.jboss.spec artifacts for Java EE 6. As I've outlined, the javax.xyz artifacts are ...

Of course you're right - you have no choice because of Sun/Oracle/JCP :)

That's why I look for standard artifacts in JBoss' namespace right after having not found them in javax namespace. However - I just can't wait to see that Hibernate relies on javax.persistence:jpa-api:2.0 instead of org.hibernate.javax.persistence:hibernate-jpa-2.0-api:1.0.0.Final... (just think of it - what's the version? 2.0 or 1.0.0?)

I wish JBoss would do something regarding these real life aspects of JEE...

p.s. and here is some more discussion on this topic: http://www.restfusion.com/blog/2010/02/jee-sdk-loathe-it-or-ignore-it-you-cant-like-it/comment-page-1/#comment-33.

 
07. Jun 2010, 12:13 CET | Link
Grzegorz Grzybek wrote on Jun 07, 2010 01:00:
That's why I look for standard artifacts in JBoss' namespace right after having not found them in javax namespace. However - I just can't wait to see that Hibernate relies on javax.persistence:jpa-api:2.0 instead of org.hibernate.javax.persistence:hibernate-jpa-2.0-api:1.0.0.Final... (just think of it - what's the version? 2.0 or 1.0.0?)

Please, give us a bit of time ;-) We've only started this conversion to a standard set of JBoss spec API artifacts in the last couple of months, and it takes a while to align everything. I'm going to work with Shelly (who is in charge of the API artifacts) on this next week a bit - hopefully we can refine the mission of these artifacts, and let everyone know excatly what our intention is :-)

For example, things I want to get sorted -- get all JBoss projects using them, get them published to Maven central, work out exactly who we target with them, work out how/if they can be used without JBoss AS as the app server.

 
08. Jun 2010, 13:52 CET | Link
Aslak Knutsen | aslak(AT)redhat.com
Only glitch I see is using junit instead of testgn. See why testng rocks http://www.mkyong.com/unittest/junit-4-vs-testng-comparison/

Arquillian work with both TestNG and JUnit, see Arquillian TestNG Examples for how to use it with TestNG.

The TestNG integration Maven artifact is org.jboss.arquillian:arquillian-testng

 
08. Jun 2010, 18:35 CET | Link
Sten Aksel Heien | sten_aksel(AT)users.sf.net

Great intro to the Summer-stack Nicklas, I'm looking forward to the other parts.

Thanks also to all other JBoss and Glassfish projects and people shaping spec's and giving JavaEE the summer touch - future's bright ... I need my shades ;-)

 
16. Jun 2010, 13:41 CET | Link

First of all, thx for this great tutorial! Now, for the problems... 1) When it comes to test with arquillian, i had to install manually activation.jar and trove.jar. Since you didn't mention that, I wonder if I missed something. 2) After that GreetingTest runs but fails with this message: initializationError(com.acme.greetings.GreetingTest) I guess some injection didn't work, but the message is a bit cryptic, could you give me some hint ?

 
18. Jun 2010, 22:29 CET | Link
Jocelyn wrote on Jun 16, 2010 07:41:
First of all, thx for this great tutorial! Now, for the problems... 1) When it comes to test with arquillian, i had to install manually activation.jar and trove.jar. Since you didn't mention that, I wonder if I missed something. 2) After that GreetingTest runs but fails with this message: initializationError(com.acme.greetings.GreetingTest) I guess some injection didn't work, but the message is a bit cryptic, could you give me some hint ?

Hmm, all transitive dependencies should be available from the same set of repositories, are you sure it wasn't a temporary glitch? Have a look at the output in the surefire target dirs (and the AS logs if it gets that far)

 
23. Jun 2010, 18:23 CET | Link
Jocelyn wrote on Jun 16, 2010 07:41:
First of all, thx for this great tutorial! Now, for the problems... 1) When it comes to test with arquillian, i had to install manually activation.jar and trove.jar. Since you didn't mention that, I wonder if I missed something. 2) After that GreetingTest runs but fails with this message: initializationError(com.acme.greetings.GreetingTest) I guess some injection didn't work, but the message is a bit cryptic, could you give me some hint ?

Did you try excluding trove? At least it worked for me...

<dependency>
    <groupId>org.jboss.jbossas</groupId>
    <artifactId>jboss-as-client</artifactId>
    <version>6.0.0.20100429-M3</version>
    <type>pom</type>
    <exclusions>
        <exclusion>
            <groupId>trove</groupId>
            <artifactId>trove</artifactId>
        </exclusion>
    </exclusions>
</dependency>
 
08. Jul 2010, 20:00 CET | Link
Tom

These posts are great, but leave me wondering something. I'm trying to get up to speed with the state of Java EE and I'm finding it very difficult since so many pre-existing libraries have been standardized, at least partially, so please forgive me if this question seems odd:

If someone needs a stable platform upon which to develop new enterprise apps today, is it not reasonable to use most of the technologies you mention (Mojarra JSF 2.0, Weld (JSR 330 CDI), Seam 2.2, Hibernate 3.5 for JPA 2.0, and Hibernate Validator (JSR 303)) and deploy them on JBoss AS 5.1.0?

It seems this would give you 90% of JEE6 on a stable JEE5 AS, would it not? Would there be conflicts when you try to update the code to JEE6 in a few months?

All responses are appreciated :)

 
19. Jul 2010, 08:36 CET | Link
If someone needs a stable platform upon which to develop new enterprise apps today, is it not reasonable to use most of the technologies you mention (Mojarra JSF 2.0, Weld (JSR 330 CDI), Seam 2.2, Hibernate 3.5 for JPA 2.0, and Hibernate Validator (JSR 303)) and deploy them on JBoss AS 5.1.0? It seems this would give you 90% of JEE6 on a stable JEE5 AS, would it not? Would there be conflicts when you try to update the code to JEE6 in a few months?

Most of the stuff is in the category heavy AS integration (Weld deployers etc) and getting those running on 5.1 is... non-trivial. Well, actually impossible for all practical purposes if you don't write large amount of wizardry code.

 
24. Jul 2010, 22:38 CET | Link

Just a note on a problem I was having, you may (or may not) need to set the Arquillian profile dependencies to test scope. It was packaging them in and making JBoss all sorts of confused.

20. Jan 2011, 23:05 CET | Link
Sebastiao

How do the hot deploy with this project? In Add and Remove project I added the project, but is made of only deploy /WEB-INF/classes. ThanksS

22. Jul 2011, 06:06 CET | Link

When I run the tests I get this exception:

java.lang.reflect.UndeclaredThrowableException
        at $Proxy0.invoke(Unknown Source)
        at org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:150)
        at org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcess(SurefireStarter.java:91)
        at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:69)
Caused by: java.lang.reflect.InvocationTargetException
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.apache.maven.surefire.booter.ProviderFactory$ClassLoaderProxy.invoke(ProviderFactory.java:103)
        ... 4 more
Caused by: java.lang.NoClassDefFoundError: org/jboss/shrinkwrap/api/asset/Asset
        at java.lang.Class.getDeclaredMethods0(Native Method)
        at java.lang.Class.privateGetDeclaredMethods(Class.java:2427)
        at java.lang.Class.getMethod0(Class.java:2670)
        at java.lang.Class.getMethod(Class.java:1603)
        at org.apache.maven.surefire.util.ReflectionUtils.tryGetMethod(ReflectionUtils.java:57)
        at org.apache.maven.surefire.common.junit3.JUnit3TestChecker.isSuiteOnly(JUnit3TestChecker.java:65)
        at org.apache.maven.surefire.common.junit3.JUnit3TestChecker.isValidJUnit3Test(JUnit3TestChecker.java:60)
        at org.apache.maven.surefire.common.junit3.JUnit3TestChecker.accept(JUnit3TestChecker.java:55)
        at org.apache.maven.surefire.common.junit4.JUnit4TestChecker.accept(JUnit4TestChecker.java:52)
        at org.apache.maven.surefire.util.DefaultDirectoryScanner.locateTestClasses(DefaultDirectoryScanner.java:80)
        at org.apache.maven.surefire.junit4.JUnit4Provider.scanClassPath(JUnit4Provider.java:164)
        at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:86)
        ... 9 more
Caused by: java.lang.ClassNotFoundException: org.jboss.shrinkwrap.api.asset.Asset
        at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
        at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:247)

Here's my POM file:

<?xml version="1.0" encoding="UTF-8"?>
<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/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <groupId>hitchhiker-jee6</groupId>
    <artifactId>hitchhiker-jee6</artifactId>
    <version>1.0</version>
    <packaging>war</packaging>

    <properties>
        <arquillian.version>1.0.0.Alpha2</arquillian.version>
    </properties>

    <build>
        <plugins>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-compiler-plugin</artifactId>
                <version>2.3.2</version>
                <configuration>
                    <source>1.6</source>
                    <target>1.6</target>
                </configuration>
            </plugin>
        </plugins>
    </build>

    <dependencies>
        <dependency>
            <groupId>org.jboss.spec</groupId>
            <artifactId>jboss-javaee-6.0</artifactId>
            <version>1.0.0.Beta4</version>
            <type>pom</type>
            <scope>provided</scope>
        </dependency>

        <dependency>
            <groupId>org.jboss.arquillian</groupId>
            <artifactId>arquillian-junit</artifactId>
            <version>${arquillian.version}</version>
            <scope>test</scope>
        </dependency>

        <dependency>
            <groupId>junit</groupId>
            <artifactId>junit</artifactId>
            <version>4.8.1</version>
            <scope>test</scope>
        </dependency>
    </dependencies>

    <profiles>
        <profile>
            <id>jbossas-local-60</id>
            <dependencies>
                <dependency>
                    <groupId>org.jboss.arquillian.container</groupId>
                    <artifactId>arquillian-jbossas-local-60</artifactId>
                    <version>1.0.0.Alpha2</version>
                </dependency>
                <dependency>
                    <groupId>org.jboss.jbossas</groupId>
                    <artifactId>jboss-server-manager</artifactId>
                    <version>1.0.4.Final</version>
                </dependency>
                <dependency>
                    <groupId>org.jboss.jbossas</groupId>
                    <artifactId>jboss-as-client</artifactId>
                    <version>6.0.0.Final</version>
                    <type>pom</type>
                </dependency>
            </dependencies>
        </profile>
    </profiles>

    <repositories>
        <repository>
            <id>jboss-public-repository-group</id>
            <name>JBoss Public Maven Repository Group</name>
            <url>http://repository.jboss.org/nexus/content/groups/public</url>
            <releases>
                <enabled>true</enabled>
                <updatePolicy>never</updatePolicy>
            </releases>
            <snapshots>
                <enabled>true</enabled>
                <updatePolicy>never</updatePolicy>
            </snapshots>
        </repository>
        <repository>
            <id>jboss-deprecated</id>
            <name>JBoss Deprecated</name>
            <url>https://repository.jboss.org/nexus/content/repositories/deprecated/</url>
            <layout>default</layout>
            <releases>
                <enabled>true</enabled>
                <updatePolicy>never</updatePolicy>
            </releases>
            <snapshots>
                <enabled>false</enabled>
            </snapshots>
        </repository>
    </repositories>

</project>

And I am using Maven 3.

 
22. Jul 2011, 06:08 CET | Link
Chap

I also face the same issue.

 
23. Dec 2013, 09:07 CET | Link

Last week while out to dinner Swiss Replica Watches for Sale I announced to the hubby, ‘We need more candles.’ This was after a trip to, of all places, the bathroom. It had a soft music, a little heater running, and the best smelling candle ever. It was so warm and cozy I was tempted to lock the door and take a little nap. But Cheap Fake Rolex then again, you might have noticed I have a bit of a thing for candles. They are so satisfyingly easy to make – and wrapped in piece of old t-shirt (bonus points if it looks like a peppermint!) they make the perfect hostess gift.

 
21. Jun 2014, 16:14 CET | Link

Although it is a fact that, for a lot of programs, diesel powered, heavy-duty forklift trucks are indispensable, for example on construction sites forklift trucks While Medicare insurance options available usually are meant to profit the seniors with medical costs they cant afford according to earnings, you will find still some gaps in coverage that leaves many senior citizens without the best care possible. insurance provider

 
29. Sep 2014, 04:53 CET | Link
darwin

This election will be an option that many feared by many people. There are so many people como perder peso rapido

 
03. Oct 2014, 04:31 CET | Link

I say thank you to the creator of this article, Pusat Crystal X Asli Nasa Jogja this article contains information that is very helpful for readers smeua especially my own. I'm waiting for the other information that is not less interesting. Good luck to you. visit our website to increase knowledge Crystal X NASA

 
04. Nov 2014, 04:44 CET | Link

Noticed that apart from the component and testing frameworks, they are all standards? That's a lot of stuff. Fortunately, the appserver already provides most of the stuff so you're app will still be reasonably small.