October 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JBJCA-1394) getConnection is leaking application classloader

by Scott Marlow (Jira)

Scott Marlow created JBJCA-1394: ----------------------------------- Summary: getConnection is leaking application classloader Key: JBJCA-1394 URL: https://issues.jboss.org/browse/JBJCA-1394 Project: IronJacamar Issue Type: Bug Reporter: Scott Marlow Assignee: Scott Marlow Affected version=1.4.18.Final see [https://issues.jboss.org/browse/WFLY-12676] for more information, which is a leak that I saw while investigating [https://issues.jboss.org/browse/WFLY-12671]. [https://github.com/ironjacamar/ironjacamar/blob/1.4/adapters/src/main/jav...] saves the application classloader but never clears it (in the getConnection call). -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4625) Scenario Test: UX for background data error reporting

by Elizabeth Clayton (Jira)

[ https://issues.jboss.org/browse/DROOLS-4625?page=com.atlassian.jira.plugi... ] Elizabeth Clayton edited comment on DROOLS-4625 at 10/16/19 2:52 PM: --------------------------------------------------------------------- [~danielezonca] [~ederign] so this might be a bit more involved than I initially thought, and I'm not sure I fully follow even now. ;) Need to re-read and will get back. was (Author: uxdlc): [~danielezonca] [~ederign] so this might be a bit more involved than I initially thought, and I'm not sure I fully follow even now. ;) But perhaps for the 2 use cases, for now, could be something like: * Compilation error: Some type of toast message cause it seems more like a building error than a scenario error? * Background data error: Perhaps after the test runs it should open to the Background tab instead? * and then if any of the actual Scenario test results are bogus because of these cases reflect that in the test panel, not show the pie chart and show some info text instead or something like that. wdyt? > Scenario Test: UX for background data error reporting > ----------------------------------------------------- > > Key: DROOLS-4625 > URL: https://issues.jboss.org/browse/DROOLS-4625 > Project: Drools > Issue Type: Task > Components: Scenario Simulation and Testing > Reporter: Jozef Marko > Assignee: Elizabeth Clayton > Priority: Major > Labels: ScenarioSimulation, UX, UXTeam > Attachments: Screenshot from 2019-10-16 16-42-25.png, Screenshot from 2019-10-16 16-44-18.png, background-error.png > > > As a user I want to be informed about errors that occurred in the data I provided in the new *Background* tab. For more details about the *Backround* tab please see DROOLS-4162 and BAPL-1401. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ELY-1833) Add ability to KeyStoreCredentialStore to use Provider[] for passwords.

by Ilia Vassilev (Jira)

[ https://issues.jboss.org/browse/ELY-1833?page=com.atlassian.jira.plugin.s... ] Ilia Vassilev commented on ELY-1833: ------------------------------------ New option to Credential Store command to utilize attribute "providersForPasswords" Elytron Tool new option Long option (no arguments): --providers-for-passwords Short option (no arguments): -w Description: Use the specified Provider(s) algorithm implementation for passwords. > Add ability to KeyStoreCredentialStore to use Provider[] for passwords. > ----------------------------------------------------------------------- > > Key: ELY-1833 > URL: https://issues.jboss.org/browse/ELY-1833 > Project: WildFly Elytron > Issue Type: Feature Request > Components: Credential Store > Affects Versions: 1.10.0.CR1 > Reporter: Darran Lofthouse > Assignee: Ilia Vassilev > Priority: Major > > The KeyStoreCredentialStore implementation does not use the Provider[] passed in during initialisation for PasswordFactory interaction. However it does use it for the underlying KeyStore. Any changes here will need to consider backwards compatibility as existing users may be used to this difference. > Elytron Tool: Add new option to Credential Store command to utilize the new feature. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ELY-1878) Elytron Tool: Add new option to Credential Store command to utilize attribute "providersForPasswords".

by Ilia Vassilev (Jira)

[ https://issues.jboss.org/browse/ELY-1878?page=com.atlassian.jira.plugin.s... ] Ilia Vassilev closed ELY-1878. ------------------------------ Release Notes Text: Combined with ELY-1833 Resolution: Deferred > Elytron Tool: Add new option to Credential Store command to utilize attribute "providersForPasswords". > ------------------------------------------------------------------------------------------------------ > > Key: ELY-1878 > URL: https://issues.jboss.org/browse/ELY-1878 > Project: WildFly Elytron > Issue Type: Enhancement > Components: Command-Line Tool > Affects Versions: 1.10.1.Final > Reporter: Ilia Vassilev > Assignee: Ilia Vassilev > Priority: Major > > Add new option to Credential Store command to utilize attribute "providersForPasswords" > Elytron Tool new option > Long option (no arguments): --providers-for-passwords > Short option (no arguments): -w > Description: Use the specified Provider(s) algorithm implementation for passwords. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ELY-1833) Add ability to KeyStoreCredentialStore to use Provider[] for passwords.

by Ilia Vassilev (Jira)

[ https://issues.jboss.org/browse/ELY-1833?page=com.atlassian.jira.plugin.s... ] Ilia Vassilev updated ELY-1833: ------------------------------- Description: The KeyStoreCredentialStore implementation does not use the Provider[] passed in during initialisation for PasswordFactory interaction. However it does use it for the underlying KeyStore. Any changes here will need to consider backwards compatibility as existing users may be used to this difference. Elytron Tool: Add new option to Credential Store command to utilize the new feature. was: The KeyStoreCredentialStore implementation does not use the Provider[] passed in during initialisation for PasswordFactory interaction. However it does use it for the underlying KeyStore. Any changes here will need to consider backwards compatibility as existing users may be used to this difference. > Add ability to KeyStoreCredentialStore to use Provider[] for passwords. > ----------------------------------------------------------------------- > > Key: ELY-1833 > URL: https://issues.jboss.org/browse/ELY-1833 > Project: WildFly Elytron > Issue Type: Feature Request > Components: Credential Store > Affects Versions: 1.10.0.CR1 > Reporter: Darran Lofthouse > Assignee: Ilia Vassilev > Priority: Major > > The KeyStoreCredentialStore implementation does not use the Provider[] passed in during initialisation for PasswordFactory interaction. However it does use it for the underlying KeyStore. Any changes here will need to consider backwards compatibility as existing users may be used to this difference. > Elytron Tool: Add new option to Credential Store command to utilize the new feature. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4625) Scenario Test: UX for background data error reporting

by Elizabeth Clayton (Jira)

[ https://issues.jboss.org/browse/DROOLS-4625?page=com.atlassian.jira.plugi... ] Elizabeth Clayton commented on DROOLS-4625: ------------------------------------------- [~danielezonca] [~ederign] so this might be a bit more involved than I initially thought, and I'm not sure I fully follow even now. ;) But perhaps for the 2 use cases, for now, could be something like: * Compilation error: Some type of toast message cause it seems more like a building error than a scenario error? * Background data error: Perhaps after the test runs it should open to the Background tab instead? * and then if any of the actual Scenario test results are bogus because of these cases reflect that in the test panel, not show the pie chart and show some info text instead or something like that. wdyt? > Scenario Test: UX for background data error reporting > ----------------------------------------------------- > > Key: DROOLS-4625 > URL: https://issues.jboss.org/browse/DROOLS-4625 > Project: Drools > Issue Type: Task > Components: Scenario Simulation and Testing > Reporter: Jozef Marko > Assignee: Elizabeth Clayton > Priority: Major > Labels: ScenarioSimulation, UX, UXTeam > Attachments: Screenshot from 2019-10-16 16-42-25.png, Screenshot from 2019-10-16 16-44-18.png, background-error.png > > > As a user I want to be informed about errors that occurred in the data I provided in the new *Background* tab. For more details about the *Backround* tab please see DROOLS-4162 and BAPL-1401. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12676) memory leak, org.jboss.jca.core.connectionmanager.pool.idle.IdleRemover$IdleRemoverRunner is keeping deployment in memory after undeployment

by Scott Marlow (Jira)

[ https://issues.jboss.org/browse/WFLY-12676?page=com.atlassian.jira.plugin... ] Scott Marlow updated WFLY-12676: -------------------------------- Issue Type: Bug (was: Task) > memory leak, org.jboss.jca.core.connectionmanager.pool.idle.IdleRemover$IdleRemoverRunner is keeping deployment in memory after undeployment > -------------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-12676 > URL: https://issues.jboss.org/browse/WFLY-12676 > Project: WildFly > Issue Type: Bug > Components: JCA > Affects Versions: 18.0.0.Final > Reporter: Scott Marlow > Assignee: Stefano Maestri > Priority: Blocker > Fix For: 19.0.0.Beta1 > > Attachments: 2lc.jar, java_pid12802.0001.zip, jcaleakmarlow.txt > > > As part of looking at [WFLY-12671], I found that org.jboss.jca.core.connectionmanager.pool.idle.IdleRemover$IdleRemoverRunner is leaking the application classloader (after undeployment) via org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory originalTCCL being kept after undeployment. > See attached jcaleakmarlow.txt (also attached to [WFLY-12671]), which shows the leak. > I tried waiting a few minutes after undeployment and the leak was still there. I also tried an even simpler app (2lc.jar) and still there is a leak. I also attached the heapdump (java_pid12802.0001.zip) > To recreate: > * Deploy simple (no app code will be executed) 2lc.jar app. > * Undeploy by doing "rm 2lc.jar.deployed" in wildfly/standalone/deployments > * Look at memory with MAT or other memory leak tool. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ELY-1833) Add ability to KeyStoreCredentialStore to use Provider[] for passwords.

by Ilia Vassilev (Jira)

[ https://issues.jboss.org/browse/ELY-1833?page=com.atlassian.jira.plugin.s... ] Ilia Vassilev updated ELY-1833: ------------------------------- Summary: Add ability to KeyStoreCredentialStore to use Provider[] for passwords. (was: KeyStoreCredentialStore does not use Provider[] for passwords.) > Add ability to KeyStoreCredentialStore to use Provider[] for passwords. > ----------------------------------------------------------------------- > > Key: ELY-1833 > URL: https://issues.jboss.org/browse/ELY-1833 > Project: WildFly Elytron > Issue Type: Bug > Components: Credential Store > Affects Versions: 1.10.0.CR1 > Reporter: Darran Lofthouse > Assignee: Ilia Vassilev > Priority: Major > > The KeyStoreCredentialStore implementation does not use the Provider[] passed in during initialisation for PasswordFactory interaction. > However it does use it for the underlying KeyStore. > Any changes here will need to consider backwards compatibility as existing users may be used to this difference. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ELY-1833) Add ability to KeyStoreCredentialStore to use Provider[] for passwords.

by Ilia Vassilev (Jira)

[ https://issues.jboss.org/browse/ELY-1833?page=com.atlassian.jira.plugin.s... ] Ilia Vassilev updated ELY-1833: ------------------------------- Issue Type: Feature Request (was: Bug) > Add ability to KeyStoreCredentialStore to use Provider[] for passwords. > ----------------------------------------------------------------------- > > Key: ELY-1833 > URL: https://issues.jboss.org/browse/ELY-1833 > Project: WildFly Elytron > Issue Type: Feature Request > Components: Credential Store > Affects Versions: 1.10.0.CR1 > Reporter: Darran Lofthouse > Assignee: Ilia Vassilev > Priority: Major > > The KeyStoreCredentialStore implementation does not use the Provider[] passed in during initialisation for PasswordFactory interaction. > However it does use it for the underlying KeyStore. > Any changes here will need to consider backwards compatibility as existing users may be used to this difference. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12666) JPA jipijapa use optional dependencies instead of modifying the system module

by Brian Stansberry (Jira)

[ https://issues.jboss.org/browse/WFLY-12666?page=com.atlassian.jira.plugin... ] Brian Stansberry commented on WFLY-12666: ----------------------------------------- [~smarlow] The description says the user provides the module: {quote} It would be better if these modules depended on an optional module which would not exist unless the user configured this. So for example a user could create modules/org/eclipse/persistence/impl/main/module.xml {quote} If we provide the module, then the patching issue that Brad wants to solve still exists, just with a different module. > JPA jipijapa use optional dependencies instead of modifying the system module > ----------------------------------------------------------------------------- > > Key: WFLY-12666 > URL: https://issues.jboss.org/browse/WFLY-12666 > Project: WildFly > Issue Type: Enhancement > Components: JPA / Hibernate > Affects Versions: 18.0.0.Final > Reporter: Brad Maxwell > Assignee: Scott Marlow > Priority: Major > Attachments: WFLY-12666-overlay.zip > > > As per [1] it requires modifying the modules under system/layers/base, these are system modules which users really should not modify. When applying patches it will complain because the module has been modified. > It would be better if these modules depended on an optional module which would not exist unless the user configured this. So for example a user could create modules/org/eclipse/persistence/impl/main/module.xml > modules/system/layers/base/org/eclipse/persistence/main/module.xml > It looks like this almost works with just adding the optional dependency, except there is an exception where it looks like the classloader may not be set correctly for some reason when the module is split into 2. > {code} > <module name="org.eclipse.persistence" xmlns="urn:jboss:module:1.5"> > ... > <module name="org.eclipse.persistence.impl" optional="true" services="import"/> > {code} > {code} > <?xml version="1.0" encoding="UTF-8"?> > <module xmlns="urn:jboss:module:1.5" name="org.eclipse.persistence.impl"> > <resources> >  > <resource-root path="eclipselink.jar"> > <filter> > <exclude path="javax/**"/> > </filter> > </resource-root> > </resources> > <dependencies> > <module name="javax.api"/> > <module name="javax.annotation.api"/> > <module name="javax.enterprise.api"/> > <module name="javax.persistence.api"/> > <module name="javax.transaction.api"/> > <module name="javax.validation.api"/> > <module name="javax.xml.bind.api"/> > <module name="org.antlr"/> > <module name="org.dom4j"/> > <module name="org.jboss.as.jpa.spi"/> > <module name="org.jboss.logging"/> > <module name="org.jboss.vfs"/> > <module name="org.eclipse.persistence"/>  > </dependencies> > </module> > {code} > {code} > Caused by: java.lang.IllegalArgumentException: Object: com.jboss.examples.jpa.model.User@4fbcb157 is not a known Entity type. > at org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.registerNewObjectForPersist(UnitOfWorkImpl.java:4326) > at org.eclipse.persistence.internal.jpa.EntityManagerImpl.persist(EntityManagerImpl.java:596) > at org.jboss.as.jpa.container.AbstractEntityManager.persist(AbstractEntityManager.java:580) > at com.jboss.examples.jpa.TestSingleton.test(TestSingleton.java:29) > 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:498) > at org.jboss.as.ee.component.ManagedReferenceLifecycleMethodInterceptor.processInvocation(ManagedReferenceLifecycleMethodInterceptor.java:96) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) > at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:509) > at org.jboss.as.weld.interceptors.Jsr299BindingsInterceptor.delegateInterception(Jsr299BindingsInterceptor.java:79) > at org.jboss.as.weld.interceptors.Jsr299BindingsInterceptor.doLifecycleInterception(Jsr299BindingsInterceptor.java:126) > at org.jboss.as.weld.interceptors.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:112) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) > at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:509) > at org.jboss.weld.module.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:81) > at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:89) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) > at org.jboss.as.weld.injection.WeldInjectionInterceptor.processInvocation(WeldInjectionInterceptor.java:53) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) > at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:112) > {code} > [1] https://docs.jboss.org/author/display/WFLY10/JPA+Reference+Guide#JPARefer... -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 9 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 2019