📄 ch08s20.html
字号:
<method-name>*</method-name>
</method>
<trans-attribute>Required</trans-attribute>
</container-transaction>
</assembly-descriptor>
</ejb-jar>
</pre><p>And here it is the <tt>jboss.xml</tt> descriptor specific to JBoss:</p><pre class="programlisting">
<?xml version="1.0" encoding="Cp1252"?>
<jboss>
<resource-managers>
<resource-manager>
<res-name>xmlBlaster</res-name>
<res-jndi-name>java:/XmlBlasterDS</res-jndi-name>
</resource-manager>
</resource-managers>
<enterprise-beans>
<message-driven>
<ejb-name>JmsAdapter</ejb-name>
<configuration-name>Standrad Message Driven Bean</configuration-name>
<destination-jndi-name>topic/testTopic</destination-jndi-name>
<resource-ref>
<res-ref-name>xmlBlaster</res-ref-name>
<resource-name>xmlBlaster</resource-name>
</resource-ref>
</message-driven>
<secure>false</secure>
</enterprise-beans>
</jboss>
</pre></div></div><div class="section"><a name="mdb.config.advanced"></a><div class="titlepage"><div><h3 class="title"><a name="mdb.config.advanced"></a>Advanced MDB configuration</h3></div></div><p>The implementation of MDB support in JBoss has been written in such a way that a user should not need to know a lot about the internals of JBoss to use MDBs. Apart from the few necessary lines in <tt>jboss.xml</tt>, just standard knowledge about Message Driven Beans should suffice.</p><p>Following the design of other parts of JBoss, the MDB implementation is also extremely configurable, if one wants to tune or totally change the default configuration and implementation! Here, there follow some short notes on how to configure MDBs in JBoss.</p><div class="section"><a name="jms-mdb-config-deploy"></a><div class="titlepage"><div><h4 class="title"><a name="jms-mdb-config-deploy"></a>EJB deployment descriptor</h4></div></div><p>All MDBs are quite configurable. Here there are the basic choices that can be made:</p><div class="itemizedlist"><ul><li><p><a name="d0e5173"></a>A bean may be either a <tt>javax.jms.Topic</tt> or a <tt>javax.jms.Queue</tt> bean; this is specified in the <tt>destination-type</tt> element. <span class="emphasis"><i>Up to 2.4.0, this part of JBoss is not standard-compliant. The <tt>message-driven-destination</tt> element is actually an optional element in the EJB 2.0 DTD of the <tt>ejb-jar.xml</tt>, but in JBoss it is required because there is no other way for JBoss to know to which type of JMS destination the bean should be bound.</i></span>. In [<span class="bold"><b>2.4.1</b></span>] this has been solved, and the element is now optional. If no message-driven-destination is given, JBoss will try to deduce one from the given destination in <tt>jboss.xml</tt>. If this is not possible it will default to a topic type.</p><pre class="programlisting">
<message-driven-destination>
<destination-type>javax.jms.Queue</destination-type>
<subscription-durability>NonDurable</subscription-durability>
</message-driven-destination>
</pre></li><li><p><a name="d0e5202"></a>If a bean is a Topic it may be either non-durable or durable, as specified in the <tt>subscription-durability</tt> element.</p><pre class="programlisting">
<message-driven-destination>
<destination-type>javax.jms.Topic</destination-type>
<subscription-durability>Durable</subscription-durability>
</message-driven-destination>
</pre></li><li><p><a name="d0e5210"></a>A bean may be have transactions managed by either the bean or the container, as specified in the <tt>transaction-type</tt> element.</p><pre class="programlisting">
<transaction-type>Container</transaction-type>
</pre></li><li><p><a name="d0e5218"></a>A bean with bean-managed transactions may have an acknowledgement type of either <tt>Auto-acknowledge</tt> or <tt>Dups-ok-acknowledge</tt>. This is currently not supported in JBoss since the container is always receiving messages under a transaction, but it is specified in the <tt>acknowledge-mode</tt> element.</p><pre class="programlisting">
<transaction-type>Bean</transaction-type>
<acknowledge-mode>Auto-acknowledge</acknowledge-mode>
</pre></li><li><p><a name="d0e5232"></a>A bean with container-managed transactions may either specify that requires transactions or that it does not support them, as specified in the <tt>trans-attribute</tt> element.</p><pre class="programlisting">
<assembly-descriptor>
<container-transaction>
<method>
<ejb-name>HelloTopicDurableMDB</ejb-name>
<method-name>*</method-name>
</method>
<trans-attribute>Required</trans-attribute>
</container-transaction>
</assembly-descriptor>
</pre></li><li><p><a name="d0e5240"></a>An MDB may also use a selector which follows the JMS selector syntax, as specified in the <tt>message-selector</tt> element.</p><pre class="programlisting">
<message-selector>JMSType='activityCompletion'</message-selector>
</pre></li></ul></div><p>Of course, inside a <tt>message-driven</tt> stanza one may also specify other elements typical of an EJB deployment descriptor, such as <tt>ejb-ref</tt> and <tt>resource-ref</tt> elements.</p></div><div class="section"><a name="jms-mdb-config-jboss"></a><div class="titlepage"><div><h4 class="title"><a name="jms-mdb-config-jboss"></a>JBoss deployment descriptor</h4></div></div><p>The meat of the MDB configuration options is in the <tt>jboss.xml</tt> deployment descriptor.</p><p>[<span class="bold"><b>2.4.0</b></span>. This file is optional starting with this version of JBoss. In such a case, a destination to which to bind the bean is not specified and JBoss will create a destination for the bean, with the name of the bean. This might be handy, but it is also dangerous since misspelled destinations may get you way wrong; and you will also have to tie the clients to a destination that is only temporarily available, as the destination will be destroyed if the MDB bean is undeployed or redeployed.]</p><p>The configuration in this file may be divided in two parts: The mandatory one to configure a particular bean and the optional one to configure the container, which will default to the contents in <tt>standardjboss.xml</tt>. We will describe both here, but the container configuration will be broken into several parts since it involves stuff outside the <tt>jboss.xml</tt> file.</p><p>In the bean part one always has to specify the JNDI for the JMS destination. In JBossMQ this is always composed of either the prefix <tt>topic/</tt> or the prefix <tt>queue/</tt> followed by the name of the destination.</p><div class="figure"><p><a name="d0e5289"></a><b>Figure 8.64. Defining a destination in <tt>jboss.xml</tt></b></p><pre class="programlisting">
<destination-jndi-name>topic/testTopic</destination-jndi-name>
</pre></div><p>You also have to specify the bean name and the name of the container configuration. To use the one in <tt>standardjboss.xml</tt>, provide the name <tt>Standard Message Driven Bean</tt>.</p><div class="figure"><p><a name="d0e5304"></a><b>Figure 8.65. Example <tt>jboss.xml</tt> for MDB</b></p><pre class="programlisting">
<message-driven>
<ejb-name>HelloTopicMDB</ejb-name>
<configuration-name>Standard Message Driven Bean</configuration-name>
<destination-jndi-name>topic/testTopic</destination-jndi-name>
</message-driven>
</pre></div><p>It is also possible to use a user name and a password (configurable in <tt>conf/default/jbossmq.xml</tt>) to log in to JBossMQ. If you have specified a <tt>Durable</tt> topic, they are required along with the subscription Id that identifies the durable subsripition that will be used. Using one of the pre-defined values in <tt>jbossmq.xml</tt> we could have a deployment descriptor looking like this:</p><div class="figure"><p><a name="d0e5323"></a><b>Figure 8.66. Example <tt>jboss.xml</tt> for MDB with durable subscription</b></p><pre class="programlisting">
<message-driven>
<ejb-name>HelloTopicDurableMDB</ejb-name>
<configuration-name>Standard Message Driven Bean</configuration-name>
<destination-jndi-name>topic/testTopic</destination-jndi-name>
<mdb-user>john</mdb-user>
<mdb-passwd>needle</mdb-passwd>
<mdb-subscriber-id>DurableSubscriberExample</mdb-subscriber-id>
</message-driven>
</pre></div><p>The standard container configuration for MDB is in <tt>standardjboss.xml</tt>. It is possible, however, to override this configuration by specifying other values in the <tt>jboss.xml</tt> deployment descriptor. We will first see the complete set before going through the individual entries.</p><div class="figure"><p><a name="d0e5339"></a><b>Figure 8.67. Container configuration for MDB, from <tt>HelloMDB-Topic-FullConf-jboss.xml</tt> in directory <tt>org/jboss/docs/jms/resources</tt></b></p><pre class="programlisting">
<?xml version="1.0"?>
<jboss>
<enterprise-beans>
<message-driven>
<ejb-name>HelloTopicMDB</ejb-name>
<configuration-name>My Message Driven Config</configuration-name>
<destination-jndi-name>topic/testTopic</destination-jndi-name>
</message-driven>
</enterprise-beans>
<container-configurations>
<container-configuration>
<container-name>My Message Driven Config</container-name>
<call-logging>false</call-logging>
<container-invoker>org.jboss.ejb.plugins.jms.JMSContainerInvoker</container-invoker>
<container-interceptors>
<interceptor>org.jboss.ejb.plugins.LogInterceptor</interceptor>
<interceptor>org.jboss.ejb.plugins.SecurityInterceptor</interceptor>
<!-- CMT -->
<interceptor transaction="Container">org.jboss.ejb.plugins.TxInterceptorCMT</interceptor>
<interceptor transaction="Container" metricsEnabled="true">org.jboss.ejb.plugins.MetricsInterceptor</interceptor>
<interceptor transaction="Container">org.jboss.ejb.plugins.MessageDrivenInstanceInterceptor</interceptor>
<!-- BMT -->
<interceptor transaction="Bean">org.jboss.ejb.plugins.MessageDrivenInstanceInterceptor</interceptor>
<interceptor transaction="Bean">org.jboss.ejb.plugins.MessageDrivenTxInterceptorBMT</interceptor>
<interceptor transaction="Bean" metricsEnabled="true">org.jboss.ejb.plugins.MetricsInterceptor</interceptor>
</container-interceptors>
<instance-pool>org.jboss.ejb.plugins.MessageDrivenInstancePool</instance-pool>
<instance-cache></instance-cache>
<persistence-manager></persistence-manager>
<transaction-manager>org.jboss.tm.TxManager</transaction-manager>
<container-invoker-conf>
<JMSProviderAdapterJNDI>DefaultJMSProvider</JMSProviderAdapterJNDI>
<ServerSessionPoolFactoryJNDI>StdJMSPool</ServerSessionPoolFactoryJNDI>
<MaximumSize>15</MaximumSize>
<MaxMessages>1</MaxMessages>
<Optimized>True</Optimized>
</container-invoker-conf>
<container-pool-conf>
<MaximumSize>100</MaximumSize>
<MinimumSize>10</MinimumSize>
</container-pool-conf>
</container-configuration>
</container-configurations>
</jboss>
</pre></div><p>Let's go through some of the configurable attributes of the MDB container</p><div class="section"><a name="d0e5351"></a><div class="titlepage"><div><h5 class="title"><a name="d0e5351"></a>Container invoker</h5></div></div><p>The container invoker is what sends messages into the container system. It is responsible for handling everything that has to do with JMS. The rest of the MDB container parts are basically agnostic regarding what kind of message system the container invoker uses. It is therefore possible to write a new container invoker for other types of message systems. There is currently one limitation to this. The bean class still has to implement the MessageListener interface and the invoker therefore has to adopt this interface. This will be made pluggable in a later release of MDB.</p></div><div class="section"><a name="d0e5356"></a><div class="titlepage"><div><h5 class="title"><a name="d0e5356"></a>Container interceptors</h5></div></div><p>The container interceptors are an integral part of the container system and each of them does some particular thing needed to fulfill the EJB container contract. All of them are pluggable, meaning that it is possible to write new implementations of them and plug them in for a bean with a particular need, even though this should be considered a very advanced task.</p></div><div class="section"><a name="d0e5361"></a><div class="titlepage"><div><h5 class="title"><a name="d0e5361"></a>Container invoker configuration</h5></div></div><p>This is probably the most interesting part to understand. Lets look at it in smaller pieces. First it defines a <tt>JMSProviderAdapterJNDI</tt>:</p><div class="figure"><p><a name="d0e5369"></a><b>Figure 8.68. Configuring the <tt>JMSProviderAdapterJNDI</tt> in <tt>jboss.xml</tt></b></p><pre class="programlisting">
<JMSProviderAdapterJNDI>DefaultJMSProvider</JMSProviderAdapterJNDI>
</pre></div><p>It should contain a JNDI name for a JMX bean where one might lookup a provider adapter class. This class is then used by the invoker to find the names of the connection factories; all IntitialContext lookups are done through this class, to make it possible to get access to a JMS provider outside of JBoss.</p><p>The name used by default is bound to the JbossMQProvider in <tt>jboss.jcml</tt>, which looks like this:
</p><div class="figure"><p><a name="d0e5386"></a><b>Figure 8.69. Defining a JMSProviderAdapter in <tt>jboss.jcml</tt></b></p><pre class="programlisting">
<mbean code="org.jboss.jms.jndi.JMSProviderLoader"
name=":service=JMSProviderLoader,name=JBossMQProvider">
<attribute name="ProviderName">DefaultJMSProvider</attribute>
<attribute name="ProviderAdapterClass">org.jboss.jms.jndi.JBossMQProvider</attribute>
</mbean>
</pre></div><p>[<span class="bold"><b>2.4.0</b></span>. It has some additional information in this version.]</p><div class="figure"><p><a name="d0e5398"></a><b>Figure 8.70. [<span class="bold">2.4.0</span>] Defining a JMSProviderAdapter in <tt>jboss.jcml</tt></b></p><pre class="programlisting">
<mbean code="org.jboss.jms.jndi.JMSProviderLoader"
name=":service=JMSProviderLoader,name=JBossMQProvider">
<attribute name="ProviderName">DefaultJMSProvider</attribute>
<attribute name="ProviderAdapterClass">org.jboss.jms.jndi.JBossMQProvider</attribute>
<attribute name="QueueFactoryRef">java:/INVMXAQueueConnectionFactory</attribute>
<attribute name="TopicFactoryRef">java:/INVMXATopicConnectionFactory</attribute>
</mbean>
</pre></div><p>[<span class="bold"><b>2.4.1</b></span>. The JNDI strings have changed in this version.]</p><div class="figure"><p><a name="d0e5413"></a><b>Figure 8.71. [<span class="bold">2.4.1</span>] Defining a JMSProviderAdapter in <tt>jboss.jcml</tt></b></p><pre class="programlisting">
<mbean code="org.jboss.jms.jndi.JMSProviderLoader"
name=":service=JMSProviderLoader,name=JBossMQProvider">
<attribute name="ProviderName">DefaultJMSProvider</attribute>
<attribute name="ProviderAdapterClass">org.jboss.jms.jndi.JBossMQProvider</attribute>
<attribute name="QueueFactoryRef">java:/INVMXAConnectionFactory</attribute>
<attribute name="TopicFactoryRef">java:/INVMXAConnectionFactory</attribute>
</mbean>
</pre></div><p>It is possible, also, to add more JMSProviders to the <tt>jboss.jcml</tt> and use them in the container configuration. One possible reason to do this is to listen to a queue or topic in another JBoss server. In that case, one could define another provider and configure its context. This is done by adding the attribute <tt>ProviderUrl</tt> to the JMSProviderLoader MBean configuration. Let's assume that we have a JBoss server on another machine <tt>remote.com</tt>. We might then add this to <tt>jboss.jcml</tt>:</p><div class="figure"><p><a name="d0e5437"></a><b>Figure 8.72. Defining a remote JMSProviderAdapter in <tt>jboss.jcml</tt></b></p><pre class="programlisting">
<attribute name="ProviderUrl">remote.com:1099</attribute>
</pre></div><p>Once we added a <tt>ProviderUrl</tt> attribute, we would write in <tt>jboss.xml</tt> the following <tt>JMSProviderAdapterJNDI</tt> element:</p><div class="figure"><p><a name="d0e5455"></a><b>Figure 8.73. Configuring a remote JMSProviderAdapter in <tt>jboss.xml</tt></b></p><pre class="programlisting">
<JMSProviderAdapterJNDI>RemoteJMSProvider</JMSProviderAdapterJNDI>
</pre></div><p>Yet another way to use this configuration option is to integrate another JMS provider into JBoss. This was actually how MDB was first implemented in JBoss through the OpenJMS implementation. To do this, one has to implement the interface <tt>org.jboss.jms.jndi.JMSProviderAdapter</tt>. Be aware, though, of the fact that if the JMS provider does not support the full JMS Application Service Facility (ASF, Chapter 8 in the JMS specification), you will have to write a full implementation of both the ProviderAdapter and the ServerSession stuff. Doing this is really an advanced subject and it should probably be handled through contacts on the <tt>jboss-dev</tt> mailing list.</p><p>Next we have the <tt>ServerSessionPoolFactoryJNDI</tt> element:</p><div class="figure"><p><a name="d0e5475"></a><b>Figure 8.74. Configuring the <tt>ServerSessionPool</tt> factory JNDI in <tt>jboss.xml</tt></b></p><pre class="programlisting">
<ServerSessionPoolFactoryJNDI>StdJMSPool</ServerSessionPoolFactoryJNDI>
</pre></div><p>This also points to a class loaded through <tt>jboss.jcml</tt>. It is the entry point to the <tt>ServerSessionPool</tt>. If one needs to write a provider-specific pool or do some customization of the existing one, it is possible to load it for a particular bean. The existing one is defined this way in <tt>jboss.jcml</tt>:</p><div class="figure"><p><a name="d0e5496"></a><b>Figure 8.75. Setting up the <tt>ServerSessionPool</tt> factory in <tt>jboss.jcml</tt></b></p><pre class="programlisting">
<mbean code="org.jboss.jms.asf.ServerSessionPoolLoader"
name=":service=ServerSessionPoolMBean,name=StdJMSPool">
<attribute name="PoolName">StdJMSPool</attribute>
<attribute name="PoolFactoryClass">org.jboss.jms.asf.\
StdServerSessionPoolFactory</attribute>
</mbean>
</pre></div><p>The first implementation of MDB for JBoss was based on another server session pool factory, especially written for OpenJMS. Currently, it does not work. What does work is the pluggability of server session pool factories.</p><p>The last two entries look like this:</p><div class="figure"><p><a name="d0e5510"></a><b>Figure 8.76. Server session pool configuration in <tt>jboss.xml</tt></b></p><pre class="programlisting">
<MaximumSize>15</MaximumSize>
<MaxMessages>1</MaxMessages>
</pre></div><p>The first of these, <tt>MaximumSize</tt>, defines how large the pool will be in terms of how many session it will have ready to serve incoming messages. The second one, <tt>MaxMessages</tt>, is used to configure the maximum number of messages a session is allowed to handle at once. I have never tweaked that option, and I do not know if JBossMQ actually supports it. It might enhance performance, if used.</p></div></div></div></div><table border="0" cellpadding="0" cellspacing="0" height="65"><tr height="65"><td rowspan="2"><img src="gbar.gif" tppabs="http://www.huihoo.org/jboss/online_manual/3.0/gbar.gif" width="432" height="79"></td><td rowspan="2" background="gbar.gif" tppabs="http://www.huihoo.org/jboss/online_manual/3.0/gbar.gif" width="100%" align="right" valign="top"><a href="index.html" tppabs="http://www.huihoo.org/jboss/online_manual/3.0/index.html"><img src="doc.gif" tppabs="http://www.huihoo.org/jboss/online_manual/3.0/doc.gif" border="0"></a><a href="ch08.html" tppabs="http://www.huihoo.org/jboss/online_manual/3.0/ch08.html"><img src="toc.gif" tppabs="http://www.huihoo.org/jboss/online_manual/3.0/toc.gif" border="0"></a><a href="ch08s07.html" tppabs="http://www.huihoo.org/jboss/online_manual/3.0/ch08s07.html"><img src="prev.gif" tppabs="http://www.huihoo.org/jboss/online_manual/3.0/prev.gif" border="0"></a><a href="ch08s32.html" tppabs="http://www.huihoo.org/jboss/online_manual/3.0/ch08s32.html"><img src="next.gif" tppabs="http://www.huihoo.org/jboss/online_manual/3.0/next.gif" border="0"></a></td></tr><tr></tr></table></body></html>⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -