Java EE Overview and JBoss AS

1. Overview of Java Enterprise Edition
1.1. What is Java EE?

Java EE is an open and standard-based platform for developing, deploying, and managing
multi-tier, web-enabled, server-centric, and component-based enterprise applications
As a super-set of Java SE, Java EE adds additional specifications, libraries,
documentation, and tools.

Note
Java EE stands for Java Enterprise Edition Java SE stands for Java Standard Edition In
addition to Java SE and Java EE Sun released an edition of Java for mobile and resource-
constrained devices like cellular phones and PDAs called Java ME (Java Mobile Edition).
Before Java 5, these versions were called J2EE, J2SE and J2ME.

1.2. Open and Standard-based

Single specification, multiple competing implementations
Implementations available as both OSS/free and high-end commercial
Vast community resources: books, tutorials, guides, examples, etc.
Large developer pool
Application portability

Some of Java EE Application Servers available on the market today:

Apache Tomcat (Servlet/JSP container only)
ATG Dynamo
BEA WebLogic
Borland Enterprise Server
Caucho Resin (Servlet/JSP container only)
Fujitsu Software Interstage
Hitachi Cosminexus
IBM Websphere
JBoss AS
Mort Bay Consulting Jetty (Servlet/JSP container only)
Macromedia JRun Server
Novell exteNd
ObjectWeb JOnAS
Oracle Application Server 10g
Pramati Server
SAP AG Web Application Server
Sun Java System Application Server
Sybase EAServer
TmaxSoft JEUS

Together Teamlösungen EDV-Dienstleistungen GmbH. in cooperation with ObjectWeb
Enhydra Server
Trifork Enterprise Application Server

1.3. Multi-tier

OO framework for integrating together:
o Clients (e.g. web browsers)
o Access and presentation components
o Business components (e.g. ecommerce business logic)
o Data-stores (e.g. RDBMS)
o Legacy systems (e.g. order fulfillment)
System-level separation of concerns

Figure 1. Multi-tier Architecture

Client Tier usually consists of thin clients like web browsers and it makes the request into
the Web Tier over HTTP.
Client Tier (B2B) is a set of external applications that makes requests into the Business
Tier through Web Services over SOAP or directly through Java‟s RMI.
Web Tier is usually implemented with Servlets, JSPs, and simple JavaBeans, based on
the Model-View-Controller design pattern.
Business Tier is composed of EJBs and/or plain old Java objects (POJOs).
Data Access Tier is either managed by the applications (e.g. BMP, DAO), O/R mapping
tools (e.g. Hibernate), or through Container Managed Persistence (CMP).
Connector/Messaging Tier allows asynchronous access to legacy systems or other
external systems.
Legacy/External Tier consists of enterprise information systems.
Data Tier is usually composed of RDBMS and/or LDAP Directory Servers.

1.4. Web-Enabled

Thanks to Servlet/JSP technology, Java EE applications are automatically web-enabled:
o Efficient, Java/OO, Easy, I18N, MVC
Complete support for web-services
o Clients
o End-points

1.5. Server Centric

Java EE apps run within a Java EE application server that provides all middle-tier
services.
Thin (web-based) clients
Support for rich clients through RMI, Web Services, etc.
o The design of such clients is beyond the scope of Java EE

1.6. Component-Based Distributed Architecture

ava EE applications and services are built out of components that can run in a single or multiple
(distributed) Java EE Application Server instances.

1.7. Enterprise Applications

Java EE applications are made up of:
o Presentation logic
o Business logic
o Data access logic and model
Java EE facilitates separation of concerns

The goal of Java EE is to significantly reduce the cost, time, and complexity of developing and
managing multi-tier enterprise applications.

1.8. Java EE Contents

Java SE: JVM, Tools, Libraries, Docs
Expanded API, Specifications, Tools, Docs
Reference development and deployment platform (production-quality) from Sun
Compatibility Test Suite
Java EE Blueprints
Sample code
Java EE Brand

1.8.1. Java EE 5 APIs and Technologies :

Java SE 5
Web Services 1.1, JSR-109
Java API for XML-Based RPC (JAX-RPC) 1.1, JSR-101
Java API for XML Messaging (JAXM), JSR-67
Java API for XML Registries (JAXR) 1.0, JSR-93
SOAP with Attachments API for Java (SAAJ) 1.2, JSR-67
Management API, JSR-77
Deployment API, JSR-88
Authorization SPI, JSR-115
Java Network Launch Protocol (JNLP), JSR-56
J2EE Connector Architecture (JCA) 1.5, JSR-112
JavaServer Pages (JSP) 2.1, JSR-245
JavaServer Faces (JSF) 1.0, JSR-127
JavaServer Pages Standard Tag Library (JSTL) 1.1, JSR-52
Java Servlet 2.5, JSR-154
Enterprise Java Beans (EJB) 3.0, JSR-220
Java Messaging Service (JMS) 1.1, JSR-914
Java Management Extensions (JMX) 1.1, JSR-3
Java Transaction API (JTA) 1.0.1, JSR-907
Java Mail 1.3. JSR-919
JavaBeans Activation Framework (JAF) 1.1, JSR-925

Java Authentication and Authorization Service (JAAS) 1.0
Java Naming and Directory Interface (JNDI) 1.2.1
Java Authorization Contract for Containers (JACC) 1.0, JSR-115

1.9. Java EE Services

Java EE Application Server handles:
o Concurrency, Scalability, Availability
o Security
o Persistence, Transactions
o Life-Cycle Management
Application Components focus on:
o Presentation
o Business Logic

2. Overview of JBoss Application Server
2.1. JBoss Organization

JBoss - The Professional Open Source Company
Focuses on middleware software and services - JBoss Enterprise Middleware Suite
(JEMS)
Software is open source and free
Makes money on services
Acquired by Red Hat in April 2006 for $420M

JBoss Enterprise Middleware Suite (JEMS):

Application Server (JBoss AS, Tomcat)
O/R Mapping and Persistence (Hibernate)
Portal Platform (JBoss Protal)
Business Process Management and Rules (JBoss jBPM, JBoss Rules)
Object/Data Cache (JBoss Cache)
Distributed Transaction Management (JBoss Transactions)
Development Tools (JBoss Tools plugin for Eclipse)

JBoss Organization Services:

Training
Certification
Online Education
Consulting

2.2. JBoss AS Background

Established in 1999 as an open-source EJB container

Version 2.x becomes a full J2EE application server
Version 3.x is the production series - based on JMX microkernel and service-oriented
architecture (May 2002)
Version 4.x explores the aspect-oriented middleware services, adds support for EJB 3
(September 2004)
Version 5.x comes with JBoss Microcontainer (also a stand-alone project) and replaces
JMX Microkernel of the 3.x and 4.x JBoss series (December 2008)
Version 6.x to add support for Java EE 6 APIs and Profiles. Replaces JBoss Messaging
with HornetQ (6.0.0.M3 released in April 2010)

2.3. Highlights of JBoss AS

Enterprise-class reliability, performance, scalability, and high-availability
Zero-cost product license, to download, use, embed, and distribute
Open-source
Built for standards - provides a safe choice for portable applications (interoperable)
Service-oriented architecture provides consistency, makes it embeddable
Aspect-oriented architecture simplifies interaction with middleware services
24x7 professional support by the core development team
Active developer community
Over 5 million downloads
25+% market share

Note
JBoss AS 5 has passed the Java EE 5 Technology Compatibility Kit (TCK) test suite
(100%).

2.4. What is new in JBoss AS 5?

New kernel ⇒ JBoss Microcontainer
o is a refactoring of old JMX Microkernel (JBoss AS 3.x and 4.x)
o the core of JBoss AS 5
New messaging provider ⇒ JBoss Messaging
o Replaces old JBossMQ (shipped with JBoss AS 4.x series)
One of the first application servers to implement EJB 3.0 specification (dating back to 4.x
series)
Reliable transaction manager ⇒ JBoss TS
o more than 20 years of expertise in transaction management
JBoss Web based on Apache Tomcat 6.0
JBoss WS 3.0 (support for JAX-WS/JAX-RPC)
o can be replaced by Sun Metro or Apache CXF for example
Two new configurations:
o standard: Java EE compliant configuration.
o web: provides support for JTA/JCA and JPA in addition to the Servlet/JSP
container. The server can only be accessed through the http port.

2.5. JBoss AS Architecture

"JBoss AS is assembled from a set of independent, yet cooperating components and services that
are neatly packaged and fully hot-deployable. It is architected to be seamlessly embeddable in
applications, and the nature of its embedding is completely customizable to the requirements of
the application itself. Only the critical and necessary application server components, therefore,
need to be brought along as part of the application‟s baseline footprint. Developers can also
easily create and add their own services to the system, thus ensuring that custom services exhibit
the same consistent behavior as the JBoss standard set of services."

Figure 2. JBoss AS 4.x Architecture

Figure 3. JBoss AS 5.x Architecture

2.6. JBoss Microcontainer Layer

JBoss Microcontainer is an inversion of control (IoC) framework. IoC frameworks let you create,
configure and wire up simple Java objects (POJOs). Classes don‟t need special coding to be
usable. The objects created usualy represent the modules of your application.

Replaces JMX-based Microkernel, though still supports all JMX Microkernel features
IoC framework similar to Spring IoC
POJO based kernel (no need for Standard/XMBean or MBeanProxy)
Simplified and improved lifecycle management
Additional control over dependencies
Transparent AOP integration
Virtual File System (VFS)
Virtual Deployment Framework
OSGi class-loading

2.7. Services Layer

Service-oriented architecture - service is either defined as a POJO or a JMX Managed
Bean (use the JMX kernel, still available in JBoss 5.x but is created by JBoss
Microcontainer).
Services are hot-pluggable
Makes it possible to tune the system for just the required services to lower the overall
footprint (easier to secure and tune)
Easy to define new services and package them as SARs (service archives) or JARs (Java
ARchives)
Examples: Servlet/JSP container, EJB container, transaction management, messaging,
connection pooling, security etc.

2.8. Aspect Layer

Increase the modularity of an application by allowing the separation of cross-cutting concerns
(e.g logging is often required in many parts of your application).

Based on aspect-oriented programming model (AOP)
Defines cross-cutting simple-to-use services
Makes it possible to add object persistence, caching, replication, remoteness, security,
etc. late in the development cycle by annotating existing plain-old-java-objects (a.k.a
POJOs)

Note
Available since JBoss AS 4

2.9. Application Layer

This is where Java EE applications reside
This layer deals with the business logic while leaving the container services up to JBoss
AS
Portable - Independent of JBoss AS

2.10. JBoss AS Services

JBoss Microcontainer - POJOs services container
JBoss Microkernel - JMX MBean server (One of the primary POJOs created by JBoss
Microcontainer)
Aspect-oriented Framework
Web Application Services - based on Tomcat (Servlet, JSP, JSF)
Enterprise Services: EJB, ORB, JNDI, JTA
Web Services - based on SOAP, WSDL, UDDI, and XML
Messaging Services: JMS, JDBC, JCA
Persistence Services - Hibernate O/R mapping and transparent persistence
HA Services: clustering, fail-over, load-balancing, distributed deployments
Security Services - based on JAAS

Console Services - monitoring, configuration, deployment, management, lifecycle

2.11. JBoss AS Requirements

Important

JBoss AS 5.x requires at least Java SE 5 and can run on Java SE 6 (though this is a separate
download). Run java -version to find out if you already have Java installed, and if so, which
version of the JVM. JBoss AS does not require the JDK (thanks to the embedded JDT compiler
that can be used to compile JSPs), so JRE is sufficient in production environments. With that
said, having the extra JDK tools available on the system is recommended. Verify that you have
the JDK installed by running javac -version .

3. Installing JBoss AS
3.1. Getting and Installing Java

Download Java SE 6 JDK from http://java.sun.com/javase/downloads/index.jsp or
http://java.sun.com/products/archive/ (for Java SE 5 JDK)
On UNIX run the installer or uncompress the distribution into a directory of your choice
On Windows, run the installer
o Avoid installing Java into a directory that contains spaces or other special
characters (e.g. under C:Program Files)
o You can choose not to install "Public JRE", demos, and source components

Note
While the "Public JRE" on Windows is not required by JBoss itself, having it installed will
make it possible for your browsers to load the navigation applet which is part of JBoss'
/web-console/ application.

3.2. Configuring Java

Set JAVA_HOME to point to the directory where you installed Java and add
$JAVA_HOME/bin to your PATH
o On Windows, add JAVA_HOME System Variable under Start -> Settings ->
Control Panel -> System -> Advanced -> Environmental Variables and
prefix the existing Path variable with %JAVA_HOME%bin;. Re-open any existing
"Command Prompt" windows for this change to take effect.
o On UNIX-like systems, make these changes in your shell‟s configuration file (e.g.
~/.bashrc): export JAVA_HOME=/path/to/java-install-dir and export
PATH=$JAVA_HOME/bin:$PATH
Test that java -version prints the expected Java version
Test that javac prints usage message
This verifies that JDK is installed (vs. JRE)

3.3. Getting JBoss AS

Download packaged distribution
o Preferred
Build from source
http://www.jboss.org/jbossas/downloads

Note
You can either download jboss-<version>.zip or jboss-<version>-jdk6.zip
depending on the version of Java you installed. Generally, Java 6 is preferred as it is faster,
offers better management features, and it is backwards compatible with Java 5.

How to build from source ?

1. Get Ant from http://ant.apache.org/
2. Uncompress it in a directory like C:Ant
3. Set ANT_HOME to point to the directory where you installed Ant
4. Add $ANT_HOME/bin (on Linux), %ANT_HOME%bin (on Windows) to your PATH
5. get jboss-<release>-src.tar.gz from http://www.jboss.org/jbossas/downloads
6. unzip it
7. browse to build directory and run ant
8. Once finished the binaries will be under jboss-<release>.GA-
srcbuildoutputjboss-<release>.GA

3.4. Installing JBoss AS 5

Unpack the compressed archive
o This is the typical installation method because it is the easiest
Alternatively, install the source-built binary
o Not a common installation method

Set JBOSS_HOME to the root folder of JBoss.
You can also add $JBOSS_HOME/bin (Linux) or %JBOSS_HOME%bin (Windows) to your
PATH in case you want to run your server from the command-line

Important
You will still have to secure JBoss services, before deploying it in production. More on this
later.
Note
Even though this is supported, avoid installing/unpacking JBoss AS into a directory path
that contains spaces or any other special characters. There is no requirement for for the
installation directory to be owned by "root" (or any other privileged user). JBoss AS does
not require super-user privileges, since none of the default ports are within the 0-1023 port
range, which is considered privileged on many Unix-like systems.

4. JBoss Directory Structure
4.1. JBoss AS Directory Structure
JBossORG-EULA.txt copyright.txt lib/
bin/ docs/ readme.html
client/ jar-versions.xml server/
common/ lgpl.html

Root dir known as jboss.home.dir or $JBOSS_HOME
Understanding the layout is important:
o Locating libraries
o Updating configuration
o Deploying apps and services

When JBoss AS is installed (uncompressed), the following directories are created:

${jboss.home.dir}/bin
${jboss.home.dir}/client
${jboss.home.dir}/common
${jboss.home.dir}/docs
${jboss.home.dir}/lib
${jboss.home.dir}/server

4.2. The bin Directory
README-service.txt run.conf twiddle.sh
classpath.sh run.conf.bat wsconsume.bat
jboss_init_hpux.sh run.jar wsconsume.sh
jboss_init_redhat.sh run.sh wsprovide.bat
jboss_init_suse.sh service.bat wsprovide.sh
jbosssvc.exe shutdown.bat wsrunclient.bat
password_tool.sh shutdown.jar wsrunclient.sh

probe.bat shutdown.sh wstools.bat
probe.sh twiddle.bat wstools.sh
run.bat twiddle.jar

JBoss AS ${jboss.home.dir}/bin directory contains startup/shutdown scripts, bootstrap
libraries, Web Services and server management utilities:

classpath.sh: A tool to determine JBoss classpaths (both client and server)
jboss_init_redhat.sh and jboss_init_suse.sh: JBoss system control scripts for
RedHat and SuSE systems
probe.sh and probe.bat: used for discovering JBoss AS clusters.
run.sh and run.bat: Scripts for starting JBoss AS
run.jar: Bootstrap code for starting JBoss AS
service.bat: Script to manage JBoss as a Windows service.
shutdown.sh and shutdown.bat: Scripts for shutting down JBoss AS (including remote
instances)
shutdown.jar: Bootstrap code for shutting down JBoss AS
twiddle.sh and twiddle.bat: Scripts for running JBoss AS command-line
management client (based on JMX)
twiddle.jar: Bootstrap code for the JMX management (instrumentation) client
wsconsume, wsprovide, wsrunclient and wstools are utilities for Web Services. We
will see that later on Web Services chapter.

4.3. The client Directory

Contains the Java libraries (JARs) required for clients that run outside the JBoss AS
containers, such as:
o WebService clients
o EJB clients
o JMX clients
Used by external applications that need to access JNDI resources
On Unix, to get the client CLASSPATH, run: ${jboss.home.dir}/bin/classpath.sh
-c
As of JBoss 5, the file client/jbossall-client.jar contains references to other JARs
via Class-Path setting in its META-INF/MANIFEST.MF file. This makes it possible for
external JBoss clients to just reference this one JAR file as opposed to many of them.

Note
We will use the client/ directory later with some clients (like JMS) that will run outside
the JBoss AS.

4.4. The common directory

Contains the lib directory (also known as jboss.common.lib.url).
o lib folder contains the common libraries shared by all server configurations
(more on this later)

o This directory is new to JBoss 5. In earlier versions of JBoss a number of
common libraries were simply duplicated for each configuration set.

4.5. The docs Directory
dtd/ examples/ licenses/ schema/ tests/

Examples: sample configuration: JMX, JCA, JMS, NetBoot, etc.
o Contains excellent examples for many different configurations. For example, the
file docs/examples/jca/mysql-ds.xml can serve as a starting point in defining
a MySQL-based DataSource (shared database connection-pool) in JBoss AS.
DTDs and Schemas for J2EE and JBoss XML files
o Contain all J2EE-referenced XML DTD and XSD files, making it simple to
validate XML files and lookup the relevant "grammar" when making
configuration changes. DTDs were employed by J2EE 1.3 and JBoss 4 whereas
Schemas are used since J2EE 1.4 and JBoss 5.
Licenses for all JBoss components
Unit test results

Note
The actual JBoss AS documentation can be downloaded from
http://www.jboss.org/jbossas/docs/5-x.html

4.6. The lib Directory

Contains JBoss bootstrap libraries (core libraries)
Do not place your own files here or remove any of the existing files
As an example, you‟ll find here the JBoss Microcontainer and the old JMX kernel.

4.7. The server Directory
all/ minimal/ node2/ web/
default/ node1/ standard/

Known in JBoss AS as jboss.server.base.dir
Root of server configuration sets
JBoss comes with minimal, default and all
Version 5.x comes with 2 new configurations: standard and web
Defaults to configuration set in server/default
Configuration sets contain the actual JBoss services

To change the configuration set that JBoss AS runs with, execute: bin/run.sh -c
<configuration-set>

For example:

bin/run.sh -c minimal
bin/run.sh -c all

Configuration sets:

minimal/

Includes support for JNDI and logging. It does not contain any other J2EE services like
Servlet/JSP container, EJB container, or JMS.
Can serve as a starting point when creating your own configuration sets

default/

As the name implies, this is the default Java EE 5 configuration. Contains the most used
services except JAXR, IIOP and clustering services.

all/

This configuration extends the default configuration set and also include JAXR, IIOP and
clustering services

standard/

Certified Java EE 5 configuration compliant.

Note
The major differences with the existing configurations is that call-by-value and deployment
isolation are enabled by default, along with support for rmiiiop and juddi (taken from the all
config).

web/

Lightweight web container profile (Java EE 6 web profile). It provides support for
JTA/JCA and JPA except for the servlet/JSP container.

4.8. The server Configuration Sets
all/ minimal/ node2/ web/
default/ node1/ standard/

The currently running server/<server> dir is known in JBoss AS as
jboss.server.home.url
The name of the server (e.g. "default") is known as jboss.server.name
Configuration sets are independent of each other

Note

Each configuration set has to have at least the following four directories: conf/, deploy/,
deployers/, and lib/. Other (referenced) directories such as data/, log/, tmp/, and
work/ are automatically created on JBoss AS startup if they do not exist.

4.9. The default/conf Directory
bindingservice.beans/ jbossts-properties.xml
bootstrap/ jndi.properties
bootstrap.xml login-config.xml
java.policy props/
jax-ws-catalog.xml standardjboss.xml
jboss-log4j.xml standardjbosscmp-jdbc.xml
jboss-service.xml xmdesc/

Known in JBoss as jboss.server.config.url
Contains a bootstrap descriptor (jboss-service.xml) that defines which services are
loaded for the lifetime of the instance

The files in directory ${jboss.server.config.url} :

bootstrap/*: Bootstrap descriptors for core microcontainer services defined in
bootstrap.xml
bootstrap.xml: Defines the core microcontainer beans to load during bootstap
jboss-service.xml: Defines the core JMX services configurations
jndi.properties: Specifies a set of properties that are passed to JNDI when new
InitialDirContext() is called within JBoss
jboss-log4j.xml: Configuration file for the logging service (Log4J) defining log filters,
priorities, and destinations
login-config.xml: Defines security realms used for authentication and authorization
(JAAS)
props/*.properties: Java property files (usually used for JAAS realms)
java.policy: Placeholder for security permissions (Java Security Manager). Grant-All
by default
standardjboss.xml: Configuration file for the standard EJB container
standardjbosscmp-jdbc.xml: Configuration file for the standard JBossCMP engine
xmdesc/*-mbean.xml: XMBean descriptors for services configured in the jboss-
service.xml file
props/*: property files defining users and roles for the jmx-console

Important
Any changes to files in this directory require a full server restart in order to take effect.

4.10. The default/data Directory
hypersonic/ wsdl/
tx-object-store/ xmbean-attrs/

Known in JBoss as jboss.server.data.dir
Location where some services store private content on the file system
o Hypersonic DB - built-in (by default use as the temporary message store by JMS)
o XMBeans attribute persistence (not enabled by default)
o Transaction objects (temporary storage of objects during the two-phase commit
process)
This directory is not directory exposed to the end users (e.g. though the web interface)

Note
Unless you use Hypersonic DB, the contents of this directory (including the directory itself)
can be cleared (deleted) between JBoss restarts.

4.11. The default/deploy Directory
CurrencyConverterApp.ear jsr88-service.xml
ROOT.war/ legacy-invokers-service.xml
admin-console.war/ mail-ra.rar
cache-invalidation-service.xml mail-service.xml
ejb2-container-jboss-beans.xml management/
ejb2-timer-service.xml messaging/
ejb3-connectors-jboss-beans.xml monitoring-service.xml
ejb3-container-jboss-beans.xml my-ws.war
ejb3-interceptors-aop.xml printservice.sar/
ejb3-timerservice-jboss-beans.xml profileservice-jboss-beans.xml
fortune.war/ profileservice-secured.jar/
hdscanner-jboss-beans.xml properties-service.xml
hsqldb-ds.xml quartz-ra.rar
http-invoker.sar/ remoting-jboss-beans.xml
jboss-local-jdbc.rar schedule-manager-service.xml
jboss-xa-jdbc.rar scheduler-service.xml
jbossweb.sar/ security/
jbossws.sar/ sqlexception-service.xml
jca-jboss-beans.xml transaction-jboss-beans.xml
jms-ra.rar transaction-service.xml
jmx-console.war/ uuid-key-generator.sar/
jmx-invoker-service.xml vfs-jboss-beans.xml
jmx-remoting.sar/ xnio-provider.jar/

Dynamic deployment content directory
This is where applications and services are deployed
Default location used by hot deployment service
Contains code and configuration files for all services

Some files in the deploy directory include:

ROOT.war: is the / root web application
cache-invalidation-service.xml - Custom invalidation of EJB caches via JMS
ejb2-container-jboss-beans.xml - UserTransaction integration bean for EJB2
container
ejb2-timer-service.xml - EJB timer service bean

ejb3-connectors-jboss-beans.xml - EJB3 remoting transport bean
ejb3-container-jboss-beans.xml - UserTransaction integration bean for EJB3
container
ejb3-interceptors-aop.xml - AOP for EJB3
ejb3-timer-service.xml - alternate quartz based timer service
hdscanner-jboss-beans.xml - hot deployment scanner bean
hsqldb-ds.xml - Hypersonic embedded database and related connection factories
http-invoker.sar - Detached invoker that supports RMI/HTTP
jboss-local-jdbc.rar - JCA to DataSource adaptor for JDBC drivers
jboss-xa-jdbc.rar - JCA to XADataSource adaptor for JDBC drivers.
jbossweb.sar - Tomcat Servlet/JSP Engine
jbossws.sar - The JBoss service that supports web services
jca-jboss-beans.xml - Connection management facilities for integrating JCA adaptors
into JBoss AS
jms-ra.rar - JMS resssource adapter
messaging/connection-factories-service.xml - DLQ, ExpiryQueue JMS
connection factory
messaging/destinations-service.xml - Message persistence store service
messaging/jms-ds.xml
messaging/legacy-service.xml
messaging/messaging-jboss-beans.xml - JMS security and management beans
messaging/messaging-service.xml - Core messaging service
messaging/remoting-bisocket-service.xml - JMS remoting service layer
jmx-console.war - Web application that provides HTML interface to manage MBean
server
jmx-invoker-service.xml - RMI to JMX adaptor into JBoss
jmx-remoting.sar -
legacy-invokers-service.xml -
jsr-88-service.xml -
mail-ra.rar - Resource adaptor that provides a JavaMail connector
mail-service.xml - JavaMail session service (SMTP)
monitoring-service.xml - Configuration for alert monitors such as email or console
listeners
properties-service.xml - JavaBeans PropertyEditors and definition of system
properties
admin-console.war - admin console for JBoss AS
scheduler-service.xml - JBoss scheduling service
sqlexception-service.xml - Vendor-specific SQL exception handler
security/security-jboss-beans.xml - Security domain related beans
security/security-policies-jboss-beans.xml - Security authorization for EJB and
web authorization
transaction-jboss-beans.xml - JTA transaction manager related beans
uuid-key-generator.sar - UUID-based key generation facility

4.12. The default/deployers Directory

alias-deployers-jboss-beans.xml jboss-threads.deployer/
bsh.deployer/ jbossweb.deployer/
clustering-deployer-jboss-beans.xml jbossws.deployer/
dependency-deployers-jboss-beans.xml jsr77-deployers-jboss-beans.xml
directory-deployer-jboss-beans.xml logbridge-jboss-beans.xml
ear-deployer-jboss-beans.xml messaging-definitions-jboss-beans.xml
ejb-deployer-jboss-beans.xml metadata-deployer-jboss-beans.xml
ejb3.deployer/ seam.deployer/
hibernate-deployer-jboss-beans.xml security-deployer-jboss-beans.xml
jboss-aop-jboss5.deployer/ webbeans.deployer/
jboss-ejb3-endpoint-deployer.jar xnio.deployer/
jboss-jca.deployer/

Contains all the JBoss AS services that are used to recognize and deploy different
application and archive types.

Some files in the deployers directory:

hibernate-deployer-jboss-beans.xml - Deployer for Hibernate archives (HAR)
ejb-deployer-jboss-beans.xml - Service responsible for deploying EJB JAR files
ear-deployer-jboss-beans.xml - Service responsible for deploying EAR files
jbossweb.deployer - Service responsible for deploying WAR files
jboss-aop-jboss5.deployer - Deployer that sets up Aspect Manager Service and
deploys AOP applications
etc…

Note
This directory is new as of JBoss AS 5

4.13. The default/lib Directory

Directory referred to by the bootstrap code when loading the configuration set
Known within JBoss as jboss.server.lib.url
This directory is for Java code (JARs) to be used both by the deployed applications and
JBoss AS services
If you have Java libraries that you need to be made available to all your
applications/services, these can be placed in the ${jboss.server.lib.url} directory.
Similarly, you would also use this directory for Java libraries that need to be used by both
your applications/services, and JBoss AS services.
o A typical example of this is a JDBC driver that is needed by JBoss AS to manage
a pool of database connections, as well as your code, which implicitly uses it to
interact with the database server.

Note
As of JBoss 5, some JARs that used to reside in this directory have been moved to
common/lib in order to share them with other configuration sets.

4.14. The default/log Directory

Known within JBoss as jboss.server.log.dir
Default destination directory for JBoss AS log files (3 log files)
boot.log - logs boot process until logging service starts
server.log - takes over once the logging service is initialized from
${jboss.server.config.url}/jboss-log4j.xml
audit.log - audit security
Default startup log priority: DEBUG
STDOUT and STDERR are logged to console

By default:

Log file server.log is rolled over daily (with the ".yyyy-MM-dd" extension)
Existing logs are overwritten on [re]start
Old log files are not automatically cleaned by the server during runtime

Since the logging system is managed by Log4J it can be easily configured to:

Roll over logs hourly
Roll over logs by size (e.g. 500KB)
Automatically remove old logs
Log to SMTP, SNMP, Syslog, JMS, etc.

This directory can be cleared (deleted) between JBoss restarts.

4.15. The default/tmp Directory

Known in JBoss as jboss.server.temp.dir
Used by JBoss AS to store temporary files such as unpacked service and application
deployments
Deployments are automatically removed on server shutdown

This directory can be cleared (deleted) between JBoss restarts.

Note
Unpacked deployments (e.g. expanded WAR files) are not copied over. Packed deployments
(WAR, EAR, RAR) are uncompressed, whereas JARs and XML-described services are
copied over.

4.16. The default/work Directory

Directory where compiled JSP .java and .class files reside
Also contains cached TLDs
Very useful for debugging problems in JSPs

Java ServerPages (.jsp files) are automatically compiled into Java Servlets (.java file) and then
into Java byte-code (.class files) by Tomcat (the embedded servlet engine running within JBoss
AS).

Many JSP errors are easier to fix when developers are able to look at the compiled .java files
and match the line numbers to error/exception messages.

Unless you care to preserve compiled JSPs, this directory can be cleared (deleted) between JBoss
restarts.

5. Controlling the Life-Cycle of JBoss AS
5.1. Starting JBoss AS

To start JBoss, run $JBOSS_HOME/bin/run.sh on Unix/Linux and
%JBOSS_HOME%run.bat on Windows
The script figures out JBOSS_HOME by itself - though it does not hurt to have it pre-
specified as discussed already
By default, this script runs the default configuration set
o Alternative configuration set can be specified: ./run.sh -c
<configuration_set_name>
By default, this script binds JBoss AS to 127.0.0.1 (for security reasons) making it
inaccessible from the outside world
o To bind JBoss to a specific address, execute: ./run.sh -b 10.1.2.3 or
./run.sh --host=10.1.2.3
o To bind JBoss to all addresses, execute: ./run.sh -b 0.0.0.0 or ./run.sh --
host=0.0.0.0
To start JBoss as a system service
o On Unix/Linux, use a script like jboss_init_redhat.sh
 Copy (or symbolically link) this script to /etc/init.d/jboss
 Edit the script as needed (to specify user, IP, and file paths)
 Add #chkconfig: 3 80 20 and #description: JBoss to this script
 Run chkconfig --add jboss
o On Windows use JavaService (http://forge.objectweb.org/projects/javaservice/),
which comes with an installation script for JBoss

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)
-m, --mcast_port=<ip> UDP multicast port; only used by JGroups
-u, --udp=<ip> UDP multicast address
-l, --log=<log4j|jdk> Specify the logger plugin type
Note
On Unix/Linux, run.sh (and shutdown.sh) source JVM/runtime options from run.conf file
whereas on Windows run.bat specifies those options internally.

5.2. Verifying JBoss AS Startup

JBoss has successfully started when in its console window you can see a line like this:

13:26:33,625 INFO [ServerImpl] JBoss (Microcontainer) [5.1.0.GA (build:
SVNTag=JBoss_5_1_0_GA date=200905221634)] Started in 2m:20s:844ms

If you see any exception traces, then there was a problem starting one or more of the
JBoss services. Examine the error messages before continuing. A common problem is a
port conflict: another server (possibly another instance of JBoss AS itself) is running on
one or more of the required JBoss AS ports.

Point your browser to http://localhost:8080/status to verify the server startup.

5.3. Stopping JBoss AS

If started in foreground using the run script, simply hit CTRL+C
If running in the background as an OS service, stop it just like any other OS service
o /etc/init.d/jboss stop (on UNIX/Linux)
o kill -TERM <jboss-pid> (on UNIX/Linux)
o NET STOP JBoss (on Windows)
Use the shutdown script (remote shutdown): $JBOSS_HOME/bin/shutdown.sh -S
(shutdown.bat on Windows)

A JMX client to shutdown (exit or halt) a remote JBoss server.

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

To shutdown a remote JBoss AS instance, use: ./shutdown.sh -s
jnp://remoteHostOrIP:1099 -S Remote instance‟s IP address and port are specified by its
Naming service configured in ${jboss.server.config.url}/jboss-service.xml

5.4. Starting From a Remote Server

JBoss can load itself from a network server using run script‟s -netboot=<url> option
Result: jboss.home.dir=<url>
o Everything resolved relative to home URL
NetBoot requires run.jar on the client side, and a web server with support for PROPFIND
WebDAV command
o JBoss AS itself can serve this role
o Use an Ant script to set this up
To boot JBoss AS from a remote server, you would execute something like this:
./run.sh --netboot=http://192.168.0.1:8080/jboss/

6. Deployments on JBoss
6.1. Java EE Deployment Lifecycle

Development and Deployment Lifecycle:

1. Design static content (HTML, CSS, GIF, JPG, etc.)
2. Develop dynamic content (Servlets, JSPs, and other Java components like EJBs)
3. Write deployment descriptors (e.g. web.xml, application.xml, ejb-jar.xml, etc.) for
components
4. Assemble components into deployable packages (e.g. WAR, JAR, EAR, etc.)
5. Provide all resources that the components require (e.g DBCP, Mail sessions, message queues,
etc.)
6. Deploy packages (e.g. WAR, JAR, EAR, etc.) on the Java EE application server
7. Manage Java EE applications on the server

6.2. Deployment Descriptors

Give the containers instructions on how to use and manage deployed Java EE
components
o Security
o Transactions
o Persistence
Declarative customization (XML-based)
Enables portability of Java EE components

Note

J2EE 1.3 and JBoss pre 5.x deployment descriptors are defined by XML DTD documents.
These can be found in $JBOSS_HOME/docs/dtd/ directory. As of J2EE 1.4 and JBoss 5.x,
deployment descriptors are defined by XML Schema (XSD) documents. These can be found
in $JBOSS_HOME/docs/schema/ directory.

6.3. Deployment on JBoss AS

Deployment is a two-step process
o First we notify JBoss that of the application we want to deploy by copying it to
${jboss.server.home.url}/deploy/ or any of its subdirectories
o Then, JBoss performs the necessary steps to make that application ready for our use
Undeployment is also a two-step process
o First we notify JBoss that of the application we want to undeploy by removing it from
${jboss.server.home.url}/deploy/ directory
o Then, JBoss performs the necessary steps to stop the application and unload its
resources
Alternatively, applications can be deployed/undeployed/and re-deployed via
jboss.system:service=MainDeployer JMX MBean (more on this later).
o This mechanism also support remote management of JBoss deployments
Supports deployment dependencies
Hot-deployment vs. cold-deployment
Archived components are uncompressed (a.k.a. exploded) under
${jboss.server.temp.dir}/deploy/
o JBoss deletes (or at least it is supposed to delete)
${jboss.server.temp.dir}/deploy/ deployments upon restart
o It is recommended to deploy applications already uncompressed (exploded) for to avoid
the overhead of uncompression, and provide easy access to deployment descriptors and
JSP files
The deployed components are automatically redeployed if their deployment descriptors are
modified while JBoss AS is running
JBoss supports nested deployments (e.g. WAR under EAR) regardless of whether they are
compressed into archives or deployed uncompressed
With clustering enabled, JBoss AS also supports farmed deployment - that is, pushing
applications across the entire cluster when deployed on any single member of that cluster
JBoss supports JSR-88 (Java EE application deployment spec) but
o There are no tools that make this kind of deployment easy - requires writing code
o The resulting deployments go into the tmp/ directory - making redeployments harder

6.4. Deployers on JBoss AS

JBoss has an extensible deployment architecture that allows components to be easily integrated
into the core JBoss Microcontainer
Deployers for: WARs, EARs, EJBs, JAR libraries, RARs, SARs, XML-based services,
HARs, Aspects, Client, BeanShell scripts
o The deployers are deployed themselves as *.deployer or *-deployer-beans.xml
under ${jboss.server.home.url}/deployers/ directory

6.4.1. Type of Deployers

Web - handles web application archives as .war files with descriptors WEB-INF/web.xml,
WEB-INF/jboss-web.xml (optional), and WEB-INF/context.xml (optional)

EAR - handles enterprise application archives as .ear files with descriptors META-
INF/application.xml and META-INF/jboss-app.xml (optional)
EJB - handles Enterprise Java Bean archives as .jar files with descriptors META-INF/ejb-
jar.xml and META-INF/jboss.xml (optional)
RAR - handles JCA resource archives as .rar files with a descriptor META-INF/ra.xml
SAR - handles JBoss MBean service archives either as .sar files with a META-INF/jboss-
service.xml descriptor, or as stand alone *-service.xml files
Web Service - handles JBoss Web Services as *.wsr files
POJO - handles plain old java objects deployed as *-jboss-beans.xml files that register with
JBoss Microcontainer
XML - handles arbitrary .xml files that are converted into SARs (e.g. *-ds.xml get deployed as
data sources)
HAR - handles Hibernate archives as .har files with a META-INF/hibernate-service.xml
descriptor
Aspect - handles aspect archives either as .aop files with a META-INF/jboss-aop.xml
descriptor or as stand-alone *-aop.xml files
Client - handles Java EE application client resources as .jar files with META-
INF/application-client.xml and META-INF/jboss-client.xml (optional) descriptors
BeanShell - handles bean shell scripts as .bsh files that represent MBeans
Zip - handles arbitrary .zip archives that are examined for that actual deployment type based
on the internal deployment descriptors

6.4.2. Deployment Configuration

JBoss deployers (and the file extensions that trigger them) are configured in
${jboss.server.home.url}/conf/bootstrap/deployers.xml file.
By default JBoss scans ${jboss.server.home.url}/deploy/ for deployments, but this
can be changed/extended in BootstrapProfileFactory → applicationURIs property
in ${jboss.server.home.url}/conf/bootstrap/profile.xml file:
<deployment ...>
...
<bean name="BootstrapProfileFactory" ...>
<property
name="deployersURI">${jboss.server.home.url}deployers</property>
<property name="applicationURIs">
<list elementClass="java.net.URI">
<value>${jboss.server.home.url}deploy</value>
</list>
</property>
...
</bean>
...
</deployment>

JBoss rescans the deployment directories for new deployments (or changes to the existing
deployments) every 5 seconds as specified by HDScanner → scanPeriod in
${jboss.server.home.url}deploy/hdscanner-jboss-beans.xml file:
<deployment ...>

...
<bean name="HDScanner" ...>
...
<property name="scanPeriod">5000</property>
...
</bean>
</deployment>
Note

In JBoss 5.0, deployment directories were defined by VFSDeploymentScanner →
URIList in profile-service.xml file.

6.4.3. Deployment Ordering

During the server startup, after initializing all deployers, JBoss will deploy
applications/components in the following order: AOPs, SARs, POJOs, RARs, Data Sources, HARs,
EJBs, ZIPs, WARs, Web Services, EARs, Bean Shell Scripts
To force the deployment of an application/component at the very end of the startup phase,
deploy it under ${jboss.server.home.url}/deploy/last or as *.last

6.5. Deployment Dependencies

Components can define dependencies on other components through JMX:
<depends optional-attribute-name="ConnectionManager">
jboss.jca:service=DataSourceBinding,name=DefaultDS
</depends>

For example:
o Undeploy Hypersonic DB (hsqldb-ds.xml) and JMS MQ automatically shuts
down
o 12:07:13,767 INFO [testTopic] Unbinding JNDI name:
topic/testTopic
o 12:07:13,776 INFO [securedTopic] Unbinding JNDI name:
topic/securedTopic
o 12:07:13,779 INFO [testDurableTopic] Unbinding JNDI name:
topic/testDurableTopic
o 12:07:13,783 INFO [testQueue] Unbinding JNDI name:
queue/testQueue
o 12:07:13,838 INFO [A] Unbinding JNDI name: queue/A
o 12:07:13,850 INFO [B] Unbinding JNDI name: queue/B
o 12:07:13,859 INFO [C] Unbinding JNDI name: queue/C
o 12:07:13,866 INFO [D] Unbinding JNDI name: queue/D
o 12:07:13,869 INFO [ex] Unbinding JNDI name: queue/ex
o 12:07:13,885 INFO [DLQ] Unbinding JNDI name: queue/DLQ
o 12:07:13,895 INFO [ConnectionFactoryBindingService] Unbound
ConnectionManager
'jboss.jca:service=DataSourceBinding,name=DefaultDS' from JNDI
name 'java:DefaultDS'
12:07:16,578 INFO [HypersonicDatabase] Database standalone
closed clean

o Redeploy Hypersonic DB (hsqldb-ds.xml) and JMS MQ automatically starts up
again
o 12:18:48,713 INFO [ConnectionFactoryBindingService] Bound
ConnectionManager
'jboss.jca:service=DataSourceBinding,name=DefaultDS' to JNDI name
'java:DefaultDS'
o 12:18:48,847 INFO [A] Bound to JNDI name: queue/A
o 12:18:48,852 INFO [B] Bound to JNDI name: queue/B
o 12:18:48,856 INFO [C] Bound to JNDI name: queue/C
o 12:18:48,861 INFO [D] Bound to JNDI name: queue/D
o 12:18:48,865 INFO [ex] Bound to JNDI name: queue/ex
o 12:18:48,870 INFO [testTopic] Bound to JNDI name:
topic/testTopic
o 12:18:48,879 INFO [securedTopic] Bound to JNDI name:
topic/securedTopic
o 12:18:48,883 INFO [testDurableTopic] Bound to JNDI name:
topic/testDurableTopic
o 12:18:48,887 INFO [testQueue] Bound to JNDI name:
queue/testQueue
o 12:18:48,934 INFO [UILServerILService] JBossMQ UIL service
available at : /0.0.0.0:8093
12:18:48,950 INFO [DLQ] Bound to JNDI name: queue/DLQ

o Observe the <depends> in the descriptors

6.6. Hot vs. Cold Deployment

Hot deployment is cool, but there is a risk of:
o Class-Loader exceptions (more on this later)
o Unrecognized configuration settings
o Lost session/application scoped data
Cold deployment is slow but stable
o Stop JBoss AS
o Optionally delete data/, log/, tmp/, work/
o Redeploy your application(s)
o Start JBoss AS

Hot deployment is generally considered safe for:

Java Server Pages (.jsp) files. They get recompiled automatically by the servlet engine
following a change.
Class files that do not change their public interfaces, especially when there is no RMI involved.
This requires full redeployment, so it is still somewhat risky.

Hot and cold [re]deployments can be easily automated with the Ant build tool. See
http://ant.apache.org for more info.

6.7. Bootstrapping JBoss

When JBoss AS is first started, it is nothing more than a JBoss Microcontainer.

o It shows its true nature once it loads (bootstraps) the core services from the
${jboss.server.config.url}/jboss-service.xml and
${jboss.server.config.url}/bootstrap.xml files, based on the configuration
set (defined on the command line).

6.7.1. File conf/jboss-service.xml

Defines settings and JMX-based services that are fixed for the lifetime of the server:

Class-path: ${jboss.server.lib.url}/* and ${jboss.common.lib.url}/*
MainDeployer - now just a wrapper for the existing deployment mechanism (as specified above)
Attribute Persistence Service
o Used to persist changes made through JMX to server configuration
o Disabled by default
Thread Pool
o Used by a number of JBoss services, including EJBs
o The maximum pool size (MaximumPoolSize=10) and blocking mode
(BlockingMode=run) may need to be tuned (more on that later)
Logging
o Based on Log4J
o Configured via ${jboss.server.home.url}/conf/jboss-log4j.xml
 Automatically refreshed every 60 seconds if changed
Class Loading (including for RMI)
JNDI Naming Service
o Includes JNDIView for JMX-based monitoring of JNDI
JaasSecurityManager

6.7.2. File conf/bootstrap.xml

Lists URLs (files) that are to be loaded and processed for Microcontainer-based beans during the
bootstrapping process

<bootstrap xmlns="urn:jboss:bootstrap:1.0">
<url>bootstrap/logging.xml</url>
<url>bootstrap/vfs.xml</url>
<url>bootstrap/classloader.xml</url>
<url>bootstrap/aop.xml</url>
<url>bootstrap/jmx.xml</url>
<url>bootstrap/deployers.xml</url>
<url>bootstrap/profile.xml</url>
</bootstrap>

6.7.3. XMBeans in conf/xmdesc/

XMBeans annotate MBeans (defined in jboss-service.xml) by adding ability to:
o Describe attributes and operations
o Expose notification information
o Define persistence of attributes

o Inject custom interceptors for security and remote access
Unique to JBoss AS
Declarative (XML-based), not hard-coded

XMBeans in conf/xmdesc/:

AttributePersistenceService-xmbean.xml
ClientUserTransaction-xmbean.xml
JNDIView-xmbean.xml
Log4jService-xmbean.xml
NamingService-xmbean.xml
...

6.8. Lab: Deployment

Deploying fortune.war example application
Undeploy it
Redeploy it
Test access to it

1. Start JBoss AS
2. Deploy fortune.war to ${jboss.server.home.url}/deploy/
3. Observe JBoss AS console output and test http://localhost:8080/fortune/
4. Undeploy fortune.war (move or delete)
5. Observe JBoss AS console output and test http://localhost:8080/fortune/
6. Redeploy - twice
7. Observe JBoss AS console output
8. Restart JBoss AS
9. Is the application still deployed?
10. Modify deployed fortune.war/WEB-INF/web.xml file (while JBoss AS is running). For
example, add:
11. <servlet-mapping>
12. <servlet-name>fortune</servlet-name>
13. <url-pattern>/get</url-pattern>
</servlet-mapping>

14. Observe JBoss AS console output and test http://localhost:8080/fortune/get

7. Web Application Administration
7.1. Web Technologies

CGI - Common Gateway Interface

CGI scripts executed in a separate process by the web server (e.g. Apache HTTPD)
Used since the early days because of its simplicity (minimal requirements). Still popular.
Language independent, but mostly used in conjunction with Perl and Python
Inefficient, as interpreters had to be reloaded and scripts re-parsed on every single request

Cold Fusion - ColdFusion Markup Language (CFML)

Developed and controlled by Macromedia
Easy to learn and powerful
Still widely used, although many shops are switching to other technologies

PHP - PHP Hypertext Preprocessor

Scripting language that runs within PHP-enabled web servers, like Apache
Very popular for developing smaller-scale web applications, especially in the open-
source community
Easy to learn and powerful

ASP - Active Server Pages

Developed and controlled by Microsoft
Runs on Microsoft IIS web server

Dynamic content written in VBScript, JavaScript, VisualBasic, or C# (part of ASP.NET)

Servlet / JSP - JavaServer Pages

Developed through the Java Community Process (part of Java EE)
Based on Java: OO, rich library, powerful environment, platform independent, efficient
(run in-memory), scalable
Easy to separate presentation from logic

7.2. CGI vs. Servlets/JSPs

Servlets/JSPs are executed in the same Java Virtual Machine process in separate threads. This
leads to very optimized and efficient system utilization.

CGI scripts on the other hand also utilize the system, but very inefficiently. Many CPU cycles
are spent on starting/scheduling new processes, re-loading the interpreter, and re-parsing the
scripts. Sharing of data is achieved through some external system, like RDBMS, file system, or
another process.

7.3. Tomcat Web Container

Apache Tomcat (6.x) is a free and open source Servlet (2.5) and JSP (2.1) Container
Embedded in JBoss AS as deploy/jbossweb.sar
JBoss AS configuration for Tomcat integration in each application are located in META-
INF/jboss-web.xml

o Default JAAS Security Domain
o Class Loading and Sharing
o Session Management and Caching
o Clustering and Load Balancing (in all config)

<jboss-web>
<security-domain>java:/jaas/simple-security-domain</security-domain>
</jboss-web>

7.4. Tomcat’s server.xml

Tomcat‟s own configuration file: deploy/jbossweb.sar/server.xml
Configures
o Connectors (HTTP, HTTPS, AJP)
o Security Realms (Inherits from JBoss)
o Logging (Tomcat Service)
o Valves (Request/Response interceptors)
o Virtual Hosts (Name-based)
o Web application contexts (Per-app configuration)

<Server>

<Listener className="org.apache.catalina.core.AprLifecycleListener"
SSLEngine="on" />

<Listener className="org.apache.catalina.core.JasperListener" />

<Service name="jboss.web">

<Connector protocol="HTTP/1.1" port="8080"
address="${jboss.bind.address}"
connectionTimeout="20000" redirectPort="8443" />
...

<Connector protocol="AJP/1.3" port="8009" address="${jboss.bind.address}"
redirectPort="8443" />
...
<Engine name="jboss.web" defaultHost="localhost">
...
<Realm className="org.jboss.web.tomcat.security.JBossWebRealm"
certificatePrincipal="org.jboss.security.auth.certs.SubjectDNMapping"
allRolesMode="authOnly"
/>
...
<Host name="localhost">
...
<Valve
className="org.jboss.web.tomcat.service.jca.CachedConnectionValve"

cachedConnectionManagerObjectName="jboss.jca:service=CachedConnectionManager"
transactionManagerObjectName="jboss:service=TransactionManager" />

</Host>
</Engine>
</Service>
</Server>

7.5. Tomcat’s web.xml

Default web descriptor for all web apps deployers/jbossweb.deployer/web.xml
Configures
Common Filters
Servlets for handling static content (DefaultServlet), JSPs, SSI, CGI scripts, invokers,
etc.
Default session timeout
MIME Type mappings
Welcome file list: index.html, index.jsp, etc.

Note
While most of the settings in this file can be left as default, the JSP servlet has a number of
options (http://tomcat.apache.org/tomcat-6.0-doc/jasper-howto.html) that we may wish to
change before putting JBoss in production. These include: development,
modificationTestInterval, checkInterval, classdebuginfo, suppressSmap,
mappedfile, trimSpaces, and genStrAsCharArray.
Note
While the deployment descriptors are usually the responsibility of developers and
application assemblers, this web.xml file is global to the entire web container and as such it
is owned by the administrators.

7.6. Defining and Mapping Servlets

In WEB-INF/web.xml file:
o Define a servlet with <servlet> where <servlet-name> points to a fully
qualified <servlet-class>
 Optionally initialize with <init-param>-s
 Optionally <load-on-startup>
o Map a defined servlet with <servlet-mapping> where <url-pattern> points to
previously specified <servlet-name>
 Map under multiple <url-pattern>-s if needed
 <servlet>
 <servlet-name>IPLoggerServlet</servlet-name>
 <servlet-class>example.servlet.IPLoggerServlet</servlet-
class>
 <init-param>
 <param-name>file</param-name>
 <param-value>/WEB-INF/ip.log</param-value>
 </init-param>
 <load-on-startup>2</load-on-startup>
 </servlet>


 <servlet-mapping>
 <url-pattern>/ip</url-pattern>
 </servlet-mapping>

 <servlet-mapping>
 <url-pattern>/logmyip</url-pattern>
</servlet-mapping>
Note
While web.xml files are now defined with schemas, prior to J2EE 1.4 they were defined
with DTDs. These are often easier to read by humans:
<!ELEMENT servlet (icon?, servlet-name, display-name?, description?,(servlet-
class|jsp-file), init-param*, load-on-startup?, run-as?, security-role-ref*)>
<!ELEMENT servlet-mapping (servlet-name, url-pattern)>

7.7. Defining and Mapping Filters

In WEB-INF/web.xml file:
o Define a filter with <filter> where <filter-name> points to a fully qualified
<filter-class>
 Optionally initialize with <init-param>-s
o Map a defined filter with <filter-mapping> where <url-pattern> points to
previously specified <filter-name>
 Map under multiple <url-pattern>-s if needed
 Map with /* to apply to all requests
 <!ELEMENT filter (icon?, filter-name, display-name?,
description?, filter-class, init-param*)>
 <filter>
 <filter-name>Logger</filter-name>
 <filter-class>example.servlet.AccessLogFilter</filter-
class>
 </filter>

 <!ELEMENT filter-mapping (filter-name, (url-pattern |
servlet-name))>
 <filter-mapping>
 <filter-name>Logger</filter-name>
 <url-pattern>/*</url-pattern>
</filter-mapping>

7.8. Session Configuration

Configure <session-timeout> in the <session-config> element
The value (in minutes) indicates how long the servlet container will maintain an idle
session (in memory or on disk) before timing out
Value ⇐ 0 indicates that sessions never expire - unless destroyed explicitly (through
users logouts)

Significant impact on server memory usage and end users dissatisfaction with time outs
<session-config>
<session-timeout>30</session-timeout>
</session-config>

7.9. Welcome File List

Configured through <welcome-file-list> in WEB-INF/web.xml file
Defines the files to be served when an end-user makes a request for a directory on the
server (e.g. http://host.com/dir/)
Defined globally, but can be overridden in individual applications (replaces global)
The first matched file is served
If no match is made, directory listing is returned, or (if disabled) an HTTP 404
<!ELEMENT welcome-file-list (welcome-file+)>
<welcome-file-list>
<welcome-file>index.html</welcome-file>
<welcome-file>index.htm</welcome-file>
<welcome-file>index.jsp</welcome-file>
</welcome-file-list>

7.10. Error Documents

Configured through web.xml's <error-page> elements
Define mapping between an <error-code> (or <exception-type>) and a <location>
of the error document to be served on those errors
Exception-type is somewhat unreliable as Java EE app servers wrap exceptions
<!ELEMENT error-page ((error-code | exception-type), location)>
<error-page>
<error-code>404</error-code>
<location>/FileNotFoundError.html</location>
</error-page>

<error-page>
<exception-type>
java.lang.IllegalArgumentException
</exception-type>
<location>/IllegalInputError.html</location>
</error-page>
Note
The <location> is relative to the root of the application and it
must start with a slash (/) character.
Note
Browsers such as Microsoft‟s Internet Explorer and Google‟s Chrome do not show
server error pages (instead they show friendly error pages) unless those pages are
either styled (e.g. contain references to style sheets, images, etc.) or exceed 512
bytes

7.11. Serving Static Content

Tomcat serves static content via its DefaultServlet (configured in Tomcat‟s web.xml
file)
o Any file under an application‟s structure (but outside WEB-INF and META-INF
directories) is considered static content
Application deploy/ROOT.war/ is considered special - it has no context path
o Serves all content not served by any other application
Returns a HTTP 404 response if the requested static content does not exist
ROOT.war also provides support for http://localhost:8080/status servlet (see its WEB-
INF/web.xml)

Note
For example, to share images across multiple applications, create a directory
deploy/ROOT.war/images/ and place your images there. A request for
http://localhost:8080/images/cool.png would be served from
ROOT.war/images/cool.png

7.12. Virtual Hosting with Tomcat

Add hosts and aliases to server.xml:
<Host name="myhost.com">
<Alias>www.myhost.com</Alias>
</Host>

Register applications for virtual hosts in their WEB-INF/jboss-web.xml files:
<jboss-web>
<context-root>/myapp</context-root>
<virtual-host>myhost.com</virtual-host>
</jboss-web>

Applications default to host specified by <Engine>'s defaultHost attribute

server.xml:

<Server>
<Service>
<Connector .../>
<Engine>
<Host name="myhost.com">
<Alias>www.myhost.com</Alias>
</Host>
<Host name="anotherhost.com"/>
</Engine>
</Service>
</Server>

myapp.war/WEB-INF/jboss-web.xml:

<jboss-web>
<context-root>/myapp</context-root>
<virtual-host>myhost.com</virtual-host>
</jboss-web>

ROOT-another.war/WEB-INF/jboss-web.xml:

<jboss-web>
<context-root>/</context-root>
<virtual-host>anotherhost.com</virtual-host>
</jboss-web>

7.13. Web Access Logging

In server.xml define a <Valve> in
o <Engine> - global for the entire server
o <Host> - per virtual host
o <Context> - per application
 Store as WEB-INF/context.xml
Automatic rotation of logs (daily/hourly)
Supports customizable and standard patterns
Conditional logging
<Valve className="org.apache.catalina.valves.AccessLogValve"
prefix="localhost_access_log." suffix=".log"
pattern="common" directory="${jboss.server.home.url}/log"
resolveHosts="false" />

In addition to common and combined, pattern can also be set to a mix of:

%a - Remote IP address
%A - Local IP address
%b - Bytes sent, excluding HTTP headers, or - if zero
%B - Bytes sent, excluding HTTP headers
%h - Remote host name (or IP address if resolveHosts is false)
%H - Request protocol
%l - Remote logical username from identd (always returns -)
%m - Request method (GET, POST, etc.)
%p - Local port on which this request was received
%q - Query string (prepended with a ? if it exists)
%r - First line of the request (method and request URI)
%s - HTTP status code of the response
%S - User session ID
%t - Date and time, in Common Log Format
%u - Remote user that was authenticated (if any), else -
%U - Requested URL path
%v - Local server name
%D - Time taken to process the request, in millis

%T - Time taken to process the request, in seconds

See http://tomcat.apache.org/tomcat-6.0-doc/config/valve.html

7.14. Lab: Tomcat

Define a HTTP 404 error handler for the ROOT.war web application and test it (You can
find help here)
o A simple 404.html error document could look like:
o <html>
o <head><title>File Not Found</title></head>
o <body>
o <h2>The file you requested has not been found</h2>
o <p><a href="http://google.com">Search for it?</a></p>
o </body>
</html>
Note
Internet Explorer will not show the error document (it will use its own error
page) if the content is smaller than 512 bytes. Either add more content to
your error page or use a different browser, like Firefox.

Configure two virtual hosts
o Use localhost and the name of your machine or
o Invent new hostnames and add them to hosts file
 The location of this file is dependent on the operating system:
/etc/hosts (on most UNIX-type operating systems)
C:WindowsSystem32driversetchosts (on Windows)
 Alternatively, use vhost1.marakana.com and vhost2.marakana.com
which simply point back to 127.0.0.1. In fact, www.vhost1.marakana.com
and www.vhost2.marakana.com also point to the same loop-back address.
Deploy some static content and test that you get retrieve it through your browser
Set up web access logging
o Separate for each host
o Use a different pattern on each

8. JNDI Administration
8.1. Java Naming and Directory Interface

Core infrastructure (glue) for locating objects or services within an application server
Also allows external clients to locate services
Important for clustering: hides actual location
Divided into API and SPI
o Applications code against the API
o Application servers provide the SPI

SPIs for accessing remote resources, such as LDAP, DNS, NIS, file systems, RMI
registry

Note
Even though JNDI is defined in Java SE, it has a fundamental role in Java EE. It provides
the isolation for Java EE component code from the environment in which the code is
deployed - i.e. easily customize the environment without modifying the source.

8.2. JNDI in Java EE

JNDI is to Java EE what DNS is to Internet apps
JNDI maps high-level names to resources like mail sessions, database connection pools,
EJBs, and plain environmental properties
JNDI organizes its namespace using Environmental Naming Context (ENC) naming
convention:
o Starts with java:comp/env
o Private to each application
o Contexts are delimited with a forward-slash (/)

JNDI ENC naming convention:

java:comp/env/var - Environmental variables
java:comp/env/url - URLs
java:comp/env/mail - JavaMail sessions
java:comp/env/jms - JMS connection factories and destinations
java:comp/env/ejb - EJB home interfaces
java:comp/env/jdbc - JDBC DataSources

Important
The use of the ENC naming convention is not required, but it is strongly encouraged!

8.3. JNDI on JBoss

Supports both local (optimized) and remote (over RMI) access to named objects
Provides a JVM-private app-shared java: context in addition to app-private java:comp
Everything outside java: is public and externally visible
Exposes JNDI operations over JMX invoke operations - allows access over HTTP/S
Supports viewing JNDI Tree remotely
Supports clustering through HA-JNDI

Configured in ${jboss.server.config.url}/jboss-service.xml:

<mbean code="org.jboss.naming.NamingService"
name="jboss:service=Naming"
xmbean-dd="resource:xmdesc/NamingService-xmbean.xml">

...
<mbean code="org.jboss.naming.JNDIView"
name="jboss:service=JNDIView"
xmbean-dd="resource:xmdesc/JNDIView-xmbean.xml">
</mbean>

Client configuration ${jboss.server.config.url}/jndi.properties:

java.naming.factory.initial=org.jnp.interfaces.NamingContextFactory
java.naming.factory.url.pkgs=org.jboss.naming:org.jnp.interfaces

Remote clients would need to add:

java.naming.provider.url=jnp://jbosshost.domain.com:1099

8.4. Lab: JNDI View

In your browser, navigate to http://localhost/jmx-console/
Under jboss context, click on service=JNDIView
Invoke the list(true) operation
Verify that in the java: namespace you can see JBoss services such as DefaultDS,
DefaultJMSProvider, etc.
Deploy jndiview.war and compare results

We will cover JMX Console soon.

Note that jndiview.war updates the JNDI tree on every request, recording global visit counter. If
you are interested, take a look at its source code.

9. Javamail Administration
9.1. What is JavaMail?

Platform and protocol-independent framework for building [email] messaging
applications
Split into abstract API and protocol-specific SPI
o Default implementation for SMTP, POP3, IMAP
Optional in J2SE, included in J2EE
In J2EE, application server generally manage a mail session - a shared resource for
sending email messages over SMTP
JavaMail implicitly uses JavaBeans Activation Framework (JAF).
o JAF provides standard services to:
 determine the type of an arbitrary piece of data,
 encapsulate access to it,
 discover the operations available on it,
 and create the appropriate JavaBeans component to perform those
operations

JAF unifies the manner of working with various data formats, be it simple text files, or
complex types such as audio, images, video, etc. JAF provides a framework for plugging
in data-handlers into JavaMail.

9.2. Configuring JavaMail Service

Configured in JBoss AS by deploy/mail-service.xml
Shared connection information for sending email messages over SMTP
o Set mail.smtp.host in deploy/mail-service.xml, and optionally set
mail.debug to true:
o <server>
o <mbean code="org.jboss.mail.MailService"
o name="jboss:service=Mail">
o <attribute name="JNDIName">java:/Mail</attribute>
o ...
o <attribute name="Configuration">
o <configuration>
o ...
o <property name="mail.smtp.host"
value="smtp.nosuchhost.nosuchdomain.com"/>
o <property name="mail.smtp.port" value="25"/>
o ...
o </configuration>
o </attribute>
o ...
o </mbean>
</server>

o To enable support for SMTP over SSL:
o <server>
o ...
o <configuration>
o ...
o <property name="mail.smtp.port" value="465"/>
o <property name="mail.smtp.ssl.enable" value="true"/>
o <property name="mail.smtp.socketFactory.class"
value="javax.net.ssl.SSLSocketFactory"/>
o ...
o </configuration>
o </attribute>
o ...
o </mbean>
</server>

o To enable support for SMTP authentication:
o <server>
o ...
o <attribute name="User">your-username</attribute>

o <attribute name="Password">your-password</attribute>
o <configuration>
o ...
o <property name="mail.smtp.auth" value="true"/>
o <property name="mail.smtp.user" value="your-username"/>
o ...
o </configuration>
o </attribute>
o ...
o </mbean>
</server>

Can also configure the defaults for receiving mail over POP/IMAP4
Can enable debugging to STDOUT <property name="mail.debug" value="true"/>

Note
If you don‟t have access to mail server that will relay your mail then set mail.smtp.host to
your inbound SMTP mail server. On unix you can use the following command dig mx
"domain_name" (e.g gmail.com)
gmail.com. 2156 IN MX 5 gmail-smtp-in.l.google.com.
gmail.com. 2156 IN MX 20 alt2.gmail-smtp-
in.l.google.com.
in.l.google.com.
in.l.google.com.
in.l.google.com.

9.3. Lab: Mail

Configure mail-service.xml for your environment
In sendmail.war
o Determine the resource requirement
o Add required resource mapping
Deploy sendmail.war
Test that you can send email
Experiment by enabling debugging

Note
SMTP authentication for JavaMail under JBoss is not trivial to enable. Experiment without
it. Try setting the mail server to the host that handles your own email.

10. JMS Administration
10.1. JMS Overview

Framework for reliable both synchronous and asynchronous communication between
distributed components
Guaranteed push-based delivery
Peer to peer
o One to One, One to Many, Many to Many
Loosely coupled (standard message formats)
JMS Implementation provides necessary services to its clients
JMS is unlike RMI, which is tightly coupled. In JMS, The sender and the receiver need to
know only which message format and which destination to use.
JMS is unlike email, which is people oriented. JMS is meant to serve distributed software
applications and components, although it is also used for local (in-JVM) messaging.

10.2. JMS in Java EE

Allows loosely coupled, reliable, asynchronous interactions among Java EE components
and legacy systems capable of messaging
Is reliable, it ensure that a message is delivered once and only once.
Application clients, EJBs, and web components can send and receive JMS messages
Message-driven beans enable the asynchronous (possibly concurrent) consumption of
messages, making it easy to plug in new business event handlers into an existing
deployment
Message send and receive operations can participate in distributed transactions, which
allow JMS operations and database accesses to take place within a single transaction
JMS can be used outside the context of a full-blown app server

10.3. When is JMS Used

When no dependency between components is important
o Compile-time dependency (loose coupling)
o Run-time dependency (components run independently)
When we need asynchronous yet reliable communication
Consider the following usage scenario:

o Components of an enterprise application for an automobile manufacturer can use the JMS
API in situations like these:
 The inventory component can send a message to the factory component when the
inventory level for a product goes below a certain level so that the factory can
make more cars
 The factory component can send a message to the parts components so that the
factory can assemble the parts it needs
 The parts components in turn can send messages to their own inventory and order
components to update their inventories and to order new parts from suppliers
 Both the factory and the parts components can send messages to the accounting
component to update their budget numbers
 The business can publish updated catalog items to its sales force

JMS clients are the programs (possibly external) or components, written in the Java
programming language, that produce and consume messages. Any Java EE application
component can act as a JMS client.
A JMS provider is a messaging system that implements the JMS interfaces and provides
administrative and control features. JBoss Messaging is such provider.
Messages are the objects that communicate information between JMS clients.
Administered objects are preconfigured JMS objects created by an administrator for the
use of clients:
o Connection Factories
o Destinations

10.5. JMS Messaging Domains

Figure 4. Point to Point

Point to Point

A sender (producer) sends a message addressed to a specific queue
A receiver (consumer) consumes the message from the queue established to hold its
messages
Queues retain all messages sent to them until the messages are consumed or until the
messages expire
Each message has only one consumer
A sender and a receiver of a message have no timing dependencies. The receiver can
fetch the message whether or not it was running when the client sent the message
The receiver acknowledges the successful processing of a message

Publish and Subscribe

Publisher clients publish messages to one or more message topics
Subscriber clients subscribe to one or more message topics and receive messages when
they are sent to them
The topics hold the messages as long as it takes to deliver them to all currently subscribed
clients
Each message can have multiple consumers
Publishers and subscribers have a timing dependency. A client that subscribes to a topic
can consume only messages published after the client has created a subscription, and the
subscriber must continue to be active in order for it to consume messages (unless it holds
a durable subscription)

10.6. JMS Message Consumption

Synchronous: A subscriber or a receiver explicitly fetches the message from the
destination by calling the blocking receive method (with support for timeouts)
Asynchronous: A client can register a message listener with a consumer. Whenever a
message arrives at the destination, the JMS provider delivers the message by calling the
listener‟s onMessage method, which acts on the contents of the message

We will use an asynchronous JMS client in the JMS lab.

10.7. JMS on JBoss Configuration

Configuration files can be found in deploy/messaging directory of your JBoss server.
o connection-factories-service.xml: Define connection factories
o destinations-service.xml: Define destinations (Topic,Queue)
o hsqldb-persistence-service.xml: Define persistence for messages (The
messaging service stores all messages before delivering them)
o jms-ds.xml: JMSProviderLoader and JmsXA inflow resource adaptor connection
factory binding configuration
o legacy-service.xml: JMSProviderLoader and JmsXA inflow resource adaptor
connection factory binding configuration
o messaging-jboss-beans.xml: Configures JMS security and management beans
o messaging-service.xml: Contains the server‟s configuration and core
messaging services
o remoting-bisocket-service.xml: Contains JMS remoting configuration

10.8. Configure JMS connection factories

New JMS connections are created by ConnectionFactory.
JBoss AS 5 ships already configured, non-clusterable and clusterable connection factories
o Non-clustered are bound to the following JNDI contexts: /ConnectionFactory,
/XAConnectionFactory, java:/ConnectionFactory,
java:/XAConnectionFactory
o Clustered are bound to the following JNDI contexts:
/ClusteredConnectionFactory, /ClusteredXAConnectionFactory,
java:/ClusteredConnectionFactory,
java:/ClusteredXAConnectionFactory
Configuration located in deploy/messaging/connection-factories-service.xml

Note
Factories that are bound to the java: namespace are reserved for local JMS Client (running
on the same JVM of the server)

You can find an example on how to create a ConnectionFactory inside
deploy/messaging/connection-factories-service.xml

10.9. Configure JMS destinations

The deploy/messaging/destinations-service.xml contains preconfigured
destinations deployed during server startup
To create your own queue called exampleQueue, you could either add it to
deploy/messaging/destinations-service.xml or deploy your own exampleQueue-
service.xml:
<server>
<mbean code="org.jboss.jms.server.destination.QueueService"
name="jboss.messaging.destination:service=Queue,name=exampleQueue"
xmbean-dd="xmdesc/Queue-xmbean.xml">
<depends optional-attribute-
name="ServerPeer">jboss.messaging:service=ServerPeer</depends>
</mbean>
</server>

o Deploying it binds this queue to JNDI as /queue/exampleQueue:

13:27:57,421 INFO [QueueService] Queue[/queue/exampleQueue]
started, fullSize=200000, pageSize=2000, downCacheSize=2000

Similarly, to create your own topic called exampleTopic, you could either add it to
deploy/messaging/destinations-service.xml or create your own exampleTopic-
service.xml:
<server>
<mbean code="org.jboss.jms.server.destination.TopicService"
name="jboss.messaging.destination:service=Topic,name=exampleTopic"
xmbean-dd="xmdesc/Topic-xmbean.xml">
name="ServerPeer">jboss.messaging:service=ServerPeer</depends>
<depends>jboss.messaging:service=PostOffice</depends>
</mbean>
</server>

o Deploying it binds this topic to JNDI as /topic/exampleTopic:

13:27:57,890 INFO [TopicService] Topic[/topic/exampleTopic]
started, fullSize=200000, pageSize=2000, downCacheSize=2000

You can inspect destination attributes via the JMX console in the
jboss.messaging.destination domain.
Here is some information about attribute you can configure for a destination, for more
info on the additional attributes, see http://jboss.org/jbossmessaging/docs.html
o name: name of the queue
o JNDIName: JNDI name where the queue is bound
o DLQ: Dead Letter Queue to use. It‟s a special destination where the messages are
sent when the server has attempted to deliver them unsuccessfully more than a
certain number of times

o ExpiryQueue: is a special destinations where messages are sent when they have
expired
o RedeliveryDelay: redelivery delay to be used for this queue
o MaxDeliveryAttempts: number of times a delivery attempt will happen before
the message goes to the DLQ
o SecurityConfig: Allows you to determine which roles can read, write and create
on the destination
o FullSize: maximum number of messages held by the queue or the topic in
memory at any given time

10.10. Advanded JBoss Messaging

JBoss Messaging bridge
Persistence service
Securing JMS destinations

10.11. JBoss Messaging bridge

Route messages from one destination to another. Works also across different message
servers.

Note
The source and target servers do not have to be in the same cluster which makes bridging
suitable for reliably sending messages from one cluster to another, for instance across a
WAN, and where the connection may be unreliable.

An simple example on how to configure the bridge:

<mbean code="org.jboss.jms.server.bridge.BridgeService"
name="jboss.messaging:service=Bridge,name=TestBridge"
xmbean-dd="xmdesc/Bridge-xmbean.xml">

<depends optional-attribute-name="SourceProviderLoader">
jboss.messaging:service=JMSProviderLoader,name=JMSProvider 
</depends>

<depends optional-attribute-name="TargetProviderLoader">
jboss.messaging:service=JMSProviderLoader,name=JMSProvider 
</depends>

<attribute name="SourceDestinationLookup">/queue/A</attribute> 

<attribute name="TargetDestinationLookup">/queue/B</attribute> 

<attribute name="MaxBatchSize">5</attribute> 

<attribute name="MaxBatchTime">-1</attribute> 

</mbean>

Source destination provider
Target destination provider. We can change this to reach a remote server.
JNDI lookup for the source destination
JNDI lookup for the target destination
Maximum number of messages to consume from the source before sending to the target
Maximum time to wait (in ms) before sending a batch to the target even if MaxBatchSize is
not exceeded. -1 means wait forever

Save this configuration file as jbm-bridge-service.xml in deploy/messaging

Adding a remote provider
o Create the following jbm-remote-service.xml in the deploy/messaging
folder:
o <mbean code="org.jboss.jms.jndi.JMSProviderLoader"
o
name="jboss.messaging:service=JMSProviderLoader,name=MyRemoteJMSP
rovider,server=localhost">
o 
o <attribute
name="ProviderName">RemoteXAConnectionFactory</attribute>
o <attribute
name="ProviderAdapterClass">org.jboss.jms.jndi.JNDIProviderAdapte
r</attribute>
o <attribute name="FactoryRef">XAConnectionFactory</attribute>
o <attribute
name="QueueFactoryRef">XAConnectionFactory</attribute>
o <attribute
name="TopicFactoryRef">XAConnectionFactory</attribute>
o
o 
o <attribute name="Properties">
o
java.naming.factory.initial=org.jnp.interfaces.NamingContextFacto
ry
o
java.naming.factory.url.pkgs=org.jboss.naming:org.jnp.interfaces
o java.naming.provider.url=remoteServerIPAddress:1099
o </attribute>
</mbean>
This part contains the Factory configuration of the remote server
This part contains the JNDI properties to reach the remote server. Replace
remoteServerIPAddress by the IP of the remote server

Then you will just have to make a change in the jbm-remote-service.xml:

<mbean>
...
<depends optional-attribute-name="SourceProviderLoader">

jboss.messaging:service=JMSProviderLoader,name=MyRemoteJMSProvider,server=rem
oteserver 
</depends>
...
</mbean>
We specify here that we will use MyRemoteJMSProvider as a source

10.12. Persistence service configuration

By default, persistence service is provided by Hypersonic DB and its datasource
DefaultDS
Configuration is located in deploy/messaging/xxx-persistence-service.xml where
xxx is the database name

In this example, we‟re going to use MySQL for the persistence of our messages:

Create a datasource in mysql-ds.xml
Remove hsqldb-persistence-service.xml from the deploy/messaging folder
Then, you need to create mysql-ds-persistence.xml in the deploy/messaging folder.
Do not start from scratch, you can find an example in the
%JBOSS_HOME%/docs/examples/jms

Reduced version of mysql-persistence-service.xml:

...
<server>
<mbean code="org.jboss.messaging.core.jmx.JDBCPersistenceManagerService"
name="jboss.messaging:service=PersistenceManager"
xmbean-dd="xmdesc/JDBCPersistenceManager-xmbean.xml">

<depends>jboss.jca:service=DataSourceBinding,name=MySqlDS</depends>

name="TransactionManager">jboss:service=TransactionManager</depends>


<attribute name="DataSource">java:/MySqlDS</attribute>


<attribute name="CreateTablesOnStartup">true</attribute>


<attribute name="DetectDuplicates">true</attribute>


<attribute name="IDCacheSize">500</attribute>

<attribute name="SqlProperties">...</attribute>

Java EE Overview and JBoss AS

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (20)

Semelhante a Java EE Overview and JBoss AS

Semelhante a Java EE Overview and JBoss AS (20)

Java EE Overview and JBoss AS