October 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-967) Update the managed version of org.apache.aries.blueprint.noosgi in test dependencies and re-enable all of the kie-aries-blueprint tests

by Michael Reynolds (JIRA)

[ https://issues.jboss.org/browse/DROOLS-967?page=com.atlassian.jira.plugin... ] Michael Reynolds commented on DROOLS-967: ----------------------------------------- The only work that needs to be made in the kie-aries-blueprint is to get rid of all the @Ignore annotations, uncomment the createNamespaceHandlerSets method in KieBlueprintContainer, and delete the GAV test, since it is missing the original XML file. > Update the managed version of org.apache.aries.blueprint.noosgi in test dependencies and re-enable all of the kie-aries-blueprint tests > --------------------------------------------------------------------------------------------------------------------------------------- > > Key: DROOLS-967 > URL: https://issues.jboss.org/browse/DROOLS-967 > Project: Drools > Issue Type: Feature Request > Reporter: Michael Reynolds > Assignee: Mark Proctor > Priority: Minor > > All of the unit tests in kie-aries-blueprint are ignored with the message to re-enable them once org.apache.aries.blueprint.noosgi 1.0.1 is out. As of right now the latest version of Blueprint noosgi is 1.1.0. > Since the enforcer plugin ensures that all dependencies are managed, we just need to update the managed version and then re-enable the code for adding the namespace handler and unit tests. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

6 years

1
0
0 / 0

[JBoss JIRA] (DROOLS-967) Update the managed version of org.apache.aries.blueprint.noosgi in test dependencies and re-enable all of the kie-aries-blueprint tests

by Michael Reynolds (JIRA)

[ https://issues.jboss.org/browse/DROOLS-967?page=com.atlassian.jira.plugin... ] Michael Reynolds updated DROOLS-967: ------------------------------------ Issue Type: Enhancement (was: Feature Request) > Update the managed version of org.apache.aries.blueprint.noosgi in test dependencies and re-enable all of the kie-aries-blueprint tests > --------------------------------------------------------------------------------------------------------------------------------------- > > Key: DROOLS-967 > URL: https://issues.jboss.org/browse/DROOLS-967 > Project: Drools > Issue Type: Enhancement > Reporter: Michael Reynolds > Assignee: Mark Proctor > Priority: Minor > > All of the unit tests in kie-aries-blueprint are ignored with the message to re-enable them once org.apache.aries.blueprint.noosgi 1.0.1 is out. As of right now the latest version of Blueprint noosgi is 1.1.0. > Since the enforcer plugin ensures that all dependencies are managed, we just need to update the managed version and then re-enable the code for adding the namespace handler and unit tests. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

6 years

1
0
0 / 0

[JBoss JIRA] (JBJCA-1297) Verify if a SQLException is fatal in all methods

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1297?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on JBJCA-1297: ------------------------------------------------ Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1271806|https://bugzilla.redhat.com/show_bug.cgi?id=1271806] from MODIFIED to ON_QA > Verify if a SQLException is fatal in all methods > ------------------------------------------------ > > Key: JBJCA-1297 > URL: https://issues.jboss.org/browse/JBJCA-1297 > Project: IronJacamar > Issue Type: Bug > Components: JDBC > Affects Versions: WildFly/IronJacamar 1.3.1.Final, 1.2.6.Final > Reporter: Jesper Pedersen > Assignee: Jesper Pedersen > Fix For: WildFly/IronJacamar 1.3.2.Final, 1.2.7.Final > > > WrappedConnection: > * setTransactionIsolation > * commit > * rollback > * setClientInfo -- This message was sent by Atlassian JIRA (v6.4.11#64026)

6 years

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: ----------------------------------------------- Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1266913|https://bugzilla.redhat.com/show_bug.cgi?id=1266913] from MODIFIED to ON_QA > 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 (v6.4.11#64026)

6 years

1
0
0 / 0

[JBoss JIRA] (WFLY-5232) Naming store is null before CDI lifecycle BeforeShutdown event fires

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-5232?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-5232: ----------------------------------------------- Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1252583|https://bugzilla.redhat.com/show_bug.cgi?id=1252583] from MODIFIED to ON_QA > Naming store is null before CDI lifecycle BeforeShutdown event fires > -------------------------------------------------------------------- > > Key: WFLY-5232 > URL: https://issues.jboss.org/browse/WFLY-5232 > Project: WildFly > Issue Type: Bug > Reporter: Ryan Emerson > Assignee: Ryan Emerson > Attachments: reproducer.tar.gz > > > A CDI extension has a BeforeShutdown event handler that looks up the UserTransaction and performs a clean-up operation. If the application is undeployed, all works as expected, but if Wildfly is shut down gracefully the lookup fails. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

6 years

1
0
0 / 0

[JBoss JIRA] (SECURITY-893) Second security vault warning is displayed even if only one vault definition is present in the server configuration

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/SECURITY-893?page=com.atlassian.jira.plug... ] RH Bugzilla Integration commented on SECURITY-893: -------------------------------------------------- Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1181457|https://bugzilla.redhat.com/show_bug.cgi?id=1181457] from MODIFIED to ON_QA > Second security vault warning is displayed even if only one vault definition is present in the server configuration > ------------------------------------------------------------------------------------------------------------------- > > Key: SECURITY-893 > URL: https://issues.jboss.org/browse/SECURITY-893 > Project: PicketBox > Issue Type: Bug > Components: JBossSX, Security-SPI > Affects Versions: PicketBox_4_1_0.Beta2 > Reporter: Ivo Studensky > Assignee: Peter Skopek > > The BZ's description: > I have only one vault configured in the standalone.xml but I see following warning message in the server log file after login attempt (bindCredentials login module option uses a vaulted password): > {noformat} > 09:10:58,854 WARN [org.jboss.security] (http-/127.0.0.1:8080-1) PBOX000378: Attempt to create the second Security Vault [org.picketbox.plugins.vault.PicketBoxSecurityVault] is invalid. Only one Security Vault is supported. Change your configuration, please. > {noformat} > This issue is related to the previous fix for bz1055577, \[1\]. The problem needs to be fixed on EAP side in time of Security Subsystem configuration processing. Fix will be provided by bz1181457 \[2\]. > \[1\] https://bugzilla.redhat.com/show_bug.cgi?id=1055577 > \[2\] https://bugzilla.redhat.com/show_bug.cgi?id=1181457 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

6 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-1014) DefaultDeploymentOperations.getDeploymentsStatus doesn't consider model operation result outcome

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1014?page=com.atlassian.jira.plugi... ] RH Bugzilla Integration commented on WFCORE-1014: ------------------------------------------------- Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1266615|https://bugzilla.redhat.com/show_bug.cgi?id=1266615] from MODIFIED to ON_QA > DefaultDeploymentOperations.getDeploymentsStatus doesn't consider model operation result outcome > ------------------------------------------------------------------------------------------------ > > Key: WFCORE-1014 > URL: https://issues.jboss.org/browse/WFCORE-1014 > Project: WildFly Core > Issue Type: Bug > Affects Versions: 2.0.0.CR6 > Reporter: Aaron Ogburn > Assignee: Aaron Ogburn > Fix For: 2.0.0.CR6 > > > The deployment scanner doesn't properly consider the result outcome of its read child operation during getDeploymentsStatus(). This has bad consequences if the operation fails, for instance due to an OOME or possibly some other unexpected exception. > The operation catches the exception and returns an empty result. The deployment scanner misinterprets that empty result to mean there are no applications deployed and sets .undeployed marker files for all of them. The deployment scanner should confirm if the operation was a success or not so we can avoid potential side effects of undeployed applications from an OOME. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

6 years

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: -------------------------------------------------- Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1052644|https://bugzilla.redhat.com/show_bug.cgi?id=1052644] from MODIFIED to ON_QA > 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 (v6.4.11#64026)

6 years

1
0
0 / 0

[JBoss JIRA] (WFLY-5348) Propagate transaction timeout value for distributed transaction when using JTA and EJB remoting

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-5348?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-5348: ----------------------------------------------- Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1265300|https://bugzilla.redhat.com/show_bug.cgi?id=1265300] from MODIFIED to ON_QA > Propagate transaction timeout value for distributed transaction when using JTA and EJB remoting > ----------------------------------------------------------------------------------------------- > > Key: WFLY-5348 > URL: https://issues.jboss.org/browse/WFLY-5348 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 10.0.0.Beta2 > Reporter: Stephen Fikes > Assignee: Panagiotis Sotiropoulos > Labels: ejb3, jta, transactions > Fix For: 10.0.0.CR4 > > > When a transaction begins in "server 1" and an EJB remoting request is made to "server 2" the timeout value for the transaction branch in "server 2" is initially set to {{Integer.MAX_VALUE}} which means {{set-tx-query-timeout}} does not work properly on datasources enlisted in the distributed branch of the transaction in server 2. This essentially requests that statement execution not be timed out at all (though in some cases the large value seems to result in abnormally fast timeout after a couple of seconds). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

6 years

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: ----------------------------------------------- Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1268185|https://bugzilla.redhat.com/show_bug.cgi?id=1268185] from MODIFIED to ON_QA > 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 (v6.4.11#64026)

6 years

1
0
0 / 0

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira October 2015