JBOSS  IN ACTION - Errata

If you find any mistakes in the book, please post them in the Author Online Forum.

Appendix B lists a number of changes that were made to JBoss AS 5.0.0 between the CR2 and GA releases. This errata will not repeat those changes. For example, B.1.3 describes the common/lib directory which holds the JAR files that used to be in server/xxx/lib. The book references the server/xxx/lib directory in many locations, but those locations are not mentioned in this errata because the change is already covered in B.1.3. Having said that, this errata focuses on changes to JBoss AS 5.0.0.GA that did not get into the book or appendix B.

Changes specific to the JBoss AS 5.1.0.GA released are marked as such.

Chapter 1

Page 1, Part I opener, Second Paragraph

Edit: Current text reads "...almost all the other chapters rely on this knowledge as you deploy web application, enterprise application....". Text should read "...almost all the other chapters rely on this knowledge as you deploy web applications, enterprise applications...."

Page 7, Table 1.1

Edit: "Red Hat Developer Studio" should be "JBoss Developer Studio"

Reason: This was renamed for marketing reasons.

Page 12, First paragraph after note

Edit: Current text reads: "The installer should also allow you to specify a name for you configuration." Should read: "The installer should also allow you to specify a name for your configuration."

Page 18, Table 1.4

Edit: The description for standardjboss.xml should be "Used to configure the various EJB 2.x containers."

Reason: The book focuses on EJB3 configuration, but we accidentally snuck in a few EJB 2.x references in chapter 7.

Page 18, The LIB Directory, last sentence

Edit: The last sentence of this section should be removed.

Reason: Database drivers have issues when deployed in isolated/scoped deployments, though there are workarounds. See this article. Even if you're not using a scoped deployment, you may want to switch to one in the future, so the simplest thing to do is avoid doing it in the first place.

Page 19, first paragraph (continued from last page)

Edit: Text currently reads: "The security service logs all security-related log files to this file to make it easier to audit security error. " Text should read: "The security service logs all security-related log files to this file to make it easier to audit security errors."

Chapter 2

Page 30, Understanding the Beans Configuration File

The profile.xml file is now located in the server/xxx/conf/bootstrap directory. Most of the bean configuration files were moved from the server/xxx/conf directory to the server/xxx/conf/bootstrap directory.

Page 33, table 2.1

JBoss AS 5.1.0: File jbossjta-properties.xml has been renamed jbossts-properties.xml.

Page 33, paragraph after table 2.1

The file standardjboss.xml is specific to EJB 2.x.

Page 33, Last bullet item: Various MBeans related to the remoting service

The remoting service is now governed using POJOs defined in the file server/xxx/deploy/remoting-jboss-beans.xml.

Page 33, Table 2.1

The boostrap.xml and bootstrap-norepo.xml files are discussed in B.1.5.

There is no longer a jboss-minimal.xml file.

There is now a java.policy file which is used to define the security policy (or lack thereof) for the application server.

For the jacorb.properties file the description should read "Used to configure the Java Object Request Broker (JacORB) service."

Pages 34, section 2.2.1

JBoss AS 5.1.0: By default only INFO level and higher messages are logged in server.log. You can change this by adding the jboss.server.log.threshold system property to the JAVA_OPTS in the run scripts. For example, adding “-Djboss.server.log.threshold=DEBUG” will log at DEBUG level in the server.log file. You can also change the default by editing the server/xxx/conf/jboss-service.xml file, the DefaultJBossServerLogThreshold attribute of the jboss.system:type=Log4jService,service=Logging Mbean.

Pages 40-41, section 2.2.3

You can view the system properties that were set by looking at the server/xxx/log/boot.log file.

Chapter 3

Page 51, Table 3.1

For suffix .zip, the URL in the Application Type column should be http://localhost:8080/someapp.zip.

Pages 51

Table 3.1 should be numbered 3.2.

Pages 52-55, Section 3.1.5

Table 3.2 should be numbered 3.3.

Changes to this section, and table 3.3, are covered in B.1.5.

Page 56, Tip

Due to various classload changes, the useJBossWebLoader and java2ClassLoadingCompliance properties are no longer used. To provide access to classes in a WAR file to other applications, remove or comment out the WarClassLoaderDeployer bean in the server/xxx/deployers/jbossweb.deploy/META-INF/war-deployers-jboss-beans.xml file. Optionally, you could supply as WEB-INF/jboss-classloader.xml file and configure exactly which applications have visibility to the classes in the WAR. See http://www.jboss.org/community/wiki/useJBossWebClassLoaderinJBoss5 for more details.

Page 62

Table 3.3 should be numbered 3.4.

Pages 63-65

Table 3.4 should be numbered 3.5.

Page 64, table 3.5 (erroneously numbered 3.4)

For tag <min-pool-size>, the second sentence of the description should read "Note that, unless the <prefill> option is given, the application server doesn’t open…"

Add a new entry: tag - <prefill>, description – "If set to true, the application server will establish the number of connections specified by <min-pool-size> at the time the data source is deployed. If set to false (default), the application server does not establish any connections until the first application request."

Pages 65-66

Table 3.5 should be numbered 3.6.

Page 65, table 3.6 (erroneously numbered 3.5)

Mbean "jboss.jca:name=XXX, service=LocalTxCM", in the description delete the sentence "You can use this Mbean to manage various aspects of distributed transactions, such as the local XA resource transaction timeout value."

Page 66, section “Packaging the data source in an EAR file”

The third paragraph states that you can include the JDBC driver JAR file in the EAR archive. Be aware that this practice is not recommended, and in addition if you use class scoping by defining a loader repository, redeploying the EAR will cause a memory leak in the permgen due to the JDBC driver classes not being released.

Chapter 4

Page 81, 4.1.6 - Logging security on the server

Edit: Remove both class="org.jboss.logging.XLevel" attributes.

Reason: When Log4J was updated to 1.2.14, this attribute became unnecessary. If you specify the attribute, TRACE logging will in fact not be shown.

Chapter 5

Page 113, Table 5.1

Edit: The description for replication-config should start "Specifies when and how to replicate ..."

Page 115, Locating key directories, third paragraph, next to last sentence

Edit: A slash was left off, should read: "The server/xxx/deployers/jbossweb.deployer directory..."

Page 115, Locating key directories, first bullet point

Edit: Directory should be "deploy/jbossweb.sar/server.xml"

Page 115, Locating key directories, fourth bullet point

Edit: Directory should be "deployers/jbossweb.depoloyer/web.xml"

Chapter 6

Page 137, Configuring security in web.xml, second paragraph, second sentence

Edit: "web-resource-collection" should be "auth-constraint"

Chapter 7

Page 166, Listing 7.1

The archive filenames are incorrect, the listing should read as follows:

<application>
  <display-name>Some Enterprise Archive</display-name>
  <module>
    <web>
      <web-uri>SomeWebArchive.war</web-uri>
      <context-root>/myapp</context-root>
    </web>
  </module>
  <module>
    <ejb>SomeEjbJarArchive.jar</ejb>
  </module>
</application>

Page 172, Section 7.3, Second paragraph, first sentence

Edit: Should say "... configuration of individual *EJB* applications and configuration of..."

Page 172, Section 7.3, After Second paragraph

Edit: Add paragraph: "Much of the JBoss AS specific EJB configuration is applied to EJBs using annotations. Default annotations are applied to EJBs using Aspect Oriented Programming (AOP). These default annotations can be overridden in the individual beans, or the default values can be changed by configuring the aspects."

Page 172, Section 7.3.1, Second paragraph

Edit: Remove the paragraph that starts with "The conf directory contains.."

Reason: This paragraph describes the standardjboss.xml file which which is used to configure EJB2 containers, not EJB3.

Page 172, Section 7.3.1, Third paragraph

Edit: Replace the last sentence with - "The deploy/ejb3-interceptors-aop.xml file is the main file you modify to configure default global EJB settings such as EJB pool sizes, pool timeouts, and cache configurations."

Page 176, Table 7.1, description for deploy/ejb3-interceptors-aop.xml

Edit: add the following to the end of the description "..., and default EJB pool sizes."

Page 178, First sentence (after code example)

Edit: This sentence should change to the following two sentences: "... it gets bound under the name MessagePrinterBean/remote or MessagePrinterBean/local, depending on whether it extends a remote or local interface. Then clients will use this name to look up the bean."

Reason: We describe the /remote and /local part of the JNDI name on the next page, but this example was technically incorrect without talking about these endings.

Page 180-182, Section 7.4.3

Reason: This entire section was incorrectly written to describe configuration of the EJB3 containers using the standardjboss.xml file. This file is used to configure EJB2 containers, but not EJB3 containers. The changes in this section are too scattered to document individually, so we have provided the entire updated text for 7.4.3 here.

Edit:

7.4.3 Configuring EJB containers

In JBoss AS, there’s a container definition for each type of remotely accessible EJB. It’s useful to know how to configure containers and the dynamic proxies configured to call the containers so that you can control features such as session-bean pool size and SFSB passivation. In this section, we take a high-level look at how to configure the various EJB containers to help you with more specific configurations throughout the rest of this chapter.

NOTE In EJB3, an entity manager (the interface used to read/write entity objects to a database) can’t be accessed remotely and isn’t managed by a server container. The entity manager accesses entity objects from within a persistent context, which is an in-memory cache of entity objects synchronized to the database. A persistence context is configured in an application’s META-INF/persistence.xml file. Because entities aren’t managed by a server container, as we explore the container configuration, you won’t see anything relating to EJB3 entities.

Default values for both the dynamic proxy and the container definition for each type of EJB are defined in the server/xxx/deploy/ejb3-interceptors-aop.xml file. This is a JBoss AOP configuration file that dynamically applies behavior to beans using pointcuts. Many of the configurable parts of the beans are applied using annotations, thereby enabling you to override them in an individual bean. This file defines two main blocks: one that defines the dynamic proxies and one that defines the containers. Listing 7.12 shows you the general structure of the file.

Listing 7.12 General structure of ejb3-interceptors-aop.xml
<aop>
  <stack>...</stack>
  <stack>...</stack>
  <domain>...</domain>
  <domain>...</domain>
</aop>

Each top-level stack block defines the interceptor stack for a dynamic proxy. The domain blocks are aspect domains, which (in this file) are used to configure the server container for each type of EJB. Listing 7.13 shows you the SFSB configuration as an example.

Listing 7.13 Container configuration for SFSB in ejb3-interceptors-aop.xml

<domain name="Base Stateful Bean" extends="Intercepted Bean" inheritBindings="true">          |#1
  ...
  <annotation expr="!class(@org.jboss.ejb3.annotation.Pool)">                                 |#2
    @org.jboss.ejb3.annotation.Pool (value="ThreadlocalPool", maxSize=30, timeout=10000)      |#2
  </annotation>                                                                               |#2
</domain>

<domain name="Stateful Bean" extends="Base Stateful Bean" inheritBindings="true">             |#3
  <annotation expr="!class(@org.jboss.ejb3.annotation.Cache) …">                              |#4
    @org.jboss.ejb3.annotation.Cache ("SimpleStatefulCache")                                  |#4
  </annotation>                                                                               |#4
  <annotation expr="!class(@org.jboss.ejb3.annotation.PersistenceManager) …">                 |#5
    @org.jboss.ejb3.annotation.PersistenceManager ("StatefulSessionFilePersistenceManager")   |#5
  </annotation>                                                                               |#5
  <annotation expr="!class(@org.jboss.ejb3.annotation.CacheConfig) …">                        |#6
    @org.jboss.ejb3.annotation.CacheConfig (maxSize=100000,                                   |#6
                   idleTimeoutSeconds=300,   removalTimeoutSeconds=0)                         |#6
  </annotation>                                                                               |#6
  ...
</domain>

You know that the second domain block is the configuration for the SFSB container because of the name attribute (#3). The second domain block inherits from the first block (#1) using the extends attribute. By extending the Base Stateful Bean block, the Stateful Bean block inherits any annotations and bindings declared in the Base Stateful Bean block.

The container configuration is primarily composed of interceptors defined in the Base Stateful Bean block, which are not shown in this listing. The container passes incoming requests through a chain of interceptors before it reaches the EJB. Each interceptor handles different non-business concerns of the request, such as checking for security and initializing transaction management. Although you can create custom interceptors and change the order of the existing ones, we’ve found little use for this in practice. If you do need to extend or change the interceptors, the JBoss AS Configuration Guide (referenced at the end of this chapter) explains how to do so.

Some of the other elements in these configuration files are much more commonly changed. Let’s take a look at some of these uses.

CONFIGURING BEAN POOL SIZES

You can configure the default pool sizes for any container managed bean – such as a SFSB or SLSB – by setting the values of the attributes on the org.jboss.ejb3.annotation.Pool annotation (#2) annotation. The annotation XML element defines the pointcut that must be matched before applying the default annotation. In most cases, the pointcut is configured to apply the annotation if it doesn’t already exist on the class. This is done using the exclamation point before the class keyword in the expr attribute.

The annotation that is applied is inside of the annotation XML element. To configure the default values for the pool, you change the maxSize and timeout attributes. The maxSize setting isn’t a strict maximum size; it tells the pool the maximum number of bean instances to keep alive. If more requests come in than this maximum, the server creates more. If you want to strictly limit the number of concurrent requests to a server, use StrictMaxPool in the value attribute as follows:

<annotation expr="!class(@org.jboss.ejb3.annotation.Pool)">
  @org.jboss.ejb3.annotation.Pool (value="StrictMaxPool", maxSize=30, timeout=10000)
</annotation>

The StrictMaxPool value tells the container to never allow more concurrent requests than the value defined in the maxSize attribute(30, in this case). Requests that come in after the maximum are blocked until they timeout based on the number of milliseconds defined by the timeout attribute, after which a java.rmi.ServerException is thrown. If the value of the timeout is 0, then it immediately times out. The maximum (and default) value is the maximum possible Long value which is 9,223,372,036,854,775,807 milliseconds or about 292,471,208 years.

You can also apply the @Pool attribute directly on a bean if you want to override the default values. The org.jboss.ejb3.annotation.defaults.PoolDefaults class contains constants that you can use when specifying the annotation arguments. For example, when specifying the value argument you can use PoolDefaults.POOL_IMPLEMENTATION_THREADLOCAL or PoolDefaults.POOL_IMPLEMENTATION_STRICTMAX for the standard thread local pool or the strict maximum size pool respectively.

CONFIGURING SFSB PASSIVATION

Stateful bean passivation is configured with three annotations: Cache (#4), PersistenceManager (#5), and CacheConfig (#6). The PersistenceManager annotation defines which persistence manager should be used for passivation. The container uses the persistence manager to read and write passivated objects to secondary storage. The default SFSB persistence manager is the StatefulSessionFilePersistenceManager, which writes the session bean state to a file.

The passivation rules are defined in the CacheConfig annotation. In this annotation, maxSize attribute defines the maximum number of beans that can be stored in the cache before the cache will start passivating beans. Passivation is handled using a Least Recently Used (LRU) algorithm. The idleTimeoutSeconds attribute specifies the number of seconds to wait before passivating a SFSB instance, regardless of whether the cache has reached the maximum size. The removalTimeoutSeconds attribute is the number of seconds to wait before the cache removes the bean altogether.

Notice that by default the removalTimeoutSeconds attribute is set to zero seconds. Setting this attribute to zero effectively disables the removal feature and will cause the SFSB to always passivate after the idleTimeoutSeconds period, which is 300 seconds by default. If you set the removalTimeoutSeconds attribute, you’ll want it to be greater than the idleTimeoutSeconds if you want passivation to work. Setting the removalTimeoutSeconds to a non-zero value less than idleTimeoutSeconds will cause the SFSB to be removed from the cache before it is passivated; which is one way to achieve disabling SFSB passivation.

Another way to disable passivation is to change the Cache annotation (#4) from using SimpleStatefulCache to NoPassivationCache, as shown here.

<annotation expr="!class(@org.jboss.ejb3.annotation.Cache) …">
    @org.jboss.ejb3.annotation.Cache ("NoPassivationCache")
</annotation>

If you want to write to a database or use a distributed cache for your SFSB passivation, the best bet is to use the all configuration and use a cache loader. We talk about this more when we discuss clustering in chapters 12 and 13.

We’ve seen how to configure session beans and their containers; now let’s look at how to configure entity persistence.

Page 184, Section 7.6, after last sentence of second (last) paragraph

Edit: Because there is only a single instance, the code for the service must be written to be thread-safe.

Page 193, Section 7.8.1, Tip

Edit: Make sure you’re referencing the correct annotation class. For example, there’s an org.jboss.ejb3.annotation.SecurityDomain annotation class and an org.jboss.aspects.security.SecurityDomain annotation class. Because they share a name and they both take the same number and type of arguments, it’s easy to import the wrong class (org.jboss.aspects.security.SecurityDomain) when annotating an EJB with security.

Reason: The annotation was renamed since the JBoss 5.0 Beta, but the tip was not updated.

Page 200, Third Paragraph, Third Sentence

Edit: The word nonlocal should be non-local

Chapter 8

Page 209, first paragraph, next to last sentence

The example-destinations-service.xml file that contains the destinations used by the example can be found in the docs/examples/jms directory.

Page 217, paragraph following table 8.4

This paragraph relates to EJB 2.x MDBs only.

Page 223, section 8.5.1, paragraph before listing 8.8

The correct location for the example *-ds.xml file is docs/examples/jca/postgres-ds.xml

Page 226, listing 8.1

The listing heading should read: messaging-jboss-beans.xml (expert)

Chapter 9

Page 236, fourth paragraph

The JAX-RPC documentation is now at http://jbossws.jboss.org/mediawiki/index.php?title=JAX-RPC_User_Guide

Page 248, table 9.3, second item

The configFile default is now server/xxx/deployers/jbossws.deployer/META-INF/standard-jaxws-endpoint-config.xml. In fact, all of the standard-*-config.xml files moved from the server/xxx/deploy/jbossws.sar/META-INF directory to the server/xxx/deployers/jbossws.deployer/META-INF directory.

Page 255, paragraph before listing 9.16

As noted earlier, the standard-jaxws-endpoint-config.xml file can now be found at server/xxx/deployers/jbossws.deployer/META-INF.

Page 257, last paragraph

As noted earlier, the standard-jaxws-client-config.xml file can now be found at server/xxx/deployers/jbossws.deployer/META-INF.

Chapter 10

JBoss Portal 2.7

See B.1.2 for information on JBoss Portal 2.7.0.

The chapter mentions several DTD files - in 2.7 those files are located in the source code at core/src/resources/portal-core-sar/dtd, and the version number changed to 2_6. For example, the text regarding the jboss-app_2_0.dtd file on page 281, next to last paragraph, is correct for Portal 2.6 but in Portal 2.7 the file is core/src/resources/portal-core-sar/dtd/jboss-app_2_6.dtd.

Chapter 11

Page 300, second paragraph

For Portal 2.7.0, the overview.xhtml file is located at jboss-portal.sar/portal-identity.sar/portal-identity.war/jsf/register.

Chapter 12

Page 332, Third Paragraph, Last Sentence (before Invalidating cached entity data section)

Edit: Remove everything after the words SFSB state.

Reason: Buddy replication is not enabled for HTTP-session replication in the GA release.

Page 336, Creating a clustered EJB, first paragraph, second sentence

Edit: Start the sentence "Because the server is clustered and the client is accessing a SLSB, the client's..."

Reason: This is to clarify that round-robin load balancing happens because we're accessing a SLSB. With SFSBs, round-robin load balancing is not used.

Page 337, Deploying your application, first paragraph, last sentence

Edit: Strike the last sentence about the JBoss farming service.

Reason: This service is no longer available in JBoss AS 5.

Page 338, Table 12.2

Edit: The table should read as follows:

Node 1 console outputNode 2 console output
INFO [STDOUT] 0INFO [STDOUT] 1
INFO [STDOUT] 2INFO [STDOUT] 3
INFO [STDOUT] 4INFO [STDOUT] 5
INFO [STDOUT] 6INFO [STDOUT] 7
INFO [STDOUT] 8INFO [STDOUT] 9
INFO [STDOUT] 10...

Reason: The default load-balancing strategy is round-robin, but the table was showing random-robin load balancing.

Page 340, Configuring JBoss Clustering Services

Edit: The file server/all/deploy/cluster/cluster-jboss-beans.xml should be server/all/deploy/cluster/hapartition-jboss-beans.xml

Page 341, first paragraph after table

Edit: The file cluster-jboss-beans.xml should be hapartition-jboss-beans.xml

Page 342, last paragraph

Edit: The file cluster-jboss-beans.xml should be hapartition-jboss-beans.xml

Page 342, First paragraph after the second code snippet, last sentence

Edit: Should change to "All the services found in this file are configured to use the UDP protocol stack out of the box.

Reason: The JBoss Messaging Post Office service is not defined in this file and does not use the UDP protocol stack.

Page 343, second sentence in paragraph after warning

Edit: DefaultParition should be DefaultPartition

Page 343, Configuring the protocol stack, next to last setence on page

Edit: Append ", except for the JBoss Messaging Post Office service, which uses the jbm-data stack."

Page 344, Third paragraph (on when to use TCP vs. UDP), second sentence

Edit: Remove the claim that TCP is more reliable than UDP. Sentence should start "TCP is supported by most machines..."

Reason: We said that TCP is generally more reliable than UDP, which is true in general, but with JGroups UDP has NAKACK and UNICAST protocols which make it just as reliable as TCP.

Page 347, Table 12.5, HA Partition Cache

Edit: Configuration file should change to deploy/cluster/hapartition-jboss-beans.xml

Page 351, next to last paragraph

Edit: First and second sentence should capitalize Cache when referring to JBoss Cache.

Page 357, second paragraph

Edit: The file should be: server/all/deploy/cluster/jboss-cache-manager.sar/META-INF/jboss-cache-manager-jboss-beans.xml

Page 357, third paragraph

Edit: "CacheMode" should be "cacheMode" and "SyncReplTimeout" should be "syncReplTimeout"

Page 357, third paragraph, last sentence

Edit: Should read: "The cache buddy replication is disabled, but if you enable it, note that it is configured to replicate with only a single node. This should be fine for most uses, but can be increased if necessary."

Chapter 13

Page 367, first paragraph, last sentence

Edit: Should read "The options supported by Hibernate are shown in table 13.6"

Reason: Hibernate enables these strategies, not JBoss Cache.

Page 368, Next to last paragraph, last sentence

Edit: Remove "The searching stops as soon as a successful lookup has occurred, so" and capitalize the word "the" that follows.

Reason: This feature is not available in JBoss AS 5.0, but is scheduled to be available in JBoss AS 5.1 CR1. Currently, it will look through every node before returning a response. See: https://jira.jboss.org/jira/browse/JBAS-5703

Page 369, Enabling HA-JNDI, First paragraph

Edit: The file server/all/deploy/cluster/cluster-jboss-beans.xml should be server/all/deploy/cluster/hapartition-jboss-beans.xml

Page 369, Table 13.7, bindAddress

Edit: Replace "Leaving it blank (the default)" with "Not specifying the -b option"

Page 370, Auto Discovering Nodes, first paragraph

Edit: Take the word "JGroups'" out of the sentence.

Reason: HA-JNDI uses multicasting, but it is not built on JGroups.

Page 370, last sentence

Edit: Add the following to the sentence ", and is not recommended in environments where clients and servers are separated by firewalls."

Chapter 14

Pages 385 and 387, sections 14.5 and 14.5.1

JBoss AS 5.1.0: On Windows, the JAVA_OPTS are now set inside the bin/run.conf.bat file.

Page 386, table 14.2

For MaxPermSize, note that run.bat and run.conf set this to 256MB, which should be sufficient for most purposes. The JDK default, usually 64MB, is not sufficient for running an application server.

Page 388, Understanding the Collector Types

Last sentence of first paragraph is incorrect - there is a new argument, available since JDK 1.5.0_06, that you can use to run a parallel collector for a major collection: -XX:+UseParallelOldGC.

Page 389, the CMS collector

We recommend that you use the CMS collector in a clustering environment to prevent the false failure detection that can occur with JGroups if a major collection takes too long.

Pages 397-398, section 14.5.6

Looks like the JVM options were automatically capitalized when the book was typeset. The proper names are:

Page 400, section 14.6.2, first paragraph

The server.xml file is located at server/xxx/deploy/jbossweb.sar.

Page 401, table 14.9

The latest versions of JBoss Web Server ignores the maxSpareThreads option. Instead, you must define an executor, as described at http://tomcat.apache.org/tomcat-6.0-doc/config/executor.html. For example, the following executor will reduce the thread count to 50 threads if the system is using 50 threads or less for 60 second:

<Executor name="executor1" namePrefix="EXEC-http-"
  maxThreads="200" minSpareThreads="50" maxIdleTime="60000" />

Then reference this executor in the HTTP connector:

<Connector protocol="HTTP/1.1" executor="executor1" ... />

Thanks to sra78 in the JBoss forums for pointing this out.

Page 405, table 14.12

The CompilerThread1 thread is used by the just-in-time (JIT) compiler to compile Java bytecode into machine-specific opcodes - it is not used to compile JSPs.

Page 407, section 14.9

The URL http://java.sun.com/developer/technicalArticles/J2SE/jconsole.html appears correctly in the text, but in the ebook PDF file the URL used is all lower case which results in a 404 - Page Not Found error.

Chapter 15

Page 415, section 15.2.2, second paragraph

The bindings.xml file is now located at server/xxx/conf/bootstrap (see B.1.5).

JBoss AS 5.1.0: The file server/xxx/conf/bindingservice.beans/META-INF/bindings-jboss-beans.xml contains the port assignments that were in the server/xxx/conf/bootstrap/bindings.xml file in 5.0.0 and 5.0.1. The process for defining or using port assignments remains the same.

The binding service configuration file underwent various changes just before GA, and while the text in section 15.2.2 still applies in general, some of the specifics have changed:

The JNDI port is defined by the jboss:service=Naming Mbean declared in server/xxx/conf/service.xml, not by the RemoteNamingBean defined in server/xxx/deploy/naming-jboss-beans.xml file. (NOTE: Between 5.0.0.CR2 and GA there was a failed attempt to replace the MBeans in jboss-service.xml with a series of service-specific *-jboss-beans.xml POJO configuration files, and the naming-jboss-beans.xml file was one of those files. However, a series of regressions caused the code to be reverted back to using jboss-service.xml, but not within time to revert this section of the book back to the original text.)

Page 423, table 15.3

For service Monitoring Service, the file server/xxx/lib/Jboss-monitoring.jar should be server/xxx/lib/jboss-monitoring.jar

Page 426, table 15.4

The configuration file for the Timer Service for EJB 2.x is server/xxx/deploy/ejb2-timer-service.xml.

Pages 426-427, section 15.5.1

The ejb3-timer-service.xml file was dropped in the JBoss AS 5.0.1.GA release therefore if you are using that version the steps outlined in this section are not required to change the DefaultDS data source.

Page 428, section 15.6.1, second paragraph

Replace "_JAVA_LOADER_DEBUG" with "_JAVA_LAUNCHER_DEBUG".

Staring with JBoss AS 5.0.0 the service.bat and the jbosssvc.exe file which are used to run the application server as a Windows service ship with the application server. However, the jbosssvc.exe file in both 5.0.0 and 5.0.1 is corrupted and thus does not work, so you still need to obtain the file from JBoss Native. However, the jbossvc.exe file in 5.1.0 is not corrupt and thus can be used to run the application server as a Windows service.

Appendix A

Appendix B

Page 443, section B.1.1

The name of the WAR file for Embedded Jopr changed again with the 1.1 release, but fortunately there is a jboss-web.xml and it declares a context of /admin-console. Therefore, the URLs we provide are now correct! :-)

JBoss AS 5.1.0: Embedded Jopr now comes with JBoss AS and does not have to be installed separately. It appears at server/xxx/deploy/admin-console.war.

Section B.1.2 through B.1.7

These sections are at the wrong level and should be B.2 through B.7.

Page 448, section B.1.2

JBoss AS 5.1.0: On Windows, the JAVA_OPTS are now set inside the bin/run.conf.bat file..

Page 449, section B.1.4

The is yet another configuration that showed up with GA: standard. This configuration is the one that passed the Java EE 5 JCK. You can read more about this configuration in the readme.html file.

Page 450, second paragraph

As noted earlier, the tables in chapter 3 are mis-numbered. Thus the reference to table 3.3 means the table on pages 53 and 54, which is incorrectly numbered 3.2 in the book.

Page 451, section B.1.6

JBoss AS 5.1.0: The default log level is INFO. See the discussion on page 34, above, for more details.