# [Maven & Arquillian] Projekt bekanntgeben



## Smoothi (3. Dez 2012)

Hallo,

ich hoff jemand kennt sich mit meiner Problematik aus.

Ich möchte meine Arquillian-Tests in ein separates Maven-Projekt legen. 
Soweit ich weiß, muss ich das Hauptprojekt als Dependency in die pom.xml schreiben. 

Weiß jemand, wie ich das im Detail mache, sodass ich meine CDI-Klassen in das Arquillian-Projekt injizieren kann?


----------



## Smoothi (3. Dez 2012)

ok, habs hinbekommen:

```
<dependency>
	<groupId>[Projektname]</groupId>
	<artifactId>[Projektname]</artifactId>
	<version>0.0.1-SNAPSHOT</version>
</dependency>
```

jetzt brauch ich nur noch eine Möglichkeit, dass das ganze beim Testen deployed wird.


----------



## FArt (4. Dez 2012)

Maven - Introduction to the Dependency Mechanism


----------



## Smoothi (5. Dez 2012)

Danke ersteinmal... aber das hilft mir glaube ich nicht weiter. 

Ich werd mal etwas genauer:

Ich habe 2 Projekte, *bank-swt* (Hauptprojekt) und *arquillian-swt *(enthält nur die Tests)

Die Testprojekt hat folgende pom.xml:
[XML]
<?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>de.java.ArquillianTutorial</groupId>
	<artifactId>arquillian-swt</artifactId>
	<version>1.0-SNAPSHOT</version>
	<packaging>jar</packaging>

	<name>de.java.ArquillianTutorial</name>

	<properties>
		<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
	</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>

	<dependencyManagement>
		<dependencies>
			<dependency>
				<groupId>org.jboss.arquillian</groupId>
				<artifactId>arquillian-bom</artifactId>
				<version>1.0.3.Final</version>
				<scope>import</scope>
				<type>pom</type>
			</dependency>
		</dependencies>
	</dependencyManagement>

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

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

		<dependency>
			<groupId>org.jboss.arquillian.junit</groupId>
			<artifactId>arquillian-junit-container</artifactId>
			<scope>test</scope>
		</dependency>

		<dependency>
		    <groupId>org.jboss.arquillian.container</groupId>
		    <artifactId>arquillian-weld-ee-embedded-1.1</artifactId>
		    <version>1.0.0.CR3</version>
		    <scope>test</scope>
		</dependency>

		<dependency>
		    <groupId>org.jboss.weld</groupId>
		    <artifactId>weld-core</artifactId>
		    <version>1.1.5.Final</version>
		    <scope>test</scope>
		</dependency>

		<dependency>
		    <groupId>org.slf4j</groupId>
		    <artifactId>slf4j-simple</artifactId>
		    <version>1.6.4</version>
		    <scope>test</scope>
		</dependency>

		<dependency>
			<groupId>bank-swt</groupId>
			<artifactId>bank-swt</artifactId>
			<version>0.0.1-SNAPSHOT</version>
		</dependency>
	</dependencies>
</project>
[/XML]

die letzte Dependency ist für das Hauptprojekt... was mit der Versionsnummer aufsich hat, versteh ich nicht. Damit geht es aber...

Das Hauptprojekt war zunächst eine normales JavaEE-Projekt und ich habe es in ein Maven-Projekt umgewandelt. An der pom.xml habe ich nichts geändert:
[XML]
<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>bank-swt</groupId>
  <artifactId>bank-swt</artifactId>
  <version>0.0.1-SNAPSHOT</version>
  <build>
    <sourceDirectory>JavaSource</sourceDirectory>
    <testSourceDirectory>Test</testSourceDirectory>
    <resources>
      <resource>
        <directory>JavaSource</directory>
        <excludes>
          <exclude>**/*.java</exclude>
        </excludes>
      </resource>
    </resources>
    <plugins>
      <plugin>
        <artifactId>maven-compiler-plugin</artifactId>
        <version>2.3.2</version>
        <configuration>
          <source>1.6</source>
          <target>1.6</target>
        </configuration>
      </plugin>
    </plugins>
  </build>
</project>
[/XML]

Ich habe also anhand des Arquillian-Tutorials noch folgende Klassen erstellt:

Einen Greeter, der im Hauptprojekt liegt:

```
public class Greeter {
    public void greet(PrintStream to, String name) {
        to.println(createGreeting(name));
    }

    public String createGreeting(String name) {
        return "Hello, " + name + "!";
    }
}
```

und die Testklasse (natürlich im Testprojekt) dazu:

```
@RunWith(Arquillian.class)
public class GreeterTest {

    @Deployment
    public static JavaArchive createDeployment() {
        return ShrinkWrap.create(JavaArchive.class)
            .addClass(Greeter.class)
            .addAsManifestResource(EmptyAsset.INSTANCE, "beans.xml");
    }

    @Inject
    Greeter greeter;

    @Test
    public void should_create_greeting() {
        Assert.assertEquals("Hello, Earthling!",
        greeter.createGreeting("Earthling"));
        greeter.greet(System.out, "Earthling");
    }
}
```

Das Ganze funktioniert wunderbar und der Test wird erfolgreich ausgeführt.

Problem ist, wenn ich beispielsweise eine Crud-Methode testen will:

```
@RunWith(Arquillian.class)
public class CRUDTest {

    @Deployment
    public static JavaArchive createDeployment() {
        return ShrinkWrap.create(JavaArchive.class)
            .addClass(BankCRUD.class)
            .addAsManifestResource(EmptyAsset.INSTANCE, "beans.xml");
    }

    @Inject
    BankCRUD bankCrud;

    @Test
    public void testBank() {
        Bank bank = new Bank();
        bank.setName("Testbank");
        
        bankCrud.save(bank);
    }
}
```
(ein Assert hab ich natürlich noch nicht... ich will den Eintrag ersteinmal auf die Datenbank bekommen)

In Eclipse habe ich eine JBoss.7.1.1-Instance als Server eingerichtet, aber ich bekomm es einfach nicht hin, dass der Test genau da ausgeführt wird und ich auf die Datenbank zugreifen kann.

:/


----------



## FArt (6. Dez 2012)

Was ist der Fehler? Was ist BankCRUD bzw. was soll hier injected werden?

https://docs.jboss.org/author/display/ARQ/Dependency+injection


----------



## Smoothi (6. Dez 2012)

Kurz: Es handelt isch um ein Bankprojekt - Banken anlegen, Konten anlegen, Überweisungen etc...

Die BankCRUD stellt einfach nur CRUD-Methoden zur Verfügung. Zunächst einmal wird von folgender Elternklasse geerbt, da die CRUD-Methoden für jedes Objekt gleich sind.


```
public abstract class AbstractCRUDBean<T extends IEntityBase, E extends EntityManager> implements IAbstractCRUDBean<T, E> {
	private static final long serialVersionUID = 1L;

	abstract E getEntityManager();

	@Override
	public void save(T instance) {
		if (isManaged(instance)) {
			getEntityManager().merge(instance);
		} else {
			getEntityManager().persist(instance);
		}
	}

	public boolean isManaged(T instance) {
		if (instance != null) {
			if (instance.getId() > 0) {
				return true;
			}
		} 
		return false;
	}

	@Override
	public T createInstance() {
		try {
			return getClassType().newInstance();
		} catch (Exception e) {
			Logger.getLogger(AbstractCRUDBean.class.getSimpleName()).log(Level.ERROR, e.getMessage());
		}
		return null;
	}

	@SuppressWarnings("unchecked")
	private Class<T> getClassType() {
		ParameterizedType parameterizedType = (ParameterizedType) getClass().getGenericSuperclass();
		return (Class<T>) parameterizedType.getActualTypeArguments()[0];
	}
}
```
(habe ein paar Methoden der übersichthalber weggelassen.

Die BankCRUD selber sieht so aus:

```
@Stateful
public class BankCRUD extends AbstractCRUDBean<Bank, EntityManager>{
	private static final long serialVersionUID = 1L;
	
	@PersistenceContext(type=PersistenceContextType.EXTENDED)
	private EntityManager entityManager;
	
	@Override
	public EntityManager getEntityManager() {
		return entityManager;
	}
}
```

Ich lege also eine Bank-Entity an und speicher diese in der Datenbank. Die Ganze CDI-Sache funktioniert in der Hauptanwendung schon (die größtenteils fertig ist).

Wie gesagt, das Problem liegt dabei, dass die Tests derzeit lokal aufgerufen werden. Mit dem Greeter geht das, da dieser nur eine Ausgabe an die Konsole enthält. Für die CRUD-Funktionen benötige ich aber die Verbindung zu meiner PostGres-Datenbank. Also muss das Hauptprojekt und das Testprojekt beim Testen auf den Server deployed und dann ausgeführt werden....und das bekomm ich nicht hin. :/


----------



## FArt (6. Dez 2012)

Die Antwort wäre also gewesen, dass es sich um ein SFSB handelt und du nicht weißt, wie du mit Arquillian die Datasource bzw. den persistent Layer konfigurierst, richtig?

Das sollte helfen:
Testing Java Persistence · Arquillian Guides

Wenn ich mir dein SFSB so anschaue, drängt sich mir der Verdacht auf, dass das Design hier suboptimal ist.

Warum benötigst du ein SFSB? Die sollte man so weit es geht vermeiden. 
Die Ableitung (zusammen mit den generischen Anteilen) kommt mir auch ein wenig ... seltsam vor. Ich kenne das gesamt Design natürlich nicht, aber auch hier würde ich mal ein Review empfehlen.

Kleinigkeiten: Der Klassenname BankCRUD ist ... unschön. Die UID auch...


----------



## Smoothi (6. Dez 2012)

Das SFSB benötige ich wegen dem LazyLoading von Hibernate. Hatte erst ein SLSB und keinen Extended-PersC und das erschien mir performanter als den FetchType auf EAGER zu setzen. 

Die Architektur könnte noch etwas überarbeitet werden. Sollte aber im Großen und Ganzen passen - bzw. bekam ich das sowieso mehr oder weniger etwas vorgeschrieben. Wieso, weshalb, warum würde jetzt etwas ausarten. 

Die Benennung find ich auch noch nicht optimal, werde ich nach den Tests aber erst ändern, weil ich damit fertig werden muss (Bachelorarbeit, wird ein Lehrprojekt fürs Masterstudium). Ein bißchen Refactoring sollte dann nicht das Problem sein. Konnte mich mit meinem Prof aber noch nicht wirklich einigen wie die Dinger sinnvoll heißen sollen. DAO wollte er nicht 

Naja und die UID ist automatisch generiert von Eclipse.

Aber wie gesagt... Optimierung mach ich zum Schluss. Wenn ich das mit dem Testen hinbekomme, ist der Rest nicht mehr schlimm. 

Ich schau mal ob mir das hilft..Danke erstmal


----------



## FArt (6. Dez 2012)

Ich antworte mal prinzipiell auf die Aussagen. 



Smoothi hat gesagt.:


> Das SFSB benötige ich wegen dem LazyLoading von Hibernate. Hatte erst ein SLSB und keinen Extended-PersC und das erschien mir performanter als den FetchType auf EAGER zu setzen.


Schlechter Ansatz. Ein SFSB, welches man vermeiden sollte wo möglich, verwenden, um ein offzielles Feature einer gebräuchlichen API nicht zu verwenden, weil man vermutet, dass es so besser ist.... aua.

Der erste Ansatz sollte der mit dem guten Design sein. Danach gibt es noch Möglichkeiten der Konfiguration (Hibernate oder DB). Danach kann man, wenn man bewiesenermaßen damit Probleme hat, davon abweichen. Aber nur nachdem man das Problem analysiert und eine passende Lösung gefunden hat.



Smoothi hat gesagt.:


> Die Architektur könnte noch etwas überarbeitet werden. Sollte aber im Großen und Ganzen passen - bzw. bekam ich das sowieso mehr oder weniger etwas vorgeschrieben. Wieso, weshalb, warum würde jetzt etwas ausarten.


Das kommt im wahren Leben auch vor. Ist aber dennoch diskussionswürdig (das würde ich von einem Mitarbeiter erwarten, denn der sollte mitdenken).



Smoothi hat gesagt.:


> Die Benennung find ich auch noch nicht optimal, werde ich nach den Tests aber erst ändern, weil ich damit fertig werden muss (Bachelorarbeit, wird ein Lehrprojekt fürs Masterstudium). Ein bißchen Refactoring sollte dann nicht das Problem sein. Konnte mich mit meinem Prof aber noch nicht wirklich einigen wie die Dinger sinnvoll heißen sollen. DAO wollte er nicht


Mein Prof hätte so was angemeckert. Die Software überprüfen ist nicht so einfach. Der Name einer Klasse fällt aber sofort ins Auge. Im wahren Leben liest man mehr fremden Code, als man Code schreibt. Da sind sinnvolle Klassennamen wichtig.



Smoothi hat gesagt.:


> Naja und die UID ist automatisch generiert von Eclipse.


Andere IDEs generieren hier die UID, die auch das Javatool anhand der Signatur berechnen würde.



Smoothi hat gesagt.:


> Aber wie gesagt... Optimierung mach ich zum Schluss. Wenn ich das mit dem Testen hinbekomme, ist der Rest nicht mehr schlimm.


Optimierungen sollte man auch am Schluss machen.



Smoothi hat gesagt.:


> Ich schau mal ob mir das hilft..Danke erstmal


Bitte.


----------



## Smoothi (6. Dez 2012)

FArt hat gesagt.:


> Ich antworte mal prinzipiell auf die Aussagen.
> 
> Schlechter Ansatz. Ein SFSB, welches man vermeiden sollte wo möglich, verwenden, um ein offzielles Feature einer gebräuchlichen API nicht zu verwenden, weil man vermutet, dass es so besser ist.... aua.
> 
> Der erste Ansatz sollte der mit dem guten Design sein. Danach gibt es noch Möglichkeiten der Konfiguration (Hibernate oder DB). Danach kann man, wenn man bewiesenermaßen damit Probleme hat, davon abweichen. Aber nur nachdem man das Problem analysiert und eine passende Lösung gefunden hat.



Nein nein... ganz so ist es nicht. Ich musste nur das Teil erstmal zum Laufen haben, damit ich weiter machen kann. Darüber mach ich mir zum Schluss nochmal Gedanken. Aber kann mich zwischendrin nicht ewig damit aufhalten. 

Diesbezüglich hatte ich mit meinem Prof genug Diskussionen. Die aktuelle Lösung habe ich von einem JavaTrainer und sollte ich erstmal so belassen.



FArt hat gesagt.:


> Das kommt im wahren Leben auch vor. Ist aber dennoch diskussionswürdig (das würde ich von einem Mitarbeiter erwarten, denn der sollte mitdenken).
> 
> Mein Prof hätte so was angemeckert. Die Software überprüfen ist nicht so einfach. Der Name einer Klasse fällt aber sofort ins Auge. Im wahren Leben liest man mehr fremden Code, als man Code schreibt. Da sind sinnvolle Klassennamen wichtig.



Auch hier gab es ewige Diskussionen. Im Großen- und Ganzen habe ich aber den Standardweg genommen. Sprich Daten-Schicht, DAO-Schicht, Service-Schicht, Präsentations-Schicht... Diese abstrakte Klasse find ich dennoch ziemlich übersichtlich. 

Am Ende muss ich mich trotzdem nach dem Wunsch des Kunden (in dem Fall mein Prof) richten. Trotzdem lass ich nichts unkommentiert. 

Wie gesagt...die Optimierung mach ich zum Schluss...das heißt auch hier und da mal eine Bezeichnung ändern.


----------



## Smoothi (7. Dez 2012)

Alsooooo 

ich bin durchaus weiter gekommen. 
Die Lösung der Seite hatte mich nicht direkt zum Ziel geführt, aber durch verschiedene Lösungen kam ich dem Ziel zumindest schonmal näher.

Es sieht nun wie folgt aus:

pom.xml
[XML]
<?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>de.java.arquillian</groupId>
	<artifactId>arquillian-swt</artifactId>
	<version>0.0.1-SNAPSHOT</version>

	<name>Arquillian-Projekt</name>

	<properties>
		<arquillian.version>1.0.3.Final</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>

  	<dependencyManagement>
        <dependencies>
            <dependency>
                <groupId>org.jboss.arquillian</groupId>
                <artifactId>arquillian-bom</artifactId>
                <version>${arquillian.version}</version>
                <scope>import</scope>
                <type>pom</type>
            </dependency>
        </dependencies>
    </dependencyManagement>

	<repositories>
		<repository>
			<id>jboss-public-repository</id>
			<name>JBoss Repository</name>
			<url>https://repository.jboss.org/nexus/content/groups/public</url>
			<releases>
				<updatePolicy>never</updatePolicy>
			</releases>
			<snapshots>
				<updatePolicy>daily</updatePolicy>
			</snapshots>
		</repository>

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

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

		<dependency>
			<groupId>org.jboss.arquillian.junit</groupId>
			<artifactId>arquillian-junit-container</artifactId>
			<scope>test</scope>
		</dependency>
	</dependencies>

	<profiles>
		<profile>
			<id>jbossas-remote-7</id>
			<dependencies>
		        <dependency>
		            <groupId>org.jboss.spec</groupId>
		            <artifactId>jboss-javaee-6.0</artifactId>
		            <version>1.0.0.Final</version>
		            <type>pom</type>
		            <scope>provided</scope>
		        </dependency>

		        <dependency>
		        	<groupId>org.jboss.as</groupId>
		        	<artifactId>jboss-as-arquillian-container-remote</artifactId>
		        	<version>7.1.1.Final</version>
		        </dependency>
			</dependencies>
		</profile>
	</profiles>
</project>
[/XML]

dann habe ich eine XML angelegt: src/test/resources/arquillian.xml
[XML]
<?xml version="1.0" encoding="UTF-8"?>
<arquillian xmlns="http://jboss.org/schema/arquillian"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://jboss.org/schema/arquillian http://jboss.org/schema/arquillian/arquillian_1_0.xsd">
	<engine>
		<property name="deploymentExportPath">target</property>
	</engine>

	<container qualifier="jbossas-remote-7" default="true">
		<configuration>
			<property name="providerUrl">localhost:80</property>
		</configuration>
	</container>
</arquillian>
[/XML]

und: src/main/resources/META-INF/persistence.xml
[XML]
<persistence xmlns="http://java.sun.com/xml/ns/persistence"  
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"  
             xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd"  
             version="2.0">  
	<persistence-unit name="BankUnit" transaction-type="JTA">
		<provider>org.hibernate.ejb.HibernatePersistence</provider>

		<!-- Datenquelle ist PostGres -->
		<jta-data-source>java:jboss/datasources/PostgresDS</jta-data-source> 

		<properties>				
			<property name="hibernate.dialect" value="org.hibernate.dialect.PostgreSQLDialect"/>
			<property name="hibernate.hbm2ddl.auto" value="update"/>
			<property name="hibernate.show_sql" value="false"/>
			<property name="hibernate.format_sql" value="false"/>
			<property name="hibernate.use_sql_comments" value="false"/>
			<property name="hibernate.archive.autodetection" value="class"/>
		</properties>
	</persistence-unit>
</persistence>
[/XML]

Inhaltlich ist die selbe Persistence.xml nochmal im Hauptprojekt. Anscheinend ist es nicht ganz so einfach eine zentrale Datei zu verwenden wenn man 2 separate Projekte hat...damit will ich mich jetzt aber auch nicht aufhalten.

Nochmal zur Erinnerung mein kleiner Greeter-Test:

```
@RunWith(Arquillian.class)
public class GreeterTest {

    @Deployment
    public static JavaArchive createDeployment() {
        return ShrinkWrap.create(JavaArchive.class, "test.jar")
        	   .addClass(Greeter.class)
        	   .addAsManifestResource(EmptyAsset.INSTANCE, "beans.xml");
    }

    @Inject
    Greeter greeter;

    @Test
    public void should_create_greeting() {
        Assert.assertEquals("Hello, Earthling!",
        greeter.createGreeting("Earthling"));
        greeter.greet(System.out, "Earthling");
    }
}
```

Dieser wird jetzt auf den Server deployed (insofern der läuft) und erfolgreich ausgeführt. *freu

Nun habe ich noch einen kleinen PersistenceTest geschrieben.

```
@RunWith(Arquillian.class)
public class PersistenceTest {
    @Deployment
    public static Archive<?> createDeployment() {
        return ShrinkWrap.create(WebArchive.class, "test.war")
        	   .addPackage(Bank.class.getPackage())
        	   .addAsManifestResource(EmptyAsset.INSTANCE, "beans.xml")
        	   .addAsManifestResource("META-INF/persistence.xml", 
        			   ArchivePaths.create("persistence.xml"))
        	   .addAsManifestResource(EmptyAsset.INSTANCE, 
        			   ArchivePaths.create("ejb-jar.xml"));
    }
    
    @PersistenceContext(unitName="BankUnit")
    EntityManager em;
    
    @Inject
    UserTransaction utx;
    
    @Test
    public void testPersist() throws Exception {
    	Bank bank = new Bank();
    	bank.setName("Testbank");
    	bank.setSortCode(12345);
    	
    	utx.begin();
    	em.persist(bank);
    	utx.commit();
    	
    	Bank pBank = em.find(Bank.class, bank.getId());
    	assertNotNull(pBank);
    }
}
```

Leider klappt der noch nicht... bei 
	
	
	
	





```
utx.begin();
```
 wirft er eine NullPointerException.


----------



## Nogothrim (9. Dez 2012)

du bist da doch in einer JTA Umgebung, da is eigentlich nix mit UserTransaction injecten und von Hand committen.


----------



## Smoothi (9. Dez 2012)

ok,  aber wenn ich die UserTransaction rausnehme, wirft er die NullPointerException beim em.persist();

EDIT:
ich hab jetzt noch eine Testklasse geschrieben, in der auf den EM in den CRUD-Objekten zugegriffen wird:

```
@RunWith(Arquillian.class)
public class CrudTest {
    @Deployment
    public static Archive<?> createDeployment() {
        return ShrinkWrap.create(WebArchive.class, "crudTest.war")
        	   .addClasses(Bank.class, BankCRUD.class)
        	   .addAsManifestResource(EmptyAsset.INSTANCE, "beans.xml")
        	   .addAsManifestResource("META-INF/persistence.xml", 
        			   ArchivePaths.create("persistence.xml"))
        	   .addAsManifestResource(EmptyAsset.INSTANCE, 
        			   ArchivePaths.create("ejb-jar.xml"));
    }
    
    @Inject
    BankCRUD bankCrud;
    
    @Test
    public void testPersist() throws Exception {
    	Bank bank = new Bank();
    	bank.setName("Testbank");
    	bank.setSortCode(12345);
    	
    	bankCrud.save(bank);
    	
    	Bank pBank = bankCrud.loadInstance(bank.getId());
    	assertNotNull(pBank);
    }
 }
```

dabei kommt folgendes:

```
org.jboss.arquillian.container.spi.client.container.DeploymentException: Could not deploy to container: {"JBAS014671: Failed services" => {"jboss.deployment.unit.\"crudTest.war\".POST_MODULE" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"crudTest.war\".POST_MODULE: Failed to process phase POST_MODULE of deployment \"crudTest.war\""}}
	at org.jboss.as.arquillian.container.ArchiveDeployer.deploy(ArchiveDeployer.java:74)
	at org.jboss.as.arquillian.container.CommonDeployableContainer.deploy(CommonDeployableContainer.java:148)
	at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:161)
	at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:128)
	at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.executeOperation(ContainerDeployController.java:271)
	at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deploy(ContainerDeployController.java:127)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
	at java.lang.reflect.Method.invoke(Unknown Source)
	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
	at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
	at ...
```

bei den anderen Testklassen klappts ja auch :/

EDIT2:
Mein GreeterTest klappt zwar nur, wenn der Server läuft, andererseits ist es aber egal, was ich in der arquillian.xml eintrage... ich versteh das alles nicht... -.-

Es wird sogar deployed, wenn ich die arquillian.xml komplett weglasse


----------

