BAEL-150 Introduction to DeltaSpike

This commit is contained in:
Lukasz Rzeszotarski 2016-07-31 18:36:03 +02:00
parent 6bc064d571
commit ca84ed7ff0
3 changed files with 0 additions and 798 deletions

View File

@ -1,695 +0,0 @@
<?xml version="1.0" encoding="UTF-8"?>
<!--
JBoss, Home of Professional Open Source
Copyright 2013, Red Hat, Inc. 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.
-->
<cheatsheet title="CDI + JSF + EJB + JTA + Bean Validation + JAX-RS + Arquillian: baeldung-jee7-seed quickstart">
<intro>
<description>
This quickstart shows off all the new features of Java EE 7, and makes a great starting point for your project.
<br/><br/>
<b>Bean Validation 1.1</b>
<br/><br/>
Bean Validation is an update specification for Java EE 7, inspired by Hibernate Validator. It allows application developers to specify constraints once (often in their domain model), and have them applied in all layers of the application, protecting data and giving useful feedback to users.
<br/><br/>
<b>JAX-RS: The Java API for RESTful Web Services</b>
<br/><br/>
JAX-RS is an update specification for Java EE 7. It allows application developers to easily expose Java services as RESTful web services.
</description>
</intro>
<item
skip="false"
title="The baeldung-jee7-seed example in depth">
<description>
The baeldung-jee7-seed application shows off a number of Java EE technologies such as CDI, JSF, EJB, JTA, JAX-RS and Arquillian.
It does this by providing a member registration database, available via JSF and JAX-RS.
<br/><br/>
As usual, let&apos;s start by looking at the necessary deployment descriptors.
By now, we're very used to seeing <b>beans.xml</b> and <b>faces-config.xml</b> in <b>WEB-INF/</b>
(which can be found in the <b>src/main/webapp</b> directory of the example).
Notice that, once again, we don&apos;t need a web.xml.
There are two configuration files in <b>WEB-INF/classes/META-INF</b>
(which can be found in the <b>src/main/resources</b> directory of the example) — <b>persistence.xml</b>,
which sets up JPA, and <b>import.sql</b> which Hibernate, the JPA provider in WildFly,
will use to load the initial users into the application when the application starts.
We discussed both of these files in detail in The <b>greeter example in depth</b>, and these are largely the same.
</description>
<command
required="true"
returns="currentProject"
serialization="org.jboss.tools.project.examples.cheatsheet.getProjectForCheatsheet"/>
</item>
<item
title="default.xhtml">
<description>
Next, let&apos;s take a look at the JSF view the user sees. As usual, we use a template to provide the sidebar and footer. This one lives in <b>WEB-INF/templates/default.xhtml</b>:
</description>
<subitem
label="We have a common &lt;head&gt; element, where we define styles and more. "
skip="true">
<command
required="false"
serialization="org.jboss.tools.project.examples.cheatsheet.openFileInEditor(path=/${currentProject}/src/main/webapp/WEB-INF/templates/default.xhtml,fromLine=22,toLine=26)"/>
</subitem>
<subitem
label="This application defines a common sidebar, putting them in the template means we only have to define them once."
skip="true">
<command
required="false"
serialization="org.jboss.tools.project.examples.cheatsheet.openFileInEditor(path=/${currentProject}/src/main/webapp/WEB-INF/templates/default.xhtml,fromLine=37,toLine=46)"/>
</subitem>
<subitem
label="and a common footer... "
skip="true">
<command
required="false"
serialization="org.jboss.tools.project.examples.cheatsheet.openFileInEditor(path=/${currentProject}/src/main/webapp/WEB-INF/templates/default.xhtml,fromLine=47,toLine=52)"/>
</subitem>
<subitem
label="The content is inserted here, and defined by views using this template. "
skip="true">
<command
required="false"
serialization="org.jboss.tools.project.examples.cheatsheet.openFileInEditor(path=/${currentProject}/src/main/webapp/WEB-INF/templates/default.xhtml,fromLine=32,toLine=36)"/>
</subitem>
</item>
<item
title="index.xhtml">
<description>
That leaves the main page, index.xhtml, in which we place the content unique to the main page:
</description>
<subitem
label="The JSF form allows us to register new users. There should be one already created when the application started."
skip="true">
<command
required="false"
serialization="org.jboss.tools.project.examples.cheatsheet.openFileInEditor(path=/${currentProject}/src/main/webapp/index.xhtml,fromLine=33,toLine=62)"/>
</subitem>
<subitem
label="The application uses Bean Validation to validate data entry. The error messages from Bean Validation are automatically attached to the relevant field by JSF, and adding a messages JSF component will display them."
skip="true">
</subitem>
<subitem
label="Name validation">
<command
required="false"
serialization="org.jboss.tools.project.examples.cheatsheet.openFileInEditor(path=/${currentProject}/src/main/webapp/index.xhtml,fromLine=39,toLine=40)"/>
</subitem>
<subitem
label="Email validation"
skip="true">
<command
required="false"
serialization="org.jboss.tools.project.examples.cheatsheet.openFileInEditor(path=/${currentProject}/src/main/webapp/index.xhtml,fromLine=43,toLine=44)"/>
</subitem>
<subitem
label="Phone number validation"
skip="true">
<command
required="false"
serialization="org.jboss.tools.project.examples.cheatsheet.openFileInEditor(path=/${currentProject}/src/main/webapp/index.xhtml,fromLine=47,toLine=49)"/>
</subitem>
<subitem
label="This application exposes REST endpoints for each registered member. The application helpfully displays the URL to the REST endpoint on this page. "
skip="true">
<command
required="false"
serialization="org.jboss.tools.project.examples.cheatsheet.openFileInEditor(path=/${currentProject}/src/main/webapp/index.xhtml,fromLine=86,toLine=90)"/>
</subitem>
</item>
<item
skip="true"
title="Member.java">
<description>
Next, let&apos;s take a look at the Member entity, before we look at how the application is wired together:
</description>
<subitem
label="As usual with JPA, we define that the class is an entity by adding @Entity"
skip="true">
<command
required="false"
serialization="org.jboss.tools.project.examples.cheatsheet.openFileInEditor(path=/${currentProject}/src/main/java/baeldung/model/Member.java,fromLine=37)"/>
</subitem>
<subitem
label="Members are exposed as a RESTful service using JAX-RS. We can use JAXB to map the object to XML and to do this we need to add @XmlRootElement."
skip="true">
<command
required="false"
serialization="org.jboss.tools.project.examples.cheatsheet.openFileInEditor(path=/${currentProject}/src/main/java/baeldung/model/Member.java,fromLine=38)"/>
</subitem>
<subitem
label="Bean Validation allows constraints to be defined once (on the entity) and applied everywhere. Here we constrain the person's name to a certain size and regular expression. "
skip="true">
<command
required="false"
serialization="org.jboss.tools.project.examples.cheatsheet.openFileInEditor(path=/${currentProject}/src/main/java/baeldung/model/Member.java,fromLine=46,toLine=48)"/>
</subitem>
<subitem
label="Hibernate Validator also offers some extra validations such as @Email. "
skip="true">
<command
required="false"
serialization="org.jboss.tools.project.examples.cheatsheet.openFileInEditor(path=/${currentProject}/src/main/java/baeldung/model/Member.java,fromLine=53,toLine=53)"/>
</subitem>
<subitem
label="@Digits, @NotNull and @Size are further examples of constraints. "
skip="true">
<command
required="false"
serialization="org.jboss.tools.project.examples.cheatsheet.openFileInEditor(path=/${currentProject}/src/main/java/baeldung/model/Member.java,fromLine=56,toLine=58)"/>
</subitem>
</item>
<item
skip="true"
title="MemberRepository.java">
<description>
Let&apos;s take a look at MemberRepository, which is responsible for interactions with the persistence layer:
</description>
<subitem
label="The bean is application scoped, as it is a singleton."
skip="true">
<command
required="false"
serialization="org.jboss.tools.project.examples.cheatsheet.openFileInEditor(path=/${currentProject}/src/main/java/baeldung/data/MemberRepository.java,fromLine=29)"/>
</subitem>
<subitem
label="The entity manager is injected, to allow interaction with JPA."
skip="true">
<command
required="false"
serialization="org.jboss.tools.project.examples.cheatsheet.openFileInEditor(path=/${currentProject}/src/main/java/baeldung/data/MemberRepository.java,fromLine=32)"/>
</subitem>
<subitem
label="The JPA criteria api is used to load a member by his or her unique identifier, email address."
skip="true">
<command
required="false"
serialization="org.jboss.tools.project.examples.cheatsheet.openFileInEditor(path=/${currentProject}/src/main/java/baeldung/data/MemberRepository.java,fromLine=40,toLine=47)"/>
</subitem>
<subitem
label="The criteria api can also be used to load lists of entities ."
skip="true">
<command
required="false"
serialization="org.jboss.tools.project.examples.cheatsheet.openFileInEditor(path=/${currentProject}/src/main/java/baeldung/data/MemberRepository.java,fromLine=51,toLine=58)"/>
</subitem>
</item>
<item
skip="true"
title="MemberListProducer.java">
<description>
Next, let&apos;s take a look at MemberListProducer, which is responsible for building the list of members, ordered by name. It uses JPA 2 criteria to do this.
</description>
<subitem
label="This bean is request scoped, meaning that any fields (such as members) will be stored for the entire request."
skip="true">
<command
required="false"
serialization="org.jboss.tools.project.examples.cheatsheet.openFileInEditor(path=/${currentProject}/src/main/java/baeldung/data/MemberListProducer.java,fromLine=30)"/>
</subitem>
<subitem
label="The MemberRepository is responsible for interactions with the persistence layer"
skip="true">
<command
required="false"
serialization="org.jboss.tools.project.examples.cheatsheet.openFileInEditor(path=/${currentProject}/src/main/java/baeldung/data/MemberListProducer.java,fromLine=33,toLine=34)"/>
</subitem>
<subitem
label="The list of members is exposed as a producer method. It's also available via EL. "
skip="true">
<command
required="false"
serialization="org.jboss.tools.project.examples.cheatsheet.openFileInEditor(path=/${currentProject}/src/main/java/baeldung/data/MemberListProducer.java,fromLine=40,toLine=41)"/>
</subitem>
<subitem
label="The observer method is notified whenever a member is created, removed, or updated. This allows us to refresh the list of members whenever they are needed. This is a good approach as it allows us to cache the list of members, but keep it up to date at the same time."
skip="true">
<command
required="false"
serialization="org.jboss.tools.project.examples.cheatsheet.openFileInEditor(path=/${currentProject}/src/main/java/baeldung/data/MemberListProducer.java,fromLine=46,toLine=48)"/>
</subitem>
</item>
<item
skip="true"
title="MemberRegistration.java">
<description>
Let&apos;s now look at MemberRegistration, the class that allows us to create new members from the JSF page
</description>
<subitem
label="This bean requires transactions as it needs to write to the database. Making this an EJB gives us access to declarative transactions - much simpler than manual transaction control! "
skip="true">
<command
required="false"
serialization="org.jboss.tools.project.examples.cheatsheet.openFileInEditor(path=/${currentProject}/src/main/java/baeldung/service/MemberRegistration.java,fromLine=28)"/>
</subitem>
<subitem
label="Here we inject a JDK logger, defined in the Resources class."
skip="true">
<command
required="false"
serialization="org.jboss.tools.project.examples.cheatsheet.openFileInEditor(path=/${currentProject}/src/main/java/baeldung/service/MemberRegistration.java,fromLine=31)"/>
</subitem>
<subitem
label="An event is sent every time a member is updated. This allows other pieces of code (in this quickstart the member list is refreshed) to react to changes in the member list without any coupling to this class. "
skip="true">
<command
required="false"
serialization="org.jboss.tools.project.examples.cheatsheet.openFileInEditor(path=/${currentProject}/src/main/java/baeldung/service/MemberRegistration.java,fromLine=43)"/>
</subitem>
</item>
<item
skip="true"
title="Resources.java">
<description>
Now, let's take a look at the Resources class, which provides resources such as the entity manager. CDI recommends using "resource producers", as we do in this example, to alias resources to CDI beans, allowing for a consistent style throughout our application:
</description>
<subitem
label="We use the 'resource producer' pattern, from CDI, to 'alias' the old fashioned @PersistenceContext injection of the entity manager to a CDI style injection. This allows us to use a consistent injection style (@Inject) throughout the application. "
skip="true">
<command
required="false"
serialization="org.jboss.tools.project.examples.cheatsheet.openFileInEditor(path=/${currentProject}/src/main/java/baeldung/util/Resources.java,fromLine=43)"/>
</subitem>
<subitem
label="We expose a JDK logger for injection. In order to save a bit more boiler plate, we automatically set the logger category as the class name! "
skip="true">
<command
required="false"
serialization="org.jboss.tools.project.examples.cheatsheet.openFileInEditor(path=/${currentProject}/src/main/java/baeldung/util/Resources.java,fromLine=47)"/>
</subitem>
<subitem
label="We expose the FacesContext via a producer method, which allows it to be injected. If we were adding tests, we could also then mock it out."
skip="true">
<command
required="false"
serialization="org.jboss.tools.project.examples.cheatsheet.openFileInEditor(path=/${currentProject}/src/main/java/baeldung/util/Resources.java,fromLine=52)"/>
</subitem>
<subitem
label="If you want to define your own datasource, take a look at the Administration Guide for WildFly"
skip="true">
<command
required="false"
serialization="org.eclipse.ui.browser.openBrowser(url=https://docs.jboss.org/author/display/WFLY8/Admin+Guide#AdminGuide-DatasourceDefinitions/)"/>
</subitem>
</item>
<item
skip="true"
title="MemberController.java">
<description>
Of course, we need to allow JSF to interact with the services. The MemberController class is responsible for this:
</description>
<subitem
label="The MemberController class uses the @Model stereotype, which adds @Named and @RequestScoped to the class. "
skip="true">
<command
required="false"
serialization="org.jboss.tools.project.examples.cheatsheet.openFileInEditor(path=/${currentProject}/src/main/java/baeldung/controller/MemberController.java,fromLine=34)"/>
</subitem>
<subitem
label="The FacesContext is injected, so that messages can be sent to the user."
skip="true">
<command
required="false"
serialization="org.jboss.tools.project.examples.cheatsheet.openFileInEditor(path=/${currentProject}/src/main/java/baeldung/controller/MemberController.java,fromLine=37)"/>
</subitem>
<subitem
label="The MemberRegistration bean is injected, to allow the controller to interact with the database."
skip="true">
<command
required="false"
serialization="org.jboss.tools.project.examples.cheatsheet.openFileInEditor(path=/${currentProject}/src/main/java/baeldung/controller/MemberController.java,fromLine=40)"/>
</subitem>
<subitem
label="The Member class is exposed using a named producer field, which allows access from JSF. Note that the named producer field has dependent scope, so every time it is injected, the field will be read "
skip="true">
<command
required="false"
serialization="org.jboss.tools.project.examples.cheatsheet.openFileInEditor(path=/${currentProject}/src/main/java/baeldung/controller/MemberController.java,fromLine=43,toLine=45)"/>
</subitem>
<subitem
label="The @PostConstruct annotation causes a new member object to be placed in the newMember field when the bean is instantiated."
skip="true">
<command
required="false"
serialization="org.jboss.tools.project.examples.cheatsheet.openFileInEditor(path=/${currentProject}/src/main/java/baeldung/controller/MemberController.java,fromLine=47)"/>
</subitem>
<subitem
label="When the register method is called, the newMember object is passed to the persistence service."
skip="true">
<command
required="false"
serialization="org.jboss.tools.project.examples.cheatsheet.openFileInEditor(path=/${currentProject}/src/main/java/baeldung/controller/MemberController.java,fromLine=54)"/>
</subitem>
<subitem
label="We also send a message to the user, to give them feedback on their actions."
skip="true">
<command
required="false"
serialization="org.jboss.tools.project.examples.cheatsheet.openFileInEditor(path=/${currentProject}/src/main/java/baeldung/controller/MemberController.java,fromLine=56)"/>
</subitem>
<subitem
label="Finally, we replace the newMember with a new object, thus blanking out the data the user has added so far. This works as the producer field is dependent scoped."
skip="true">
<command
required="false"
serialization="org.jboss.tools.project.examples.cheatsheet.openFileInEditor(path=/${currentProject}/src/main/java/baeldung/controller/MemberController.java,fromLine=57)"/>
</subitem>
</item>
<item
skip="true"
title="JAX-RS">
<description>
Before we wrap up our tour of the baeldung-jee7-seed example application,
let&apos;s take a look at how the JAX-RS endpoints are created. Firstly, {<b>JaxRSActivator</b>}},
which extends <b>Application</b> and is annotated with <b>@ApplicationPath</b>,
is the Java EE 6 <b>no XML</b> approach to activating JAX-RS.
</description>
<subitem
label="JaxRsActivator.java"
skip="true">
<command
required="false"
serialization="org.jboss.tools.project.examples.cheatsheet.openFileInEditor(path=/${currentProject}/src/main/java/baeldung/rest/JaxRsActivator.java,fromLine=30, toLine=33)"/>
</subitem>
</item>
<item
skip="true"
title="MemberResourceRESTService.java">
<description>
The real work goes in MemberResourceRESTService, which produces the endpoint:
</description>
<subitem
label="The @Path annotation tells JAX-RS that this class provides a REST endpoint mapped to rest/members (concatenating the path from the activator with the path for this endpoint). "
skip="true">
<command
required="false"
serialization="org.jboss.tools.project.examples.cheatsheet.openFileInEditor(path=/${currentProject}/src/main/java/baeldung/rest/MemberResourceRESTService.java,fromLine=52)"/>
</subitem>
<subitem
label="The bean is request scoped, as JAX-RS interactions typically don&apos;t hold state between requests."
skip="true">
<command
required="false"
serialization="org.jboss.tools.project.examples.cheatsheet.openFileInEditor(path=/${currentProject}/src/main/java/baeldung/rest/MemberResourceRESTService.java,fromLine=53)"/>
</subitem>
<subitem
label="JAX-RS endpoints are CDI enabled, and can use CDI-style injection. "
skip="true">
<command
required="false"
serialization="org.jboss.tools.project.examples.cheatsheet.openFileInEditor(path=/${currentProject}/src/main/java/baeldung/rest/MemberResourceRESTService.java,fromLine=56)"/>
</subitem>
<subitem
label="CDI allows us to inject a Bean Validation Validator instance, which is used to validate the POSTed member before it is persisted."
skip="true">
<command
required="false"
serialization="org.jboss.tools.project.examples.cheatsheet.openFileInEditor(path=/${currentProject}/src/main/java/baeldung/rest/MemberResourceRESTService.java,fromLine=59)"/>
</subitem>
<subitem
label="MemberRepository is injected to allow us to query the member database "
skip="true">
<command
required="false"
serialization="org.jboss.tools.project.examples.cheatsheet.openFileInEditor(path=/${currentProject}/src/main/java/baeldung/rest/MemberResourceRESTService.java,fromLine=62)"/>
</subitem>
<subitem
label="MemberRegistration is injected to allow us to alter the member database."
skip="true">
<command
required="false"
serialization="org.jboss.tools.project.examples.cheatsheet.openFileInEditor(path=/${currentProject}/src/main/java/baeldung/rest/MemberResourceRESTService.java,fromLine=65)"/>
</subitem>
<subitem
label="The listAllMembers() method is called when the raw endpoint is accessed and offers up a list of endpoints. Notice that the object is automatically marshalled to JSON by RESTEasy (the JAX-RS implementation included in WildFly)."
skip="true">
<command
required="false"
serialization="org.jboss.tools.project.examples.cheatsheet.openFileInEditor(path=/${currentProject}/src/main/java/baeldung/rest/MemberResourceRESTService.java,fromLine=68,toLine=72)"/>
</subitem>
<subitem
label="The lookupMemberById() method is called when the endpoint is accessed with a member id parameter appended (for example rest/members/1). Again, the object is automatically marshalled to JSON by RESTEasy."
skip="true">
<command
required="false"
serialization="org.jboss.tools.project.examples.cheatsheet.openFileInEditor(path=/${currentProject}/src/main/java/baeldung/rest/MemberResourceRESTService.java,fromLine=74,toLine=83)"/>
</subitem>
<subitem
label="createMember() is called when a POST is performed on the URL. Once again, the object is automatically unmarshalled from JSON."
skip="true">
<command
required="false"
serialization="org.jboss.tools.project.examples.cheatsheet.openFileInEditor(path=/${currentProject}/src/main/java/baeldung/rest/MemberResourceRESTService.java,fromLine=89,toLine=120)"/>
</subitem>
<subitem
label="In order to ensure that the member is valid, we call the validateMember method, which validates the object, and adds any constraint violations to the response. These can then be handled on the client side, and displayed to the user."
skip="true">
<command
required="false"
serialization="org.jboss.tools.project.examples.cheatsheet.openFileInEditor(path=/${currentProject}/src/main/java/baeldung/rest/MemberResourceRESTService.java,fromLine=136,toLine=148)"/>
</subitem>
<subitem
label="The object is then passed to the MemberRegistration service to be persisted."
skip="true">
<command
required="false"
serialization="org.jboss.tools.project.examples.cheatsheet.openFileInEditor(path=/${currentProject}/src/main/java/baeldung/rest/MemberResourceRESTService.java,fromLine=100)"/>
</subitem>
<subitem
label="We then handle any remaining issues with validating the object, which are raised when the object is persisted."
skip="true">
<command
required="false"
serialization="org.jboss.tools.project.examples.cheatsheet.openFileInEditor(path=/${currentProject}/src/main/java/baeldung/rest/MemberResourceRESTService.java,fromLine=104,toLine=117)"/>
</subitem>
</item>
<item
skip="true"
title="Run and deploy the application">
<description>
Right-click the project and select <b>Run As</b> &gt; <b>Run On Server</b> or click on the &quot;Click to Perform&quot; link below.
</description>
<!-- the runOnServer command is not implemented yet
<command
required="false"
serialization="org.jboss.tools.project.examples.cheatsheet.actions.runOnServer(project=${currentProject})"/>
-->
<action
pluginId="org.jboss.tools.project.examples.cheatsheet"
class="org.jboss.tools.project.examples.cheatsheet.actions.RunOnServer"
param1="${currentProject}"/>
</item>
<item
skip="true"
title="Arquillian">
<description>
If you&apos;ve been following along with the Test Driven Development craze of the past few years,
you&apos;re probably getting a bit nervous by now, wondering how on earth you are going to test your application.
Lucky for you, the Arquillian project is here to help!
<br/><br/>
Arquillian provides all the boiler plate for running your test inside WildFly,
allowing you to concentrate on testing your application.
In order to do that, it utilizes Shrinkwrap, a fluent API for defining packaging,
to create an archive to deploy.
We'll go through the testcase, and how you configure Arquillian in just a moment,
but first let's run the test.
</description>
</item>
<item
skip="true"
title="Start Arquillian tests">
<description>
Arquillian defines two modes, managed and remote.
The managed mode will take care of starting and stopping the server for you,
while the remote mode connects to an already running server.
<br/><br/>
The following action starts the test in the <b>remote</b> mode because you have started the server in the previous step.
<br/>
Right-click the project, select <b>Properties&gt;Maven</b> and
enter <b>arq-jbossas-remote</b> to the <b>Active Maven Profile</b> field.
After that, right-click the project and select <b>Run As&gt;JUnit test</b>.
</description>
<!-- the launchJUnitTest command is not implemented yey
<command
required="false"
serialization="org.jboss.tools.project.examples.cheatsheet.actions.launchJUnitTest(project=${currentProject}, activateProfile=arq-wildfly-remote)"/>
-->
<action
pluginId="org.jboss.tools.project.examples.cheatsheet"
class="org.jboss.tools.project.examples.cheatsheet.actions.LaunchJUnitTest"
param1="${currentProject}"
param2="arq-wildfly-remote"/>
</item>
<item
skip="true"
title="MemberRegistrationTest.java">
<description>
So far so good, the test is running. But what does the test look like?
</description>
<subitem
label="@RunWith(Arquillian.class) tells JUnit to hand control over to Arquillian when executing tests."
skip="true">
<command
required="false"
serialization="org.jboss.tools.project.examples.cheatsheet.openFileInEditor(path=/${currentProject}/src/test/java/baeldung/test/MemberRegistrationTest.java,fromLine=37)"/>
</subitem>
<subitem
label="The @Deployment annotation identifies the createTestArchive static method to Arquillian as the one to use to determine which resources and classes to deploy "
skip="true">
<command
required="false"
serialization="org.jboss.tools.project.examples.cheatsheet.openFileInEditor(path=/${currentProject}/src/test/java/baeldung/test/MemberRegistrationTest.java,fromLine=39)"/>
</subitem>
<subitem
label="We add just the classes needed for the test, no more "
skip="true">
<command
required="false"
serialization="org.jboss.tools.project.examples.cheatsheet.openFileInEditor(path=/${currentProject}/src/test/java/baeldung/test/MemberRegistrationTest.java,fromLine=42)"/>
</subitem>
<subitem
label="We also add persistence.xml as our test is going to use the database "
skip="true">
<command
required="false"
serialization="org.jboss.tools.project.examples.cheatsheet.openFileInEditor(path=/${currentProject}/src/test/java/baeldung/test/MemberRegistrationTest.java,fromLine=43)"/>
</subitem>
<subitem
label="Of course, we must add beans.xml to enable CDI."
skip="true">
<command
required="false"
serialization="org.jboss.tools.project.examples.cheatsheet.openFileInEditor(path=/${currentProject}/src/test/java/baeldung/test/MemberRegistrationTest.java,fromLine=44)"/>
</subitem>
<subitem
label="Finally, we add a test datasource, so that test data doesn&apos;t overwrite production data."
skip="true">
<command
required="false"
serialization="org.jboss.tools.project.examples.cheatsheet.openFileInEditor(path=/${currentProject}/src/test/java/baeldung/test/MemberRegistrationTest.java,fromLine=46)"/>
</subitem>
<subitem
label="Arquillian allows us to inject beans into the test case."
skip="true">
<command
required="false"
serialization="org.jboss.tools.project.examples.cheatsheet.openFileInEditor(path=/${currentProject}/src/test/java/baeldung/test/MemberRegistrationTest.java,fromLine=49,toLine=50)"/>
</subitem>
<subitem
label="The test method works as you would expect - creates a new member, registers them, and then verifies that the member was created "
skip="true">
<command
required="false"
serialization="org.jboss.tools.project.examples.cheatsheet.openFileInEditor(path=/${currentProject}/src/test/java/baeldung/test/MemberRegistrationTest.java,fromLine=55,toLine=64)"/>
</subitem>
</item>
<item
skip="true"
title="arquillian.xml">
<description>
As you can see, Arquillian has lived up to the promise - the test case is focused on what to test
(the @Deployment method) and how to test (the @Test method).
It&apos;s also worth noting that this isn&apos;t a simplistic unit test - this is a fully fledged integration
test that uses the database.
<br/><br/>
Now, let&apos;s look at how we configure Arquillian.
First of all, let&apos;s take a look at <b>arquillian.xml</b> in <b>src/test/resources</b>.
</description>
<subitem
label="Arquillian deploys the test war to WildFly, and doesn't write it to disk. For debugging, it can be very useful to see exactly what is in your war, so Arquillian allows you to export the war when the tests runs "
skip="true">
<command
required="false"
serialization="org.jboss.tools.project.examples.cheatsheet.openFileInEditor(path=/${currentProject}/src/test/resources/arquillian.xml)"/>
</subitem>
</item>
<item
skip="true"
title="pom.xml">
<description>
Now, we need to look at how we select between containers in the pom.xml:
</description>
<subitem
label="The profile needs an id so we can activate from Eclipse or the command line "
skip="true">
<command
required="false"
serialization="org.jboss.tools.project.examples.cheatsheet.openFileInEditor(path=/${currentProject}/pom.xml,fromLine=238,toLine=314)"/>
</subitem>
<subitem
label="Arquillian decides which container to use depending on your classpath. Here we define the remote WildFly container."
skip="true">
<command
required="false"
serialization="org.jboss.tools.project.examples.cheatsheet.openFileInEditor(path=/${currentProject}/pom.xml,fromLine=277,toLine=289)"/>
</subitem>
</item>
<item
skip="true"
title="Arquillian project page">
<description>
And that&apos;s it! As you can see Arquillian delivers simple and true testing.
You can concentrate on writing your test functionality, and run your tests in the same environment in which you will run your application.
<br/><br/>
Arquillian also offers other containers, allowing you to run your tests against Weld Embedded (super fast, but your enterprise services are mocked), GlassFish, and more.
<br/><br/>
More info on Arquillian you can find on the Arquillian project page.
</description>
<command
required="false"
serialization="org.eclipse.ui.browser.openBrowser(url=http://www.jboss.org/arquillian)"/>
</item>
<item
skip="true"
title="Creating your own application ">
<description>
What we didn&apos;t tell you about the <b>baeldung-jee7-seed quickstart</b> is that it is generated from a Maven archetype.
Using this archetype offers you the perfect opportunity to generate your own project.
<br/><br/>
In order to perform that, you should select <b>Help&gt;JBoss Central</b> and click the <b>Java EE Web Project</b> wizard.
<br/>
You will get a brand new project with the same functionality as <b>baeldung-jee7-seed</b>,
but customized with your details.
</description>
</item>
</cheatsheet>

View File

@ -1,5 +0,0 @@
<factorypath>
<factorypathentry kind="PLUGIN" id="org.eclipse.jst.ws.annotations.core" enabled="true" runInBatchMode="false"/>
<factorypathentry kind="VARJAR" id="M2_REPO/org/hibernate/hibernate-jpamodelgen/1.1.1.Final/hibernate-jpamodelgen-1.1.1.Final.jar" enabled="true" runInBatchMode="false"/>
<factorypathentry kind="VARJAR" id="M2_REPO/org/hibernate/javax/persistence/hibernate-jpa-2.0-api/1.0.0.Final/hibernate-jpa-2.0-api-1.0.0.Final.jar" enabled="true" runInBatchMode="false"/>
</factorypath>

View File

@ -1,98 +0,0 @@
baeldung-jee7-seed: Assortment of technologies including Arquillian
========================
Author: Pete Muir
Level: Intermediate
Technologies: CDI, JSF, JPA, EJB, JPA, JAX-RS, BV
Summary: An example that incorporates multiple technologies
Target Project: WildFly
Source: <https://github.com/wildfly/quickstart/>
What is it?
-----------
This is your project! It is a sample, deployable Maven 3 project to help you get your foot in the door developing with Java EE 7 on JBoss WildFly.
This project is setup to allow you to create a compliant Java EE 7 application using JSF 2.2, CDI 1.1, EJB 3.3, JPA 2.1 and Bean Validation 1.1. It includes a persistence unit and some sample persistence and transaction code to introduce you to database access in enterprise Java.
There is a tutorial for this quickstart in the [Getting Started Developing Applications Guide](https://github.com/wildfly/quickstart/guide/baeldung-jee7-seed/).
System requirements
-------------------
All you need to build this project is Java 7.0 (Java SDK 1.7) or better, Maven 3.1 or better.
The application this project produces is designed to be run on JBoss WildFly.
Configure Maven
---------------
If you have not yet done so, you must [Configure Maven](https://github.com/jboss-developer/jboss-developer-shared-resources/blob/master/guides/CONFIGURE_MAVEN.md) before testing the quickstarts.
Start JBoss WildFly with the Web Profile
-------------------------
1. Open a command line and navigate to the root of the JBoss server directory.
2. The following shows the command line to start the server with the web profile:
For Linux: JBOSS_HOME/bin/standalone.sh
For Windows: JBOSS_HOME\bin\standalone.bat
Build and Deploy the Quickstart
-------------------------
_NOTE: The following build command assumes you have configured your Maven user settings. If you have not, you must include Maven setting arguments on the command line. See [Build and Deploy the Quickstarts](https://github.com/jboss-developer/jboss-eap-quickstarts#build-and-deploy-the-quickstarts) for complete instructions and additional options._
1. Make sure you have started the JBoss Server as described above.
2. Open a command line and navigate to the root directory of this quickstart.
3. Type this command to build and deploy the archive:
mvn clean package wildfly:deploy
4. This will deploy `target/baeldung-jee7-seed.war` to the running instance of the server.
Access the application
---------------------
The application will be running at the following URL: <http://localhost:8080/baeldung-jee7-seed/>.
Undeploy the Archive
--------------------
1. Make sure you have started the JBoss Server as described above.
2. Open a command line and navigate to the root directory of this quickstart.
3. When you are finished testing, type this command to undeploy the archive:
mvn wildfly:undeploy
Run the Arquillian Tests
-------------------------
This quickstart provides Arquillian tests. By default, these tests are configured to be skipped as Arquillian tests require the use of a container.
_NOTE: The following commands assume you have configured your Maven user settings. If you have not, you must include Maven setting arguments on the command line. See [Run the Arquillian Tests](https://github.com/jboss-developer/jboss-developer-shared-resources/blob/master/guides/RUN_ARQUILLIAN_TESTS.md) for complete instructions and additional options._
1. Make sure you have started the JBoss Server as described above.
2. Open a command line and navigate to the root directory of this quickstart.
3. Type the following command to run the test goal with the following profile activated:
mvn clean test -Parq-wildfly-remote
Run the Quickstart in JBoss Developer Studio or Eclipse
-------------------------------------
You can also start the server and deploy the quickstarts from Eclipse using JBoss tools. For more information, see [Use JBoss Developer Studio or Eclipse to Run the Quickstarts](https://github.com/jboss-developer/jboss-developer-shared-resources/blob/master/guides/USE_JBDS.md)
Debug the Application
------------------------------------
If you want to debug the source code or look at the Javadocs of any library in the project, run either of the following commands to pull them into your local repository. The IDE should then detect them.
mvn dependency:sources
mvn dependency:resolve -Dclassifier=javadoc