[JBoss Tools Development] - How to Build JBoss Tools with Maven 3
by Andre Dietisheim
Andre Dietisheim [http://community.jboss.org/people/adietish] modified the document:
"How to Build JBoss Tools with Maven 3"
To view the document, visit: http://community.jboss.org/docs/DOC-16604
--------------------------------------------------------------
+*This article is a replacement for its precursor, http://community.jboss.org/docs/DOC-15513 How to Build JBoss Tools 3.2 with Maven 3.*+
h2. Prerequisites
1. Java 1.6 SDK
2. Maven 3
3. Ant 1.7.1 or later
4. About 6 GB of free disk space if you want to run all integration tests for (JBoss AS, Seam and Web Services Tools)
5. subversion client 1.6.X (should work with lower version as well)
h2. Environment Setup
h3. Maven and Java
Make sure your maven 3 is available by default and Java 1.6 is used.
mvn -version
should print out something like
*Apache Maven 3.0.2* (r1056850; 2011-01-08 19:58:10-0500)
*Java version: 1.6.0_20*, vendor: Sun Microsystems Inc.
*Java home: /usr/java/jdk1.6.0_20/jre*
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "2.6.32.23-170.fc12.i686", arch: "i386", family: "unix"
h2.
h2. Building Locally Via Commandline
To run a local build of JBoss Tools 3.3 against the new Eclipse 3.7-based Target Platform, I suggest a three-step approach:
a) build the parent & target platform poms (v0.0.3-SNAPSHOT) *[ONLY NEEDED WHEN THESE CHANGE]*
b) resolve the target platform to your local disk *[ONLY NEEDED WHEN THESE CHANGE]*
c) build against your local copy of the target platform [every time you change sources and want to rebuild]
Once (a) and (b) are done, you need only perform (c) iteratively until you're happy (that is, until everything compiles). This lets you test changes locally before committing back to SVN.
*(a) and (b) need only be done when the parent pom and Target Platform (TP) change.* Of course if we get these published to nexus then you may not need those first bootstrapping steps. Stay tuned - work in progress.
*a) build the parent & target platform poms (v0.0.3-SNAPSHOT)*
svn co http://svn.jboss.org/repos/jbosstools/trunk jbosstools
cd jbosstools/build/parent
mvn clean install
...
[INFO] Reactor Summary:
[INFO]
[INFO] JBoss Tools Target Platform Definition ............ SUCCESS [0.724s]
[INFO] JBoss Tools Parent ................................ SUCCESS [0.461s]
...
*b) resolve the target platform to your local disk*
There are two ways to do this:
i) Download and unpack the latest TP zip, *OR*
ii) Resolve the TP using Maven or Ant
+i) Download and unpack the latest TP zip+
You can either download the TP as a zip [5] and unpack it into some folder on your disk. For convenience, the easiest is to unzip into jbosstools/build/target-platform/REPO/, since that's where the Maven or Ant process will by default operate.
You can do that with any browser or on a command line with curl or similar:
curl -C - -O http://download.jboss.org/jbosstools/updates/target-platform_3.3.indigo/e...
...
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 606M 100 606M 0 0 164k 0 1:02:54 1:02:54 --:--:-- 172k
and then unzip it:
mkdir jbosstools/build/target-platform/REPO
unzip 37M5-wtp33M5.target.zip -d jbosstools/build/target-platform/REPO
[5] http://download.jboss.org/jbosstools/updates/target-platform_3.3.indigo/e... http://download.jboss.org/jbosstools/updates/target-platform_3.3.indigo/e...
*OR*
*
*
+ii) Resolve the TP using Maven or Ant with wget
+
cd jbosstools/build/target-platform
mvn clean install -Pget.local.target
The get.local.target profile will resolve the target platform file, multiple.target, as a p2 repository on your local disk in ~/3.3.indigo/build/target-platform/REPO/. It may take a while, so you're better off from a speed point-of-view simply fetching the latest zip [5]. However, if you want to see what actually happens to create the TP (as done in Hudson) this is the approach to take.
Since the Maven profile is simply a wrapper call to Ant, you can also use Ant 1.7.1 or later directly:
cd jbosstools/build/target-platform
ant
*c) build against your local copy of the target platform*
*LINUX / MAC USERS*
cd build
mvn clean install -U -B -fae -e -P local.site -Dlocal.site=file:/${HOME}/3.3.indigo/build/target-platform/REPO/ | tee build.all.log.txt
(tee is a program that pipes console output to BOTH console and a file so you can watch the build AND keep a log.)
*WINDOWS USERS*
cd c:\3.3.indigo\build
mvn3 clean install -U -B -fae -e -P local.site -Dlocal.site=file:///C:/3.3.indigo/build/target-platform/REPO/
or
mvn3 clean install -U -B -fae -e -Plocal.site -Dlocal.site=file:///C:/3.3.indigo/build/target-platform/REPO/ > build.all.log.txt
If you downloaded the zip and unpacked is somewhere else, use -Dlocal.site=file:/.../ to point at that folder instead.
If you would rather build a single component (or even just a single plugin), go into that folder and run Maven there:
cd ~/3.3.indigo/build/jmx
mvn3 clean install -U -B -fae -e -P local.site -Dlocal.site=file:/${HOME}/3.3.indigo/build/target-platform/REPO/ | tee build.jmx.log.txt
+-- OR, if you prefer to use the "bootstrap profiles": --+
cd ~/3.3.indigo/build
mvn3 clean install -U -B -fae -e -P local.site,jmx-bootstrap -Dlocal.site=file:/${HOME}/3.3.indigo/build/target-platform/REPO/ | teebuild.jmx.log.txt
++
#
h2. Building Locally In Eclipse
First, you must have installed m2eclipse into your Eclipse (or JBDS). You can install the currently supported version from this update site:
http://download.jboss.org/jbosstools/updates/indigo/ http://download.jboss.org/jbosstools/updates/indigo/
Next, start up Eclipse or JBDS and do *File > Import* to import the project(s) you already checked out from SVN above into your workspace.
http://community.jboss.org/servlet/JiveServlet/showImage/102-16604-13-138... http://community.jboss.org/servlet/JiveServlet/downloadImage/102-16604-13...
Browse to where you have the project(s) checked out, and select a folder to import pom projects. In this case, I'm importing the parent pom (which refers to the target platform pom). Optionally, you can add these new projects to a working set to collect them in your Package Explorer view.
http://community.jboss.org/servlet/JiveServlet/showImage/102-16604-13-138... http://community.jboss.org/servlet/JiveServlet/downloadImage/102-16604-13...
Once the project(s) are imported, you'll want to build them. You can either do *CTRL-SHIFT-X,M (Run Maven Build),* or right-click the project and select *Run As > Maven Build*. The following screenshots show how to configure a build job.
First, on the *Main* tab, set a *Name*, *Goals*, *Profile*(s), and add a *Parameter*. Or, if you prefer, put everything in the *Goals* field for simplicity:
+clean install -U -B -fae -e -Plocal.site -Dlocal.site=file://home/nboldt/tmp/JBT_REPO_Indigo/+
Be sure to check *Resolve Workspace artifacts*, and, if you have a newer version of Maven installed, point your build at that *Maven Runtime* instead of the bundled one that ships with m2eclipse.
http://community.jboss.org/servlet/JiveServlet/showImage/102-16604-13-138... http://community.jboss.org/servlet/JiveServlet/downloadImage/102-16604-13...
On the *JRE* tab, make sure you're using a 6.0 JDK.
http://community.jboss.org/servlet/JiveServlet/showImage/102-16604-13-138... http://community.jboss.org/servlet/JiveServlet/downloadImage/102-16604-13...
On the *Refresh* tab, define which workspace resources you want to refresh when the build's done.
http://community.jboss.org/servlet/JiveServlet/showImage/102-16604-13-138... http://community.jboss.org/servlet/JiveServlet/downloadImage/102-16604-13...
On the *Common* tab, you can store the output of the build in a log file in case it's particularly long and you need to refer back to it.
http://community.jboss.org/servlet/JiveServlet/showImage/102-16604-13-138... http://community.jboss.org/servlet/JiveServlet/downloadImage/102-16604-13...
Click *Run* to run the build.
http://community.jboss.org/servlet/JiveServlet/showImage/102-16604-13-138... http://community.jboss.org/servlet/JiveServlet/downloadImage/102-16604-13...
Now you can repeat the above step to build any other component or plugin or feature or update site from the JBoss Tools repo. Simply import the project(s) and build them as above.
h2. Tips and tricks for making BOTH PDE UI and headless Maven builds happy
It's fairly common to have plugins compiling in eclipse while tycho would not work. Basically you could say that tycho is far more picky compared to Eclipse PDE.
h3.
Check your build.properties
Check build.properties in your plugin. If it has warnings in Eclipse, you'll most likely end with tycho failing to compile your sources. You'll have to make sure that you correct all warnings.
Especially check your build.properties to have entries for *source..* and *output..*
*
*
source.. = src/
output.. = bin/
h2.
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-16604]
Create a new document in JBoss Tools Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
13 years
[JBoss AS7 Development] - Format of a Detyped Operation Request
by Brian Stansberry
Brian Stansberry [http://community.jboss.org/people/brian.stansberry] modified the document:
"Format of a Detyped Operation Request"
To view the document, visit: http://community.jboss.org/docs/DOC-16336
--------------------------------------------------------------
The basic method a user of the AS 7 programmatic managment API would use it very simple:
ModelNode execute(ModelNode operation) throws CancellationException, IOException;
where the return value is the detyped representation of the response, and operation is the detyped representation of the operating being invoked.
The purpose of this article is to document the structure of operation.
See http://community.jboss.org/docs/DOC-16354 this page for a discussion of the format of the response.
See http://community.jboss.org/docs/DOC-16317 this page for a more in depth example of using the native management API.
h3. Simple Operations
A text representation of simple operation would look like this:
{
"operation" => "write-core-threads",
"address" => [
("profile" => "production"),
("subsystem" => "threads"),
("bounded-queue-thread-pool" => "pool1")
],
"count" => 0,
"per-cpu" => 20
}
Java code to produce that output would be:
ModelNode op = new ModelNode();
op.get("operation").set("write-core-threads");
ModelNode addr = opB.get("address");
addr.add("base", "domain");
addr.add("profile", "production");
addr.add("subsystem", "threads");
addr.add("bounded-queue-thread-pool", "pool1");
op.get("count").set(0);
op.get("per-cpu").set(20);
System.out.println(op);
The order in which the items appear in the request is not relevant. The required elements are:
* operation -- String -- The name of the operation being invoked.
* address -- the address of the managed resource against which the request should be executed. If not set, the address is the root resource.
The other key/value pairs are parameter names and their values. The names and values should match what is specified in the operation's http://community.jboss.org/docs/DOC-16317 description.
Parameters may have any name, except for operation, address and operation-headers.
h3. Operation Headers
(Note: this information is correct for releases after 7.0.0.Beta2, following completion of JBAS-9112. Prior to that, the headers were at the same level as operation and address.)
Besides the special operation and address values discussed above, operation requests can also include special "header" values that help control how the operation executes. These headers are created under the special reserved word operation-headers:
ModelNode op = new ModelNode();
op.get("operation").set("write-core-threads");
ModelNode addr = opB.get("address");
addr.add("base", "domain");
addr.add("profile", "production");
addr.add("subsystem", "threads");
addr.add("bounded-queue-thread-pool", "pool1");
op.get("count").set(0);
op.get("per-cpu").set(20);
op.get("operation-headers", "rollback-on-runtime-failure").set(false);
System.out.println(op);
This produces:
{
"operation" => "write-core-threads",
"address" => [
("profile" => "production"),
("subsystem" => "threads"),
("bounded-queue-thread-pool" => "pool1")
],
"count" => 0,
"per-cpu" => 20
"operation-headers" => {
"rollback-on-runtime-failure => false
}
}
The following operation headers are supported:
* rollback-on-runtime-failure -- boolean, optional, defaults to true. Whether an operation that successfully updates the persistent configuration model should be reverted if it fails to apply to the runtime. Operations that affect the persistent configuration are applied in two stages -- first to the configuration model and then to the actual running services. If there is an error applying to the configuration model the operation will be aborted with no configuration change and no change to running services will be attempted. However, operations are allowed to changed the configuration model even if there is a failure to apply the change to the running services -- if and only if this rollback-on-runtime-failure header is set to false. So, this header only deals with what happens if there is a problem applying an operation to the running state of a server (e.g. actually increasing the size of a runtime thread pool.)
* rollout-plan -- only relevant to requests made to a Domain Controller or Host Controller. See "Operations with a Rollout Plan" for details.
h3. Composite Operations
The root resource managed by a (Domain|Host|Server)Controller will expose an operation named "composite". This operation executes a list of other operations as an atomic unit*. The structure of the request for the "composite" operations has the same fundamental structure as a simple operation (operation name, address, params as key value pairs.
+* See the discussion below of the rollback-on-runtime-failure operation header for how the atomicity requirement can be relaxed.+
{
"operation" => "composite",
"address" => [],
"steps" => [
{
"operation" => "write-core-threads",
"address" => [
("profile" => "production"),
("subsystem" => "threads"),
("bounded-queue-thread-pool" => "pool1")
],
"count" => 0,
"per-cpu" => 20
},
{
"operation" => "write-core-threads",
"address" => [
("profile" => "production"),
("subsystem" => "threads"),
("bounded-queue-thread-pool" => "pool2")
],
"count" => 5,
"per-cpu" => 10
}
],
"rollback-on-runtime-failure" => false
}
The "composite" operation takes a single parameter:
* steps -- a list, where each item in the list has the same structure as a simple operation request. In the example above each of the two steps is modifying the thread pool configuration for a different pool. There need not be any particular relationship between the steps.
The rollback-on-runtime-failure operation header discussed above has a particular meaning when applied to a composite operation, controlling whether steps that successfully execute should be reverted if other steps fail at runtime. Note that if any steps modify the persistent configuration, and any of those steps fail, all steps will be reverted. Partial/incomplete changes to the persistent configuration are not allowed.
h3. Operations with a Rollout Plan
Operations targetted at domain or host level resources can potentially impact multiple servers. Such operations can include a "rollout plan" detailing the sequence in which the operation should be applied to servers as well as policies for detailing whether the operation should be reverted if it fails to execute successfully on some servers.
If the operation includes a rollout plan, the structure is as follows:
{
"operation" => "write-core-threads",
"address" => [
("profile" => "production"),
("subsystem" => "threads"),
("bounded-queue-thread-pool" => "pool1")
],
"count" => 0,
"per-cpu" => 20,
"rollout-plan" => {
"in-series" => [
{
"concurrent-groups" => {
"groupA" => {
"rolling-to-servers" => true,
"max-failure-percentage" => 20
},
"groupB" => undefined
},
"server-group" => {"groupC" => {
"rolling-to-servers" => false,
"max-failed-servers" => 1
}}
},
{"server-group" => {"groupC" => undefined}},
{"concurrent-groups" => {
"groupD" => {
"rolling-to-servers" => true,
"max-failure-percentage" => 20
},
"groupE" => undefined
}}
]
},
"rollback-across-groups" => true
}
As you can see, the rollout plan is simply another structure at the same level as op, op-addr and the operation parameters. The root node of the structure allows two children:
* in-series -- a list -- A list of steps that are to be performed in series, with each step reaching completion before the next step is executed. Each step involves the application of the operation to the servers in one or more server groups. See below for details on each element in the list.
* rollback-across-groups -- boolean -- indicates whether the need to rollback the operation on all the servers in one server group should trigger a rollback across all the server groups. This is an optional setting, and defaults to false.
Each element in the list under the in-series node must have one or the other of the following structures:
* concurrent-groups -- a map of server group names to policies controlling how the operation should be applied to that server group. For each server group in the map, the operation may be applied concurrently. See below for details on the per-server-group policy configuration.
* server-group -- a single key/value mapping of a server group name to a policy controlling how the operation should be applied to that server group. See below for details on the policy configuration. +(Note: there is no difference in plan execution between this and a "concurrent-groups" map with a single entry.)+
The policy controlling how the operation is applied to the servers within a server group has the following elements, each of which is optional:
* rolling-to-servers -- boolean -- If true, the operation will be applied to each server in the group in series. If false or not specified, the operation will be applied to the servers in the group concurrently.
* max-failed-servers -- int -- Maximum number of servers in the group that can fail to apply the operation before it should be reverted on all servers in the group. The default value if not specified is zero; i.e. failure on any server triggers rollback across the group.
* max-failure-percentage -- int between 0 and 100 -- Maximum percentage of the total number of servers in the group that can fail to apply the operation before it should be reverted on all servers in the group. The default value if not specified is zero; i.e. failure on any server triggers rollback across the group.
If both max-failed-servers and max-failure-percentage are set to non-zero values, max-failure-percentage takes precedence.
Looking at the (contrived) example above, application of the operation to the servers in the domain would be done in 3 phases. If the policy for any server group triggers a rollback of the operation across the server group, all other server groups will be rolled back as well. The 3 phases are:
1. Server groups groupA and groupB will have the operation applied concurrently. The operation will be applied to the servers in groupA in series, while all servers in groupB will handle the operation concurrently. If more than 20% of the servers in groupA fail to apply the operation, it will be rolled back across that group. If any servers in groupB fail to apply the operation it will be rolled back across that group.
2. Once all servers in groupA and groupB are complete, the operation will be applied to the servers in groupC. Those servers will handle the operation concurrently. If more than one server in groupC fails to apply the operation it will be rolled back across that group.
3. Once all servers in groupC are complete, server groups groupD and groupE will have the operation applied concurrently. The operation will be applied to the servers in groupD in series, while all servers in groupE will handle the operation concurrently. If more than 20% of the servers in groupD fail to apply the operation, it will be rolled back across that group. If any servers in groupE fail to apply the operation it will be rolled back across that group.
h3. Default Rollout Plan
All operations that impact multiple servers will be executed with a rollout plan. However, actually specifying the rollout plan in the operation request is not required. If no rollout-plan is specified, a default plan will be generated. The plan will have the following characteristics:
* There will only be a single high level phase. All server groups affected by the operation will have the operation applied concurrently.
* Within each server group, the operation will be applied to all servers concurrently.
* Failure on any server in a server group will cause rollback across the group.
* Failure of any server group will result in rollback of all other server groups.
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-16336]
Create a new document in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
13 years
[JBoss AS7 Development] - Experiments with EJB3 annotation + DD merging in AS7
by jaikiran pai
jaikiran pai [http://community.jboss.org/people/jaikiran] created the document:
"Experiments with EJB3 annotation + DD merging in AS7"
To view the document, visit: http://community.jboss.org/docs/DOC-16688
--------------------------------------------------------------
h4. Purpose:
This document outlines the issues encountered while trying to implement merging of EJB3 deployment descriptor and annotations for AS 7.0.0.Beta2
h4. Details:
h5. Pre-AS7 deployers and metdata merging:
Typically the way we used to create a merged view of deployment descriptor (DD) values with annotation values involved the following:
* 2 separate views were maintained during deployment processing. One view corresponding to DD values and the other for annotations
* After a certain point, the 2 views would be merged into one
* After that point, the deployers which required to work on the metadata, would start using the merged view of the metadata
h5. AS7 Deployment Unit Processors (DUPs):
The previous mentioned steps would ideally have worked out in the current AS7 DUP framework. However, most (all?) of the EE specific DUPs which work on annotations expect the metadata (== *ComponentDescription) to be available. For example, see the ResourceInjectionAnnotationParsingProcessor. It gets hold of a AbstractComponentDescription and starts looking for annotations on that component class. The AbstractComponentDescription is fetched from the EEModuleDescription and leads to a chicken and egg problem. For example, while working on EJB3 DD + annotation merging, this is what I initially tried:
1. Various (ordered) EJB DD processing DUPs running first and creating the EJBComponentDescription(s).
2. Various (ordered) annotation DUPs running after the DD based DUPs and creating a parallel EJBComponentDescription(s).
3. A merging DUP which merges the EJBComponentDescription(s) created in #1 and #2 and then attaching each of these EJBComponentDescriptions to EEModuleDescription.
4. Rest of the DUPs then working off the merged EJBComponentDescription(s) by fetching them from the EEModuleDescription.
The problem with this approach is that the DUPs like ResourceInjectionAnnotationParsingProcessor which scan for annotations require the EJBComponentDescription to be available in EEModuleDescription for it to fire. Effectively, until #3 is done (the merging of DD + annotations), such DUPs can't fire. However, for #3 (a.k.a merging) to be successfully completed we need the ResourceInjectionAnnotationParsingProcessor and such DUPs to fire. Effectively this leads to a chicken and egg issue.
There's one other approach which I tried out (with issues of its own), the one which is currently implemented (and broken) in upstream, for merging DD + annotations. That approach was more of a workaround for this main issue and isn't really relevant at this point. However, I can outline that approach here if required (just need to recap some finer details on why it is broken)
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-16688]
Create a new document in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
13 years
[JBoss AS7 Development] - EJB3 support in JBoss AS 7.0.0.Beta2
by Carlo de Wolf
Carlo de Wolf [http://community.jboss.org/people/wolfc] modified the document:
"EJB3 support in JBoss AS 7.0.0.Beta2"
To view the document, visit: http://community.jboss.org/docs/DOC-16682
--------------------------------------------------------------
This document outlines the EJB 3.x support that's currently available in JBoss AS 7.0.0.Beta2
h3. Support for EJB 3.x session beans
h4. Annotation based support
h5. @Stateless, @Stateful, @Singleton :
JBoss AS 7.0.0.Beta2 has support for annotation based session beans (i.e. @Stateless, @Stateful and @Singleton). A bean annotated with any of these session bean annotation will be picked up and processed appropriately.
h5. Local annotated views:
* @Local and @LocalBean : JBoss AS 7.0.0.Beta2 supports local business interface view and the no-interface view of session beans.
* @Remote view: Currently, the @Remote annotation is processed and a view is created out of it. However, remote view semantics don't apply and it works the same as a @Local.
* @RemoteHome and @LocalHome view: Furthermore, there is *no* support yet for EJB2.x views (via @LocalHome and @RemoteHome)
h5. Tansaction management annotations:
* @TransactionManagement : JBoss AS 7.0.0.Beta2 supports both container managed transactions and bean managed transactions, configured through annotations.
* @TransactionAttribute : Various different transaction attributes (configured via @TransactionAttribute annotation) are also supported. Note that JBoss specific way of setting a transaction timeout through an annotation is *not* yet supported in this version.
h5. Concurrency management annotations:
* @ConcurrencnyManagement : Both bean and container managed concurrency support for @Singleton beans is available in JBoss AS 7.0.0.Beta2.
* @Lock : Both READ and WRITE lock support is also available in JBoss AS 7.0.0.Beta2
* @AccessTimeout : Support for configuring an access timeout through the @AccessTimeout annotation is also available in JBoss AS 7.0.0.Beta2.
h5. Init on Startup for singleton beans:
* @Startup : Init-on-startup support for singleton beans, through the use of @Startup is available in JBoss AS 7.0.0.Beta2
h5. Dependencies configuration for singleton beans:
* @DependsOn : Only a partial support is available for this annotation in JBoss AS 7.0.0.Beta2. The annotation is processed and appropriate dependencies are added between the singleton beans. This works fine against @Startup @Singleton beans. But for normal (lazy) @Singleton beans, the @DependsOn may not work as mandated by the spec. This will be fixed in later versions of JBoss AS 7.0.0.Beta2
h5. Resource injection and EJB injection:
* @Resource and @EJB : These annotations are supported in JBoss AS 7.0.0.Beta2. These can be used in container managed components to inject the resources and EJBs respectively.
h4. ejb-jar.xml deployment descriptor based support
* Support for session beans: JBoss AS 7.0.0.Beta2 allows you to configure your session beans through the use of ejb-jar.xml. All types of session beans (Stateless, Stateful and Singleton) are supported.
* Transaction Management support: You can configure transaction management semantic through the use of ejb-jar.xml for your session beans. Both bean managed transactions and container managed transactions are supported.
* Support for business views: Currently only business-local and local-bean views are supported through ejb-jar.xml for session beans. business-remote element is processed and a view is created out of it, but remote semantics haven't been implemented and it works like a business-local for now.
* Support for interceptors: JBoss AS 7.0.0.Beta2 has support for interceptors of EJBs configured via ejb-jar.xml. However, explicit interceptor-ordering isn't yet supported.
h4. Merged view of annotations and ejb-jar.xml for EJBs
Although there is an initial implementation available in JBoss AS 7.0.0.Beta2 for supporting partial deployment descriptor + partial annotation based EJBs, it's still in its early stages and isn't stable. Upcoming releases will have better support for a merged view of EJBs.
h3. Where to ask questions or report issues:
If you run into any issue while trying out any EJB3 application against JBoss AS 7, then please either report it in the user forums http://community.jboss.org/en/jbossas?view=discussions http://community.jboss.org/en/jbossas?view=discussions or subscribe to the AS7 mailing list https://lists.jboss.org/mailman/listinfo/jboss-as7-dev https://lists.jboss.org/mailman/listinfo/jboss-as7-dev and mail your question there.
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-16682]
Create a new document in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
13 years
[JBoss AS7 Development] - EJB3 support in JBoss AS 7.0.0.Beta2
by jaikiran pai
jaikiran pai [http://community.jboss.org/people/jaikiran] modified the document:
"EJB3 support in JBoss AS 7.0.0.Beta2"
To view the document, visit: http://community.jboss.org/docs/DOC-16682
--------------------------------------------------------------
This document outlines the EJB 3.x support that's currently available in JBoss AS 7.0.0.Beta2h3. Support for EJB 3.x session beansh4. Annotation based supporth5. @Stateless, @Stateful, @Singleton :
JBoss AS 7.0.0.Beta2 has support for annotation based session beans (i.e. @Stateless, @Stateful and @Singleton). A bean annotated with any of these session bean annotation will be picked up and processed appropriately.h5. Local annotated views: * @Local and @LocalBean : JBoss AS 7.0.0.Beta2 supports local business interface view and the no-interface view of session beans. * @Remote view: Currently, this annotation is processed and a business view is created out of it. But remote semantics do not yet work and a @Remote behaves the same as a @Local for now. * @RemoteHome and @LocalHome view: Furthermore, there is *no* support yet for EJB2.x views (via @LocalHome and @RemoteHome) h5. Tansaction management annotations: * @TransactionManagement : JBoss AS 7.0.0.Beta2 supports both container managed transactions and bean managed transactions, configured through annotations. * @TransactionAttribute : Various different transaction attributes (configured via @TransactionAttribute annotation) are also supported. Note that JBoss specific way of setting a transaction timeout through an annotation is *not* yet supported in this version. h5. Concurrency management annotations: * @ConcurrencnyManagement : Both bean and container managed concurrency support for @Singleton beans is available in JBoss AS 7.0.0.Beta2. * @Lock : Both READ and WRITE lock support is also available in JBoss AS 7.0.0.Beta2 * @AccessTimeout : Support for configuring an access timeout through the @AccessTimeout annotation is also available in JBoss AS 7.0.0.Beta2. h5. Init on Startup for singleton beans: * @Startup : Init-on-startup support for singleton beans, through the use of @Startup is available in JBoss AS 7.0.0.Beta2 h5. Dependencies configuration for singleton beans: * @DependsOn : Only a partial support is available for this annotation in JBoss AS 7.0.0.Beta2. The annotation is processed and appropriate dependencies are added between the singleton beans. This works fine against @Startup @Singleton beans. But for normal (lazy) @Singleton beans, the @DependsOn may not work as mandated by the spec. This will be fixed in later versions of JBoss AS 7.0.0.Beta2 h5. Resource injection and EJB injection: * @Resource and @EJB : These annotations are supported in JBoss AS 7.0.0.Beta2. These can be used in container managed components to inject the resources and EJBs respectively.h4. ejb-jar.xml deployment descriptor based support* Support for session beans: JBoss AS 7.0.0.Beta2 allows you to configure your session beans through the use of ejb-jar.xml. All types of session beans (Stateless, Stateful and Singleton) are supported.* Transaction Management support: You can configure transaction management semantic through the use of ejb-jar.xml for your session beans. Both bean managed transactions and container managed transactions are supported.* Support for business views: Currently only business-local and local-bean views are supported through ejb-jar.xml for session beans. business-remote element is processed and a view is created out of it, but remote semantics aren't yet supported. Instead it works as a business-local for now. * Support for interceptors: JBoss AS 7.0.0.Beta2 has support for interceptors of EJBs configured via ejb-jar.xml. However, explicit interceptor-ordering isn't yet supported.h4. Merged view of annotations and ejb-jar.xml for EJBsAlthough there is an initial implementation available in JBoss AS 7.0.0.Beta2 for supporting partial deployment descriptor + partial annotation based EJBs, it's still in its early stages and isn't stable. Upcoming releases will have better support for a merged view of EJBs.h3. Where to ask questions or report issues:If you run into any issue while trying out any EJB3 application against JBoss AS 7, then please either report it in the user forums http://community.jboss.org/en/jbossas?view=discussions http://community.jboss.org/en/jbossas?view=discussions or subscribe to the AS7 mailing list https://lists.jboss.org/mailman/listinfo/jboss-as7-dev https://lists.jboss.org/mailman/listinfo/jboss-as7-dev and mail your question there.
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-16682]
Create a new document in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
13 years
[JBoss AS7 Development] - Writing a AS7 Test Case in testsuite module
by Brian Stansberry
Brian Stansberry [http://community.jboss.org/people/brian.stansberry] modified the document:
"Writing a AS7 Test Case in testsuite module"
To view the document, visit: http://community.jboss.org/docs/DOC-16664
--------------------------------------------------------------
**
#Background Background
**
#Requirements Requirements
**
#Choices_of_Technologies Choices of Technologies
**
#Test_Case Test Case
**
#Web_Deployment Web Deployment
**
#Where_should_I_look_for_the_source_code Where should I look for the source code?
**
#Show_me_the_test_in_action_buddy Show me the test in action, buddy
**
#Troubleshooting Troubleshooting
h2. Background
h2.
I wanted to write a test case for web security using FORM authentication in the AS7 testsuite. I chose the testsuite/integration submodule.
h2.
h2. Requirements
* I wanted to be able to run the test case in Eclipse.
* I wanted to use JPDA to set breakpoints in the AS7 codebase.
h2.
h2. Choices of Technologies
* Arquilian
* Shrinkwrap
* JUnit
* Eclipse
*Note*: Both Arquilian and Shrinkwrap are available in the AS7 development environment by default.
h2.
h2. Test Case
/*
* JBoss, Home of Professional Open Source.
* Copyright (c) 2011, Red Hat, Inc., and individual contributors
<snip> Copyright header
*/
package org.jboss.as.testsuite.integration.websecurity;
import static org.junit.Assert.assertEquals;
import java.io.File;
import java.net.URL;
import java.util.ArrayList;
import java.util.List;
import org.apache.http.Header;
import org.apache.http.HttpEntity;
import org.apache.http.HttpResponse;
import org.apache.http.NameValuePair;
import org.apache.http.StatusLine;
import org.apache.http.client.entity.UrlEncodedFormEntity;
import org.apache.http.client.methods.HttpGet;
import org.apache.http.client.methods.HttpPost;
import org.apache.http.cookie.Cookie;
import org.apache.http.impl.client.DefaultHttpClient;
import org.apache.http.message.BasicNameValuePair;
import org.apache.http.protocol.HTTP;
import org.jboss.arquillian.api.Deployment;
import org.jboss.arquillian.api.Run;
import org.jboss.arquillian.api.RunModeType;
import org.jboss.arquillian.junit.Arquillian;
import org.jboss.shrinkwrap.api.ShrinkWrap;
import org.jboss.shrinkwrap.api.spec.WebArchive;
import org.junit.Test;
import org.junit.runner.RunWith;
/**
* Unit Test web security
*
* @author Anil Saldhana
*/
@RunWith(Arquillian.class)
@Run(RunModeType.AS_CLIENT)
public class WebSecurityFORMTestCase {
private static final String URL = "http://localhost:8080/web-secure/secured/";
@Deployment
public static WebArchive deployment() {
ClassLoader tccl = Thread.currentThread().getContextClassLoader();
URL webxml = tccl.getResource("web-secure.war/web.xml");
WebArchive war = ShrinkWrap.create(WebArchive.class, "web-secure.war");
war.addClass(SecuredServlet.class);
URL userProp = tccl.getResource("web-secure.war/users.properties");
URL roleProp = tccl.getResource("web-secure.war/roles.properties");
URL loginJSP = tccl.getResource("web-secure.war/login.jsp");
URL errorJSP = tccl.getResource("web-secure.war/error.jsp");
war.addResource(loginJSP, "login.jsp");
war.addResource(errorJSP, "error.jsp");
war.addResource(userProp, "/WEB-INF/classes/users.properties");
war.addResource(roleProp, "/WEB-INF/classes/roles.properties");
war.setWebXML(webxml);
return war;
}
/**
* Test with user "anil" who has the right password and the right role to access the servlet
*
* @throws Exception
*/
@Test
public void testSuccessfulAuth() throws Exception {
makeCall("anil", "anil", 200);
}
/**
* <p>
* Test with user "marcus" who has the right password but does not have the right role
* </p>
* <p>
* Should be a HTTP/403
* </p>
*
* @throws Exception
*/
@Test
public void testUnsuccessfulAuth() throws Exception {
makeCall("marcus", "marcus", 403);
}
protected void makeCall(String user, String pass, int expectedStatusCode) throws Exception {
DefaultHttpClient httpclient = new DefaultHttpClient();
try {
HttpGet httpget = new HttpGet(URL);
HttpResponse response = httpclient.execute(httpget);
HttpEntity entity = response.getEntity();
if (entity != null)
entity.consumeContent();
// We should get the Login Page
StatusLine statusLine = response.getStatusLine();
System.out.println("Login form get: " + statusLine);
assertEquals(200, statusLine.getStatusCode());
System.out.println("Initial set of cookies:");
List<Cookie> cookies = httpclient.getCookieStore().getCookies();
if (cookies.isEmpty()) {
System.out.println("None");
} else {
for (int i = 0; i < cookies.size(); i++) {
System.out.println("- " + cookies.get(i).toString());
}
}
// We should now login with the user name and password
HttpPost httpost = new HttpPost(URL + "/j_security_check");
List<NameValuePair> nvps = new ArrayList<NameValuePair>();
nvps.add(new BasicNameValuePair("j_username", user));
nvps.add(new BasicNameValuePair("j_password", pass));
httpost.setEntity(new UrlEncodedFormEntity(nvps, HTTP.UTF_8));
response = httpclient.execute(httpost);
entity = response.getEntity();
if (entity != null)
entity.consumeContent();
statusLine = response.getStatusLine();
// Post authentication - we have a 302
assertEquals(302, statusLine.getStatusCode());
Header locationHeader = response.getFirstHeader("Location");
String location = locationHeader.getValue();
HttpGet httpGet = new HttpGet(location);
response = httpclient.execute(httpGet);
entity = response.getEntity();
if (entity != null)
entity.consumeContent();
System.out.println("Post logon cookies:");
cookies = httpclient.getCookieStore().getCookies();
if (cookies.isEmpty()) {
System.out.println("None");
} else {
for (int i = 0; i < cookies.size(); i++) {
System.out.println("- " + cookies.get(i).toString());
}
}
// Either the authentication passed or failed based on the expected status code
statusLine = response.getStatusLine();
assertEquals(expectedStatusCode, statusLine.getStatusCode());
} finally {
// When HttpClient instance is no longer needed,
// shut down the connection manager to ensure
// immediate deallocation of all system resources
httpclient.getConnectionManager().shutdown();
}
}
}
In this test case, I am specifying that the test case should run using Arquilian (via @RunWith) annotation. Plus I am telling Arquilian to run the test as a client test case and not inside AS7. [via @Run(RunModeType.AS_CLIENT) ] +If you want the test to run inside AS7, then you have to use IN_CONTAINER (which is default anyway).+
Also note above. that I am adding users.properties and roles.properties to WEB-INF/classes directory inside the Web Archive.+
+
h2. Web Deployment
h2.
I need the following Items in my web archive
* Servlet
* web.xml
* Two properties files (users.properties and roles.properties)
Let us look at the servlet
/*
* JBoss, Home of Professional Open Source.
* Copyright (c) 2011, Red Hat, Inc., and individual contributors
* as indicated by the @author tags. See the copyright.txt file in the
* distribution for a full listing of individual contributors.
* <SNIP>
*/
package org.jboss.as.testsuite.integration.websecurity;
import java.io.IOException;
import java.io.Writer;
import javax.servlet.ServletException;
import javax.servlet.annotation.HttpConstraint;
import javax.servlet.annotation.ServletSecurity;
import javax.servlet.annotation.WebServlet;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
/**
* A simple servlet that just writes back a string
*
* @author Anil Saldhana
*/
@WebServlet(urlPatterns = { "/secured/" })
@ServletSecurity(@HttpConstraint(rolesAllowed = { "gooduser" }))
public class SecuredServlet extends HttpServlet {
private static final long serialVersionUID = 1L;
@Override
protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
Writer writer = resp.getWriter();
writer.write("GOOD");
}
}
My test resources were in a folder as
web-secure.war/
login.jsp
error.jsp
users.properties
roles.properties
web.xml
h2.
h2. Where should I look for the source code?
https://github.com/anilsaldhana/jboss-as/commit/0efdc673a45d6d17255918324...
https://github.com/anilsaldhana/jboss-as/commit/0efdc673a45d6d17255918324... https://github.com/anilsaldhana/jboss-as/commit/0efdc673a45d6d17255918324...
h2.
h2.
h2. Show me the test in action, buddy
anil@localhost:~/as7/jboss-as/testsuite/integration$ mvn clean install
Running org.jboss.as.testsuite.integration.websecurity.WebSecurityFORMTestCase
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.531 sec
h2.
h2. Troubleshooting
* How do I run AS7 with JPDA enabled?
** Uncomment the following line in bin/standalone.conf
** #JAVA_OPTS="$JAVA_OPTS -Xrunjdwp:transport=dt_socket,address=8787,server=y,suspend=y"
* Any Eclipse settings for the test case?* VM arguments in the eclipse config for the test case was
* -Djboss.home=/home/anil/as7/jboss-as/testsuite/integration/../../build/target/jboss-7.0.0.Beta2
* How do I see what is in the web archive ShrinkWrap creates? You definitely need to add this always.* System.out.println(war.toString(true));
* What about when Arquilian is running in a managed mode?* Stuart Douglas gave some insight into this.
* There are two ways, you can either start a standalone instance and attach your
debugger to it normally,
and then run
mvn install -Premote -Dtest=com.my.Test
Alternatively
mvn install -Djboss.options="-Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=8787"
And then attach. This way will not let you use -Dtest= though,
so generally when I am debugging I use the remote profile.
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-16664]
Create a new document in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
13 years
