cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benson Margulies <bimargul...@gmail.com>
Subject Re: Fwd: [CONF] Apache CXF Documentation > Using the JMSConfigFeature
Date Wed, 27 Oct 2010 11:43:00 GMT
On Wed, Oct 27, 2010 at 3:04 AM, Christian Schneider
<chris@die-schneider.net> wrote:
> Hi Benson,
>
> I just checked the source code of jms transport. It seems that the is not
> even a property useMessageIDAsCorrealationID in JmsConfiguration. The
> JmsOldConfigHolder does not read this property.
> So this does not seem to be used at all. I just copied the description to
> the JmsConfigFeature as I assumed it should be present.
>
> I have not yet tested this with a Tibco Business Works Server where the
> messageId is used to correlate messages but I guess there could be problems.
> There could be another algorithm present of course.
> Any ideas?

Honestly, no. I am a JMS novice, and I am happy to have the SOAP/JMS
stuff working find with ActiveMQ.

>
> Best Regards
>
> Christian
>
>
>
>
> Am 26.10.2010 15:21, schrieb Benson Margulies:
>>
>> There's a nasty spelling error highlighted here. Anyone care to open a
>> JIRA?
>>
>> ---------- Forwarded message ----------
>> From:<confluence@apache.org>
>> Date: Tue, Oct 26, 2010 at 5:18 AM
>> Subject: [CONF] Apache CXF Documentation>  Using the JMSConfigFeature
>> To: commits@cxf.apache.org
>>
>>
>>    Using the
>> JMSConfigFeature<https://cwiki.apache.org/confluence/display/CXF20DOC/Using+the+JMSConfigFeature>
>> Page
>> *edited* by Christian
>>
>> Schneider<https://cwiki.apache.org/confluence/display/~christian%2Bschneider>
>> Changes (1)
>>  ...
>> true means use topics \\ |
>> | jmsProviderTibcoEms | false | true means that the jms provider is Tibco
>> EMS. Currently this activates that the principal in the SecurityContext is
>> populated from the header JMS_TIBCO_SENDER. (available from cxf version
>> 2.2.6) |
>> | useMessageIDAsCorrealationID | false | Specifies whether the JMS broker
>> will use the message ID to correlate messages. By default a CXF client
>> will
>> set a generated correlation id instead |
>> \\
>>  Full Content
>>
>> In older CXF version the JMS transport is configured by defining a
>> JMSConduit or JMSDestination. Starting with CXF 2.0.9 and 2.1.3 the JMS
>> transport includes an easier configuration option that is more conformant
>> to
>> the spring dependency injection. Additionally the new configuration has
>> much
>> more options. For example it is not necessary anymore to use JNDI to
>> resolve
>> the connection factory. Instead it can be defined in the spring config.
>>
>> The following example configs use the
>>
>> p-namespace<http://static.springframework.org/spring/docs/2.5.x/reference/beans.html>from
>> spring 2.5 but the old spring bean style is also possible.
>>
>> Inside a features element the JMSConfigFeature can be defined.
>>
>>  <jaxws:client id="CustomerService"
>>        xmlns:customer="http://customerservice.example.com/"
>>  serviceName="customer:CustomerServiceService"
>>        endpointName="customer:CustomerServiceEndpoint"
>> address="jms://"
>>  serviceClass="com.example.customerservice.CustomerService">
>>        <jaxws:features>
>>                <bean xmlns="http://www.springframework.org/schema/beans"
>>                     class="org.apache.cxf.transport.jms.JMSConfigFeature"
>>                        p:jmsConfig-ref="jmsConfig"/>
>>        </jaxws:features>
>> </jaxws:client>
>>
>>  In the above example it references a bean "jmsConfig" where the whole
>> configuration for the JMS transport can be done.
>>
>> A jaxws Endpoint can be defined in the same way:
>>
>> <jaxws:endpoint
>>        xmlns:customer="http://customerservice.example.com/"
>>  id="CustomerService"
>>        address="jms://"
>>  serviceName="customer:CustomerServiceService"
>>        endpointName="customer:CustomerServiceEndpoint"
>>        implementor="com.example.customerservice.impl.CustomerServiceImpl">
>>        <jaxws:features>
>>                <bean class="org.apache.cxf.transport.jms.JMSConfigFeature"
>>                        p:jmsConfig-ref="jmsConfig" />
>>        </jaxws:features>
>> </jaxws:endpoint>
>>
>>  The JMSConfiguration bean needs at least a reference to a conncection
>> factory and a target destination.
>>
>>  <bean id="jmsConfig"
>> class="org.apache.cxf.transport.jms.JMSConfiguration"
>>        p:connectionFactory-ref="jmsConnectionFactory"
>>        p:targetDestination="test.cxf.jmstransport.queue"
>> />
>>
>>  If your ConnectionFactory does not cache connections you should wrap it
>> in
>> a spring SingleConnectionFactory. This is necessary because the JMS
>> Transport creates a new connection for each message and the
>> SingleConnectionFactory is needed to cache this connection.
>>
>>  <bean id="jmsConnectionFactory"
>> class="org.springframework.jms.connection.SingleConnectionFactory">
>>        <property name="targetConnectionFactory">
>>                <bean
>> class="org.apache.activemq.ActiveMQConnectionFactory">
>>                        <property name="brokerURL"
>> value="tcp://localhost:61616" />             </bean>
>>        </property>
>> </bean>
>>
>>  JMSConfiguration options:
>>   Name  Default
>>  Description
>>   connectionFactory  (mandatory field)  Reference to a bean that defines a
>> jms ConnectionFactory. Remember to wrap the connectionFactory like
>> described
>> above when not using a pooling ConnectionFactory
>>   wrapInSingleConnectionFactory  true  Will wrap the connectionFactory
>> with
>> a Spring SingleConnectionFactory, which can improve the performance of the
>> jms transport   reconnectOnException  false  If wrapping the
>> connectionFactory with a Spring SingleConnectionFactory and
>> reconnectOnException is true, will create a new connection if there is an
>> exception thrown, otherwise will not try to reconnect if the there is an
>> exception thrown.   targetDestination
>>  JNDI name or provider specific name of a destination. Example for
>> ActiveMQ:
>>
>> test.cxf.jmstransport.queue   replyDestination
>>
>>   destinationResolver  DynamicDestinationResolver  Reference to a Spring
>> DestinationResolver. This allows to define how destination names are
>> resolved to jms Destinations. By default a DynamicDestinationResolver is
>> used. It resolves destinations using the jms providers features. If you
>> reference a JndiDestinationResolver you can resolve the destination names
>> using JNDI.
>>   transactionManager
>>  none  Reference to a spring transaction manager. This allows to take part
>> in JTA Transactions with your webservice.
>>   taskExecutor  SimpleAsyncTaskExecutor  Reference to a spring
>> TaskExecutor.
>> This is used in listeners to decide how to handle incoming messages.
>> Default
>> is a spring SimpleAsyncTaskExecutor.
>>   useJms11>  CXF 2.1.3: false  true means JMS 1.1 features are used
>> false means only JMS 1.0.2 features are used
>>   messageIdEnabled  true    messageTimestampEnabled  true
>> cacheLevel  -1 Specify the level of caching that the JMS listener
>> container is allowed to
>> apply.
>> Please check out the java doc of the
>> org.springframework.jms.listenerDefaultMessageListenerContainer for more
>> information
>>   pubSubNoLocal  false  true do not receive your own messages when using
>> topics
>>   receiveTimeout  0  How many milliseconds to wait for response messages.
>> 0
>> means wait indefinitely
>>   explicitQosEnabled  false  true means that QoS parameters are set for
>> each
>> message.   deliveryMode  1  NON_PERSISTENT = 1 messages will only be kept
>> in
>> memory
>>
>> PERSISTENT = 2    messages will be persisted to disk
>>   priority  4
>>  Priority for the messages. See your JMS provider doc for details
>>   timeToLive  0  After this time the message will be discarded by the jms
>> provider
>>   sessionTransacted  false  true means JMS transactions are used
>>   concurrentConsumers  1  minimum number of concurrent consumers for
>> listener
>>   maxConcurrentConsumers  1  maximum number of concurrent consumers for
>> listener   maxConcurrentTasks  10  Maximum number of threads that handle
>> the
>> received requests (available from cxf 2.1.4 upwards)   messageSelector
>>
>>  jms selector to filter incoming messages (allows to share a queue)
>>   subscriptionDurable
>>  false    durableSubscriptionName
>>
>>     messageType
>>  text
>>  text
>> binary
>> byte
>>   pubSubDomain
>>  false
>>  false means use queues
>> true means use topics
>>   jmsProviderTibcoEms  false  true means that the jms provider is Tibco
>> EMS.
>> Currently this activates that the principal in the SecurityContext is
>> populated from the header JMS_TIBCO_SENDER. (available from cxf version
>> 2.2.6)   useMessageIDAsCorrealationID  false  Specifies whether the JMS
>> broker will use the message ID to correlate messages. By default a CXF
>> client will set a generated correlation id instead
>>
>>
>>   Change Notification
>>
>> Preferences<https://cwiki.apache.org/confluence/users/viewnotifications.action>
>> View
>> Online<https://cwiki.apache.org/confluence/display/CXF20DOC/Using+the+JMSConfigFeature>|
>> View
>>
>> Changes<https://cwiki.apache.org/confluence/pages/diffpagesbyversion.action?pageId=100809&revisedVersion=9&originalVersion=8>|
>> Add
>>
>> Comment<https://cwiki.apache.org/confluence/display/CXF20DOC/Using+the+JMSConfigFeature?showComments=true&showCommentArea=true#addcomment>
>>
>
> --
> ----
> http://www.liquid-reality.de
>
>

Mime
View raw message