October 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JBJCA-1357) TransactionSynchronizer registered as interposed synchronization leads to ordering issue when using hibernate

by Alexander Pinske (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1357?page=com.atlassian.jira.plugin... ] Alexander Pinske commented on JBJCA-1357: ----------------------------------------- Thank you for the quick answer and the helpful pointers! I understand the workaround in wildfly. We are currently looking into using JCA&JTA outside of an application server. My understanding was that the "new" TSR method (interposed synch) was for integrating other components (e.g. JPA), whereas the method on Transaction ("normal" synch) was for platform components (e.g. JCA). Why is the JCA implementation not using Transaction.registerSynch? Wouldn't that solve the problem? Ironjacamar has the fallback to this method already anyways, when a TSR is not present. To which components are the non-interposed synchronisations targeted? Appreciate your answers. Thanks for your time on this! > TransactionSynchronizer registered as interposed synchronization leads to ordering issue when using hibernate > ------------------------------------------------------------------------------------------------------------- > > Key: JBJCA-1357 > URL: https://issues.jboss.org/browse/JBJCA-1357 > Project: IronJacamar > Issue Type: Bug > Affects Versions: 1.4.5 > Reporter: Alexander Pinske > Attachments: jca-hibernate.zip > > > The TransactionSynchronizer (to cleanup connections) is registered as an interposed synchronization. Hibernate also registers its synchronization (to close the underlying JDBC connection handle) as interposed. > This leads to undefined ordering, which in my case runs the JCA Synch before the Hibernate Synch. This leads to a log of IJ000316 and the connection being killed. > I think that platform specific cleanup should be executed after all application level synchronization have run, therefore it should be registered with the TM (not the TSR). > http://www.ironjacamar.org/doc/roadto12/txtracking.html describes this as an application misbehaviour. But I don't think the application has any means of controlling the ordering in this scenario. > If I do not provide a TSR to the TransactionIntegrationImpl (which would lead to the registration of the TransactionSynchronizer via TransactionManager - thus non-interposed) has the problem that AbstractPool uses the TSR to check if a transaction is actually in progress. > I don't know if my rationale is correct. Could you please comment on the issue? > Thanks! -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ELY-1426) DigestSasl obtains URP digest for authzid instead of username

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-1426?page=com.atlassian.jira.plugin.s... ] Jan Kalina commented on ELY-1426: --------------------------------- This will be fixes as part of ELY-991 digest callback handling rework. > DigestSasl obtains URP digest for authzid instead of username > ------------------------------------------------------------- > > Key: ELY-1426 > URL: https://issues.jboss.org/browse/ELY-1426 > Project: WildFly Elytron > Issue Type: Bug > Components: SASL > Affects Versions: 1.2.0.Beta8 > Reporter: Jan Kalina > Assignee: Jan Kalina > > In following patch was introduced bug: > https://github.com/wildfly-security/wildfly-elytron/pull/851/files#diff-d... > DigestSaslClient requests URP digest for default userName (authzid), not for authentication name (from NameCallback). > Code is ok for server side, but not for client side, where credential callback params should require name obtained by NameCallback. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ELY-1426) DigestSasl obtains URP digest for authzid instead of username

by Jan Kalina (JIRA)

Jan Kalina created ELY-1426: ------------------------------- Summary: DigestSasl obtains URP digest for authzid instead of username Key: ELY-1426 URL: https://issues.jboss.org/browse/ELY-1426 Project: WildFly Elytron Issue Type: Bug Components: SASL Affects Versions: 1.2.0.Beta8 Reporter: Jan Kalina Assignee: Jan Kalina In following patch was introduced bug: https://github.com/wildfly-security/wildfly-elytron/pull/851/files#diff-d... DigestSaslClient requests URP digest for default userName (authzid), not for authentication name (from NameCallback). Code is ok for server side, but not for client side, where credential callback params should require name obtained by NameCallback. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3386) Add configuration required to support JASPIC to the Elytron subsyste,

by Darran Lofthouse (JIRA)

Darran Lofthouse created WFCORE-3386: ---------------------------------------- Summary: Add configuration required to support JASPIC to the Elytron subsyste, Key: WFCORE-3386 URL: https://issues.jboss.org/browse/WFCORE-3386 Project: WildFly Core Issue Type: Feature Request Components: Security Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 4.0.0.Alpha1 -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ELY-1425) Add support for JASPIC / JSR-196

by Darran Lofthouse (JIRA)

Darran Lofthouse created ELY-1425: ------------------------------------- Summary: Add support for JASPIC / JSR-196 Key: ELY-1425 URL: https://issues.jboss.org/browse/ELY-1425 Project: WildFly Elytron Issue Type: Feature Request Components: HTTP Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 1.2.0.Beta9 This is an overall tracking task for changes required to WildFly Elytron to support JASPIC. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JASSIST-270) Error loading class only available to bootstrap loader with jboss7+ and javassist 3.22

by Shigeru Chiba (JIRA)

[ https://issues.jboss.org/browse/JASSIST-270?page=com.atlassian.jira.plugi... ] Shigeru Chiba commented on JASSIST-270: --------------------------------------- OK, I'll also update appendSystemPath() for Tomcat 9 / JDK 8. > Error loading class only available to bootstrap loader with jboss7+ and javassist 3.22 > -------------------------------------------------------------------------------------- > > Key: JASSIST-270 > URL: https://issues.jboss.org/browse/JASSIST-270 > Project: Javassist > Issue Type: Bug > Affects Versions: 3.22.0-GA > Environment: oracle JDK 1.8.0_40 > jboss 7, wildfly 8, wildfly 9, wildfly 10 > Reporter: Patson Luk > Assignee: Shigeru Chiba > > h3. Description > After upgrading our agent from javassist 3.21 to 3.22, we started observing class loading problem during injection of code > {{CannotCompileException: [source error] no such class: test.TestClass}} > h3. Setup > # Our agent inject a piece of code with reference to class `test.TestClass` > # `test.TestClass` is provided by adding Boot-Class-Path entry in MANIFEST.MF, for example : Boot-Class-Path: ./ (with relative path, which we put the class binary `test.TestClass.class` within "test" folder relative to the agent JAR) > # When obtaining the classpool, we always call `ClassPool.appendSystemPath()` such that `test.TestClass` available to bootstrap classloader will be loaded properly in all situations > # Start Jboss 7 or any wildfly with `javaagent` that triggers the code injection, we will then observe the exception mentioned. Such a problem does not exist in version 3.21 > h3. Cause > With some drill down into the source code, it appears that this [change|https://github.com/jboss-javassist/javassist/commit/778c463e5aa179...] in 3.22 combined with how jboss loads classes with its module class loader trigger the problem > The steps are: > # JBoss tries to load a class that triggers transformation, the javasist classpool used to load the class has a reference to the "module classloader" provided by JBoss + our `ClassPool.appendSystemPath()` call, which in 3.22, appends a LoaderClassPath of the thread's Context classloader, which is also a jboss module classloader (Module "org.jboss.as.standalone:main") > # The injected code references class `test.TestClass` > # `ClassPool.find` tries to use all the `ClassPath` to load `test.TestClass`, which they are both JBoss's "module classloader". Unfortunately, neither of those loaders can load the `test.TestClass` which is available to bootstrap loader > # Throws the CannotCompileException exception as the referenced class in injected code cannot be loaded > Take note that this worked in 3.21 as `appendSystemPath` appends the `ClassClassPath` intead of a `LoaderClassPath` with the context class loader. > As a workaround, we added > {code:java} > if (ClassLoader.getSystemClassLoader() != null) { > classPool.appendClassPath(new LoaderClassPath(ClassLoader.getSystemClassLoader())); > } else { > classPool.appendClassPath(new ClassClassPath(Object.class)); > } > {code} > on top of `classPool.appendSystemPath()` and it no longer complains about class loading problem for jdk 8 and jdk 9. > -However, wildfly 10 + jdk 9 actually prints a warning `WARNING: An illegal reflective access operation has occurred`, but this probably is some other issues to be sorted out...- Not an issue of javaagent/javassist, as this same warning is shown even w/o agent > Sorry about the long post. I honestly do not know whether this should be considered as a bug as all. As the name `appendSystemPath` somehow suggests to me that a class available to bootstrap classloader should be taken care of (is it considered part of the "system path"?), but i might be totally mistaken... > Many thanks for your attention! -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBEE-182) Add support to JASPI for integration with WildFly Elytron

by Darran Lofthouse (JIRA)

Darran Lofthouse created JBEE-182: ------------------------------------- Summary: Add support to JASPI for integration with WildFly Elytron Key: JBEE-182 URL: https://issues.jboss.org/browse/JBEE-182 Project: JBoss JavaEE Spec APIs Issue Type: Feature Request Components: jboss-jaspi-api Reporter: Darran Lofthouse Assignee: Darran Lofthouse -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9092) Access jndi datasource outside eap container?

by Brad Maxwell (JIRA)

[ https://issues.jboss.org/browse/WFLY-9092?page=com.atlassian.jira.plugin.... ] Brad Maxwell commented on WFLY-9092: ------------------------------------ Prior to JBoss AS 7 / Wildfly it was possible, but never recommended: - It is not a good idea to have an unreliable client directly controlling the resources of your server (i.e. JDBC connections). - If the client loses network connectivity or crashes before it is able to close the connection then the connection will not be closed until the server is shutdown (i.e. it will be leaked). - It is very slow. All database operations are proxied through an MBean. - Transaction propagation is not supported. It recommend using an EJB as an intermediary in accessing the data source, and defining a proper contract for how the data should be accessed and operated on. > Access jndi datasource outside eap container? > --------------------------------------------- > > Key: WFLY-9092 > URL: https://issues.jboss.org/browse/WFLY-9092 > Project: WildFly > Issue Type: Feature Request > Components: EE, JCA > Reporter: harit kumar > > Access jndi datasource outside eap container? -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ELY-1424) Add the ability to generate self-signed X.509 certificates

by Farah Juma (JIRA)

Farah Juma created ELY-1424: ------------------------------- Summary: Add the ability to generate self-signed X.509 certificates Key: ELY-1424 URL: https://issues.jboss.org/browse/ELY-1424 Project: WildFly Elytron Issue Type: Feature Request Components: X.500 Reporter: Farah Juma Assignee: Farah Juma Add the ability to generate a key pair and wrap the resulting public key into a self-signed X.509 certificate. The self-signed X.509 certificate can then be used to generate a PKCS #10 certificate signing request. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9489) Remove need for application-security-domain mapping

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-9489?page=com.atlassian.jira.plugin.... ] Darran Lofthouse updated WFLY-9489: ----------------------------------- Forum Reference: https://developer.jboss.org/wiki/AnalysisDesignRelaxNeedForsubsystemunder... > Remove need for application-security-domain mapping > --------------------------------------------------- > > Key: WFLY-9489 > URL: https://issues.jboss.org/browse/WFLY-9489 > Project: WildFly > Issue Type: Feature Request > Components: Web (Undertow) > Affects Versions: 11.0.0.Final > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 12.0.0.Alpha1 > > > The application-security-domain resource was added to map from the security domain specified within the deployment to a WildFly Elytron authentication factory with some additional related configuration. > It should be possible to define all of this within a deployment descriptor. > Additionally the subsystem includes a default-security-domain attribute, it should likely contain some default Elytron configuration options. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 8 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 October 2017