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.
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...."
Edit: "Red Hat Developer Studio" should be "JBoss Developer Studio"
Reason: This was renamed for marketing reasons.
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."
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.
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.
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."
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.
JBoss AS 5.1.0: File jbossjta-properties.xml has been renamed jbossts-properties.xml.
The file standardjboss.xml is specific to EJB 2.x.
The remoting service is now governed using POJOs defined in the file server/xxx/deploy/remoting-jboss-beans.xml.
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."
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.
You can view the system properties that were set by looking at the server/xxx/log/boot.log file.
For suffix .zip, the URL in the Application Type column should be http://localhost:8080/someapp.zip.
Table 3.1 should be numbered 3.2.
Table 3.2 should be numbered 3.3.
Changes to this section, and table 3.3, are covered in B.1.5.
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.
Table 3.3 should be numbered 3.4.
Table 3.4 should be numbered 3.5.
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."
Table 3.5 should be numbered 3.6.
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."
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.
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.
Edit: The description for replication-config should start "Specifies when and how to replicate ..."
Edit: A slash was left off, should read: "The server/xxx/deployers/jbossweb.deployer directory..."
Edit: Directory should be "deploy/jbossweb.sar/server.xml"
Edit: Directory should be "deployers/jbossweb.depoloyer/web.xml"
Edit: "web-resource-collection" should be "auth-constraint"
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>
Edit: Should say "... configuration of individual *EJB* applications and configuration of..."
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."
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.
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."
Edit: add the following to the end of the description "..., and default EJB pool sizes."
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.
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:
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.
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.
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.
Edit: Because there is only a single instance, the code for the service must be written to be thread-safe.
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.
Edit: The word nonlocal should be non-local
The example-destinations-service.xml file that contains the destinations used by the example can be found in the docs/examples/jms directory.
This paragraph relates to EJB 2.x MDBs only.
The correct location for the example *-ds.xml file is docs/examples/jca/postgres-ds.xml
The listing heading should read: messaging-jboss-beans.xml (expert)
The JAX-RPC documentation is now at http://jbossws.jboss.org/mediawiki/index.php?title=JAX-RPC_User_Guide
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.
As noted earlier, the standard-jaxws-endpoint-config.xml file can now be found at server/xxx/deployers/jbossws.deployer/META-INF.
As noted earlier, the standard-jaxws-client-config.xml file can now be found at server/xxx/deployers/jbossws.deployer/META-INF.
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.
For Portal 2.7.0, the overview.xhtml file is located at jboss-portal.sar/portal-identity.sar/portal-identity.war/jsf/register.
Edit: Remove everything after the words SFSB state.
Reason: Buddy replication is not enabled for HTTP-session replication in the GA release.
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.
Edit: Strike the last sentence about the JBoss farming service.
Reason: This service is no longer available in JBoss AS 5.
Edit: The table should read as follows:
| Node 1 console output | Node 2 console output |
| INFO [STDOUT] 0 | INFO [STDOUT] 1 |
| INFO [STDOUT] 2 | INFO [STDOUT] 3 |
| INFO [STDOUT] 4 | INFO [STDOUT] 5 |
| INFO [STDOUT] 6 | INFO [STDOUT] 7 |
| INFO [STDOUT] 8 | INFO [STDOUT] 9 |
| INFO [STDOUT] 10 | ... |
Reason: The default load-balancing strategy is round-robin, but the table was showing random-robin load balancing.
Edit: The file server/all/deploy/cluster/cluster-jboss-beans.xml should be server/all/deploy/cluster/hapartition-jboss-beans.xml
Edit: The file cluster-jboss-beans.xml should be hapartition-jboss-beans.xml
Edit: The file cluster-jboss-beans.xml should be hapartition-jboss-beans.xml
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.
Edit: DefaultParition should be DefaultPartition
Edit: Append ", except for the JBoss Messaging Post Office service, which uses the jbm-data stack."
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.
Edit: Configuration file should change to deploy/cluster/hapartition-jboss-beans.xml
Edit: First and second sentence should capitalize Cache when referring to JBoss Cache.
Edit: The file should be: server/all/deploy/cluster/jboss-cache-manager.sar/META-INF/jboss-cache-manager-jboss-beans.xml
Edit: "CacheMode" should be "cacheMode" and "SyncReplTimeout" should be "syncReplTimeout"
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."
Edit: Should read "The options supported by Hibernate are shown in table 13.6"
Reason: Hibernate enables these strategies, not JBoss Cache.
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
Edit: The file server/all/deploy/cluster/cluster-jboss-beans.xml should be server/all/deploy/cluster/hapartition-jboss-beans.xml
Edit: Replace "Leaving it blank (the default)" with "Not specifying the -b option"
Edit: Take the word "JGroups'" out of the sentence.
Reason: HA-JNDI uses multicasting, but it is not built on JGroups.
Edit: Add the following to the sentence ", and is not recommended in environments where clients and servers are separated by firewalls."
JBoss AS 5.1.0: On Windows, the JAVA_OPTS are now set inside the bin/run.conf.bat file.
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.
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.
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.
Looks like the JVM options were automatically capitalized when the book was typeset. The proper names are:
The server.xml file is located at server/xxx/deploy/jbossweb.sar.
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.
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.
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.
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.)
For service Monitoring Service, the file server/xxx/lib/Jboss-monitoring.jar should be server/xxx/lib/jboss-monitoring.jar
The configuration file for the Timer Service for EJB 2.x is server/xxx/deploy/ejb2-timer-service.xml.
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.
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.
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.
These sections are at the wrong level and should be B.2 through B.7.
JBoss AS 5.1.0: On Windows, the JAVA_OPTS are now set inside the bin/run.conf.bat file..
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.
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.
JBoss AS 5.1.0: The default log level is INFO. See the discussion on page 34, above, for more details.