This may be interesting to discuss here, please have a look at https://issues.jboss.org/browse/WFLY-2936 Other issues that are related and I’m aware https://issues.jboss.org/browse/WFLY-1168 https://issues.jboss.org/browse/WFLY-2960

—E _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

Yes this is an application requirement. You can't use CMT and call commit! Sent from my iPhone > On Feb 24, 2014, at 2:27 PM, Scott Marlow <smarlow(a)redhat.com&gt; wrote: > > Is the below requirement for the application or the container? > > " > 8.3.4 Enterprise Beans Using Container-Managed Transaction Demarcation > > This subsection describes the requirements for the Bean Provider of an > enterprise bean using container-managed transaction demarcation. > > The enterprise bean’s business methods, message listener methods, > business method interceptor methods, lifecycle callback interceptor > methods, or timeout callback methods must not use any resource-manager > specific transaction management methods that would interfere with the > container’s demarcation of transaction boundaries. For example, the > enterprise bean methods must not use the following methods of the > java.sql.Connection interface: commit, setAutoCommit, and rollback; or > the following methods of the javax.jms.Session interface: commit and > rollback. > " > > IMO, I think that the requirement is on the application code and not the > container. > >> On 02/24/2014 02:44 PM, Eduardo Martins wrote: >> This may be interesting to discuss here, please have a look at >> >> https://issues.jboss.org/browse/WFLY-2936 >> >> Other issues that are related and I’m aware >> >> https://issues.jboss.org/browse/WFLY-1168 >> https://issues.jboss.org/browse/WFLY-2960 > > I'm waiting to hear back from the Spring user but think that they will > likely be able to solve it via existing Spring support for JTA. For the > Spring case, the user might not of noticed the (using UT in CMT) problem > if it was just a warning but we can't have it both ways. > >> >> —E >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev

That’s wrt invoking EJBContext#getUserTransaction() only, but your first quote section has an additional paragraph: "The enterprise bean’s business methods, message listener methods, business method interceptor meth- ods, lifecycle callback interceptor methods, or timeout callback methods must not attempt to obtain or use the javax.transaction.UserTransaction interface.” The rule is too restrictive in my opinion, there is no harm in obtaining the UserTransaction I think, the restriction should be in using some of it’s methods, the same way restrictions are applied to the methods of the java.sql.ConnectionIt’s listed in your first quote. Anyway, the spec is what it is, I don’t think Seam should try to change it. If there is enough utility in transaction control by Seam then it should clearly define how it integrates with Java EE. If there isn’t, if it’s just a matter of getting some status from transaction control, then alternatives should be used, such as the TSR. Well, Seam could also give some “room” to the app, and use the TSR for any status retrieval, leaving the usage of the Java EE UserTransaction for managing Seam's transaction, somehow IMHO “fixing" the spec. —E On 25 Feb 2014, at 02:44, Scott Marlow <smarlow(a)redhat.com&gt; wrote: > Hmm, looks like I was looking at the wrong EJB spec section. Should of been looking at: > > " > 8.6.3.10 Handling of getUserTransaction Method > > If an instance of an enterprise bean with container-managed transaction demarcation attempts to invoke the getUserTransaction method of the EJBContext interface, the container must throw the java.lang.IllegalStateException. > " > > The pull request https://github.com/wildfly/wildfly/pull/3213 has more context about what happened (we used to throw the ISE pre-AS7, AS 7.0 didn't throw the ISE and we are now throwing it again). > > org.jboss.seam.transaction.Transaction.getUserTransaction() shouldn't be used in a CMT. I'm not sure of how to avoid that (perhaps some Seam configuration?) > > On 02/24/2014 08:55 PM, Jason T. Greene wrote: >> Yes this is an application requirement. You can't use CMT and call commit! >> >> Sent from my iPhone >> >>> On Feb 24, 2014, at 2:27 PM, Scott Marlow <smarlow(a)redhat.com&gt; wrote: >>> >>> Is the below requirement for the application or the container? >>> >>> " >>> 8.3.4 Enterprise Beans Using Container-Managed Transaction Demarcation >>> >>> This subsection describes the requirements for the Bean Provider of an >>> enterprise bean using container-managed transaction demarcation. >>> >>> The enterprise bean’s business methods, message listener methods, >>> business method interceptor methods, lifecycle callback interceptor >>> methods, or timeout callback methods must not use any resource-manager >>> specific transaction management methods that would interfere with the >>> container’s demarcation of transaction boundaries. For example, the >>> enterprise bean methods must not use the following methods of the >>> java.sql.Connection interface: commit, setAutoCommit, and rollback; or >>> the following methods of the javax.jms.Session interface: commit and >>> rollback. >>> " >>> >>> IMO, I think that the requirement is on the application code and not the >>> container. >>> >>>> On 02/24/2014 02:44 PM, Eduardo Martins wrote: >>>> This may be interesting to discuss here, please have a look at >>>> >>>> https://issues.jboss.org/browse/WFLY-2936 >>>> >>>> Other issues that are related and I’m aware >>>> >>>> https://issues.jboss.org/browse/WFLY-1168 >>>> https://issues.jboss.org/browse/WFLY-2960 >>> >>> I'm waiting to hear back from the Spring user but think that they will >>> likely be able to solve it via existing Spring support for JTA. For the >>> Spring case, the user might not of noticed the (using UT in CMT) problem >>> if it was just a warning but we can't have it both ways. >>> >>>> >>>> —E >>>> _______________________________________________ >>>> wildfly-dev mailing list >>>> wildfly-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev > _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

On 02/25/2014 07:13 AM, Eduardo Martins wrote: > That’s wrt invoking EJBContext#getUserTransaction() only, but your first quote section has an additional paragraph: > > "The enterprise bean’s business methods, message listener methods, business method interceptor meth- ods, lifecycle callback interceptor methods, or timeout callback methods must not attempt to obtain or use the javax.transaction.UserTransaction interface.” > > The rule is too restrictive in my opinion, there is no harm in obtaining the UserTransaction I think, the restriction should be in using some of it’s methods, the same way restrictions are applied to the methods of the java.sql.ConnectionIt’s listed in your first quote. > > Anyway, the spec is what it is, I don’t think Seam should try to change it. If there is enough utility in transaction control by Seam then it should clearly define how it integrates with Java EE. If there isn’t, if it’s just a matter of getting some status from transaction control, then alternatives should be used, such as the TSR. Well, Seam could also give some “room” to the app, and use the TSR for any status retrieval, leaving the usage of the Java EE UserTransaction for managing Seam's transaction, somehow IMHO “fixing" the spec. Looking at the (second) exception call stack in https://issues.jboss.org/secure/attachment/12380521/server.log that shows the Seam related issue in WFLY-2936. I don't understand how Seam was able to get the UT in the previous releases that also threw the same ISE error (when the UT is accessed from a CMT). I have a question about Seam and prior releases of the app server that didn't have this problem. Did something change in Seam or is it that we just don't reach the org.jboss.seam.transaction.Transaction.getUserTransaction() for some reason, with previous releases of the app server?

>> Right the real question is what is Seam using the UT for. There is only one method on that is “safe” with CMT (getting the status), and that isn’t all that useful. Looking at that stacktrace [1] and the code in Seam [2], it appears that Seam wants to register a transaction synchronization if a transaction is active. Unfortunately, a lot of libraries (including Seam) use the UserTransaction API (UserTransaction.getStatus()) to check if a transaction is active. The right way to do it is using the TransactionSynchronizationRegistry which is available and portable (as mandated by spec) under the java:comp/TransactionSynchronizationRegistry JNDI name. The TransactionSynchronizationRegistry has a getTransactionStatus() method which can be used to check the transaction status in the current (thread) context http://docs.oracle.com/javaee/5/api/javax/transaction/TransactionSynchron.... Usage of this API is rarely explained and applications/libraries keep using UserTransaction instead. To answer the other question as to why this started showing up now and not in earlier versions, the code in Seam tries to deal with this exact situation by catching a specific (NameNotFoundException) while doing a UserTransaction lookup [3]. Notice that in that code [3], it doesn't deal with any other exception other than NameNotFoundException although that code does realize that using UserTransaction for what it's doing can run into problems (the comments there indicate something along those lines). So my guess is that, in previous version of AS, we used to throw a NameNotFoundException in this specific case and now we are throwing a IllegalStateException [4]. Maybe in WildFly, to prevent existing libraries like Seam from breaking, we could just change this bit to throw NameNotFoundException instead of IllegalStateException (although I don't remember if the TCK tests for the exact exception type in this case).

[1] at org.jboss.seam.transaction.Transaction.instance(Transaction.java:39) [jboss-seam.jar:2.2.2.Final] at org.jboss.seam.persistence.ManagedPersistenceContext.joinTransaction(ManagedPersistenceContext.java:120) [jboss-seam.jar:2.2.2.Final] at org.jboss.seam.persistence.ManagedPersistenceContext.getEntityManager(ManagedPersistenceContext.java:112) [jboss-seam.jar:2.2.2.Final] [2] http://grepcode.com/file/repository.jboss.org/nexus/content/repositories/... [3] http://grepcode.com/file/repository.jboss.org/nexus/content/repositories/... [4] Caused by: java.lang.IllegalStateException: JBAS014237: Only session and message-driven beans with bean-managed transaction demarcation are allowed to access UserTransaction P.S: A big congratulations on the WildFly 8.0 Final release! :) Although haven't posted here so far, I've been lurking this list. Good luck with the next releases.

-Jaikiran _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

On 02/26/2014 11:04 AM, Scott Marlow wrote: > On 02/26/2014 02:02 AM, Jaikiran Pai wrote: >> >> Right the real question is what is Seam using the UT for. There is >> only one method on that is “safe” with CMT (getting the status), and >> that isn’t all that useful. >> >> Looking at that stacktrace [1] and the code in Seam [2], it appears that >> Seam wants to register a transaction synchronization if a transaction is >> active. Unfortunately, a lot of libraries (including Seam) use the >> UserTransaction API (UserTransaction.getStatus()) to check if a >> transaction is active. The right way to do it is using the >> TransactionSynchronizationRegistry which is available and portable (as >> mandated by spec) under the java:comp/TransactionSynchronizationRegistry >> JNDI name. The TransactionSynchronizationRegistry has a >> getTransactionStatus() method which can be used to check the transaction >> status in the current (thread) context >> http://docs.oracle.com/javaee/5/api/javax/transaction/TransactionSynchron.... >> Usage of this API is rarely explained and applications/libraries keep >> using UserTransaction instead. >> >> To answer the other question as to why this started showing up now and >> not in earlier versions, the code in Seam tries to deal with this exact >> situation by catching a specific (NameNotFoundException) while doing a >> UserTransaction lookup [3]. Notice that in that code [3], it doesn't >> deal with any other exception other than NameNotFoundException although >> that code does realize that using UserTransaction for what it's doing >> can run into problems (the comments there indicate something along those >> lines). So my guess is that, in previous version of AS, we used to throw >> a NameNotFoundException in this specific case and now we are throwing a >> IllegalStateException [4]. Maybe in WildFly, to prevent existing >> libraries like Seam from breaking, we could just change this bit to >> throw NameNotFoundException instead of IllegalStateException (although I >> don't remember if the TCK tests for the exact exception type in this case). > > Should we catch the ISE somewhere in [5] and throw a > NameNotFoundException (with the ISE as the cause) instead of the ISE? I > wonder if we did that before in the AS5/AS6 naming code. A better question is whether we could throw a NameNotFoundException instead of a NamingException.

> > [5] > > at > org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:142) > at > org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:81) > at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:202) > at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:179) > at > org.jboss.as.naming.InitialContext$DefaultInitialContext.lookup(InitialContext.java:235) > at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:188) > at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:184) > at javax.naming.InitialContext.lookup(InitialContext.java:411) > [rt.jar:1.7.0_51] > at javax.naming.InitialContext.lookup(InitialContext.java:411) > [rt.jar:1.7.0_51] > at > org.jboss.seam.transaction.Transaction.getUserTransaction(Transaction.java:82)[jboss-seam.jar:2.2.2.Final] > >> >> >> [1] >> >> at org.jboss.seam.transaction.Transaction.instance(Transaction.java:39) [jboss-seam.jar:2.2.2.Final] >> at org.jboss.seam.persistence.ManagedPersistenceContext.joinTransaction(ManagedPersistenceContext.java:120) [jboss-seam.jar:2.2.2.Final] >> at org.jboss.seam.persistence.ManagedPersistenceContext.getEntityManager(ManagedPersistenceContext.java:112) [jboss-seam.jar:2.2.2.Final] >> >> >> [2] http://grepcode.com/file/repository.jboss.org/nexus/content/repositories/... >> >> [3] http://grepcode.com/file/repository.jboss.org/nexus/content/repositories/... >> >> [4] Caused by: java.lang.IllegalStateException: JBAS014237: Only session and message-driven beans with bean-managed transaction demarcation are allowed to access UserTransaction >> >> P.S: A big congratulations on the WildFly 8.0 Final release! :) Although haven't posted here so far, I've been lurking this list. Good luck with the next releases. > > Big congratulations to you also Jaikiran, you are always part of the > team! :) > > Thanks for helping with this issue! > > Scott > >> >> >> -Jaikiran >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

I think we should instead change the exception from NamingException to NameNotFoundException in WildFly, which is the exception type thrown by the Java EE 7 RI. I’ve tested such change and introduces no issues in the testsuite. And after such change Seam seems to work fine, at least the build/test issue is gone for the branch referenced in the issue. If nobody disagrees I will create an issue and submit the PR.

—E On 27 Feb 2014, at 13:32, Scott Marlow <smarlow(a)redhat.com <mailto:smarlow@redhat.com>> wrote: > On 02/26/2014 08:05 PM, Scott Marlow wrote: >> On 02/26/2014 11:04 AM, Scott Marlow wrote: >>> On 02/26/2014 02:02 AM, Jaikiran Pai wrote: >>>>>> Right the real question is what is Seam using the UT for. There is >>>> only one method on that is “safe” with CMT (getting the status), and >>>> that isn’t all that useful. >>>> >>>> Looking at that stacktrace [1] and the code in Seam [2], it appears >>>> that >>>> Seam wants to register a transaction synchronization if a >>>> transaction is >>>> active. Unfortunately, a lot of libraries (including Seam) use the >>>> UserTransaction API (UserTransaction.getStatus()) to check if a >>>> transaction is active. The right way to do it is using the >>>> TransactionSynchronizationRegistry which is available and portable (as >>>> mandated by spec) under the >>>> java:comp/TransactionSynchronizationRegistry >>>> JNDI name. The TransactionSynchronizationRegistry has a >>>> getTransactionStatus() method which can be used to check the >>>> transaction >>>> status in the current (thread) context >>>> http://docs.oracle.com/javaee/5/api/javax/transaction/TransactionSynchron.... >>>> Usage of this API is rarely explained and applications/libraries keep >>>> using UserTransaction instead. >>>> >>>> To answer the other question as to why this started showing up now and >>>> not in earlier versions, the code in Seam tries to deal with this exact >>>> situation by catching a specific (NameNotFoundException) while doing a >>>> UserTransaction lookup [3]. Notice that in that code [3], it doesn't >>>> deal with any other exception other than NameNotFoundException although >>>> that code does realize that using UserTransaction for what it's doing >>>> can run into problems (the comments there indicate something along >>>> those >>>> lines). So my guess is that, in previous version of AS, we used to >>>> throw >>>> a NameNotFoundException in this specific case and now we are throwing a >>>> IllegalStateException [4]. Maybe in WildFly, to prevent existing >>>> libraries like Seam from breaking, we could just change this bit to >>>> throw NameNotFoundException instead of IllegalStateException >>>> (although I >>>> don't remember if the TCK tests for the exact exception type in >>>> this case). >>> >>> Should we catch the ISE somewhere in [5] and throw a >>> NameNotFoundException (with the ISE as the cause) instead of the ISE? I >>> wonder if we did that before in the AS5/AS6 naming code. >> >> A better question is whether we could throw a NameNotFoundException >> instead of a NamingException. > > The above change would help Seam applications to work on WildFly 8.0.1. > > If we change Seam to catch a NamingException instead of > NameNotFoundException, the newer Seam release, would work with WildFly > 8.0.0 (should also work against earlier app server versions I think). > >> >>> >>> [5] >>> >>> at >>> org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:142) >>> at >>> org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:81) >>> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:202) >>> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:179) >>> at >>> org.jboss.as.naming.InitialContext$DefaultInitialContext.lookup(InitialContext.java:235) >>> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:188) >>> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:184) >>> at javax.naming.InitialContext.lookup(InitialContext.java:411) >>> [rt.jar:1.7.0_51] >>> at javax.naming.InitialContext.lookup(InitialContext.java:411) >>> [rt.jar:1.7.0_51] >>> at >>> org.jboss.seam.transaction.Transaction.getUserTransaction(Transaction.java:82)[jboss-seam.jar:2.2.2.Final] >>> >>>> >>>> >>>> [1] >>>> >>>> at >>>> org.jboss.seam.transaction.Transaction.instance(Transaction.java:39) [jboss-seam.jar:2.2.2.Final] >>>> at >>>> org.jboss.seam.persistence.ManagedPersistenceContext.joinTransaction(ManagedPersistenceContext.java:120) >>>> [jboss-seam.jar:2.2.2.Final] >>>> at >>>> org.jboss.seam.persistence.ManagedPersistenceContext.getEntityManager(ManagedPersistenceContext.java:112) >>>> [jboss-seam.jar:2.2.2.Final] >>>> >>>> >>>> [2] >>>> http://grepcode.com/file/repository.jboss.org/nexus/content/repositories/... >>>> >>>> [3] >>>> http://grepcode.com/file/repository.jboss.org/nexus/content/repositories/... >>>> >>>> [4] Caused by: java.lang.IllegalStateException: JBAS014237: Only >>>> session and message-driven beans with bean-managed transaction >>>> demarcation are allowed to access UserTransaction >>>> >>>> P.S: A big congratulations on the WildFly 8.0 Final release! :) >>>> Although haven't posted here so far, I've been lurking this list. >>>> Good luck with the next releases. >>> >>> Big congratulations to you also Jaikiran, you are always part of the >>> team! :) >>> >>> Thanks for helping with this issue! >>> >>> Scott >>> >>>> >>>> >>>> -Jaikiran >>>> >>>> _______________________________________________ >>>> wildfly-dev mailing list >>>> wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org> >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>> >>> >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org> >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org> >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/wildfly-dev

On Thu, Feb 27, 2014 at 2:32 PM, Scott Marlow <smarlow(a)redhat.com <mailto:smarlow@redhat.com>> wrote: The above change would help Seam applications to work on WildFly 8.0.1. What if we just fix seam itself? We already have few seam specific hacks in WildFly as it is. Let fix seam properly sounds like better idea.

-- tomaz