[JBoss ESB Development] - Re: Problems with transmitting content from ESB to jBPM via
by keljboss
keljboss [http://community.jboss.org/people/keljboss] created the discussion
"Re: Problems with transmitting content from ESB to jBPM via"
To view the discussion, visit: http://community.jboss.org/message/586445#586445
--------------------------------------------------------------
Hi,
I am a new in jboss ESB, I am triyng to make JBPM and JBOSS ESB exchange().
my example is that jbpm calls ESB and get the response, when i test the esb using soapUI the process work fine, but using JBPM i have the exception below
org.jboss.soa.esb.ConfigurationException: *No EPR present in process instance*
at org.jboss.soa.esb.services.jbpm.actionhandlers.EsbActionHandler.execute(EsbActionHandler.java:137)
my jboss-esb.xml
<?xml version="1.0"?>
<jbossesb parameterReloadSecs="5"
xmlns="http://anonsvn.labs.jboss.com/labs/jbossesb/trunk/product/etc/schemas/xml..."
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://anonsvn.labs.jboss.com/labs/jbossesb/trunk/product/etc/schemas/xml...">
<providers>
<jbr-provider name="ibaSommeHttpGateway" protocol="http">
<jbr-bus busid="ibaSommeHttpGateway" port="9999"/>
</jbr-provider>
<jbr-provider name="ibaMultiplicationHttpGateway" protocol="http">
<jbr-bus busid="ibaMultiplicationHttpGateway" port="7777"/>
</jbr-provider>
</providers>
<services>
<service category="Calcule"
description="calcule la somme de deux valeurs" invmScope="GLOBAL" name="somme">
<listeners>
<jbr-listener busidref="ibaSommeHttpGateway" is-gateway="true" name="ibaHttpSommeGatewayListener"/>
</listeners>
<actions mep="RequestResponse">
<action class="org.jboss.soa.esb.actions.routing.http.HttpRouter" name="ibaSommeHttpRouter">
<property name="method" value="POST"/>
<property name="endpointUrl" value="http://localhost:8080/somme/SommeService?wsdl"/>
<property name="endpointAdresse" value="http://localhost:8080/somme/SommeService?wsdl"/>
<property name="reply-to-originator" value="true"/>
</action>
<action class="org.jboss.soa.esb.actions.SystemPrintln" name="message">
<property name="message" value="in the somme yoooou pi ESB"/>
</action>
</actions>
</service>
<service category="Calcule"
description="calcule la multiplication de deux valeurs"
invmScope="GLOBAL" name="multiplication">
<listeners>
<jbr-listener busidref="ibaMultiplicationHttpGateway"
is-gateway="true" name="ibaHttpMultiGatewayListener"/>
</listeners>
<actions mep="RequestResponse">
<action class="org.jboss.soa.esb.actions.routing.http.HttpRouter" name="ibaMultiplicationHttpRouter">
<property name="method" value="POST"/>
<property name="endpointUrl" value="http://localhost:8080/multiplication/MultiplicationService?wsdl"/>
<property name="reply-to-originator" value="true"/>
</action>
<action class="org.jboss.soa.esb.actions.SystemPrintln" name="message">
<property name="message" value="in the multiplication ESB"/>
</action>
</actions>
</service>
</services>
</jbossesb>
and the precessdefinition.xml
<?xml version="1.0" encoding="utf-8"?>
<process-definition xmlns="urn:jbpm.org:jpdl-3.2"
name="calcule">
<start-state name="start">
<transition to="somme" name="callSomme">
<action name="action">
<message>Going to the SOe</message>
</action>
</transition>
</start-state>
<node name="somme">
<action
class="org.jboss.soa.esb.services.jbpm.actionhandlers.EsbActionHandler">
<replyToOriginator>true</replyToOriginator>
<esbServiceName>
somme
</esbServiceName>
<esbCategoryName>
Calcule
</esbCategoryName>
<replyToOriginator>
reply
</replyToOriginator>
<bpmToEsbVars>
<mapping bpm="a" esb="a"></mapping>
<mapping bpm="b" esb="b"></mapping>
</bpmToEsbVars>
<esbToBpmVars>
<mapping bpm="somme" esb="somme"></mapping>
</esbToBpmVars>
</action>
<transition to="fin" name="tofin">
</transition>
</node>
<end-state name="fin"></end-state>
</process-definition>
the java code :
JbpmConfiguration jbpmConfiguration = JbpmConfiguration.getInstance();
JbpmContext jbpmContext = jbpmConfiguration.createJbpmContext();
GraphSession graphSession = jbpmContext.getGraphSession();
ProcessDefinition processDefinition =
graphSession.findLatestProcessDefinition("calcule");
String a = request.getParameter("a");
String b = request.getParameter("b");
ProcessInstance processInstance = new ProcessInstance(processDefinition);
Token token = processInstance.getRootToken();
System.out.println(token.getNode().getName());
ContextInstance contextInstance = processInstance.getContextInstance();
contextInstance.setVariable("a", new Float(500));
contextInstance.setVariable("b", new Float(500));
processInstance.getRootToken().signal();
is there anything that i messed ?
for information i am using jboss-esb4.9, jbpm 3.2 and jbossAS 5.1.0GA
thank you for your help
Cheers
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/586445#586445]
Start a new discussion in JBoss ESB Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
13 years, 1 month
[JBoss Web Development] - apache.commons.fileupload - Browser blocks ajax requests
by t_guen03
t_guen03 [http://community.jboss.org/people/t_guen03] created the discussion
"apache.commons.fileupload - Browser blocks ajax requests"
To view the discussion, visit: http://community.jboss.org/message/590187#590187
--------------------------------------------------------------
Hi,
its my first post here so far, I hope I do not ask this question in the wrong place. I hope you can help me with my problem.
I want to have a progressbar at my page, which displays the status of a fileupload.
Therefore I got a <h:form>-tag like this :
<h:form id="uploadForm" target="iframe"
enctype="multipart/form-data">
<h:outputLabel
styleClass="label" value="Select File"/>
<div class="round"><input name="file" type="file"/></div>
<h:commandButton name="upload" id="uploadbt"
action="#{uploadBean.upload}" value="Upload"
onclick="startPolling('uploadForm');">
</h:commandButton>
<div style="min-width: 400px; min-height: 22px; height: 22px; width: 400px;" id="progressbar">
<ui:repeat var="element" value="#{uploadBean.progressElements}">
<span class="progressActive" style="display: inline-block; min-width: 4px; min-height: 21px; height: 21px; width: 4px;"></span>
</ui:repeat>
<h:inputHidden value="#{uploadBean.finished}" id="flag" />
</div>
</h:form>
When the user clicks the commandButton the upload is started. On the server side the send request is wrapped and the request is parsed by a ServletFileUpload object. This looks like this:
try{
ServletFileUpload upload = new ServletFileUpload();
upload.setFileSizeMax(maxFileSize);
upload.setFileItemFactory(new ProgressMonitorFileItemFactory(request, username));
ProgressListener progressListener = new SignalFinishProgressListener(request.getSession(), "FileUpload.Progress.finished");
upload.setProgressListener(progressListener);
@SuppressWarnings("all")
List fileItems = upload.parseRequest(request);
formParameters = new HashMap<String,String>();
fileParameters = new HashMap<String,FileItem>();
for(int i=0;i<fileItems.size();i++){
FileItem item = (FileItem)fileItems.get(i);
if(item.isFormField() == true){
formParameters.put(item.getFieldName(),item.getString());
}else{
fileParameters.put(item.getFieldName(),item);
request.setAttribute(item.getFieldName(),item);
}
}
}catch(FileUploadException fe){
fe.printStackTrace();
throw new UploadError(fe.getMessage());
}catch(Exception ne){
ne.printStackTrace();
throw new RuntimeException(ne);
}
}
The installed ProgressListener just sets a sessionvariable called "FileUpload.Progress.finished" if the upload is ready. Furthermore the percentage of written bytes is stored in the session under the key "FileUpload.Progress.file" (You can't see it here, its done while writing the Fileitems to disk).
There is also registered a onclick listener to the button, which starts the polling. It is sending an ajax.request to render the progressbar.
The javascript looks like this :
function startPolling(formid) {
function poll(data){
if(data.status == "success") {
alert('POLL');
var flag = document.getElementById(formid+':flag');
if(flag.value != "true") {
startPolling(formid);
}
}
}
jsf.ajax.request(formid, null, {render: formid, onevent: poll});
}
Okay,we nearly got it : ) . Last there is the uploadBean.upload method :
public void upload(){
HttpSession session = (HttpSession)FacesContext.getCurrentInstance().getExternalContext().getSession(false);
status = (Double)session.getAttribute("FileUpload.Progress.file");
if(status == null)
return;
System.out.println("Percentage : " + status.intValue());
for(int j = status.intValue() - progressElements.size(); j > 0; j--)
progressElements.add(new Byte((byte)0xff));
if(session.getAttribute("FileUpload.Progress.finished") != null) {
for(int j = 100-progressElements.size(); j>0; j--)
progressElements.add(new Byte((byte)0xff));
finished = true;
}
}
This method gets invoked before the page gets rendered. Thats because i registered a preRenderView event listener to the page. This means, that this method gets called after every send ajax request, which goes through the partial lifecycle to render the progressbar. The method eventually adds new Bytes to the progressElements list. The list gets used by the ui:repeat element to build the progressbar. Finally the method checks if the FileUpload.Progress.finished attribute was set by the ProgressListener, which we installed to the ServletFileUpload instance (you remember ? ; ) ).
Ok, i hope you understood the set up. And now to my problem. When i upload a file, there are no ajax requests send, while uploading. The result is that my progressbar doesnt update itself.
Do you know a workaround, or at least can tell me the reason of this ?
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/590187#590187]
Start a new discussion in JBoss Web Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
13 years, 1 month
[JBoss AS7 Development] - JSF on AS7
by Stan Silvert
Stan Silvert [http://community.jboss.org/people/ssilvert] created the document:
"JSF on AS7"
To view the document, visit: http://community.jboss.org/docs/DOC-16546
--------------------------------------------------------------
This article documents the current status of JSF integration on AS7. It is expected that this document will evolve from being a status page to an informal documentation page. Then it will be deprecated in favor of the official documentation.
*JSF Feature Status*
|| *Feature
* || *Working in Master
* || *Notes
* ||
| Basic JSF integration | Yes | Mojarra 2.0.4-b09 was integrated on 2011-02-23 |
| Auto-add FacesServlet | Yes | If no FacesServlet specified in web.xml it will be automatically added according to the new rules in the FacesServlet javadoc (http://download.oracle.com/javaee/6/api/javax/faces/webapp/FacesServlet.h... This is slightly different from the auto-add feature in AS6. |
| Bean Validation | Yes | Hibernate Validator 4.0.1.Final is integrated with JSF as the bean validation provider. |
| Legacy Facelets Apps | Yes | This refers to older JSF applications that use the JSF 1.x version of Facelets. It is known to work as long as you set *com.sun.faces.validateXml=false* as shown in JBAS-8909 (https://issues.jboss.org/browse/JBAS-8909) |
| JSP-based JSF applciations | Unknown | It is unknown whether or not this works properly with current JSTL integration. |
| JSTL | Unknown | JSTL was added to master, but since there is currently no shared-TLD support it is unknown whether or not this will work properly. |
| JEE5 Injection | No | This hasn't been properly investigated yet, but it probably doesn't work. @PostCreate and @PreDestroy do work currently but it's doubtful that the other annotations are being recognized. |
| Multi-JSF implementations | No | AS6 allowed you to plug in different JSF implementations. Currently in AS7, only one implementation is allowed. |
| Integration Tests | No | Several integration tests have been developed but we are working to get JSFUnit running on AS7 before we can commit them to Master. Right now they have to be run by hand. |
*JSF-related Jiras for AS7:*
JBAS-8876 (https://issues.jboss.org/browse/JBAS-8876) Add JSF to AS7
https://issues.jboss.org/browse/JBAS-8908 JBAS-8908 AS6 ZipException now seen in AS7
https://issues.jboss.org/browse/JBAS-8909 JBAS-8909 TransformerConfigurationException when reading faces-config.xml
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-16546]
Create a new document in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
13 years, 1 month
[JBoss AS7 Development] - Checkstyle
by David Lloyd
David Lloyd [http://community.jboss.org/people/david.lloyd%40jboss.com] created the discussion
"Checkstyle"
To view the discussion, visit: http://community.jboss.org/message/560961#560961
--------------------------------------------------------------
I've introduced checkstyle into the AS7 codebase. Right now it prints violations out on the console, however in the (near) future it will cause the build to fail if a violation is detected.
This means a few things.
1. Make sure your patches do not introduce new violations.
2. People with topic branches beware: at some point (soon) the existing violations in trunk will be fixed, which can cause merge conflicts when a rebase is performed *unless* you rebase using this command: *git --whitespace=fix rebase upstream/master*
3. To avoid productivity loss in the future, make sure your IDE matches the code style, in particular the following points:1. Strip trailing whitespace from modified lines
2. Do *not* use tab characters under any circumstances
3. Remove unused and star imports, or imports of classes from the same package
4. Do not specify redundant modifiers (like "public" on interface methods)
The existing violation corrections will be going in over the next couple of days; once they're all gone, the build will no longer proceed if a violation is introduced.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/560961#560961]
Start a new discussion in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
13 years, 1 month
[JBoss AS7 Development] - JBoss Modules Surefire Plugin
by Kabir Khan
Kabir Khan [http://community.jboss.org/people/kabirkhan] modified the document:
"JBoss Modules Surefire Plugin"
To view the document, visit: http://community.jboss.org/docs/DOC-16240
--------------------------------------------------------------
This is a fork of org.apache.maven.plugins:maven-surefire-plugin:2.6:test which allows you to run tests using modular classloading provided by jboss-modules. The source for this plugin is available in github ( https://github.com/kabir/jboss-modules-surefire-plugin https://github.com/kabir/jboss-modules-surefire-plugin).
It works by suppying it with a prebuilt modules root (such as the one from a built JBoss AS 7) and a module definition file to define more modules for your test. The plugin will then create an additional modules directory from the module definition file, and then invoke org.jboss.modules.Main using the configured modules directories. Since everything is now run via jboss modules, you should not execute tests directly from your IDE, but rather run them via maven. If you want to debug the tests, do a
mvn install -Dmaven.surefire.debug=true
and attach a debugger to port 5005.
h4. Configuration
It has the configuration options of the 'real' surefire plugin ( http://maven.apache.org/plugins/maven-surefire-plugin/test-mojo.html http://maven.apache.org/plugins/maven-surefire-plugin/test-mojo.html), although your mileage may vary if you start playing with the fork modes. The plugin takes a module definition file and creates a directory structure containing modules in the jboss-modules format
It has the configuration options of the http://maven.apache.org/plugins/maven-surefire-plugin/test-mojo.html original surefire plugin, although your mileage may vary if you start playing with the fork modes. The plugin takes a module definition file and creates a directory structure containing modules in the jboss-modules format.
For the forked module there are some more options for configuring the modules:
*roots:*
Points to a list of exisiting module root directories, such as jboss-as7/modules
* *Type:* java.io.File[]
* *Required:* No
*cleanModulesDirectory:*
If true (default) clean out the modules directory created by the plugin each time we run the tests.
* *Type:* boolean
* *Required:* No
* *Expression:* ${jboss.modules.clean}
* *Default:* true
*modulesDirectory:*
The absolute path of the modules output directory created from +*moduleDefinitionFile*+
* *Type:* java.io.File
* *Required:* No
* *Expression:* ${jboss.modules.directory}
* *Default:* ${project.build.directory}/modules
*logModule:*
The name of the -logmodule parameter passed in to JBoss Modules (i.e. the name of the module containg the jboss logmanager). This is needed if the target project uses java.util.Logging or jboss logging, and the jboss log manager is not on the system classpath.
* *Type:* java.lang.String
* *Required:* No
* *Expression:* ${jboss.modules.logmodule}
*logConfiguration:*
The JBoss logging configuration if any. This must be set if the target project uses jboss logging and you want any output to be displayed
* *Type:* java.io.File
* *Required:* No
* *Expression:* ${logging.configuration}
*moduleDefinitionFile:*
The path of the module definition file.
* Type java.io.File
* Required: Yes
* Expression: ${jboss.modules.definition}
* Default: ${project.build.testOutputDirectory}/modules/module-def.xml
In addition, when using jboss logging you will need to set the following system properties in your pom when using this plugin (full example later):
<systemProperties>
<property>
<name>java.util.logging.manager</name>
<value>org.jboss.logmanager.LogManager</value>
</property>
<property>
<name>jboss.home.dir</name>
<value>${jboss.home}</value>
</property>
<property>
<name>org.jboss.boot.log.file</name>
<value>${jboss.home}/standalone/log/boot.log</value>
</property>
</systemProperties>
*h4. Module Definition File
*
This sets up the modules used for running your tests, which are then copied to *+modulesDirectory+* from the plugin settings. The plugin automatically sets up a module called +jboss.surefire.module+ for you which contains the plugin classes. This module is then used as the module passed in to org.jboss.modules.Main. If you want to set up more modules you can define those in the *+moduleDefinitionFile+*. The schema is very simple, and rather than duplicating the work done by jboss-modules the validation of most of the stuff is delegated to jboss-modules when loading the modules. Here is an example:
<?xml version="1.0" encoding="UTF-8"?>
<modules xmlns="urn:jboss:surefire-module:1.0" targetNs="urn:jboss:module:1.0">
<test-module-resources>
<resource-root path="$junit:junit$"/>
<resource-root path="$$CLASSES$$"/>
<resource-root path="$$TEST.CLASSES$$"/>
</test-module-resources>
</test-module-dependencies>
<module name="org.jboss.as.standalone"/>
<module name="org.jboss.modules"/>
<module name="org.jboss.threads"/>
<module name="my.test.module"/>
</test-module-dependencies>
<module name="my.test.module">
<resources>
<resource-root path="$some.group:some-artifact$"/>
</resources>
</module>
</modules>
+targetNs+ is the schema of the targetted jboss-modules version.
+test-module-resources+ adds the listed resources directly into the resources section of the created +jboss.surefire.module+ module.
+test-module-dependencies+ adds the listed dependencies directly into the dependencies section of the created +jboss.surefire.module+ module. In this case we follow the jboss-modules 1.0 schema. The resource root paths containing '$' get expanded as shown in this example of what the generated +modulesDirectory+/jboss/surefire/module/main/module.xml looks like:
<?xml version="1.0" encoding="UTF-8"?>
<module name="jboss.surefire.module" xmlns="urn:jboss:module:1.0">
<main-class name="org.apache.maven.surefire.booter.SurefireBooter"/>
<resources>
<!-- These two always get included -->
<resource-root path="surefire-api-2.6.jar"/>
<resource-root path="surefire-booter-1.0.0.Alpha1.jar"/>
<!-- The maven dependency $junit.junit$ gets pulled from the maven repository
using the version from your project dependencies
-->
<resource-root path="junit-4.8.1.jar"/>
<!-- $$CLASSES$$ uses the main classes directory from your project -->
<resource-root path="classes"/>
<!-- $$TEST.CLASSES$$ uses the test classes directory from your project -->
<resource-root path="test-classes"/>
</resources>
<dependencies>
<module name="org.jboss.as.standalone"/>
<module name="org.jboss.modules"/>
<module name="org.jboss.threads"/>
<module name="org.jboss.threads"/>
</dependencies>
</module>
You can have as many +modules/module entries as you like and they just get copied across. The $some.group:some.artifact$+ value gets resolved from your project's dependencies into the path to that dependency in your local maven repository. In this case (assuming your pom has a dependency on some.group:some-artifact:1.3.0, which then gets copied from the local maven repository to the module directory) +modulesDirectory+/my/test/module/main/module.xml looks like:
<?xml version="1.0" encoding="UTF-8"?>
<module name="my.test.module" xmlns="urn:jboss:module:1.0">
<resources>
<resource-root path="some-artifact-1.3.0.jar'/>
</resources>
</module>
To summarize, you have the following options to set the resource-root paths.
* Full path: Nothing special happens in this case, the module will simply point to that place
* $$CLASSES$$: Copies the main classes directory from your project to the created module
* $$TEST.CLASSES$$: Copies the test classes directory from your project to the created module
* $maven.group.id*:*maven.artifact.id$: Resolves the maven dependency from your project dependencies and copies the jar to the created module
h4. Consuming the plugin from a pom
Normally you want to turn off the normal surefire plugin since that does not understand modular classloading
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.6</version>
<!-- Disable the standard surefire plugin since that runs tests without modular classloading -->
<configuration>
<skipTests>true</skipTests>
</configuration>
</plugin>
Then enable and configure the jboss modules surefire plugin (${jboss.home} is configured elsewhere in the pom and points to a built JBoss AS 7 instance)
<plugin>
<groupId>org.jboss.maven.surefire.modular</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>1.0.0.Alpha1</version>
<executions>
<execution>
<goals>
<goal>test</goal>
</goals>
</execution>
</executions>
<configuration>
<!-- standard surefire options -->
<redirectTestOutputToFile>true</redirectTestOutputToFile>
<enableAssertions>true</enableAssertions>
<systemProperties>
<property>
<!-- We need to enable the log manager for jboss as -->
<name>java.util.logging.manager</name>
<value>org.jboss.logmanager.LogManager</value>
</property>
<property>
<!-- The root of the jboss installation -->
<name>jboss.home.dir</name>
<value>${jboss.home}</value>
</property>
<property>
<!-- Set the boot log location -->
<name>org.jboss.boot.log.file</name>
<value>${jboss.home}/standalone/log/boot.log</value>
</property>
<!-- If using EmbeddedServerFactory to create the AS instance (used by the
arquillian container) set a directory to copy across the
${jboss.home}/standalone directory to, to avoid pollution of standalone.xml
between runs
--> <property>
<name>jboss.embedded.root</name>
<value>target/temp-config</value>
</property>
</systemProperties>
<includes>
<include>org/jboss/as/test/surefire/**/*TestCase.java</include>
</includes>
<!-- Extra forked plugin options -->
<logModule>org.jboss.logmanager</logModule>
<logConfiguration>${jboss.home}/standalone/configuration/logging.properties</logConfiguration>
<roots>
<root>${jboss.home}/modules</root>
</roots>
</configuration>
</plugin>
h4. Running Arquillian Tests
The plugin can be used to run arquillian tests against an embedded AS 7 instance using modular classloading everywhere at runtime.
If running an Arquillian IN_CONTAINER test, Arquillian will first execute parts of the test on the client side to create the deployments, before starting an embedded AS instance and deploying the tests into the started server. The test is then run in the server as part of the deployment.
If running an Arquillian AS_CLIENT test, Arquiilian will start the embedded AS instance and then run the test on the client to connect to the started AS instance.
Since the tests are now booted up using JBoss Modules, there is no runtime classpath to speak of, so you need to set up your modules to be able to see the arquillian classes and to be able to see the test class and the dependencies for what is executed on the client (the parts of the test run inside the server don't need anything special since that is handled for us by the server). Here is an example of a module definition file for running an Arquillian test:
<?xml version="1.0" encoding="UTF-8"?>
<modules xmlns="urn:jboss:surefire-module:1.0" targetNs="urn:jboss:module:1.0">
<test-module-resources>
<resource-root path="$org.jboss.as:jboss-as-arquillian-container-embedded$"/>
<resource-root path="$org.jboss.as:jboss-as-arquillian-container-common$"/>
<resource-root path="$$TEST.CLASSES$$"/>
</test-module-resources>
<test-module-dependencies>
<!-- Arquillian dependencies -->
<module services="import" name="org.jboss.surefire.arquillian-deps"/>
<!-- Add other test dependencies here -->
</test-module-dependencies>
<!-- Add more test modules as needed -->
</modules>
org.jboss.surefire.arquillian-deps is a module that ships with JBoss AS 7, and contains the dependencies needed for arquillian. It can be found https://github.com/jbossas/jboss-as/blob/master/build/src/main/resources/... here. In addition, the test module in this example contains the project test classes directories, and it adds the resource roots containing the JBoss AS 7 embedded Arquillian container and the common Arquillian container classes. Including these container classes makes Arquillian start up the embedded AS 7 container.
h4. TBD
* Investigate if surefire report works with this or if that needs forking too
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-16240]
Create a new document in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
13 years, 1 month