<commit_before>:doctype: book
:toc:
:toclevels: 2

= WildFly for modern application development

[[introduction]]
== Introduction to WildFly
. Explain the difference with JBoss EAP
. Download, install, and start
.. Standalone mode
.. Domain mode

[[development]]
== Development
. IDE: IntelliJ, JBoss Developer Studio/Eclipse, NetBeans
. Forge

[[deployment]]
== Deployment
. jboss-cli
. Admin Console
. File system-based
. Maven plugin
. REST API
include::jrebel.asciidoc[]

[[testing]]
== Testing

Arquillian brings the test to runtime so that you don't have to manage the runtime from the test (or build). It covers all aspects of test execution:

. Manage the lifecycle of the container (or containers)
. Bundling the test case, dependent classes and resources into a ShrinkWrap archive (or archives)
. Deploy the archive (or archives) to the container (or containers)
. Enriching the test case by providing dependency injection and other declarative services
. Executing the tests inside (or against) the container
. Capturing the results and returning them to the test runner for reporting

Three guiding principles:

. Tests should be portable to any supported container
. Tests should be executable from both the IDE and the build tool
. The platform should extend or integrate existing test frameworks

Generate a simple Java EE 7 sample with pre-defined Arquillian dependencies:

[source,text]
----
 mvn --batch-mode archetype:generate \\
     -DarchetypeGroupId=org.javaee-samples \\
     -DarchetypeArtifactId=javaee7-arquillian-archetype \\
     -DarchetypeVersion=1.0.0 \\
     -DarchetypeRepository=http://dl.bintray.com/javaee-samples/JavaEE-Samples \\
     -DgroupId=org.wildfly.samples.javaee7.arquillian \\
     -DartifactId=arquillian
----

=== Remote container

=== Managed container
Managed Container is simply a remote container that also includes lifecycle management (start and stop). Container process is started in a different JVM. Once the container is up and running, it just behaves like a remote container.

[[rbac]]
== RBAC

Role Based Access Control (RBAC) is the ability to restrict access to system or certain portions of it to authorized users. For JBoss AS 7.x or JBoss EAP 6.0 and 6.1, the web-based administrative console had an all-or-nothing approach. So if a user can authenticate with management security realm, then he'll have all the privileges. This might be OK for smaller deployments but the roles are typically divided for mission critical deployments and a finer-grained control is required.

WildFly 8 introduces RBAC using different roles. There are essential 7 different roles in 2 different categories – administrative and privileged:

. Monitor
. Operator
. Maintainer
. Deployer
. Administrator
. Auditor
. Super User

Each Role is defined as a set of Permissions and Permissions specify what Actions are permitted by the logged in user, which is basically lookup, write, or delete.

Show basic functionality using Admin Console from https://vimeo.com/78780176[Part 1], https://vimeo.com/78785944[Part 2], https://vimeo.com/78786992[Part 3]. Here are the features that need to be highlighted:

. Start using `.bin/domain.sh`
. Access Admin Console at http://localhost:9090, show the error message.
. Create user in management realm using add-user.sh, use ``<PASSWORD>'' as user and password.
. Reload the Admin Console and show that login now works.
. Click on Administration tab and explain Access Control Providers.
. Change access control provider by giving the following command interactively on `jboss-cli`:
+
[source,text]
----
[domain@localhost:9990 /] /core-service=management/access=authorization:write-attribute(name=provider,value=rbac)
[domain@localhost:9990 /] reload --host=master
----
+
. Hmm, Admin Console is not accessible now. Restarting the server also did not help, debugging ...

== Clustering + Session failover

Run the video from https://vimeo.com/89157225[]. It shows:

. Introduction to WildFly and Managed Domain concepts
. Setup up a 2-instance cluster
. Deploy a WAR file to the cluster using centralized administration from admin console
. Access the application on one node and add HTTP session attributes on it
. Shutdown that instance and show HTTP session failover by accessing the application on other instance

[[paas]]
== PaaS

=== OpenShift

. Create an OpenShift application using WildFly cartridge
. Access the WildFly administration console using port forwarding
. Import the created application in JBoss Developer Studio/IntelliJ
. Make changes to the application and view them in the deployed application
. Add a simple Java EE 7 component to the application

=== Cloudbees<commit_msg>added more rbac content, and starting jboss-cli content<commit_after>:doctype: book
:toc:
:toclevels: 2

= WildFly for modern application development

[[introduction]]
== Introduction to WildFly
. Explain the difference with JBoss EAP
. Download, install, and start
.. Standalone mode
.. Domain mode

[[development]]
== Development
. IDE: IntelliJ, JBoss Developer Studio/Eclipse, NetBeans
. Forge

[[deployment]]
== Deployment
=== jboss-cli

WildFly comes with a Command Line Interface management tool for a standalone server or a managed domain. This script is in the `bin` directory of WildFly distrbution and can be invoked by calling `jboss-cli.sh` for Mac/Linux based systems or `jboss-cli.bat` for Windows. It allows a user to connect to a standalone server or domain controller and execute management operations available through the management model.

. Start a WildFly standalone server, if not already running, using the following command:
+
[source, text]
----
standalone.sh
----
+
. Use `jboss-cli' to connect with this instance by giving the following command:
+
[source]
----
jboss-cli.sh -c
----
+
The `-c` switch connects using the default host (`localhost') and management port (`9990'). These values are specified in `bin/jboss-cli.xml' and can be updated.
+
This opens up the `jboss-cli' interactive console and shows the following prompt:
+
[source]
----
[standalone@localhost:9990 /]
----
+
The prompt indicates that `jboss-cli' is connected to a standalone instance's default management port.
+
. If WildFly instance is running on a different host and/or port, then `--controller` switch can be used to specify that information.
+
.. In another shell, start another WildFly instance on a different port using the following command:
+
[source]
----
./bin/standalone.sh -Djboss.socket.binding.port-offset=10000
----
+
This will start another WildFly standalone instance on application port 18080 and management port 19090.
+
.. Use `jboss-cli' to connect with this instance by giving the following command:
+
[source]
----
jboss-cli.sh -c --controller=localhost:19990
----
+
This opens up the `jboss-cli' interactive console and shows the following prompt:
+
[source]
----
[standalone@localhost:19990 /]
----
+
The prompt indicates that `jboss-cli' is connected to a standalone instance on port `19990'.

WildFly internal management model consists of _management resources_ that that are added, removed, or modified by using _operations_ and _commands_. Operations are low level but a comprehensive way to manage the server. Commands are more user-friendly, although most of them still translate into operation requests and some of them even into a few composite operation requests.

All resources are organized in a tree. The path to the node in the tree for a particular resource is its _address_ and is identified by `/`.

Each resource expose information about their state as _attributes_.

Each resource may support child resources.

All resources expose metadata that describes their attributes, operations, and child types. This metadata can be queried by invoking one or more of the _global operations_ supported by the resource.

Command and operation request history is enabled by default. While in the command line session, you can use the arrow keys to go back and forth in the history of commands and operations.

=== Admin Console

=== File system-based

=== Maven plugin

=== REST API

include::jrebel.asciidoc[]

[[testing]]
== Testing

Arquillian brings the test to runtime so that you don't have to manage the runtime from the test (or build). It covers all aspects of test execution:

. Manage the lifecycle of the container (or containers)
. Bundling the test case, dependent classes and resources into a ShrinkWrap archive (or archives)
. Deploy the archive (or archives) to the container (or containers)
. Enriching the test case by providing dependency injection and other declarative services
. Executing the tests inside (or against) the container
. Capturing the results and returning them to the test runner for reporting

Three guiding principles:

. Tests should be portable to any supported container
. Tests should be executable from both the IDE and the build tool
. The platform should extend or integrate existing test frameworks

Generate a simple Java EE 7 sample with pre-defined Arquillian dependencies:

[source,text]
----
 mvn --batch-mode archetype:generate \\
     -DarchetypeGroupId=org.javaee-samples \\
     -DarchetypeArtifactId=javaee7-arquillian-archetype \\
     -DarchetypeVersion=1.0.0 \\
     -DarchetypeRepository=http://dl.bintray.com/javaee-samples/JavaEE-Samples \\
     -DgroupId=org.wildfly.samples.javaee7.arquillian \\
     -DartifactId=arquillian
----

=== Remote container

=== Managed container
Managed Container is simply a remote container that also includes lifecycle management (start and stop). Container process is started in a different JVM. Once the container is up and running, it just behaves like a remote container.

[[rbac]]
== RBAC

Role Based Access Control (RBAC) is the ability to restrict access to system or certain portions of it to authorized users. For JBoss AS 7.x or JBoss EAP 6.0 and 6.1, the web-based administrative console had an all-or-nothing approach. So if a user can authenticate with management security realm, then he'll have all the privileges. This might be OK for smaller deployments but the roles are typically divided for mission critical deployments and a finer-grained control is required.

WildFly 8 introduces RBAC using different roles. There are essential 7 different roles in 2 different categories – administrative and privileged:

. Monitor
. Operator
. Maintainer
. Deployer
. Administrator
. Auditor
. Super User

Each Role is defined as a set of Permissions and Permissions specify what Actions are permitted by the logged in user, which is basically lookup, write, or delete.

Show basic functionality using Admin Console from https://vimeo.com/78780176[Part 1], https://vimeo.com/78785944[Part 2], https://vimeo.com/78786992[Part 3]. Here are the features that need to be highlighted:

. Start using `.bin/domain.sh`
. Access Admin Console at http://localhost:9090, show the error message.
. Create user in management realm using add-user.sh, use ``admin'' as user and password.
. Reload the Admin Console and show that login now works.
. Click on `Administration' tab and explain Access Control Providers. WildFly 8 comes with two access control providers:
.. `simple' provider, the default one, gives all privileges to any authenticated administrator. This provides compatibility with older releases.
.. `rbac' provider allows you to setup configuration that will map users to different roles.
. Change access control provider by giving the following command interactively on `jboss-cli`:
+
[source,text]
----
[domain@localhost:9990 /] /core-service=management/access=authorization:write-attribute(name=provider,value=rbac)
[domain@localhost:9990 /] reload --host=master
----
+
. Hmm, Admin Console is not accessible now. Restarting the server also did not help, debugging ...
. What to show ?
.. Show information about the logged in user on top-right.
.. A user in `Super User' role can act to run in any role by clicking on `Run as'. Click on `Run as' and select drop-down list box to see the list of available roles.
.. Select the ‘Monitor’ role and click on `Run As'.
... The application has to be reloaded for changes to take effect. Click on `Confirm' to reload the application. After the reload, clicking on the user on top-right in admin console will display the selected role as `Run as Monitor'.
... Click on `Manage Deployments' and check that `Add', ‘Remove’, and similar buttons are not present.
... Click on `Profile', `Data Sources' and check that all data sources are visible but not editable. This is identified by the fact that `Add', `Remove', and `Disable' buttons are not available as shown.
... Click on `Administration' tab and make sure the user does not have access to it.
.. Feel free to select other roles and observe how different options are enabled/disabled.
.. Talk about how roles can be assigned to users and groups.

== Clustering + Session failover

Run the video from https://vimeo.com/89157225[]. It shows:

. Introduction to WildFly and Managed Domain concepts
. Setup up a 2-instance cluster
. Deploy a WAR file to the cluster using centralized administration from admin console
. Access the application on one node and add HTTP session attributes on it
. Shutdown that instance and show HTTP session failover by accessing the application on other instance

[[paas]]
== PaaS

=== OpenShift

. Create an OpenShift application using WildFly cartridge
. Access the WildFly administration console using port forwarding
. Import the created application in JBoss Developer Studio/IntelliJ
. Make changes to the application and view them in the deployed application
. Add a simple Java EE 7 component to the application

=== Cloudbees
{'fraction_non_alphanumeric': 0.07150682930392228, 'fraction_numerical': 0.012197794171353443, 'mean_word_length': 4.239954075774971, 'pattern_counts': {'":': 0, '<': 4, '<?xml version=': 0, '>': 4, 'https://': 8, 'lorem ipsum': 0, 'www.': 0, 'xml': 1}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 8, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '4003680', 'n_tokens_mistral': 3736, 'n_tokens_neox': 3461, 'n_words': 1799}