September 2016 - jbossts-issues - Jboss List Archives

[JBoss JIRA] (JBTM-2676) Allow TransactionalDriver connection.close() in afterCompletion

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2676?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-2676: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Allow TransactionalDriver connection.close() in afterCompletion > --------------------------------------------------------------- > > Key: JBTM-2676 > URL: https://issues.jboss.org/browse/JBTM-2676 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transactional Driver > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.next > > > Hibernate closes connections in afterCompletion. However, TransactionalDriver requires transaction to be in an active state in order to delist resource. > See new JTA and Hibernate standalone quickstart for reproduction. > {code} > 2016-06-15 02:21:07,413 [main] WARN com.arjuna.ats.jta - ARJUNA016029: SynchronizationImple.afterCompletion - failed for org.hibernate.resource.transaction.backend.jta.internal.synchronization.RegisteredSynchronization@e4b6f47 with exception > org.hibernate.exception.GenericJDBCException: Unable to release JDBC Connection > at org.hibernate.exception.internal.StandardSQLExceptionConverter.convert(StandardSQLExceptionConverter.java:47) > at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:111) > at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:97) > at org.hibernate.resource.jdbc.internal.LogicalConnectionManagedImpl.releaseConnection(LogicalConnectionManagedImpl.java:172) > at org.hibernate.resource.jdbc.internal.LogicalConnectionManagedImpl.afterTransaction(LogicalConnectionManagedImpl.java:135) > at org.hibernate.engine.jdbc.internal.JdbcCoordinatorImpl.afterTransaction(JdbcCoordinatorImpl.java:290) > at org.hibernate.engine.jdbc.internal.JdbcCoordinatorImpl.afterTransactionCompletion(JdbcCoordinatorImpl.java:490) > at org.hibernate.resource.transaction.backend.jta.internal.JtaTransactionCoordinatorImpl.afterCompletion(JtaTransactionCoordinatorImpl.java:345) > at org.hibernate.resource.transaction.backend.jta.internal.synchronization.SynchronizationCallbackCoordinatorNonTrackingImpl.doAfterCompletion(SynchronizationCallbackCoordinatorNonTrackingImpl.java:60) > at org.hibernate.resource.transaction.backend.jta.internal.synchronization.SynchronizationCallbackCoordinatorTrackingImpl.afterCompletion(SynchronizationCallbackCoordinatorTrackingImpl.java:72) > at org.hibernate.resource.transaction.backend.jta.internal.synchronization.RegisteredSynchronization.afterCompletion(RegisteredSynchronization.java:44) > at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.afterCompletion(SynchronizationImple.java:96) > at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.afterCompletion(TwoPhaseCoordinator.java:542) > at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.afterCompletion(TwoPhaseCoordinator.java:473) > at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.cancel(TwoPhaseCoordinator.java:127) > at com.arjuna.ats.arjuna.AtomicAction.abort(AtomicAction.java:186) > at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.rollbackAndDisassociate(TransactionImple.java:1282) > at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.rollback(BaseTransaction.java:143) > at org.jboss.narayana.quickstart.jta.TestCase.testRollback(TestCase.java:145) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47) > at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44) > at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) > at org.jboss.byteman.contrib.bmunit.BMUnitRunner$6.evaluate(BMUnitRunner.java:241) > at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) > at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229) > at org.jboss.byteman.contrib.bmunit.BMUnitRunner$1.evaluate(BMUnitRunner.java:75) > at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) > at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) > at org.junit.runners.ParentRunner.run(ParentRunner.java:309) > at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:367) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:274) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238) > at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161) > at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290) > at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121) > Caused by: java.sql.SQLException: ARJUNA017020: Transaction is not active on the thread! > at com.arjuna.ats.internal.jdbc.ConnectionImple.checkTransaction(ConnectionImple.java:1071) > at com.arjuna.ats.internal.jdbc.ConnectionImple.isClosed(ConnectionImple.java:417) > at org.hibernate.resource.jdbc.internal.LogicalConnectionManagedImpl.releaseConnection(LogicalConnectionManagedImpl.java:166) > ... 45 more > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2676) Allow TransactionalDriver connection.close() in afterCompletion

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2676?page=com.atlassian.jira.plugin.... ] Tom Jenkinson reassigned JBTM-2676: ----------------------------------- Assignee: Tom Jenkinson (was: Gytis Trikleris) > Allow TransactionalDriver connection.close() in afterCompletion > --------------------------------------------------------------- > > Key: JBTM-2676 > URL: https://issues.jboss.org/browse/JBTM-2676 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transactional Driver > Reporter: Gytis Trikleris > Assignee: Tom Jenkinson > Fix For: 5.next > > > Hibernate closes connections in afterCompletion. However, TransactionalDriver requires transaction to be in an active state in order to delist resource. > See new JTA and Hibernate standalone quickstart for reproduction. > {code} > 2016-06-15 02:21:07,413 [main] WARN com.arjuna.ats.jta - ARJUNA016029: SynchronizationImple.afterCompletion - failed for org.hibernate.resource.transaction.backend.jta.internal.synchronization.RegisteredSynchronization@e4b6f47 with exception > org.hibernate.exception.GenericJDBCException: Unable to release JDBC Connection > at org.hibernate.exception.internal.StandardSQLExceptionConverter.convert(StandardSQLExceptionConverter.java:47) > at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:111) > at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:97) > at org.hibernate.resource.jdbc.internal.LogicalConnectionManagedImpl.releaseConnection(LogicalConnectionManagedImpl.java:172) > at org.hibernate.resource.jdbc.internal.LogicalConnectionManagedImpl.afterTransaction(LogicalConnectionManagedImpl.java:135) > at org.hibernate.engine.jdbc.internal.JdbcCoordinatorImpl.afterTransaction(JdbcCoordinatorImpl.java:290) > at org.hibernate.engine.jdbc.internal.JdbcCoordinatorImpl.afterTransactionCompletion(JdbcCoordinatorImpl.java:490) > at org.hibernate.resource.transaction.backend.jta.internal.JtaTransactionCoordinatorImpl.afterCompletion(JtaTransactionCoordinatorImpl.java:345) > at org.hibernate.resource.transaction.backend.jta.internal.synchronization.SynchronizationCallbackCoordinatorNonTrackingImpl.doAfterCompletion(SynchronizationCallbackCoordinatorNonTrackingImpl.java:60) > at org.hibernate.resource.transaction.backend.jta.internal.synchronization.SynchronizationCallbackCoordinatorTrackingImpl.afterCompletion(SynchronizationCallbackCoordinatorTrackingImpl.java:72) > at org.hibernate.resource.transaction.backend.jta.internal.synchronization.RegisteredSynchronization.afterCompletion(RegisteredSynchronization.java:44) > at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.afterCompletion(SynchronizationImple.java:96) > at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.afterCompletion(TwoPhaseCoordinator.java:542) > at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.afterCompletion(TwoPhaseCoordinator.java:473) > at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.cancel(TwoPhaseCoordinator.java:127) > at com.arjuna.ats.arjuna.AtomicAction.abort(AtomicAction.java:186) > at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.rollbackAndDisassociate(TransactionImple.java:1282) > at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.rollback(BaseTransaction.java:143) > at org.jboss.narayana.quickstart.jta.TestCase.testRollback(TestCase.java:145) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47) > at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44) > at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) > at org.jboss.byteman.contrib.bmunit.BMUnitRunner$6.evaluate(BMUnitRunner.java:241) > at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) > at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229) > at org.jboss.byteman.contrib.bmunit.BMUnitRunner$1.evaluate(BMUnitRunner.java:75) > at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) > at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) > at org.junit.runners.ParentRunner.run(ParentRunner.java:309) > at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:367) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:274) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238) > at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161) > at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290) > at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121) > Caused by: java.sql.SQLException: ARJUNA017020: Transaction is not active on the thread! > at com.arjuna.ats.internal.jdbc.ConnectionImple.checkTransaction(ConnectionImple.java:1071) > at com.arjuna.ats.internal.jdbc.ConnectionImple.isClosed(ConnectionImple.java:417) > at org.hibernate.resource.jdbc.internal.LogicalConnectionManagedImpl.releaseConnection(LogicalConnectionManagedImpl.java:166) > ... 45 more > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2749) Add an SPI method to lookup imported transactions by Xid

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2749?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-2749: -------------------------------- Description: When EJB remoting sees an incoming transaction it needs to determine whether it is one that the TM already knows about and should just resume it or if it needs to start a new subordinate transaction for it on this node. (was: When EJB remoting sees an incomming transaction it needs to determine whether it is one that the TM already knows about and should just resume it or if it needs to start a new subordinate transaction for it on this node.) > Add an SPI method to lookup imported transactions by Xid > -------------------------------------------------------- > > Key: JBTM-2749 > URL: https://issues.jboss.org/browse/JBTM-2749 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: JCA, SPI > Affects Versions: 5.3.4.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Critical > Fix For: 5.next > > > When EJB remoting sees an incoming transaction it needs to determine whether it is one that the TM already knows about and should just resume it or if it needs to start a new subordinate transaction for it on this node. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2747) Modify the SimpleIsolatedServers example such that it does not need the "transport" to maintain its own map of transactions

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2747?page=com.atlassian.jira.plugin.... ] Tom Jenkinson reopened JBTM-2747: --------------------------------- > Modify the SimpleIsolatedServers example such that it does not need the "transport" to maintain its own map of transactions > --------------------------------------------------------------------------------------------------------------------------- > > Key: JBTM-2747 > URL: https://issues.jboss.org/browse/JBTM-2747 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Testing > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.next > > > The previous example relied upon the "transport" piece maintaining a list of root transactions it had seen. It is actually possible to use the existing list from the TransactionImple -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2747) Modify the SimpleIsolatedServers example such that it does not need the "transport" to maintain its own map of transactions

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2747?page=com.atlassian.jira.plugin.... ] Tom Jenkinson closed JBTM-2747. ------------------------------- Resolution: Duplicate Issue Subsumed within JBTM-2749 > Modify the SimpleIsolatedServers example such that it does not need the "transport" to maintain its own map of transactions > --------------------------------------------------------------------------------------------------------------------------- > > Key: JBTM-2747 > URL: https://issues.jboss.org/browse/JBTM-2747 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Testing > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.next > > > The previous example relied upon the "transport" piece maintaining a list of root transactions it had seen. It is actually possible to use the existing list from the TransactionImple -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2747) Modify the SimpleIsolatedServers example such that it does not need the "transport" to maintain its own map of transactions

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2747?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-2747: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Modify the SimpleIsolatedServers example such that it does not need the "transport" to maintain its own map of transactions > --------------------------------------------------------------------------------------------------------------------------- > > Key: JBTM-2747 > URL: https://issues.jboss.org/browse/JBTM-2747 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Testing > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.next > > > The previous example relied upon the "transport" piece maintaining a list of root transactions it had seen. It is actually possible to use the existing list from the TransactionImple -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2747) Modify the SimpleIsolatedServers example such that it does not need the "transport" to maintain its own map of transactions

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2747?page=com.atlassian.jira.plugin.... ] Tom Jenkinson reassigned JBTM-2747: ----------------------------------- Assignee: Tom Jenkinson > Modify the SimpleIsolatedServers example such that it does not need the "transport" to maintain its own map of transactions > --------------------------------------------------------------------------------------------------------------------------- > > Key: JBTM-2747 > URL: https://issues.jboss.org/browse/JBTM-2747 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Testing > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.next > > > The previous example relied upon the "transport" piece maintaining a list of root transactions it had seen. It is actually possible to use the existing list from the TransactionImple -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2480) Provide documentation of how to integrate with Karaf

by Amos Feng (JIRA)

[ https://issues.jboss.org/browse/JBTM-2480?page=com.atlassian.jira.plugin.... ] Issue was automatically transitioned when Amos Feng created pull request #40 in GitHub -------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Coding In Progress) > Provide documentation of how to integrate with Karaf > ---------------------------------------------------- > > Key: JBTM-2480 > URL: https://issues.jboss.org/browse/JBTM-2480 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: Documentation > Reporter: Tom Jenkinson > Assignee: Amos Feng > Priority: Minor > Fix For: 5.next > > > This should include recovery information -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2709) ObjectStoreBrowser cannot cope with JDBC store on Windows

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBTM-2709?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on JBTM-2709: ----------------------------------------------- Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1356589|https://bugzilla.redhat.com/show_bug.cgi?id=1356589] from MODIFIED to ON_QA > ObjectStoreBrowser cannot cope with JDBC store on Windows > --------------------------------------------------------- > > Key: JBTM-2709 > URL: https://issues.jboss.org/browse/JBTM-2709 > Project: JBoss Transaction Manager > Issue Type: Bug > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 4.17.35, 5.3.4.Final > > > While testing backport of JBTM-2614 I came across the ObjStoreBrowser test. This was failing on Windows. On looking into it I saw it was because the Browser map swaps the "/" in the type name to the system file separator path. This is likely because of the file system store. I have a fix that puts the entry in both ways but it will likely need some more work so providing as an example. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2708) Test does not close FileInputStream

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBTM-2708?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on JBTM-2708: ----------------------------------------------- Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1356589|https://bugzilla.redhat.com/show_bug.cgi?id=1356589] from MODIFIED to ON_QA > Test does not close FileInputStream > ----------------------------------- > > Key: JBTM-2708 > URL: https://issues.jboss.org/browse/JBTM-2708 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Testing > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 4.17.35, 5.3.4.Final > > > {code} > public XARRTestResource(String xarrHelper, File file) throws IOException { > this.xarrHelper = xarrHelper; > this.file = file; > DataInputStream fis = new DataInputStream(new FileInputStream(file)); > final int formatId = fis.readInt(); > final int gtrid_length = fis.readInt(); > final byte[] gtrid = new byte[gtrid_length]; > fis.read(gtrid, 0, gtrid_length); > final int bqual_length = fis.readInt(); > final byte[] bqual = new byte[bqual_length]; > fis.read(bqual, 0, bqual_length); > xids.put(file, new Xid() { > @Override > public byte[] getGlobalTransactionId() { > return gtrid; > } > @Override > public int getFormatId() { > return formatId; > } > @Override > public byte[] getBranchQualifier() { > return bqual; > } > }); > fis.close(); > } > {code} > Spotted while working on JBTM-2614 backport -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 7 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

jbossts-issues September 2016