[JBoss Cache Users] - How to manage an exception that occurs in the commit or roll
by nfilotto
Hi,
I'm trying to ensure the integrity of my data thanks to the TransactionManager. However, I met an issue during my study, I noticed that if I implement my own CacheLoder and an error occurs during the commit phase, the TM is never aware of this error since the commit is done in the afterCompletion of TxInterceptor$RemoteSynchronizationHandler and the exception is eaten by this method. According to the JTA specification, the afterCompletion method is not supposed to notify the TM when something wrong occured but my questions are the following:
1. Is-it normal that the commit is done in the afterCompletion? it should be done before the afterCompletion
2. What are we supposed to do? Up to now, we decided to commit in the prepare phase which is done in the beforeCompletion method if an error occurs the TM is notified and can call the rollback method but is-there a better solution?
Thank you in advance for your help,
BR,
Nicolas Filotto
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4268358#4268358
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4268358
14 years, 5 months
[JBoss Web Services Users] - JBoss 5.1.0: jbossws-native-saaj.jar conflicting with saaj-i
by jbosssupport
Hello forum,
Situation:
Using a third party application (Appl1) which can be integrated into custom software.
Appl1 uses saaj-impl.jar and saaj-api.jar (SUN original) in it's program logic. Both jars(saaj-impl.jar and saaj-api.jar) are located in server/serverDir/lib folder. Using Appl1 directly does not cause any problem!
Requirement:
Implement a WebService Application (WSAppl) using Jboss native WS-Security.
...
@EndpointConfig(configName = "Standard WSSecurity Endpoint")
@SecurityDomain("WSAppl")
WS-Sec Method is UsernameToken.
...
As you can see all WSMethods in WSAppl are secured with jbossws-native-saaj.jar, each of these method requests gets passed to Appl1.
Calling any WSMedod in WSAppl, the following Exception occurs:
| 2009-12-01 18:03:53,794 ERROR [org.jboss.ws.core.jaxws.SOAPFaultHelperJAXWS] (http-127.0.0.1-8280-1) SOAP request exception
| java.lang.UnsupportedOperationException: setProperty must be overridden by all subclasses of SOAPMessage
| at javax.xml.soap.SOAPMessage.setProperty(Unknown Source)
| at org.jboss.ws.core.soap.SOAPMessageImpl.<init>(SOAPMessageImpl.java:87)
| at org.jboss.ws.core.soap.MessageFactoryImpl.createMessage(MessageFactoryImpl.java:215)
| at org.jboss.ws.core.soap.MessageFactoryImpl.createMessage(MessageFactoryImpl.java:193)
| at org.jboss.wsf.stack.jbws.RequestHandlerImpl.processRequest(RequestHandlerImpl.java:455)
| at org.jboss.wsf.stack.jbws.RequestHandlerImpl.handleRequest(RequestHandlerImpl.java:295)
| at org.jboss.wsf.stack.jbws.RequestHandlerImpl.doPost(RequestHandlerImpl.java:205)
| at org.jboss.wsf.stack.jbws.RequestHandlerImpl.handleHttpRequest(RequestHandlerImpl.java:131)
| at org.jboss.wsf.common.servlet.AbstractEndpointServlet.service(AbstractEndpointServlet.java:85)
| at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
| at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
| at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
| at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
| at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
| at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
| at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:235)
| at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
| at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190)
| at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92)
| at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126)
| at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70)
| at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
| at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
| at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
| at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
| at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
| at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829)
| at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:598)
| at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
| at java.lang.Thread.run(Thread.java:595)
Assumption:
JBoss can not use 'jbossws-native-saaj.jar' for WS-Security in WSAppl and 'saaj-impl.jar' afterwards in Appl1 programm logic.
'jbossws-native-saaj.jar' is located in JBossDir/client folder as standard (no changes to Jboss libs).
Question:
As I can not change Appl1 Implementation to use jbossws-native-saaj.jar, is there any way to use both different implementations (JBoss native saaj for WS Security and SUN saaj in third party program logic) at the same time in the same Jboss instance?!
Thank you very much!
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4268354#4268354
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4268354
14 years, 5 months
[EJB 3.0 Users] - Re: Default value for transaction-type in persistence.xml
by jaikiran
"longbeach" wrote :
| That is what this documentation for Apache Geronimo states :
| http://cwiki.apache.org/GMOxDOC21/persistencexml.html
| anonymous wrote :
| | In general, in Java EE environments, a transaction-type of RESOURCE_LOCAL assumes that a non-JTA datasource will be provided. In a Java EE environment, if this element is not specified, the default is JTA. In a Java SE environment, if this element is not specified, a default of RESOURCE_LOCAL may be assumed.
| |
|
That's actually what the EJB3 Persistence Spec states too:
"EJB3 Persistence Spec" wrote : 6.2.1.2 transaction-type
| The transaction-type attribute is used to specify whether the entity managers provided by the entity manager factory for the persistence unit must be JTA entity managers or resource-local entity managers. The value of this element is JTA or RESOURCE_LOCAL. A transaction-type of JTA assumes that a JTA data source will be provided either as specified by the jta-data-source element or provided by the container. In general, in Java EE environments, a transaction-type of RESOURCE_LOCAL assumes that a non-JTA datasource will be provided. In a Java EE environment, if this element is not specified, the default is JTA. In a Java SE environment, if this element is not specified, a default of RESOURCE_LOCAL may be assumed.
|
|
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4268349#4268349
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4268349
14 years, 5 months