May 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (SECURITY-933) The root cause of login module failures gets lost when multiple login modules are stacked

by Tomas Hofman (JIRA)

[ https://issues.jboss.org/browse/SECURITY-933?page=com.atlassian.jira.plug... ] Tomas Hofman updated SECURITY-933: ---------------------------------- Bugzilla References: (was: https://bugzilla.redhat.com/show_bug.cgi?id=1288668) > The root cause of login module failures gets lost when multiple login modules are stacked > ----------------------------------------------------------------------------------------- > > Key: SECURITY-933 > URL: https://issues.jboss.org/browse/SECURITY-933 > Project: PicketBox > Issue Type: Bug > Components: Negotiation > Reporter: Tomas Hofman > Assignee: Tomas Hofman > Fix For: Negotiation_3_0_1_Final > > > https://bugzilla.redhat.com/show_bug.cgi?id=1288668 > The root cause of login module failures gets lost when multiple login modules are stacked and the "flag" attribute is set to "optional". > When the login attempt fails (invalid bindCredential on the LdapExtLoginModule for example) the authentication request will continue to the next login module in the stack. In this situation, the exceptions "cause" attribute is getting overwritten during the processing of the other login modules. This results in the actual cause to get lost during processing. > This makes troubleshooting authentication failures difficult. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6241) Setting of non-existing factory class to connector service can cause ActiveMQ crash

by Carlo de Wolf (JIRA)

[ https://issues.jboss.org/browse/WFLY-6241?page=com.atlassian.jira.plugin.... ] Carlo de Wolf updated WFLY-6241: -------------------------------- Labels: downstream_dependency (was: ) > Setting of non-existing factory class to connector service can cause ActiveMQ crash > ----------------------------------------------------------------------------------- > > Key: WFLY-6241 > URL: https://issues.jboss.org/browse/WFLY-6241 > Project: WildFly > Issue Type: Bug > Components: JMS > Reporter: Lin Gao > Assignee: Lin Gao > Priority: Critical > Labels: downstream_dependency > > When setting non-existing factory class to connector service, no validation is done and during startup after reload service will fail. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1168) notify property change

by Sante Stanisci (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1168?page=com.atlassian.jira.plugi... ] Sante Stanisci commented on DROOLS-1168: ---------------------------------------- Ok, it is just for efficency. But you consider my request for enhancement next version? Best Regards > notify property change > ---------------------- > > Key: DROOLS-1168 > URL: https://issues.jboss.org/browse/DROOLS-1168 > Project: Drools > Issue Type: Enhancement > Components: core engine > Affects Versions: 6.4.0.Final > Environment: java 6, eclipse 4, windows 8.1 > Reporter: Sante Stanisci > Assignee: Mario Fusco > Priority: Critical > Attachments: DroolsUtil.java, EntityBase.java, MtbLisvData.java, rules.drl > > > in the then statement instead of modify use a custom function to change the field. This change does not notify the property even if the class is annotated with @PropertyReactive > How can I manually notify the change? > Use a stateless session -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6215) SessionSynchronization callbacks allow concurrent access to SFSB

by Carlo de Wolf (JIRA)

[ https://issues.jboss.org/browse/WFLY-6215?page=com.atlassian.jira.plugin.... ] Carlo de Wolf updated WFLY-6215: -------------------------------- Labels: downstream_dependency (was: ) > SessionSynchronization callbacks allow concurrent access to SFSB > ---------------------------------------------------------------- > > Key: WFLY-6215 > URL: https://issues.jboss.org/browse/WFLY-6215 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 10.0.0.Final > Reporter: Ryan Emerson > Assignee: Ryan Emerson > Labels: downstream_dependency > Attachments: wfly_reproducer.tar.gz > > > Issue first encountered by customer in EAP5 (JBPAPP-11239). > Assume a local SFSB, B1, with container managed transactions and a calling SFSB, B2, which has bean managed transactions. B1 implements the SessionSynchronization interface. > When B2's bean managed transaction timesout whilst executing B1.exampleMethod(), B2's transaction aborts and the transaction reaper thread calls B1.afterCompletion(). However, the original worker thread that was executing B1.exampleMethod() continues to execute B1.exampleMethod() until it has completed. Hence it is possible for the B1 SFSB to be accessed concurrently. It is also possible for B1.afterCompletion() to finish executing before B1.exampleMethod(). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6215) SessionSynchronization callbacks allow concurrent access to SFSB

by Carlo de Wolf (JIRA)

[ https://issues.jboss.org/browse/WFLY-6215?page=com.atlassian.jira.plugin.... ] Carlo de Wolf updated WFLY-6215: -------------------------------- Priority: Critical (was: Major) > SessionSynchronization callbacks allow concurrent access to SFSB > ---------------------------------------------------------------- > > Key: WFLY-6215 > URL: https://issues.jboss.org/browse/WFLY-6215 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 10.0.0.Final > Reporter: Ryan Emerson > Assignee: Ryan Emerson > Priority: Critical > Labels: downstream_dependency > Attachments: wfly_reproducer.tar.gz > > > Issue first encountered by customer in EAP5 (JBPAPP-11239). > Assume a local SFSB, B1, with container managed transactions and a calling SFSB, B2, which has bean managed transactions. B1 implements the SessionSynchronization interface. > When B2's bean managed transaction timesout whilst executing B1.exampleMethod(), B2's transaction aborts and the transaction reaper thread calls B1.afterCompletion(). However, the original worker thread that was executing B1.exampleMethod() continues to execute B1.exampleMethod() until it has completed. Hence it is possible for the B1 SFSB to be accessed concurrently. It is also possible for B1.afterCompletion() to finish executing before B1.exampleMethod(). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1168) notify property change

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1168?page=com.atlassian.jira.plugi... ] Mario Fusco commented on DROOLS-1168: ------------------------------------- Drools doesn't know and then doesn't apply any restriction on cascade propagation. Property reactivity is just an heuristic to restrict the rules to be evaluated. > notify property change > ---------------------- > > Key: DROOLS-1168 > URL: https://issues.jboss.org/browse/DROOLS-1168 > Project: Drools > Issue Type: Enhancement > Components: core engine > Affects Versions: 6.4.0.Final > Environment: java 6, eclipse 4, windows 8.1 > Reporter: Sante Stanisci > Assignee: Mario Fusco > Priority: Critical > Attachments: DroolsUtil.java, EntityBase.java, MtbLisvData.java, rules.drl > > > in the then statement instead of modify use a custom function to change the field. This change does not notify the property even if the class is annotated with @PropertyReactive > How can I manually notify the change? > Use a stateless session -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1168) notify property change

by Sante Stanisci (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1168?page=com.atlassian.jira.plugi... ] Sante Stanisci commented on DROOLS-1168: ---------------------------------------- And how to Drools know that property was changed? > notify property change > ---------------------- > > Key: DROOLS-1168 > URL: https://issues.jboss.org/browse/DROOLS-1168 > Project: Drools > Issue Type: Enhancement > Components: core engine > Affects Versions: 6.4.0.Final > Environment: java 6, eclipse 4, windows 8.1 > Reporter: Sante Stanisci > Assignee: Mario Fusco > Priority: Critical > Attachments: DroolsUtil.java, EntityBase.java, MtbLisvData.java, rules.drl > > > in the then statement instead of modify use a custom function to change the field. This change does not notify the property even if the class is annotated with @PropertyReactive > How can I manually notify the change? > Use a stateless session -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-761) Not possible to overlay non existing file in WAR

by Carlo de Wolf (JIRA)

[ https://issues.jboss.org/browse/WFCORE-761?page=com.atlassian.jira.plugin... ] Carlo de Wolf updated WFCORE-761: --------------------------------- Labels: downstream_dependency (was: ) > Not possible to overlay non existing file in WAR > ------------------------------------------------ > > Key: WFCORE-761 > URL: https://issues.jboss.org/browse/WFCORE-761 > Project: WildFly Core > Issue Type: Bug > Components: Server > Reporter: Bartosz Baranowski > Assignee: Dimitris Andreadis > Priority: Critical > Labels: downstream_dependency > > It is either bug in how deployments are treated or how overlay/vfs work. > Steps to reproduce: > 1. deploy undexploded war with jar inside > 2. add overlay that will add non existing file in jar > Result: exception: > Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS018776: Failed to get content for deployment overlay WEB-INF/lib/overlayed.jar//META-INF/x/file.txt at WEB-INF/lib/overlayed.jar//META-INF/x/file.txt > Caused by: java.io.FileNotFoundException: /content/shell.war/WEB-INF/lib/overlayed.jar/META-INF/x/file.txt"}} > at org.jboss.as.test.integration.management.ManagementOperations.executeOperation(ManagementOperations.java:67) > at org.jboss.as.test.integration.management.ManagementOperations.executeOperation(ManagementOperations.java:37) > at org.jboss.as.test.integration.deployment.deploymentoverlay.jar.OverlayUtils.setupOverlay(OverlayUtils.java:76) > at org.jboss.as.test.integration.deployment.deploymentoverlay.war.OverlayNonExistingResourceTestCase.testOverlay(OverlayNonExistingResourceTestCase.java:67) > Expectation: > should work. It actually does work, if war is really exploded or > 'if(exploded)' part in overlay is removed from overlay processor and everything is handled via: https://github.com/stuartwdouglas/wildfly-core/blob/a75af9118c4062fafb899... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-459) javassist should also be exported to Hibernate (native) applications

by Carlo de Wolf (JIRA)

[ https://issues.jboss.org/browse/WFLY-459?page=com.atlassian.jira.plugin.s... ] Carlo de Wolf updated WFLY-459: ------------------------------- Priority: Blocker (was: Major) > javassist should also be exported to Hibernate (native) applications > -------------------------------------------------------------------- > > Key: WFLY-459 > URL: https://issues.jboss.org/browse/WFLY-459 > Project: WildFly > Issue Type: Task > Components: JPA / Hibernate > Reporter: Scott Marlow > Assignee: Scott Marlow > Priority: Blocker > Labels: downstream_dependency > Fix For: 10.1.0.Final > > > Originally this jira was to stop exporting the javassist module to JPA deployments but it turns out that is fine to do. In addition, native Hibernate applications that depend on Hibernate, should also get the javassist dependency. > # native Hibernate applications will get the javassist dependency via the application dependency on org.hibernate. > # container managed JPA applications will get the javassist dependency via org.jboss.as.jpa.processor.JPADependencyProcessor (JPA deployer). > # container managed JPA applications that embed their own copy of Hibernate jars will also get the javassist dependency via org.jboss.as.jpa.processor.JPADependencyProcessor (JPA deployer). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-459) javassist should also be exported to Hibernate (native) applications

by Carlo de Wolf (JIRA)

[ https://issues.jboss.org/browse/WFLY-459?page=com.atlassian.jira.plugin.s... ] Carlo de Wolf updated WFLY-459: ------------------------------- Labels: downstream_dependency (was: ) > javassist should also be exported to Hibernate (native) applications > -------------------------------------------------------------------- > > Key: WFLY-459 > URL: https://issues.jboss.org/browse/WFLY-459 > Project: WildFly > Issue Type: Task > Components: JPA / Hibernate > Reporter: Scott Marlow > Assignee: Scott Marlow > Priority: Blocker > Labels: downstream_dependency > Fix For: 10.1.0.Final > > > Originally this jira was to stop exporting the javassist module to JPA deployments but it turns out that is fine to do. In addition, native Hibernate applications that depend on Hibernate, should also get the javassist dependency. > # native Hibernate applications will get the javassist dependency via the application dependency on org.hibernate. > # container managed JPA applications will get the javassist dependency via org.jboss.as.jpa.processor.JPADependencyProcessor (JPA deployer). > # container managed JPA applications that embed their own copy of Hibernate jars will also get the javassist dependency via org.jboss.as.jpa.processor.JPADependencyProcessor (JPA deployer). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 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 May 2016