January 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-5418) start-delivery/stop-delivery operations descriptions are missing from MDB deployment in domain mode

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-5418?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-5418: ----------------------------------------------- Petr Penicka <ppenicka(a)redhat.com> changed the Status of [bug 1266913|https://bugzilla.redhat.com/show_bug.cgi?id=1266913] from VERIFIED to CLOSED > start-delivery/stop-delivery operations descriptions are missing from MDB deployment in domain mode > --------------------------------------------------------------------------------------------------- > > Key: WFLY-5418 > URL: https://issues.jboss.org/browse/WFLY-5418 > Project: WildFly > Issue Type: Bug > Components: JMS > Affects Versions: JBoss AS7 7.2.0.Final > Environment: JBoss EAP 6.4.3 > Reporter: Tom Ross > Assignee: Jeff Mesnil > Fix For: 10.0.0.CR4 > > > It is possible to start/stop delivery of messages to MDB in standalone mode using operations > start-delivery() and stop-delivery() on MDB deployment. > Those operations are available in domain mode but their descriptions are missing (preventing CLI autocompletion to work as expected). -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5556) Configure remote tx timeout via system property

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-5556?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-5556: ----------------------------------------------- Petr Penicka <ppenicka(a)redhat.com> changed the Status of [bug 1265300|https://bugzilla.redhat.com/show_bug.cgi?id=1265300] from VERIFIED to CLOSED > Configure remote tx timeout via system property > ----------------------------------------------- > > Key: WFLY-5556 > URL: https://issues.jboss.org/browse/WFLY-5556 > Project: WildFly > Issue Type: Feature Request > Components: EJB > Reporter: Panagiotis Sotiropoulos > Assignee: Panagiotis Sotiropoulos > Fix For: 10.0.0.CR4 > > > Description of problem: > The hardcoded 5 minute timeout period was replace with Integer.MAX_VALUE for the timeout period of "remote" distributed transaction branches. > - https://issues.jboss.org/browse/WFLY-2789 > - https://bugzilla.redhat.com/show_bug.cgi?id=1056585#c1 > An "infinite" timeout is a problem as this value is also passed to the database to control statement execution. This means that database statements may run uncontrolled in most cases. Too, in one case we have seen that the database driver or the database is mishandling the value and aborting almost immediately (e.g. after only 2 or 3 seconds). > Version-Release number of selected component (if applicable): > How reproducible: > Consistently > Steps to Reproduce: > 1. Start a transaction in server "one" > 2. Using JTA/EJB remoting, propagate that transaction to a remote server > 3. The timeout for the transaction on the remote can be seen to be Integer.MAX_VALUE > Actual results: > Either an "infinite" timeout period for database statement execution or else an immediate abort > Expected results: > A "reasonable" smaller value must be used. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5418) start-delivery/stop-delivery operations descriptions are missing from MDB deployment in domain mode

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-5418?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-5418: ----------------------------------------------- Petr Penicka <ppenicka(a)redhat.com> changed the Status of [bug 1266913|https://bugzilla.redhat.com/show_bug.cgi?id=1266913] from VERIFIED to CLOSED > start-delivery/stop-delivery operations descriptions are missing from MDB deployment in domain mode > --------------------------------------------------------------------------------------------------- > > Key: WFLY-5418 > URL: https://issues.jboss.org/browse/WFLY-5418 > Project: WildFly > Issue Type: Bug > Components: JMS > Affects Versions: JBoss AS7 7.2.0.Final > Environment: JBoss EAP 6.4.3 > Reporter: Tom Ross > Assignee: Jeff Mesnil > Fix For: 10.0.0.CR4 > > > It is possible to start/stop delivery of messages to MDB in standalone mode using operations > start-delivery() and stop-delivery() on MDB deployment. > Those operations are available in domain mode but their descriptions are missing (preventing CLI autocompletion to work as expected). -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5596) MessageDrivenComponent startDelivery/stopDelivery is not thread safe

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-5596?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-5596: ----------------------------------------------- Petr Penicka <ppenicka(a)redhat.com> changed the Status of [bug 1282661|https://bugzilla.redhat.com/show_bug.cgi?id=1282661] from VERIFIED to CLOSED > MessageDrivenComponent startDelivery/stopDelivery is not thread safe > -------------------------------------------------------------------- > > Key: WFLY-5596 > URL: https://issues.jboss.org/browse/WFLY-5596 > Project: WildFly > Issue Type: Bug > Components: EJB, JMS > Affects Versions: 10.0.0.CR4 > Reporter: James Livingston > Assignee: Jeff Mesnil > Fix For: 10.0.0.CR5 > > > WFLY-4470 made a change to prevent MDBs being activated or deactivated multiple times, but it is not thread safe. A volatile boolean is used for the flag, but there is no protection against multiple threads invoking the methods simultaneously. > Possible effects include: > * activating the endpoint twice, with (probably) only one deactivation later, leading to not de-registering XA resources from the recovery manager properly > * activate() and deactivate() running in the wrong order if done by separate threads > Several simple solutions probably will not work correctly. Using an AtomicBoolean would stop multiple activations/deactivations from concurrent calls, but would mean that startDelivery() could return before the activation was one. Using a synchronized block or other exclusive lock would work, however since it involves invoking non-container code (the resource adapter), there could potentially be a deadlock risk if that invoked some related container functionality. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5449) Custom socket factory for JGroups subsystem not set correctly

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-5449?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-5449: ----------------------------------------------- Petr Penicka <ppenicka(a)redhat.com> changed the Status of [bug 1268185|https://bugzilla.redhat.com/show_bug.cgi?id=1268185] from VERIFIED to CLOSED > Custom socket factory for JGroups subsystem not set correctly > ------------------------------------------------------------- > > Key: WFLY-5449 > URL: https://issues.jboss.org/browse/WFLY-5449 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 10.0.0.CR2 > Reporter: Dennis Reed > Assignee: Paul Ferraro > Priority: Blocker > Fix For: 10.0.0.CR4 > > > Wildfly's JChannelFactory tries to set a custom socket factory on the JGroups transport. > This is not the correct API to use, and it gets overwritten when the JGroups channel starts. > A custom socket factory should be set on the JChannel. > The only time the custom socket factory is currently used is if there's a race condition where two channels are started at the same time, and the custom factory is set just before the other channel uses it. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5409) Fix KerberosTestUtils in testsuite - skip Kerberos tests for IPv6 if no hostname is configured

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-5409?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-5409: ----------------------------------------------- Petr Penicka <ppenicka(a)redhat.com> changed the Status of [bug 1266482|https://bugzilla.redhat.com/show_bug.cgi?id=1266482] from VERIFIED to CLOSED > Fix KerberosTestUtils in testsuite - skip Kerberos tests for IPv6 if no hostname is configured > ---------------------------------------------------------------------------------------------- > > Key: WFLY-5409 > URL: https://issues.jboss.org/browse/WFLY-5409 > Project: WildFly > Issue Type: Bug > Components: Test Suite > Reporter: Josef Cacek > Assignee: Josef Cacek > Fix For: 10.1.0.CR1, 10.1.0.Final > > > Condition used in {{org.jboss.as.test.integration.security.common.negotiation.KerberosTestUtils.assumeKerberosAuthenticationSupported(String)}} doesn't cover Java 8. It has to be updated. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2880) DsXmlDeploymentInstallProcessor passes wrong ManagementResourceRegistration to DataSourceStatisticsListener

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2880?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2880: ----------------------------------------------- Petr Penicka <ppenicka(a)redhat.com> changed the Status of [bug 1245363|https://bugzilla.redhat.com/show_bug.cgi?id=1245363] from VERIFIED to CLOSED > DsXmlDeploymentInstallProcessor passes wrong ManagementResourceRegistration to DataSourceStatisticsListener > ----------------------------------------------------------------------------------------------------------- > > Key: WFLY-2880 > URL: https://issues.jboss.org/browse/WFLY-2880 > Project: WildFly > Issue Type: Bug > Components: Domain Management, JCA > Affects Versions: 8.0.0.CR1 > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Fix For: 8.0.0.Final > > > Unlike AbstractDataSourceAdd, which passes an override registration into DataSourceStatisticsListener, DsXmlDeploymentInstallProcessor passes in the main registration. > I believe this is the cause of the following stuff in the logs Tomaz Cerar saw when messing about with the WildFly quickstarts: > {noformat} > 22:50:05,945 ERROR [org.jboss.msc.service] (MSC service thread 1-4) MSC000002: Invocation of listener "org.jboss.as.connector.subsystems.datasources.DataSourceStatisticsListener@1281d4a" failed: java.lang.IllegalArgumentException: > JBAS014809: A node is already registered at '(deployment => *)(subsystem => datasources)(data-source => *)(statistics => jdbc)' > at org.jboss.as.controller.registry.ConcreteResourceRegistration.registerSubModel(ConcreteResourceRegistration.java:145) [wildfly-controller-8.0.0.Final-SNAPSHOT.jar:8.0.0.Final-SNAPSHOT] > at org.jboss.as.controller.registry.AbstractResourceRegistration.registerSubModel(AbstractResourceRegistration.java:90) [wildfly-controller-8.0.0.Final-SNAPSHOT.jar:8.0.0.Final-SNAPSHOT] > at org.jboss.as.connector.subsystems.datasources.DataSourceStatisticsListener.transition(DataSourceStatisticsListener.java:72) [wildfly-connector-8.0.0.Final-SNAPSHOT.jar:8.0.0.Final-SNAPSHOT] > at org.jboss.msc.service.ServiceControllerImpl.invokeListener(ServiceControllerImpl.java:1533) [jboss-msc-1.2.0.Final.jar:1.2.0.Final] > at org.jboss.msc.service.ServiceControllerImpl.access$2800(ServiceControllerImpl.java:51) [jboss-msc-1.2.0.Final.jar:1.2.0.Final] > at org.jboss.msc.service.ServiceControllerImpl$ListenerTask.run(ServiceControllerImpl.java:2099) [jboss-msc-1.2.0.Final.jar:1.2.0.Final] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0] > at java.lang.Thread.run(Thread.java:744) [rt.jar:1.8.0] > {noformat} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-868) Multithread issue when validate with cached hased password + nonce credential info from JBossCachedAuthenticationManager

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/SECURITY-868?page=com.atlassian.jira.plug... ] RH Bugzilla Integration commented on SECURITY-868: -------------------------------------------------- Petr Penicka <ppenicka(a)redhat.com> changed the Status of [bug 1219778|https://bugzilla.redhat.com/show_bug.cgi?id=1219778] from VERIFIED to CLOSED > Multithread issue when validate with cached hased password + nonce credential info from JBossCachedAuthenticationManager > -------------------------------------------------------------------------------------------------------------------------- > > Key: SECURITY-868 > URL: https://issues.jboss.org/browse/SECURITY-868 > Project: PicketBox > Issue Type: Task > Components: PicketBox > Reporter: Jim Ma > Assignee: Stefan Guilhen > Fix For: PicketBox_4_9_0.Final > > Attachments: stacktraces.log > > > When the new security domain is configured with catch-type=default in standalone.xml, the validated credential will be put in the JBossCachedAuthenticationManager with principal and domaininfo value pair. In multithread environment, a new validated credential can overwrite the previous thread cached domain info. This will cause even in the same thread , the cached authentication info could not work. For example if one user login with username , password and nonce in two threads : thread A and thread B ;thread A caches the validated credential(hased password +nonce) in JBossCachedAuthenticationMessager, thread B does the authentication, then caches the validated credential (hashed password + nonce) , even it's the same user and passoword, the credential is different because the nonce is diffrent. So the new credential created in thread B will overwrite the previous value created by thread A . So in thread A, the cached validation info won't work and following validation with cached credential will all fail. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5496) Add a testcase testing passivation of SFSB which fails to serialize

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-5496?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-5496: ----------------------------------------------- Petr Penicka <ppenicka(a)redhat.com> changed the Status of [bug 1268424|https://bugzilla.redhat.com/show_bug.cgi?id=1268424] from VERIFIED to CLOSED > Add a testcase testing passivation of SFSB which fails to serialize > ------------------------------------------------------------------- > > Key: WFLY-5496 > URL: https://issues.jboss.org/browse/WFLY-5496 > Project: WildFly > Issue Type: Enhancement > Components: Test Suite > Reporter: Tomas Hofman > Assignee: Tomas Hofman > Fix For: 10.0.0.CR4 > > > Porting a test case from https://bugzilla.redhat.com/show_bug.cgi?id=1268424 -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-784) LdapExtLoginModule cannot find custom ldap socket factory

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/SECURITY-784?page=com.atlassian.jira.plug... ] RH Bugzilla Integration commented on SECURITY-784: -------------------------------------------------- Petr Penicka <ppenicka(a)redhat.com> changed the Status of [bug 1052644|https://bugzilla.redhat.com/show_bug.cgi?id=1052644] from VERIFIED to CLOSED > LdapExtLoginModule cannot find custom ldap socket factory > --------------------------------------------------------- > > Key: SECURITY-784 > URL: https://issues.jboss.org/browse/SECURITY-784 > Project: PicketBox > Issue Type: Feature Request > Components: PicketBox > Affects Versions: PicketBox_4_0_19.Final > Reporter: Derek Horton > Assignee: Pedro Igor > Attachments: SECURITY-784.patch > > > LdapExtLoginModule cannot find custom ldap socket factory. > Passing the "java.naming.ldap.factory.socket" property in as an > module-option: > <module-option name="java.naming.ldap.factory.socket" value="org.jboss.example.CustomSocketFactory"/> > results in a ClassNotFoundException: > Caused by: javax.naming.CommunicationException: 192.168.1.8:389 [Root exception is java.lang.ClassNotFoundException: org/jboss/example/CustomSocketFactory] > at com.sun.jndi.ldap.Connection.<init>(Connection.java:226) [rt.jar:1.7.0_45] > at com.sun.jndi.ldap.LdapClient.<init>(LdapClient.java:136) [rt.jar:1.7.0_45] > at com.sun.jndi.ldap.LdapClient.getInstance(LdapClient.java:1608) [rt.jar:1.7.0_45] > at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2698) [rt.jar:1.7.0_45] > at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:316) [rt.jar:1.7.0_45] > at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:193) [rt.jar:1.7.0_45] > at com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:211) [rt.jar:1.7.0_45] > at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:154) [rt.jar:1.7.0_45] > at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:84) [rt.jar:1.7.0_45] > at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684) [rt.jar:1.7.0_45] > at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:307) [rt.jar:1.7.0_45] > at javax.naming.InitialContext.init(InitialContext.java:242) [rt.jar:1.7.0_45] > at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:153) [rt.jar:1.7.0_45] > at org.jboss.security.auth.spi.LdapExtLoginModule.constructInitialLdapContext(LdapExtLoginModule.java:767) [picketbox-4.0.17.SP2-redhat-2.jar:4.0.17.SP2-redhat-2] > I tried making the custom socket factory into a jboss module and adding the module as a dependency to picketbox and > sun.jdk. Unfortunately, that did not work. I also added the socket > factory jar to the jre/lib/ext directory. That didn't work either. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 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 January 2017