Enterprise Java Development@TOPIC@
We will be using the JBoss/Wildfly Application Server this semester. This is a fully-compliant JavaEE 8 application server.
JBoss has a community version (formerly called JBoss AS - renamed Wildfly ~2012) and commercial version (JBoss EAP) of their JavaEE application server. Both are open source and built off the same code base. In theory, changes propagate through the community version first in daily changes and short iterations. In theory, commercial version is a roll-up of a stable version of the community version with the ability to purchase support on that specific version. With commercial version support - you can receive patches for a specific issue prior to upgrading to the latest release. With the community version - you pretty much need to keep up with the latest release to get any patches. Of course, with either version you are free to perform your own support and code changes, but you can only get this commercially with the EAP release. There is a newsgoup post and slide show that provides a decent, short description of the two.
JBoss makes the EAP version available for *development* use from jboss.org but lags behind Wildfly (at wildfly.org) for obvious reasons. We will be using the open source/Wildfly version of the server.
JBoss AS/Wildfly version numbers are ahead of JBoss EAP because not every community version becomes a commercial version. JBoss AS 6 was skipped entirely by EAP.
Download Wildfly 17.0.1.Final https://www.wildfly.org/downloads/. The 'Quickstarts' examples are also helpful but class notes, exercises, and guidance may have simplified or alternative approaches to what is contained in the guides.
Install JBoss into a directory that does not have any spaces in its path.
$ unzip ~/Downloads/wildfly-17.0.1.Final.zip
$ ls wildfly-17.0.1.Final/
appclient bin copyright.txt docs domain jboss-modules.jar LICENSE.txt modules README.txt standalone welcome-content
Test the installation by starting the default configuration installation.
$ ./wildfly-17.0.1.Final/bin/standalone.sh ========================================================================= JBoss Bootstrap Environment JBOSS_HOME: /opt/wildfly-17.0.1.Final JAVA: java JAVA_OPTS: -server -Xms64m -Xmx512m -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true --add-exports=java.base/sun.nio.ch=ALL-UNNAMED --add-exports=jdk.unsupported/sun.misc=ALL-UNNAMED --add-exports=jdk.unsupported/sun.reflect=ALL-UNNAMED ========================================================================= 17:37:03,254 INFO [org.jboss.modules] (main) JBoss Modules version 1.9.1.Final 17:37:04,270 INFO [org.jboss.msc] (main) JBoss MSC version 1.4.8.Final 17:37:04,292 INFO [org.jboss.threads] (main) JBoss Threads version 2.3.3.Final 17:37:04,558 INFO [org.jboss.as] (MSC service thread 1-1) WFLYSRV0049: WildFly Full 17.0.1.Final (WildFly Core 9.0.2.Final) starting ... 17:37:11,257 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://127.0.0.1:9990/management 17:37:11,259 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://127.0.0.1:9990 17:37:11,259 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Full 17.0.1.Final (WildFly Core 9.0.2.Final) started in 8842ms - Started 314 of 576 services (369 services are lazy, passive or on-demand)
There are .sh version of scripts for *nix platforms and .bat forms of the scripts for Windows platforms. Use the one that is appropriate for your environment.
Verify you can access the server
Main Page:http://localhost:8080
Admin Page:http://localhost:9990/console This will fail until the admin account is added.
Shutdown the server using Control-C
Copy over the class example server files from what you cloned and built from github earlier.
$ cd wildfly-17.0.1.Final wildfly-17.0.1.Final]$ unzip .../ejava-student/servers/ejava-wildfly1701/target/ejava-wildfly1701-5.1.0-SNAPSHOT-server.zip Archive: .../ejava-student/servers/ejava-wildfly1701/target/ejava-wildfly1701-5.1.0-SNAPSHOT-server.zip replace standalone/configuration/application-roles.properties? [y]es, [n]o, [A]ll, [N]one, [r]ename: A inflating: standalone/configuration/application-roles.properties inflating: standalone/configuration/application-users.properties inflating: standalone/configuration/application.keystore inflating: standalone/configuration/standalone.xml inflating: domain/configuration/application-roles.properties inflating: domain/configuration/application-users.properties
Restart the server
There is a bug within the Artemis JMS logging initialization that requires an upgrade of that software to fix. I have seen the error on Windows but not on *Nix systems. It is activated when we added the ejava class configuration files because the class configuration adds JMS -- which is not part of the standard configuration.
18:13:50,363 WARN [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 82) AMQ222277: Problem initializing automatic logging configuration reload for file:c:\apps\wildfly-17.0.1.Final\standalone\configuration/logging.properties: java.net.URISyntaxException: Illegal character in opaque part at index 7: file:c:\apps\wildfly-17.0.1.Final\standalone\configuration/logging.properties
Use the batch script to add an admin user to the system. Note the password must have at least one digit and one non-alphanumeric character. If you run the application server on a remote machine or under a different account, please use the jboss.user and jboss.password supplied in build/dependencies/pom.xml. JBoss/Wildfly will bypass user credentials when the client executes on the same machine by the same user that started the server.
ejava-student]$ egrep 'jboss.user|jboss.password' -R build build/ejava-build-parent/pom.xml: <jboss.user>admin</jboss.user> build/ejava-build-parent/pom.xml: <jboss.password>password1!</jboss.password>
$ ./bin/add-user.sh
What type of user do you wish to add?
a) Management User (mgmt-users.properties)
b) Application User (application-users.properties)
(a):
Enter the details of the new user to add.
Using realm 'ManagementRealm' as discovered from the existing property files.
Username : admin
User 'admin' already exists and is disabled, would you like to...
a) Update the existing user password and roles
b) Enable the existing user
c) Type a new username
(a): a
Password recommendations are listed below. To modify these restrictions edit the add-user.properties configuration file.
- The password should be different from the username
- The password should not be one of the following restricted values {root, admin, administrator}
- The password should contain at least 8 characters, 1 alphabetic character(s), 1 digit(s), 1 non-alphanumeric symbol(s)
Password :
Re-enter Password :
What groups do you want this user to belong to? (Please enter a comma separated list, or leave blank for none)[ ]:
Updated user 'admin' to file '/opt/wildfly-17.0.1.Final/standalone/configuration/mgmt-users.properties'
Updated user 'admin' to file '/opt/wildfly-17.0.1.Final/domain/configuration/mgmt-users.properties'
Updated user 'admin' with groups to file '/opt/wildfly-17.0.1.Final/standalone/configuration/mgmt-groups.properties'
Updated user 'admin' with groups to file '/opt/wildfly-17.0.1.Final/domain/configuration/mgmt-groups.properties'
Is this new user going to be used for one AS process to connect to another AS process?
e.g. for a slave host controller connecting to the master or for a Remoting connection for server to server EJB calls.
yes/no? no
Retry logging into the Admin Application http://localhost:9990/console
Wildfly comes already prepared for remote debugging using a command line option. Therefore there is no longer anything detailed to do with step (nice!)
Restart the Wildfly server in debug mode. The default port is 8787, but can be easily customized with an extra command line argument.
## from bin/standalone.sh # Use --debug to activate debug mode with an optional argument to specify the port. # Usage : standalone.sh --debug # standalone.sh --debug 9797
Restart the server and notice the additional listen output. Use control-C to stop the server.
$ ./bin/standalone.sh --debug ========================================================================= ... ========================================================================= Listening for transport dt_socket at address: 8787 <control-C> $ ./bin/standalone.sh --debug 8000 ========================================================================= ... ========================================================================= Listening for transport dt_socket at address: 8000
If you already have a process listening on localhost:8080 or any of
the other JBoss ports on 127.0.0.1, you can switch addresses
by editing the interfaces section of
standandalone.xml. You can also do this at runtime by adding
-Djboss.bind.address.management=...
and/or
-Djboss.bind.address=... on the command line.
Note that I said "If..." above. You only need to modify the network information if you are running into a conflict on your development platform. Change is not hard, but keeping the default is the simplest way to go.
<interfaces>
<interface name="management">
<loopback-address value="${jboss.bind.address.management:127.0.0.2}"/>
</interface>
<interface name="public">
<loopback-address value="${jboss.bind.address:127.0.0.2}"/>
</interface>
<interface name="unsecure">
<inet-address value="${jboss.bind.address.unsecure:127.0.0.2}"/>
</interface>
</interfaces>
Provide a specification to maven where your JBoss server
has been installed in the .m2/settings.xml
file using the jboss.home property. *If* you
have changed the address - you can specify that using
the jboss.host property.
<profile>
<id>wildfly17</id>
<properties>
<jboss.host>127.0.0.2</jboss.host>
<jboss.home>/opt/wildfly-17.0.1.Final</jboss.home>
</properties>
</profile>
</profiles>
...
<activeProfiles>
<activeProfile>wildfly17</activeProfile>
<activeProfile>h2db</activeProfile>
</activeProfiles>
</settings>