August 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JBJCA-1392) Need to add checkTransaction handling for unwrap connection

by Ivo Studensky (Jira)

[ https://issues.jboss.org/browse/JBJCA-1392?page=com.atlassian.jira.plugin... ] Ivo Studensky commented on JBJCA-1392: -------------------------------------- This is going to 1.4.18. > Need to add checkTransaction handling for unwrap connection > ----------------------------------------------------------- > > Key: JBJCA-1392 > URL: https://issues.jboss.org/browse/JBJCA-1392 > Project: IronJacamar > Issue Type: Bug > Components: JDBC > Reporter: Ivo Studensky > Assignee: Ivo Studensky > Priority: Major > Labels: downstream_dependency > > _connection.setAutoCommit_ cannot affect _unwrap_ native connection. The following _mc.getAutoCommit_ result is true. > {code} > c = dataSource.getConnection(); > c.setAutoCommit(false); > if (c.isWrapperFor(oracle.jdbc.OracleConnection.class)) { > mc = c.unwrap(oracle.jdbc.OracleConnection.class); > } > System.out.println("[JDBC 4 Wrapper] autoCommit : " + mc.getAutoCommit()); > {code} > However, the following _getUnderlyingConnection_ native connection result is false. > {code} > c = dataSource.getConnection(); > c.setAutoCommit(false); > WrappedConnection wc = (WrappedConnection)c; > oracle.jdbc.OracleConnection mc = (oracle.jdbc.OracleConnection)wc.getUnderlyingConnection(); > System.out.println("[org.jboss.ironjacamar.jdbcadapters WrappedConnection] autoCommit : " + mc.getAutoCommit()); > {code} > The _getUnderlyingConnection_ method call _BaseWrapperManagedConnection.checkTransaction_ process, but there is no similar process in _unwrap_ method. > {code:title=org/jboss/jca/adapters/jdbc/BaseWrapperManagedConnection.java|borderStyle=solid} > void checkTransaction() throws SQLException > { > synchronized (stateLock) > { > if (inManagedTransaction) > return; > // Check autocommit > if (jdbcAutoCommit != underlyingAutoCommit) > { > con.setAutoCommit(jdbcAutoCommit); > underlyingAutoCommit = jdbcAutoCommit; > } > } > {code} -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1392) Need to add checkTransaction handling for unwrap connection

by Ivo Studensky (Jira)

[ https://issues.jboss.org/browse/JBJCA-1392?page=com.atlassian.jira.plugin... ] Ivo Studensky resolved JBJCA-1392. ---------------------------------- Resolution: Done > Need to add checkTransaction handling for unwrap connection > ----------------------------------------------------------- > > Key: JBJCA-1392 > URL: https://issues.jboss.org/browse/JBJCA-1392 > Project: IronJacamar > Issue Type: Bug > Components: JDBC > Reporter: Ivo Studensky > Assignee: Ivo Studensky > Priority: Major > Labels: downstream_dependency > > _connection.setAutoCommit_ cannot affect _unwrap_ native connection. The following _mc.getAutoCommit_ result is true. > {code} > c = dataSource.getConnection(); > c.setAutoCommit(false); > if (c.isWrapperFor(oracle.jdbc.OracleConnection.class)) { > mc = c.unwrap(oracle.jdbc.OracleConnection.class); > } > System.out.println("[JDBC 4 Wrapper] autoCommit : " + mc.getAutoCommit()); > {code} > However, the following _getUnderlyingConnection_ native connection result is false. > {code} > c = dataSource.getConnection(); > c.setAutoCommit(false); > WrappedConnection wc = (WrappedConnection)c; > oracle.jdbc.OracleConnection mc = (oracle.jdbc.OracleConnection)wc.getUnderlyingConnection(); > System.out.println("[org.jboss.ironjacamar.jdbcadapters WrappedConnection] autoCommit : " + mc.getAutoCommit()); > {code} > The _getUnderlyingConnection_ method call _BaseWrapperManagedConnection.checkTransaction_ process, but there is no similar process in _unwrap_ method. > {code:title=org/jboss/jca/adapters/jdbc/BaseWrapperManagedConnection.java|borderStyle=solid} > void checkTransaction() throws SQLException > { > synchronized (stateLock) > { > if (inManagedTransaction) > return; > // Check autocommit > if (jdbcAutoCommit != underlyingAutoCommit) > { > con.setAutoCommit(jdbcAutoCommit); > underlyingAutoCommit = jdbcAutoCommit; > } > } > {code} -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1390) BlockingFailureCount not tracking IJ000655 errors in SemaphoreConcurrentLinkedDequeManagedConnectionPool

by Ivo Studensky (Jira)

[ https://issues.jboss.org/browse/JBJCA-1390?page=com.atlassian.jira.plugin... ] Ivo Studensky commented on JBJCA-1390: -------------------------------------- Fixed in 1.4.17.Final. > BlockingFailureCount not tracking IJ000655 errors in SemaphoreConcurrentLinkedDequeManagedConnectionPool > -------------------------------------------------------------------------------------------------------- > > Key: JBJCA-1390 > URL: https://issues.jboss.org/browse/JBJCA-1390 > Project: IronJacamar > Issue Type: Bug > Environment: JBoss Enterprise Application Platform 7 > Reporter: TJ Cowhey > Assignee: Ivo Studensky > Priority: Major > > The timeout counter increment performed in the [array list version of the pool|https://github.com/ironjacamar/ironjacamar/blob/ironjacamar-1.4.15.F...] is omitted from the [linked dequeue based version|https://github.com/ironjacamar/ironjacamar/blob/ironjacamar-1.4.1...]. > This results in BlockingFailureCount not tracking IJ000655 errors. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4626) Expose ExternalModuleService as WidlFly capability

by Yeray Borges (Jira)

Yeray Borges created WFCORE-4626: ------------------------------------ Summary: Expose ExternalModuleService as WidlFly capability Key: WFCORE-4626 URL: https://issues.jboss.org/browse/WFCORE-4626 Project: WildFly Core Issue Type: Task Reporter: Yeray Borges Assignee: Yeray Borges ExternalModuleService is used to create the ExternalModuleSpecService which exposes the ModuleDefinition for any external module dependency. Currently, ExternalModuleService is used via DUPs to scan the deployment and add external modules. We should expose this service via a Capability so it can be easily accessed via not only by the DUPs, but also other services that could require configure external modules. This capability should be registered in ServerService, see for example PathManager. It should be something that ExternalModuleService implements, the goal is not to expose the start/stop/getValue methods via the capability. See [this|https://github.com/wildfly/wildfly-core/pull/3890#issuecomment-52180...] as reference comment. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1390) BlockingFailureCount not tracking IJ000655 errors in SemaphoreConcurrentLinkedDequeManagedConnectionPool

by Ivo Studensky (Jira)

[ https://issues.jboss.org/browse/JBJCA-1390?page=com.atlassian.jira.plugin... ] Ivo Studensky resolved JBJCA-1390. ---------------------------------- Resolution: Done > BlockingFailureCount not tracking IJ000655 errors in SemaphoreConcurrentLinkedDequeManagedConnectionPool > -------------------------------------------------------------------------------------------------------- > > Key: JBJCA-1390 > URL: https://issues.jboss.org/browse/JBJCA-1390 > Project: IronJacamar > Issue Type: Bug > Environment: JBoss Enterprise Application Platform 7 > Reporter: TJ Cowhey > Assignee: Ivo Studensky > Priority: Major > > The timeout counter increment performed in the [array list version of the pool|https://github.com/ironjacamar/ironjacamar/blob/ironjacamar-1.4.15.F...] is omitted from the [linked dequeue based version|https://github.com/ironjacamar/ironjacamar/blob/ironjacamar-1.4.1...]. > This results in BlockingFailureCount not tracking IJ000655 errors. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4621) Create a service to install a dynamic 'wildflyee.api' module

by Yeray Borges (Jira)

[ https://issues.jboss.org/browse/WFCORE-4621?page=com.atlassian.jira.plugi... ] Yeray Borges reassigned WFCORE-4621: ------------------------------------ Assignee: Yeray Borges > Create a service to install a dynamic 'wildflyee.api' module > ------------------------------------------------------------ > > Key: WFCORE-4621 > URL: https://issues.jboss.org/browse/WFCORE-4621 > Project: WildFly Core > Issue Type: Enhancement > Components: Server > Reporter: Brian Stansberry > Assignee: Yeray Borges > Priority: Minor > > Follow up on WFCORE-4612 by removing the list of detailed optional dependencies added there and instead have a service that installs a dynamic 'wildflyee.api' module that optional depends on all those. Then ExternalModuleDependencySpecService would add a dependency on that 'wildflyee.api' module. > Then the next step is the javaee.api module in full WildFly would become an alias to wildflyee.api. > The benefit to this is the content set for this 'ee.api' convenience module > a) gets set in one place (vs the two places that WFCORE-4612 introduces) > b) is defined in core, which makes some sense as core utilizes the module for the ExternalModuleDependencySpecService use case. > c) External uses of 'javaee.api' can benefit from the WFCORE-4612 improvement; i.e. if they have slimmed the server such that some APIs are not present, javaee.api can still be used. They just can't be using any APIs that they slimmed away. > A downside is maintaining an 'ee.api' modules is not a great fit for core. > The reason to use a dynamic module is a static module would be visible to Galleon, and with the standard passive+[1] provisioning scheme we use that would lead to Galleon provisioning the packages for all the EE APIs, regardless of whether the server config required them. > [1] https://docs.wildfly.org/galleon/#_effective_package_set > This is somewhat me brainstorming, so needs harder thought. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10554) OpenSAML 3.3.0 complains for missing class from "metrics-core"

by Radoslav Ivanov (Jira)

[ https://issues.jboss.org/browse/WFLY-10554?page=com.atlassian.jira.plugin... ] Radoslav Ivanov edited comment on WFLY-10554 at 8/26/19 2:27 AM: ----------------------------------------------------------------- how a fix in a new "own opensmal module " will solve the problem in the original opensaml module? was (Author: rady66): how a fix in a new "own opensmal module " will solve the problem in the existing opensaml module? > OpenSAML 3.3.0 complains for missing class from "metrics-core" > -------------------------------------------------------------- > > Key: WFLY-10554 > URL: https://issues.jboss.org/browse/WFLY-10554 > Project: WildFly > Issue Type: Enhancement > Components: Web Services > Affects Versions: 13.0.0.Final > Reporter: Radoslav Ivanov > Assignee: Jim Ma > Priority: Major > Attachments: screenshot-1.png > > > Module OpenSAML 3.3.0 requires depedency to module "io.dropwizard.metrics:metrics-core" but it does not present. As a result ClassNotFoundException is thrown. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10554) OpenSAML 3.3.0 complains for missing class from "metrics-core"

by Radoslav Ivanov (Jira)

[ https://issues.jboss.org/browse/WFLY-10554?page=com.atlassian.jira.plugin... ] Radoslav Ivanov commented on WFLY-10554: ---------------------------------------- how a fix in a new "own opensmal module " will solve the problem in the existing opensaml module? > OpenSAML 3.3.0 complains for missing class from "metrics-core" > -------------------------------------------------------------- > > Key: WFLY-10554 > URL: https://issues.jboss.org/browse/WFLY-10554 > Project: WildFly > Issue Type: Enhancement > Components: Web Services > Affects Versions: 13.0.0.Final > Reporter: Radoslav Ivanov > Assignee: Jim Ma > Priority: Major > Attachments: screenshot-1.png > > > Module OpenSAML 3.3.0 requires depedency to module "io.dropwizard.metrics:metrics-core" but it does not present. As a result ClassNotFoundException is thrown. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12430) Inputs to the standalone-gossip-[full-ha].xml examples use a TCPGOSSIP config that will persist differently

by Brian Stansberry (Jira)

[ https://issues.jboss.org/browse/WFLY-12430?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFLY-12430: ------------------------------------ Summary: Inputs to the standalone-gossip-[full-ha].xml examples use a TCPGOSSIP config that will persist differently (was: The docs/examples/configs/standalone-gossip-[full-ha].xml examples use a TCPGOSSIP config that will persist differently) > Inputs to the standalone-gossip-[full-ha].xml examples use a TCPGOSSIP config that will persist differently > ----------------------------------------------------------------------------------------------------------- > > Key: WFLY-12430 > URL: https://issues.jboss.org/browse/WFLY-12430 > Project: WildFly > Issue Type: Bug > Components: Clustering > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Priority: Minor > > Minor thing I want to sort to make legacy feature-pack-driven builds as consistent as possible with galleon-driven ones.... > The docs/examples/configs/standalone-gossip-[full-ha].xml examples configure a TCPGOSSIP protocol but without the required outbound-socket-bindings attribute. Compatibility code in the subsystem handles this by converting the address value to 'org.jgroups.protocols.TCPGOSSIP', which in turn has a different resource registration and Galleon feature spec. Upshot is when the resource is persisted the xml will read org.jgroups.protocols.TCPGOSSIP. To clarify this, rather than relying on magic compatibility code the inputs for generating the configs should explicitly use 'org.jgroups.protocols.TCPGOSSIP'. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12430) The docs/examples/configs/standalone-gossip-[full-ha].xml examples use a TCPGOSSIP config that will persist differently

by Brian Stansberry (Jira)

Brian Stansberry created WFLY-12430: --------------------------------------- Summary: The docs/examples/configs/standalone-gossip-[full-ha].xml examples use a TCPGOSSIP config that will persist differently Key: WFLY-12430 URL: https://issues.jboss.org/browse/WFLY-12430 Project: WildFly Issue Type: Bug Components: Clustering Reporter: Brian Stansberry Assignee: Brian Stansberry Minor thing I want to sort to make legacy feature-pack-driven builds as consistent as possible with galleon-driven ones.... The docs/examples/configs/standalone-gossip-[full-ha].xml examples configure a TCPGOSSIP protocol but without the required outbound-socket-bindings attribute. Compatibility code in the subsystem handles this by converting the address value to 'org.jgroups.protocols.TCPGOSSIP', which in turn has a different resource registration and Galleon feature spec. Upshot is when the resource is persisted the xml will read org.jgroups.protocols.TCPGOSSIP. To clarify this, rather than relying on magic compatibility code the inputs for generating the configs should explicitly use 'org.jgroups.protocols.TCPGOSSIP'. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira August 2019