Delving into his old records quite accidentally stumbled upon a document JBOSS 4.2.3 Manual, written by me (and in fact compiled from different sources) a few years ago. And in order not to disappear good, I decided to share some knowledge with a respected Habrasoobschestvom.
If you are a specialist with experience of more than a year, you will most likely not find anything new for yourself and can immediately pass by so as not to waste your time. The article may be useful to the following people:
- students starting their career in their IT career in Java direction
- java junior developers
- junior implementation and technical support engineers
- junior deploy and build to engineers
It is clear that the JBoss version 4.2.3 is quite old (the 8th JBoss is now relevant, which in fact is no longer “Jboss”), but I believe that it can still be useful, given the presence of a large amount of old legacy java-code and applications in the cruel interprize sector, which are still sometimes necessary to maintain.
Content
What is JBoss
JBossAS - J2EE open source application server.
Application Server is a software platform (software framework) designed for the effective execution of procedures (programs, mechanical operations, scripts) that support the construction of applications.
J2EE - Java Platform, Enterprise Edition. a set of specifications and related documentation for the Java language, which describes the architecture of the server platform for medium and large enterprises. The main goal of the specifications is to ensure application scalability and data integrity during system operation. J2EE is an industrial technology and is mainly used in high-performance projects that require reliability, scalability and flexibility.
JMX - Java Management Extensions (JMX) is a Java technology that provides tools for managing and monitoring applications, system objects, devices (such as printers), and service-oriented networks. These resources are represented by objects called MBeans.
Supported Application Formats
- The WAR application archive;
- The EAR application archive;
- The SAR application archive;
- The * -ds.xml file connections to external databases;
- XML files with MBean service definitions;
- JBoss AS JAR files
Packaged with JBoss server configurations
Minimal (minimal) - includes a logging service, a JNDI server, and a deployment scanner URL to be able to deploy applications. This is a clean server. It has no web container, EJB or JMS support. This is not a J2EE 1.4 compatible configuration.
EJB - Enterprise JavaBeans. specification of writing technology and support for server components containing business logic. It is part of Java EE.
JMS - Java Message Service. A middleware standard for messaging that allows applications running on the J2EE platform to create, send, receive, and read messages. Communication between components using JMS is asynchronous (the procedure does not wait for a response to its message) and is independent of the execution of the components.
')
Default (default) - is the base of J2EE 1.4. These are the most frequently used services needed to deploy J2EE applications. It does not include JAXR services, IIOP services, or any of the clustering services.
Java API for XML Registries (JAXR)Internet Inter-Orb Protocol IIOP is used by GIOP for TCP / IP. IIOP is a concrete implementation of abstract GIOP definitions.
GIOP (General Inter-ORB Protocol) - abstract protocol in distributed object systems
Full (all) . All configurations and all available services. This includes RMI / IIOP and clustering services that are not loaded in the default configuration.
If you want to know which services are configured in each of the configurations, look in the files:
jboss-4.2.2 / server / <instance-name / conf /
jboss-4.2.2 / server / <instance-name> / deploy
JBoss Server Administration Methods
JBoss comes with several possible administration methods that must be protected or removed to prevent unauthorized access to administrative functions during deployment.
The JMX Console (path:
localhost : [port] / jmx-console /)
Provides access to arbitrary administrative parameters, such as shutting down the server, stopping services, implementing new services, etc. It can be installed like any other web application or removed.
The Web Console (path
localhost : [port] / web-console /)
Uses a combination of applet and HTML and provides the same level of access to administrative functions as JMX-console.war.
Tomcat info (path
localhost : [port] / status? Full = true)
Information about running components
Server configuration directory structure
- conf - the directory contains server configuration files, for example, JBoss-service.xml - defines the main running services.
- data - the catalog is available for use by services that want to store content in the file system. Here the data is stored, allowing to restore the work of services after rebooting the server. Some JBoss services, such as Hypersonic databases, store form data here.
- deploy - directory contains services for deployment (those that can be added or removed while the server is running). It also contains applications for the current server configuration. The application code is deployed by placing application packages (JAR, WAR and EAR files) in the specified directory. The catalog is constantly checked for updates, and any modified components will be redeployed automatically.
- lib - the directory contains the JAR files (Java libraries that should not be deployed "on hot") necessary for this server configuration. You can add the necessary library files here. For example, JDBC drivers, etc. All JARs in this directory are loaded into the common “classpath” at startup.
- log - directory to write log files. JBoss uses the log4j package for logging, and you can also use it directly on your own applications inside the server. Logging parameters can be configured via the CONF / JBoss-log4j.xml configuration file.
- tmp - directory used to temporarily store Jboss files
- work - directory used by tomcat to compile jsp
Conf directory content
- JBoss-service.xml - defines the main services and their settings.
- jndi.properties - the file defines the JNDI InitialContext properties that are used inside the JBoss server when the InitialContext is created using the constructor with no arguments
- The Java Naming and Directory Interface (JNDI) is a Java API organized as a directory service that allows Java clients to open and view data and objects by their names.
- JBoss-log4j.xml - logging setup
- login-config.xml - this file contains authentication configurations that are used when using security based on JAAS
- JAAS - Java Authentication and Authorization Service
- props / * - directory contains users and JMX console roles
- standardjboss.xml - contains the Standard JBoss EJB configuration
- standardjbosscmp-jdbc.xml - This file is the default configuration file for the JBoss CMP (Container-Managed Persistence) engine
- xmdesc / -mbean.xml * - the directory contains XMBean descriptors for some services specified in the JBoss-service.xml file.
Content of the deploy directory
- jbossjca-service.xml is an application server implementation of the JCA specification. It provides communication management tools for integrating resource adapters on a JBoss server.
- JCA (Java EE Connector Architecture) - solutions for connecting server applications and enterprise information systems (EIS) as part of enterprise application integration solutions (EAI)
- properties-service.xml — Allows you to customize JavaBeans PropertyEditors, as well as their properties.
- Configuring EJB3 services is done by editing the ejb3-interceptors-aop.xml and ejb3.deployer files.
- ejb3-entity-cache-service.xml configuring the cluster cache for EJB3 entity beans (see Clustering ).
Running jboss
Run JBoss as an application
To start, you must run the batch file run with the necessary parameters:
run.bat usage: run.bat [options] options: -h, --help Show this help message -V, --version Show version information -- Stop processing options -D<name>[=<value>] Set a system property -d, --bootdir=<dir> Set the boot patch directory; Must be absolute or url -p, --patchdir=<dir> Set the patch directory; Must be absolute or url -n, --netboot=<url> Boot from net with the given url as base -c, --configuration=<name> Set the server configuration name -B, --bootlib=<filename> Add an extra library to the front bootclasspath -L, --library=<filename> Add an extra library to the loaders classpath -C, --classpath=<url> Add an extra url to the loaders classpath -P, --properties=<url> Load system properties from the given url -b, --host=<host or ip> Bind address for all JBoss services -g, --partition=<name> HA Partition name (default=DefaultDomain) -u, --udp=<ip> UDP multicast address -l, --log=<log4j|jdk> Specify the logger plugin type
To stop, you need to execute the shutdown batch file with the necessary parameters:
usage: shutdown [options] <operation> options: -h, --help Show this help message (default) -D<name>[=<value>] Set a system property -- Stop processing options -s, --server=<url> Specify the JNDI URL of the remote server -n, --serverName=<url> Specify the JMX name of the ServerImpl -a, --adapter=<name> Specify JNDI name of the MBeanServerConnection to use -u, --user=<name> Specify the username for authentication -p, --password=<name> Specify the password for authentication operations: -S, --shutdown Shutdown the server -e, --exit=<code> Force the VM to exit with a status code -H, --halt=<code> Force the VM to halt with a status code
Running JBoss as a service in Windows
For this purpose, you can use the
Tanuki java service wrapper .
In this case, we will have the following example: wrapper.exe -i .. \ etc \ conf \ wrapper.conf
Usage: wrapper <command> <configuration file> [configuration properties] [...] wrapper <configuration file> [configuration properties] [...] (<command> implicitly '-c') wrapper <command> (<configuration file> implicitly 'wrapper.conf') wrapper (<command> implicitly '-c' and <configuration file> 'wrapper.conf') where <command> can be one of: -c --console run as a Console application -t --start starT an NT service -a --pause pAuse a started NT service -e --resume rEsume a paused NT service -p --stop stoP a running NT service -i --install Install as an NT service -it --installstart Install and sTart as an NT service -r --remove Uninstall/Remove as an NT service -l=<code> --controlcode=<code> send a user controL Code to a running NT service -d --dump request a thread Dump -q --query Query the current status of the service -qs --querysilent Silently Query the current status of the service -v --version print the wrapper's version information. -? --help print this help message
In general,
tanuki java service wrapper is quite a useful utility, which may be worth dedicating a separate article in the future.
Running services and applications while running JBoss
./server/<instance-name>/deployWhen you delete or move application files to this folder, they will be immediately deployed with the results displayed in log files.
Example:
Remove the ear-deployer.xml file
... INFO [TomcatDeployer] undeploy, ctxPath=/mbg, warUrl=.../tmp/deploy/tmp5055106795108270921mbg-2.10.1.41.ear-contents/mbg-console-exp.war/ INFO [TomcatDeployer] undeploy, ctxPath=/webstarter, warUrl=.../tmp/deploy/tmp5055106795108270921mbg-2.10.1.41.ear-contents/mbg-webstarter-exp.war/ ....
We place the mail-service.xml file in the deploy directory
... INFO [org.jboss.mail.MailService] Mail Service bound to java:/Mail DEBUG [org.jboss.mail.MailService] Started jboss:service=Mail ...
Security Settings
To close users' access to any JBoss service, uncomment the parameters in the files (for example, to close access to jmx-console):
deploy / jmx-console.war / WEB-INF / jboss-web.xml
deploy / jmx-console.war / WEB-INF / web.xml
Username and password are taken from the file:
conf / login-config.xml
Which uses parameters from files:
conf / props
jmx-console-roles.properties
jmx-console-users.propertie
Port configuration
It is possible to specify JBoss server which ports to use for their work.
To do this, change the values ​​in the files to the necessary port numbers:
port-bindings.xml (if this file is specified in the conf / jboss-service.xml configuration and the ServiceBindingManager is set)
\ server [server_name] \ conf \ jboss-service.xmlView the currently used ports from the Web Console.
RMI Setup
RMI (Remote Method Invocation) is a program interface for calling remote methods in the Java language.
In terms of RMI, the object that calls the remote method is called the client object, and the remote object is called the server object.
Computers act as a client and server for a specific call only. It is possible that during the next operation, these computers will switch roles, that is, the server of the previous call may itself become a client when accessing an object on another computer.
A URL that a client can use to get a remote link to an object. This link is used to call the methods of a remote object. The URL is usually of the form
rmi: // host: port / Remote Object Name
where the host is the name of the computer that runs the registry server (rmiregistry) for remote objects (it is also the computer on which the remote object is running),
port is the port number on which the registry server is running on the host computer, and Remote ObjectName is the name that the client will provide when trying to locate a remote object in the registry.
To override the RMI ports in jboss, you need to change the RmiPort and RMIObjectPort parameters in the file
\ server [server_name] \ conf \ jboss-service.xml
Settings for connecting to the database
Data sources are configured in files with the suffix -ds.xml
These files can be located in the jboss / server / default / deploy directories or jboss / server / default / farm when using the JBoss cluster configuration
Examples of configuration files for connecting to the database can be seen in the documentation: jboss / docs / example / jca
Clustering
The easiest way to organize a cluster on JBosss is to launch several server instances on the local network with the -c all parameter.
Communication between nodes is accomplished using the JGroups communication library, which offers basic functionality for tracking nodes that are in a cluster and reliable messaging between cluster members.
Nodes can be dynamically added or removed from clusters at any time by starting and stopping a channel with a configuration and name that matches other members of the cluster.
By default, 4.2.x A.S., creates four different channels:
- copying web service session,
- EJB3 copying sfsb service,
- EJB3 caching services
- general purpose cluster service clustering service known as HAPartition
Load-Balancing Policy (Load Balancer)
Client side balancing
Types of client side balancing:
- Round-Robin - each request is sent to a new node, passing sequentially through the list of nodes. The first node is randomly selected from the list.
- Random-Robin — for each request, the target node is randomly selected from the list.
- First Available - one of the available nodes is randomly selected as the main target and then used for each call. When the list of target nodes changes (as the node starts or dies), a new node will be selected. Each client chooses its own target site independently.
- First Available Identical All Proxies - has the same behavior as “First Available”, but the choice of target node is common to all customers. So if two clients use the same target service (for example, EJB), each client will use the same target.
Deploying the application to the cluster
To deploy an application in a cluster, you need to copy it to a folder:
<server_name> / farm /
After that, the application will be automatically deployed to other nodes in the cluster.
To remove an application, it is enough to remove it from the <server_name> / farm / folder on one of the cluster nodes and it will be deleted from other nodes.
Farm deployment configuration (multiple deployment) is available through the farm-service.xml file located in the deploy / deploy.last directory
If you need to include support for farm deployments in your configuration, then you need to copy the farm-service.xml file to the directory with your configuration, for example:
$ JBOSS_HOME / server / your_own_config / deploy / deploy.last
Cluster-service.xml configuration
JBoss services settings in cluster mode are located in the cluster-service.xml file in the / deploy directory
- optional-attribute-name is a required attribute for the HAPartition service which is used for connections within the cluster
- URLs - points to the directory in which the applications are located for deploying them in a cluster. You need to specify this: farm /, i.e. full URL will be like this: $ JBOSS_HOME / server / all / farm
- ScanPeriod - folder check interval for changes
- Port is an optional attribute that indicates the address at which HA-JNDI server waits for JNP clients. The default value is 1100
- Backlog is an optional attribute for specifying the wait used by the TCP server socket for the wait time of the JNP clients. The default value is 50.
- RmiPort - determines which port the server should use to communicate with the stub. This attribute is optional. The default value is 1101. If the value is not set, the server automatically assigns an RMI port.
- AutoDiscoveryAddress is an optional attribute that indicates a group address to listen for automatic JNDI discovery. The default value of the jboss.partition.udpGroup system property, or 230.0.0.4 if it is not set.
- LoadBalancePolicy - specifying the type of Load Balancer
- It is possible to start several copies of some services specified in the cluster-service.xml file by configuring the add-ons (for example, port addresses, etc.). This is necessary if the server is a node in several different clusters.
Known clustering problems in JBoss version 4.2.3
- If you put the archive in the folder all / farm / and connect the server to an already running cluster, this application will not be deployed, because JBoss does not know this new application for deployment, or it is an old application that was removed from other nodes in the cluster while this server was unavailable.
- You cannot place an application in a cluster configuration for deployment as a folder, because it will not be deployed correctly on other nodes in the cluster.
- Deploying and collapsing an application is not an atomic operation. Those. if the application is not deployed on one of the cluster nodes, this will not prevent the deployment of this application on other cluster nodes. Unable to roll back. It is impossible to control the order of application deployment on all nodes of the cluster, i.e. it can be deployed simultaneously on all nodes, which will make the service temporarily unavailable to customers.
PS Corrections, comments, additions and comments are attached.