You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Jason Pell <ja...@pellcorp.com> on 2014/12/04 15:34:20 UTC
JMS SessionTransacted
I have set this to true in the JMSCOnfiguration
I am using CXF 2.7.x. I cannot upgrade to 3.x, so I need to get this
working using the JMS Configuration style.
What I am trying to get working is JMS managed transactions. So If I throw
an runtime exception from my JAX-WS Implementation, I would expect the
message to be rolled back.
However this does not work as expected. The JMSDestination expects a
PlatformTransactionManager to be configured in order for the rollback
process of the JMS Listener in spring to be executed.
I managed to get further by using
jmsConfig.setTransactionManager(new
JmsTransactionManager(connectionFactory));
Is this a bug in the cxf jms support or am I misunderstanding?
Re: JMS SessionTransacted
Posted by Christian Schneider <ch...@die-schneider.net>.
Sounds good to me.
Christian
On 04.12.2014 17:28, Jason Pell wrote:
> I created a new jira and will commit my changes if you don't have a better
> way to support my requirement.
>
> https://issues.apache.org/jira/browse/CXF-6136
>
>
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
Re: JMS SessionTransacted
Posted by Jason Pell <ja...@pellcorp.com>.
I created a new jira and will commit my changes if you don't have a better
way to support my requirement.
https://issues.apache.org/jira/browse/CXF-6136
On Fri, Dec 5, 2014 at 3:23 AM, Jason Pell <ja...@pellcorp.com> wrote:
> This actually allows me a great deal of control over the web service impl.
>
> This will cause a soap fault to be returned in a reply message:
> throw new SomeFault("Invalid user");
>
> This will cause the message to be rolled back:
> throw new RuntimeException("Error user");
>
>
>
> On Fri, Dec 5, 2014 at 3:22 AM, Jason Pell <ja...@pellcorp.com> wrote:
>
>> Hi Christian,
>>
>> I have a proposed change to JMSDestination to ignore checked exceptions
>> inside Faults.
>>
>> Be interested in your thoughts
>>
>> diff --git
>> a/rt/transports/jms/src/main/java/org/apache/cxf/transport/jms/JMSConfiguration.java
>> b/rt/transports/jms/src/main/java/org/apache/cxf/transport/jms/JMSConfiguration.java
>> index dcfc329..0348076 100644
>> ---
>> a/rt/transports/jms/src/main/java/org/apache/cxf/transport/jms/JMSConfiguration.java
>> +++
>> b/rt/transports/jms/src/main/java/org/apache/cxf/transport/jms/JMSConfiguration.java
>> @@ -55,6 +55,8 @@ public class JMSConfiguration implements
>> InitializingBean {
>> private PlatformTransactionManager transactionManager;
>> private boolean wrapInSingleConnectionFactory = true;
>> private TaskExecutor taskExecutor;
>> + private boolean rollbackCheckedExceptions = true;
>> +
>> private boolean useJms11 = DEFAULT_USEJMS11;
>> private boolean reconnectOnException = true;
>> private boolean createSecurityContext = true;
>> @@ -117,6 +119,14 @@ public class JMSConfiguration implements
>> InitializingBean {
>> }
>> }
>>
>> + public boolean isRollbackCheckedExceptions() {
>> + return rollbackCheckedExceptions;
>> + }
>> +
>> + public void setRollbackCheckedExceptions(boolean
>> rollbackCheckedExceptions) {
>> + this.rollbackCheckedExceptions = rollbackCheckedExceptions;
>> + }
>> +
>> public boolean isCreateSecurityContext() {
>> return createSecurityContext;
>> }
>> diff --git
>> a/rt/transports/jms/src/main/java/org/apache/cxf/transport/jms/JMSDestination.java
>> b/rt/transports/jms/src/main/java/org/apache/cxf/transport/jms/JMSDestination.java
>> index 1a81687..e9e07c7 100644
>> ---
>> a/rt/transports/jms/src/main/java/org/apache/cxf/transport/jms/JMSDestination.java
>> +++
>> b/rt/transports/jms/src/main/java/org/apache/cxf/transport/jms/JMSDestination.java
>> @@ -261,7 +261,7 @@ public class JMSDestination extends
>> AbstractMultiplexDestination
>> Exception ex =
>> inMessage.getContent(Exception.class);
>> if (ex.getCause() instanceof RuntimeException) {
>> throw (RuntimeException)ex.getCause();
>> - } else {
>> + } else if
>> (jmsConfig.isRollbackCheckedExceptions()) {
>> throw new RuntimeException(ex);
>> }
>> }
>>
>>
>> On Fri, Dec 5, 2014 at 2:52 AM, Jason Pell <ja...@pellcorp.com> wrote:
>>
>>> Yep it does work with the JMSTransactionManager set. So I guess its
>>> just a documentation issue then.
>>>
>>> If I want some exceptions to be handled as soap faults - in a reply
>>> message, and some exceptions to cause rollback.
>>>
>>> Is that possible in cxf once i have enabled the JMSTransactionManager?
>>>
>>> I note the JMSDestination wraps non runtime exceptions in runtime
>>> exceptions., but ideally if I throw a business fault (a checked exception),
>>> then I would do the normal fault processing and send a response message
>>> with the fault.
>>>
>>> Any runtime exceptions would cause a roll back.
>>>
>>> Is there some cxf interceptor magic I might be able to do?
>>>
>>>
>>>
>>>
>>>
>>> On Fri, Dec 5, 2014 at 2:09 AM, Christian Schneider <
>>> chris@die-schneider.net> wrote:
>>>
>>>> Yes. For CXF 2.x you need a spring PlatformTransactionManager. This can
>>>> then be a specific manager for JMS or a real JTA Transaction manager.
>>>> Does it then work?
>>>>
>>>> Christian
>>>>
>>>>
>>>> On 04.12.2014 15:34, Jason Pell wrote:
>>>>
>>>>> I have set this to true in the JMSCOnfiguration
>>>>>
>>>>> I am using CXF 2.7.x. I cannot upgrade to 3.x, so I need to get this
>>>>> working using the JMS Configuration style.
>>>>>
>>>>> What I am trying to get working is JMS managed transactions. So If I
>>>>> throw
>>>>> an runtime exception from my JAX-WS Implementation, I would expect the
>>>>> message to be rolled back.
>>>>>
>>>>> However this does not work as expected. The JMSDestination expects a
>>>>> PlatformTransactionManager to be configured in order for the rollback
>>>>> process of the JMS Listener in spring to be executed.
>>>>>
>>>>> I managed to get further by using
>>>>>
>>>>> jmsConfig.setTransactionManager(new
>>>>> JmsTransactionManager(connectionFactory));
>>>>>
>>>>> Is this a bug in the cxf jms support or am I misunderstanding?
>>>>>
>>>>>
>>>>
>>>> --
>>>> Christian Schneider
>>>> http://www.liquid-reality.de
>>>>
>>>> Open Source Architect
>>>> http://www.talend.com
>>>>
>>>>
>>>
>>
>
Re: JMS SessionTransacted
Posted by Jason Pell <ja...@pellcorp.com>.
This actually allows me a great deal of control over the web service impl.
This will cause a soap fault to be returned in a reply message:
throw new SomeFault("Invalid user");
This will cause the message to be rolled back:
throw new RuntimeException("Error user");
On Fri, Dec 5, 2014 at 3:22 AM, Jason Pell <ja...@pellcorp.com> wrote:
> Hi Christian,
>
> I have a proposed change to JMSDestination to ignore checked exceptions
> inside Faults.
>
> Be interested in your thoughts
>
> diff --git
> a/rt/transports/jms/src/main/java/org/apache/cxf/transport/jms/JMSConfiguration.java
> b/rt/transports/jms/src/main/java/org/apache/cxf/transport/jms/JMSConfiguration.java
> index dcfc329..0348076 100644
> ---
> a/rt/transports/jms/src/main/java/org/apache/cxf/transport/jms/JMSConfiguration.java
> +++
> b/rt/transports/jms/src/main/java/org/apache/cxf/transport/jms/JMSConfiguration.java
> @@ -55,6 +55,8 @@ public class JMSConfiguration implements
> InitializingBean {
> private PlatformTransactionManager transactionManager;
> private boolean wrapInSingleConnectionFactory = true;
> private TaskExecutor taskExecutor;
> + private boolean rollbackCheckedExceptions = true;
> +
> private boolean useJms11 = DEFAULT_USEJMS11;
> private boolean reconnectOnException = true;
> private boolean createSecurityContext = true;
> @@ -117,6 +119,14 @@ public class JMSConfiguration implements
> InitializingBean {
> }
> }
>
> + public boolean isRollbackCheckedExceptions() {
> + return rollbackCheckedExceptions;
> + }
> +
> + public void setRollbackCheckedExceptions(boolean
> rollbackCheckedExceptions) {
> + this.rollbackCheckedExceptions = rollbackCheckedExceptions;
> + }
> +
> public boolean isCreateSecurityContext() {
> return createSecurityContext;
> }
> diff --git
> a/rt/transports/jms/src/main/java/org/apache/cxf/transport/jms/JMSDestination.java
> b/rt/transports/jms/src/main/java/org/apache/cxf/transport/jms/JMSDestination.java
> index 1a81687..e9e07c7 100644
> ---
> a/rt/transports/jms/src/main/java/org/apache/cxf/transport/jms/JMSDestination.java
> +++
> b/rt/transports/jms/src/main/java/org/apache/cxf/transport/jms/JMSDestination.java
> @@ -261,7 +261,7 @@ public class JMSDestination extends
> AbstractMultiplexDestination
> Exception ex =
> inMessage.getContent(Exception.class);
> if (ex.getCause() instanceof RuntimeException) {
> throw (RuntimeException)ex.getCause();
> - } else {
> + } else if
> (jmsConfig.isRollbackCheckedExceptions()) {
> throw new RuntimeException(ex);
> }
> }
>
>
> On Fri, Dec 5, 2014 at 2:52 AM, Jason Pell <ja...@pellcorp.com> wrote:
>
>> Yep it does work with the JMSTransactionManager set. So I guess its just
>> a documentation issue then.
>>
>> If I want some exceptions to be handled as soap faults - in a reply
>> message, and some exceptions to cause rollback.
>>
>> Is that possible in cxf once i have enabled the JMSTransactionManager?
>>
>> I note the JMSDestination wraps non runtime exceptions in runtime
>> exceptions., but ideally if I throw a business fault (a checked exception),
>> then I would do the normal fault processing and send a response message
>> with the fault.
>>
>> Any runtime exceptions would cause a roll back.
>>
>> Is there some cxf interceptor magic I might be able to do?
>>
>>
>>
>>
>>
>> On Fri, Dec 5, 2014 at 2:09 AM, Christian Schneider <
>> chris@die-schneider.net> wrote:
>>
>>> Yes. For CXF 2.x you need a spring PlatformTransactionManager. This can
>>> then be a specific manager for JMS or a real JTA Transaction manager.
>>> Does it then work?
>>>
>>> Christian
>>>
>>>
>>> On 04.12.2014 15:34, Jason Pell wrote:
>>>
>>>> I have set this to true in the JMSCOnfiguration
>>>>
>>>> I am using CXF 2.7.x. I cannot upgrade to 3.x, so I need to get this
>>>> working using the JMS Configuration style.
>>>>
>>>> What I am trying to get working is JMS managed transactions. So If I
>>>> throw
>>>> an runtime exception from my JAX-WS Implementation, I would expect the
>>>> message to be rolled back.
>>>>
>>>> However this does not work as expected. The JMSDestination expects a
>>>> PlatformTransactionManager to be configured in order for the rollback
>>>> process of the JMS Listener in spring to be executed.
>>>>
>>>> I managed to get further by using
>>>>
>>>> jmsConfig.setTransactionManager(new
>>>> JmsTransactionManager(connectionFactory));
>>>>
>>>> Is this a bug in the cxf jms support or am I misunderstanding?
>>>>
>>>>
>>>
>>> --
>>> Christian Schneider
>>> http://www.liquid-reality.de
>>>
>>> Open Source Architect
>>> http://www.talend.com
>>>
>>>
>>
>
Re: JMS SessionTransacted
Posted by Jason Pell <ja...@pellcorp.com>.
Hi Christian,
I have a proposed change to JMSDestination to ignore checked exceptions
inside Faults.
Be interested in your thoughts
diff --git
a/rt/transports/jms/src/main/java/org/apache/cxf/transport/jms/JMSConfiguration.java
b/rt/transports/jms/src/main/java/org/apache/cxf/transport/jms/JMSConfiguration.java
index dcfc329..0348076 100644
---
a/rt/transports/jms/src/main/java/org/apache/cxf/transport/jms/JMSConfiguration.java
+++
b/rt/transports/jms/src/main/java/org/apache/cxf/transport/jms/JMSConfiguration.java
@@ -55,6 +55,8 @@ public class JMSConfiguration implements InitializingBean
{
private PlatformTransactionManager transactionManager;
private boolean wrapInSingleConnectionFactory = true;
private TaskExecutor taskExecutor;
+ private boolean rollbackCheckedExceptions = true;
+
private boolean useJms11 = DEFAULT_USEJMS11;
private boolean reconnectOnException = true;
private boolean createSecurityContext = true;
@@ -117,6 +119,14 @@ public class JMSConfiguration implements
InitializingBean {
}
}
+ public boolean isRollbackCheckedExceptions() {
+ return rollbackCheckedExceptions;
+ }
+
+ public void setRollbackCheckedExceptions(boolean
rollbackCheckedExceptions) {
+ this.rollbackCheckedExceptions = rollbackCheckedExceptions;
+ }
+
public boolean isCreateSecurityContext() {
return createSecurityContext;
}
diff --git
a/rt/transports/jms/src/main/java/org/apache/cxf/transport/jms/JMSDestination.java
b/rt/transports/jms/src/main/java/org/apache/cxf/transport/jms/JMSDestination.java
index 1a81687..e9e07c7 100644
---
a/rt/transports/jms/src/main/java/org/apache/cxf/transport/jms/JMSDestination.java
+++
b/rt/transports/jms/src/main/java/org/apache/cxf/transport/jms/JMSDestination.java
@@ -261,7 +261,7 @@ public class JMSDestination extends
AbstractMultiplexDestination
Exception ex =
inMessage.getContent(Exception.class);
if (ex.getCause() instanceof RuntimeException) {
throw (RuntimeException)ex.getCause();
- } else {
+ } else if
(jmsConfig.isRollbackCheckedExceptions()) {
throw new RuntimeException(ex);
}
}
On Fri, Dec 5, 2014 at 2:52 AM, Jason Pell <ja...@pellcorp.com> wrote:
> Yep it does work with the JMSTransactionManager set. So I guess its just
> a documentation issue then.
>
> If I want some exceptions to be handled as soap faults - in a reply
> message, and some exceptions to cause rollback.
>
> Is that possible in cxf once i have enabled the JMSTransactionManager?
>
> I note the JMSDestination wraps non runtime exceptions in runtime
> exceptions., but ideally if I throw a business fault (a checked exception),
> then I would do the normal fault processing and send a response message
> with the fault.
>
> Any runtime exceptions would cause a roll back.
>
> Is there some cxf interceptor magic I might be able to do?
>
>
>
>
>
> On Fri, Dec 5, 2014 at 2:09 AM, Christian Schneider <
> chris@die-schneider.net> wrote:
>
>> Yes. For CXF 2.x you need a spring PlatformTransactionManager. This can
>> then be a specific manager for JMS or a real JTA Transaction manager.
>> Does it then work?
>>
>> Christian
>>
>>
>> On 04.12.2014 15:34, Jason Pell wrote:
>>
>>> I have set this to true in the JMSCOnfiguration
>>>
>>> I am using CXF 2.7.x. I cannot upgrade to 3.x, so I need to get this
>>> working using the JMS Configuration style.
>>>
>>> What I am trying to get working is JMS managed transactions. So If I
>>> throw
>>> an runtime exception from my JAX-WS Implementation, I would expect the
>>> message to be rolled back.
>>>
>>> However this does not work as expected. The JMSDestination expects a
>>> PlatformTransactionManager to be configured in order for the rollback
>>> process of the JMS Listener in spring to be executed.
>>>
>>> I managed to get further by using
>>>
>>> jmsConfig.setTransactionManager(new
>>> JmsTransactionManager(connectionFactory));
>>>
>>> Is this a bug in the cxf jms support or am I misunderstanding?
>>>
>>>
>>
>> --
>> Christian Schneider
>> http://www.liquid-reality.de
>>
>> Open Source Architect
>> http://www.talend.com
>>
>>
>
Re: JMS SessionTransacted
Posted by Jason Pell <ja...@pellcorp.com>.
Yep it does work with the JMSTransactionManager set. So I guess its just a
documentation issue then.
If I want some exceptions to be handled as soap faults - in a reply
message, and some exceptions to cause rollback.
Is that possible in cxf once i have enabled the JMSTransactionManager?
I note the JMSDestination wraps non runtime exceptions in runtime
exceptions., but ideally if I throw a business fault (a checked exception),
then I would do the normal fault processing and send a response message
with the fault.
Any runtime exceptions would cause a roll back.
Is there some cxf interceptor magic I might be able to do?
On Fri, Dec 5, 2014 at 2:09 AM, Christian Schneider <chris@die-schneider.net
> wrote:
> Yes. For CXF 2.x you need a spring PlatformTransactionManager. This can
> then be a specific manager for JMS or a real JTA Transaction manager.
> Does it then work?
>
> Christian
>
>
> On 04.12.2014 15:34, Jason Pell wrote:
>
>> I have set this to true in the JMSCOnfiguration
>>
>> I am using CXF 2.7.x. I cannot upgrade to 3.x, so I need to get this
>> working using the JMS Configuration style.
>>
>> What I am trying to get working is JMS managed transactions. So If I
>> throw
>> an runtime exception from my JAX-WS Implementation, I would expect the
>> message to be rolled back.
>>
>> However this does not work as expected. The JMSDestination expects a
>> PlatformTransactionManager to be configured in order for the rollback
>> process of the JMS Listener in spring to be executed.
>>
>> I managed to get further by using
>>
>> jmsConfig.setTransactionManager(new
>> JmsTransactionManager(connectionFactory));
>>
>> Is this a bug in the cxf jms support or am I misunderstanding?
>>
>>
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> http://www.talend.com
>
>
Re: JMS SessionTransacted
Posted by Christian Schneider <ch...@die-schneider.net>.
Yes. For CXF 2.x you need a spring PlatformTransactionManager. This can
then be a specific manager for JMS or a real JTA Transaction manager.
Does it then work?
Christian
On 04.12.2014 15:34, Jason Pell wrote:
> I have set this to true in the JMSCOnfiguration
>
> I am using CXF 2.7.x. I cannot upgrade to 3.x, so I need to get this
> working using the JMS Configuration style.
>
> What I am trying to get working is JMS managed transactions. So If I throw
> an runtime exception from my JAX-WS Implementation, I would expect the
> message to be rolled back.
>
> However this does not work as expected. The JMSDestination expects a
> PlatformTransactionManager to be configured in order for the rollback
> process of the JMS Listener in spring to be executed.
>
> I managed to get further by using
>
> jmsConfig.setTransactionManager(new
> JmsTransactionManager(connectionFactory));
>
> Is this a bug in the cxf jms support or am I misunderstanding?
>
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com