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. 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.... ". Page 7, Table 1.1 Edit: "Red Hat Developer Studio" should be "JBoss Developer Studio" Page 12, First paragraph after note. EJB3 Plugin. JBoss EJB3 Plugin The EJB3 Plugin is an executable JAR which will patch an existing AS installation with the latest EJB3 binaries (and dependent projects). The plugin is targeted only against the latest released JBoss AS 5.x. So if the latest released JBoss AS version is 5.0.1.GA, then the plugin will be compatible against this AS version only.
The intention of the plugin and the twice-a-month release process of JBoss EJB3 team is to provide the JBoss EJB3 community with the latest and greatest implementation. Prerequisites Ant (1.6.5) - The installer internally uses Ant, so you must have Ant installed on your system where the plugin will be used. Downloading the Plugin The latest version of the EJB3 Plugin can be downloaded from here Running the Plugin Using the plugin is simple: shell $> java -jar jboss-ejb3-plugin-x.x.x.jar $JBOSS_HOME Note: The JBOSS_HOME points to the JBoss AS installation, targeted by the plugin version. EncryptingDataSourcePasswords - JBoss Community. A simple login module for encrypting a datasource password The org.jboss.resource.security.SecureIdentityLoginModule can be used to encrypt database passwords rather than using clear text passwords in the datasource configuration.
It uses a hard-coded password to encrypt/decrypt the datasource password. You can encrypt the datasource password using the SecureIdentityLoginModule main method by passing in the cleartext password, here shown as 'password': Note: The example below was recently (21 June 2007) verified against JBoss AS 3.2.8.SP1, 4.0.0, 4.0.1sp1, 4.0.2, 4.0.3SP1, 4.0.4.GA, 4.0.5.GA, and 4.2.0.GA, using PostgreSQL 8.1.9-1, Sun JDK 1.5.0_11, and Fedora Core 6 (2.6.20-1.2952.fc6). Second note: The JBoss 5.1 examples have been verified against JBoss AS 5.1.0 GA the 17 November 2009. JBoss AS 3.2.x From your JBoss 3.2.4 (or newer) home directory, invoke the secure identity login module like such: On Windows Operating System, use the following command JBoss AS 4.0.x or 4.2.x JBoss AS 5.1.x.
Transaction Timeouts and EJB3/JPA. I recently discovered somewhat odd behavior in the way transactions are timed out in my EJB3/JPA app. It was surprising to me how it worked, and though I guess it makes sense when thinking about it, something here still doesn't "feel right". Consider an EJB3/JPA application deployed in JBossAS 4.2 that uses the Arjuna's Transaction Manager (aka JBossTM - although I still call it Arjuna :) and Hibernate as the JPA implementation. Annotating an EJB3 stateless session bean (SLSB) method, is this: @org.jboss.annotation.ejb.TransactionTimeout(60) If my method takes longer than 60 seconds, the transaction it is running in will timeout, and thus rollback.
But, what happens if my method is executing a very long running SQL update? That is close to what happens, but not exactly. It turns out, the transaction manager detects that the transaction has timed out and aborts it from within an asynchronous thread (different from the thread running my method), but it never sends an interrupt to my method. Chapter 6. Messaging on JBoss. Chapter 6. Messaging on JBoss JMS Configuration and Architecture The JMS API stands for Java Message Service Application Programming Interface, and it is used by applications to send asynchronous business-quality messages to other applications. In the messaging world, messages are not sent directly to other applications. Instead, messages are sent to destinations, known as queues or topics.
Applications sending messages do not need to worry if the receiving applications are up and running, and conversely, receiving applications do not need to worry about the sending application's status. Both senders, and receivers only interact with the destinations. The JMS API is the standardized interface to a JMS provider, sometimes called a Message Oriented Middleware (MOM) system. This chapter focuses on the JBoss specific aspects of using JMS and message driven beans as well as the JBoss Messaging configuration and MBeans. 6.1.1. Let's start out with a point-to-point (P2P) example.
Example 6.1. <? HornetQ General FAQs - JBoss Community. What is HornetQ? HornetQ is an open source project to build a multi-protocol, embeddable, very high performance, clustered, asynchronous messaging system. HornetQ is designed with usability in mind. HornetQ is an example of Message Oriented Middleware (MoM) For a description of MoMs and other messaging concepts please see the chapter 2 of the user manual "Messaging Concepts". HornetQ takes over from JBoss Messaging as our premier JMS implementation. Why a Hornet? Hornets are fast, angry and have attitude, with a sting in their tail. You don't mess with the hornet. Also they make great logos.
What's the relation between JBoss Messaging and HornetQ? During most of its development the HornetQ code-base was known as JBoss Messaging 2.0. We decided to rename it and spin it off as an independent project since it differs in a great many ways from JBoss Messaging 1.x and we did not want to confuse JBoss Messaging 1.x with JBoss Messaging 2.x. Can I get support for HornetQ? Why did HornetQ start at 2.0.0? The HornetQ Team Blog. HornetQ Quickstart Guide. The JMS Examples all follow the same format. Each examples is contained in its own directory which contains the following. build.xmlThis is the ant build file used to run the examplesrc directoryThis contains the source code for the exampleserver0 configuration directoryThis contains the configuration files needed to run the server for the example.
There may be multiple configuration directories server0, server1 etc for clustered examples etc. Each example will start one or more stand-alone servers and stop them after the example has completed. As a quick start we'll run the queue example. Firstly open a Shell or a Command prompt and navigate to the examples/jms/queue directory. Type the command . Congratulations! 7.2. The Java EE Examples are examples that require a JEE application server to run. We'll use the MDB example for the purposes of this guide. Like the other Java EE examples the MDB example is a JEE Application which first needs deploying in the JBoss Application Server. . . . Chapter 3. Naming on JBoss. This chapter discusses the JBoss JNDI based naming service and the role of JNDI in JBoss and J2EE.
An introduction to the basic JNDI API and common usage conventions will also be discussed. The JBoss specific configuration of J2EE component naming environments defined by the standard deployment descriptors will also be addressed. The final topic is the configuration and architecture of the JBoss naming service. The JBoss naming service is an plays a key role in J2EE because it provides a naming service that allows a user to map a name onto an object. This is a fundamental need in any programming environment because developers and administrators want to be able to refer to objects and services by recognizable names. JNDI is a standard Java API that is bundled with JDK1.3 and higher. The SPI layer is an abstraction that naming service providers must implement to enable the core JNDI classes to expose the naming service using the common JNDI client interface. 3.1.1.2.1.
Example 3.1. <! <! Chapter 1. Session EJB and MDB Configuration. Index of /j2ee. 5.x Tuning/Slimming - JBoss Community. The following slimming recommendations are for a standard JBoss AS 5.1.0 GA (Community) "All" configuration and can be used for Jboss EAP 5.1.0 (Enterprise). Slimming is very application specific, so this is by no means a universal document. If you have documented the process for slimming other services for JBoss 5.x please add to them here. Slimming Remove EJB3 services In server/<node>/deploy/ remove: ejb3-connectors-jboss-beans.xmlejb3-container-jboss-beans.xmlejb3-interceptors-aop.xmlejb3-timerservice-jboss-beans.xmlprofile-service-secured.jar --> Note : this folder is not in Jboss EAP 5.1.0 In server/<node>/deployers/ remove jboss-ejb3-endpoint-deployer.jarejb3-deployers-jboss-beans.xml --> Note : this file is in Jboss EAP 5.1.0 but not Jboss AS 5.1.0 WARNING : Do not remove deployers/ejb3.deployer/jboss-ejb3-deployer.jar and deployers/ejb3.deployer/META-INF/ejb3-deployers-jboss-beans.xml, they are used to support annotations for EJB client.
Remove EJB2 services Remove JUDDI juddi-service.sar. AS 5 FAQ - JBoss Community. Chapter 5. XML Bindings. In the last sections you saw how to code aspects and how pointcut expressions are formed. This chapter puts it all together. There are two forms of bindings for advices, mixins, and introductions. One is XML which will be the focus of this chapter. The Annotated Bindings chapter discusses how you can replace XML with annotations. JBoss AOP resolves pointcut and advice bindings at runtime. 5.2.1. When you are running JBoss AOP outside of the application server there are a few ways that the JBoss AOP framework can resolve XML files. jboss.aop.path This is a system property that is a ';' (Windows) or ':' (Unix) delimited list of XML files and/or directories. 5.2.2. On the other hand, when you are running JBoss AOP integrated with the application server, XML files can be deployed in two different ways.
Note that in JBoss 5, you MUST specify the schema used, otherwise your information will not be parsed correctly. The xml schema can be found in the distribution's etc/literal> folder. 5.4.3.2. EJB 3.0. JBoss provides a few extensions to the EJB 3.0 spec. This chapter describes those features here. An extension offered by JBoss EJB 3.0 is the notion of a @org.jboss.annotation.ejb.Service annotated bean. They are singleton beans and are not pooled, so only one instance of the bean exists in the server.
They can have both @Remote and @Local interfaces so they can be accessed by java clients. When different clients look up the interfaces for @Service beans, all clients will work on the same instance of the bean on the server. When installing the bean it gets given a JMX ObjectName in the MBean server it runs on. The default is jboss.j2ee:service=EJB3,name=<Fully qualified name of @Service bean>,type=service You can override this default ObjectName by specifying the objectName attribute of the @Service annotation. 5.1.1. In addition to supporting @Local and @Remote interfaces, a @Service bean can also implement an interface annotated with @Management . 5.1.2.
Lifecycle Methods. 5.1.2.1.
JBoss Tutorial - HermesJMS - Confluence. JBoss Enterprise Application Platform.