[JBoss JIRA] (WFLY-6705) Namespaces / schema versions of module.xml are out of sync
by Rostislav Svoboda (JIRA)
Rostislav Svoboda created WFLY-6705:
---------------------------------------
Summary: Namespaces / schema versions of module.xml are out of sync
Key: WFLY-6705
URL: https://issues.jboss.org/browse/WFLY-6705
Project: WildFly
Issue Type: Bug
Components: Server
Reporter: Rostislav Svoboda
Assignee: Jason Greene
Namespaces / schema versions of module.xml are out of sync:
{code}
grep "urn:jboss:module" jboss-eap-7.0/modules/ -R | cut -d: -f 5 | cut -d\" -f1 | sort | uniq -c
5 1.1
352 1.3
1 1.5
{code}
1.5 is used by:
./modules/system/layers/base/javax/transaction/api/main/module.xml
1.1 is used by:
./modules/system/layers/base/org/jboss/as/domain-http-error-context/eap/module.xml
./modules/system/layers/base/org/jboss/as/product/eap/module.xml
./modules/system/layers/base/org/hibernate/search/backend-jgroups/main/module.xml
./modules/system/layers/base/org/hibernate/search/serialization-avro/main/module.xml
./modules/system/layers/base/org/hibernate/search/backend-jms/main/module.xml
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-6705) Namespaces / schema versions of module.xml are out of sync
by Rostislav Svoboda (JIRA)
[ https://issues.jboss.org/browse/WFLY-6705?page=com.atlassian.jira.plugin.... ]
Rostislav Svoboda reassigned WFLY-6705:
---------------------------------------
Assignee: Tomaz Cerar (was: Jason Greene)
> Namespaces / schema versions of module.xml are out of sync
> ----------------------------------------------------------
>
> Key: WFLY-6705
> URL: https://issues.jboss.org/browse/WFLY-6705
> Project: WildFly
> Issue Type: Bug
> Components: Server
> Reporter: Rostislav Svoboda
> Assignee: Tomaz Cerar
>
> Namespaces / schema versions of module.xml are out of sync:
> {code}
> grep "urn:jboss:module" jboss-eap-7.0/modules/ -R | cut -d: -f 5 | cut -d\" -f1 | sort | uniq -c
> 5 1.1
> 352 1.3
> 1 1.5
> {code}
> 1.5 is used by:
> ./modules/system/layers/base/javax/transaction/api/main/module.xml
> 1.1 is used by:
> ./modules/system/layers/base/org/jboss/as/domain-http-error-context/eap/module.xml
> ./modules/system/layers/base/org/jboss/as/product/eap/module.xml
> ./modules/system/layers/base/org/hibernate/search/backend-jgroups/main/module.xml
> ./modules/system/layers/base/org/hibernate/search/serialization-avro/main/module.xml
> ./modules/system/layers/base/org/hibernate/search/backend-jms/main/module.xml
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (JBJCA-1321) Statement.cancel() is not invoked until the statement is completed
by Lin Gao (JIRA)
[ https://issues.jboss.org/browse/JBJCA-1321?page=com.atlassian.jira.plugin... ]
Lin Gao resolved JBJCA-1321.
----------------------------
Resolution: Done
> Statement.cancel() is not invoked until the statement is completed
> ------------------------------------------------------------------
>
> Key: JBJCA-1321
> URL: https://issues.jboss.org/browse/JBJCA-1321
> Project: IronJacamar
> Issue Type: Bug
> Components: JDBC
> Affects Versions: WildFly/IronJacamar 1.3.4.Final, 1.2.7.Final
> Reporter: lorenzo benvenuti
> Assignee: Lin Gao
> Priority: Critical
> Fix For: WildFly/IronJacamar 1.3.5.Final, 1.2.8.Final
>
>
> Hi,
> in our application we are using the {{Statement.cancel()}} method to stop long-running queries; in Wildfly 9.0.2 this is not working because the {{cancel()}} method is synchronized using a lock which is not released until the query is executed. In {{WrappedStatement}}:
> {code:java}
> public void cancel() throws SQLException
> {
> if (doLocking)
> lock();
> try
> {
> /* ... */
> {code}
> It seems this behaviour has changed from version 1.2.5.Final of ironjacamar-jdbc; in version 1.2.4.Final {{WrappedStatement.cancel}} doesn't try to obtain the lock.
> Probably I'm missing something, but to me it's strange that in order to cancel a statement you have to wait for its completion.
> Thank you,
> lorenzo
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (JBJCA-1321) Statement.cancel() is not invoked until the statement is completed
by Lin Gao (JIRA)
[ https://issues.jboss.org/browse/JBJCA-1321?page=com.atlassian.jira.plugin... ]
Lin Gao updated JBJCA-1321:
---------------------------
Git Pull Request: https://github.com/ironjacamar/ironjacamar/pull/526, https://github.com/ironjacamar/ironjacamar/pull/527
> Statement.cancel() is not invoked until the statement is completed
> ------------------------------------------------------------------
>
> Key: JBJCA-1321
> URL: https://issues.jboss.org/browse/JBJCA-1321
> Project: IronJacamar
> Issue Type: Bug
> Components: JDBC
> Affects Versions: WildFly/IronJacamar 1.3.4.Final, 1.2.7.Final
> Reporter: lorenzo benvenuti
> Assignee: Lin Gao
> Priority: Critical
> Fix For: WildFly/IronJacamar 1.3.5.Final, 1.2.8.Final
>
>
> Hi,
> in our application we are using the {{Statement.cancel()}} method to stop long-running queries; in Wildfly 9.0.2 this is not working because the {{cancel()}} method is synchronized using a lock which is not released until the query is executed. In {{WrappedStatement}}:
> {code:java}
> public void cancel() throws SQLException
> {
> if (doLocking)
> lock();
> try
> {
> /* ... */
> {code}
> It seems this behaviour has changed from version 1.2.5.Final of ironjacamar-jdbc; in version 1.2.4.Final {{WrappedStatement.cancel}} doesn't try to obtain the lock.
> Probably I'm missing something, but to me it's strange that in order to cancel a statement you have to wait for its completion.
> Thank you,
> lorenzo
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months