December 2015 - jboss-jira - Jboss List Archives

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

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

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1202) LDAP authentication/authorization fails due to making unneeded role lookup requests

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1202?page=com.atlassian.jira.plugi... ] RH Bugzilla Integration commented on WFCORE-1202: ------------------------------------------------- Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1196343|https://bugzilla.redhat.com/show_bug.cgi?id=1196343] from MODIFIED to ON_QA > LDAP authentication/authorization fails due to making unneeded role lookup requests > ----------------------------------------------------------------------------------- > > Key: WFCORE-1202 > URL: https://issues.jboss.org/browse/WFCORE-1202 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Brad Maxwell > Assignee: Derek Horton > Fix For: 2.0.5.Final > > > LDAP authentication/authorization fails due to making unneeded role lookup requests -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4451) Security ModuleClassLoaderLocator.CombinedClassLoader does not implement getResources

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-4451?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-4451: ----------------------------------------------- Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1204300|https://bugzilla.redhat.com/show_bug.cgi?id=1204300] from MODIFIED to ON_QA > Security ModuleClassLoaderLocator.CombinedClassLoader does not implement getResources > ------------------------------------------------------------------------------------- > > Key: WFLY-4451 > URL: https://issues.jboss.org/browse/WFLY-4451 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 9.0.0.Alpha1 > Reporter: Brad Maxwell > Assignee: Brad Maxwell > Fix For: 9.0.0.Beta2 > > > org.jboss.as.security.plugins.ModuleClassLoaderLocator.CombinedClassLoader does not implement getResources. This classloader combines a module classloader with the thread context classloader. It implements loadClass, getResource & getResourceAsStream and checks the module classloader first and if it finds it returns it else checks the TCCL. > It does not implement getResources which causes custom security login modules to not be able to locate resources via getResources. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1008) KieServer to update container for SNAPSHOT kjar

by Edson Tirelli (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1008?page=com.atlassian.jira.plugi... ] Edson Tirelli reassigned DROOLS-1008: ------------------------------------- Assignee: Mario Fusco (was: Edson Tirelli) > KieServer to update container for SNAPSHOT kjar > ----------------------------------------------- > > Key: DROOLS-1008 > URL: https://issues.jboss.org/browse/DROOLS-1008 > Project: Drools > Issue Type: Feature Request > Components: kie server > Affects Versions: 6.2.0.Final, 6.3.0.Final > Reporter: Andrew Collins > Assignee: Mario Fusco > Attachments: snapshot_kjar_reproducer.patch > > > When a kjar is a snapshot version, kie-server will not react to new snapshot versions deployed to a remote artifact repository. The remote artifact repository is only queried the first time after JVM startup. Updating a KieContainer to a newer snapshot version is only possible through use of the KieScanner, which will both fetch the new artifact from the remote repository, and reload the kmodule in the KieServer JVM. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1008) KieServer to update container for SNAPSHOT kjar

by Andrew Collins (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1008?page=com.atlassian.jira.plugi... ] Andrew Collins edited comment on DROOLS-1008 at 12/16/15 12:01 PM: ------------------------------------------------------------------- Attached patch to master that includes kie-server integration test to demonstrate this issue. The failing tests should pass when this feature is implemented. After applying patch, test.sh will execute maven build to run specified test (assuming eap6.4 is downloaded) After debugging, the snapshot resolution against the remote repository only happens because a new MavenRepository is created from KieRepositoryScannerImpl.scanNow() that has a new RepositorySystemSession. Am not completely familiar with RepositorySystemSession, but I would think the session should live as long as it does attached to Aether, and should be terminated following KieContainer creation. was (Author: acollins): Attached patch to master that includes kie-server integration test to demonstrate this issue. The failing tests should pass when this feature is implemented. After debugging, the snapshot resolution against the remote repository only happens because a new MavenRepository is created from KieRepositoryScannerImpl.scanNow() that has a new RepositorySystemSession. Am not completely familiar with RepositorySystemSession, but I would think the session should live as long as it does attached to Aether, and should be terminated following KieContainer creation. > KieServer to update container for SNAPSHOT kjar > ----------------------------------------------- > > Key: DROOLS-1008 > URL: https://issues.jboss.org/browse/DROOLS-1008 > Project: Drools > Issue Type: Feature Request > Components: kie server > Affects Versions: 6.2.0.Final, 6.3.0.Final > Reporter: Andrew Collins > Assignee: Edson Tirelli > Attachments: snapshot_kjar_reproducer.patch > > > When a kjar is a snapshot version, kie-server will not react to new snapshot versions deployed to a remote artifact repository. The remote artifact repository is only queried the first time after JVM startup. Updating a KieContainer to a newer snapshot version is only possible through use of the KieScanner, which will both fetch the new artifact from the remote repository, and reload the kmodule in the KieServer JVM. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1008) KieServer to update container for SNAPSHOT kjar

by Andrew Collins (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1008?page=com.atlassian.jira.plugi... ] Andrew Collins commented on DROOLS-1008: ---------------------------------------- Attached patch to master that includes kie-server integration test to demonstrate this issue. The failing tests should pass when this feature is implemented. After debugging, the snapshot resolution against the remote repository only happens because a new MavenRepository is created from KieRepositoryScannerImpl.scanNow() that has a new RepositorySystemSession. Am not completely familiar with RepositorySystemSession, but I would think the session should live as long as it does attached to Aether, and should be terminated following KieContainer creation. > KieServer to update container for SNAPSHOT kjar > ----------------------------------------------- > > Key: DROOLS-1008 > URL: https://issues.jboss.org/browse/DROOLS-1008 > Project: Drools > Issue Type: Feature Request > Components: kie server > Affects Versions: 6.2.0.Final, 6.3.0.Final > Reporter: Andrew Collins > Assignee: Edson Tirelli > Attachments: snapshot_kjar_reproducer.patch > > > When a kjar is a snapshot version, kie-server will not react to new snapshot versions deployed to a remote artifact repository. The remote artifact repository is only queried the first time after JVM startup. Updating a KieContainer to a newer snapshot version is only possible through use of the KieScanner, which will both fetch the new artifact from the remote repository, and reload the kmodule in the KieServer JVM. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1008) KieServer to update container for SNAPSHOT kjar

by Andrew Collins (JIRA)

Andrew Collins created DROOLS-1008: -------------------------------------- Summary: KieServer to update container for SNAPSHOT kjar Key: DROOLS-1008 URL: https://issues.jboss.org/browse/DROOLS-1008 Project: Drools Issue Type: Feature Request Components: kie server Affects Versions: 6.3.0.Final, 6.2.0.Final Reporter: Andrew Collins Assignee: Edson Tirelli Attachments: snapshot_kjar_reproducer.patch When a kjar is a snapshot version, kie-server will not react to new snapshot versions deployed to a remote artifact repository. The remote artifact repository is only queried the first time after JVM startup. Updating a KieContainer to a newer snapshot version is only possible through use of the KieScanner, which will both fetch the new artifact from the remote repository, and reload the kmodule in the KieServer JVM. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1201) Could not upload new deployment

by Harald Pehl (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1201?page=com.atlassian.jira.plugi... ] Harald Pehl edited comment on WFCORE-1201 at 12/16/15 11:41 AM: ---------------------------------------------------------------- Up to now I was not able to reproduce the error. Tested with WildFly Core 2.0.4.Final "Kenny", HAL 2.8.16.Final and these OS / browser combinations: - Chrome 47.0.2526.80 on OSX El Capitan 10.11.1 (15B42) ^1^ - Chrome 46.0.2490.86 on OSX El Capitan 10.11.1 (15B42) ^1^ - Chrome 47.0.2526.73 on Windows 10 - Chrome 47.0.2526.73 on Windows 8.1 - Chrome 47.0.2526.73 on Windows 8 - Chrome 47.0.2526.73 on Windows 7 ^1^ Wasn't able to get Chrome 47.0.2526.73 for OSX was (Author: harald.pehl): Up to now I was not able to reproduce the error. Tested with WildFly Core 2.0.4.Final "Kenny", HAL 2.8.16.Final and these OS / browser combinations: - Chrome 47.0.2526.80 on OSX El Capitan 10.11.1 (15B42) * - Chrome 46.0.2490.86 on OSX El Capitan 10.11.1 (15B42) * - Chrome 47.0.2526.73 on Windows 10 - Chrome 47.0.2526.73 on Windows 8.1 - Chrome 47.0.2526.73 on Windows 8 - Chrome 47.0.2526.73 on Windows 7 * Wasn't able to get Chrome 47.0.2526.73 for OSX > Could not upload new deployment > ------------------------------- > > Key: WFCORE-1201 > URL: https://issues.jboss.org/browse/WFCORE-1201 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 1.0.2.Final > Environment: 2 different machines > Linux Debian Squeeze & Jessie > Oracle Java SE 8 > Reporter: Claudio Weiler > Assignee: Harald Pehl > Fix For: 2.0.5.Final > > > WildFly stop to accept deployments via interface upload with following stacktrace: > ERROR [io.undertow.request] (XNIO-1 task-2) Undertow request failed HttpServerExchange{ POST /management-upload}: java.io.IOException: UT000036: Connection terminated parsing multipart data > at io.undertow.server.handlers.form.MultiPartParserDefinition$MultiPartUploadHandler.parseBlocking(MultiPartParserDefinition.java:203) > at org.jboss.as.domain.http.server.DomainApiGenericOperationHandler.handleRequest(DomainApiGenericOperationHandler.java:104) > at io.undertow.server.handlers.encoding.EncodingHandler.handleRequest(EncodingHandler.java:72) > at org.jboss.as.domain.http.server.security.SubjectDoAsHandler$1.run(SubjectDoAsHandler.java:72) > at org.jboss.as.domain.http.server.security.SubjectDoAsHandler$1.run(SubjectDoAsHandler.java:68) > at java.security.AccessController.doPrivileged(Native Method) > at javax.security.auth.Subject.doAs(Subject.java:422) > at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:92) > at org.jboss.as.domain.http.server.security.SubjectDoAsHandler.handleRequest(SubjectDoAsHandler.java:68) > at org.jboss.as.domain.http.server.security.SubjectDoAsHandler.handleRequest(SubjectDoAsHandler.java:63) > at io.undertow.server.handlers.BlockingHandler.handleRequest(BlockingHandler.java:56) > at org.jboss.as.domain.http.server.DomainApiCheckHandler.handleRequest(DomainApiCheckHandler.java:87) > at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:199) > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:774) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > Same artifact was used before with success, nothing changed. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1201) Could not upload new deployment

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1201?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1201: ------------------------------------- Priority: Major (was: Blocker) > Could not upload new deployment > ------------------------------- > > Key: WFCORE-1201 > URL: https://issues.jboss.org/browse/WFCORE-1201 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 1.0.2.Final > Environment: 2 different machines > Linux Debian Squeeze & Jessie > Oracle Java SE 8 > Reporter: Claudio Weiler > Assignee: Harald Pehl > Fix For: 2.0.5.Final > > > WildFly stop to accept deployments via interface upload with following stacktrace: > ERROR [io.undertow.request] (XNIO-1 task-2) Undertow request failed HttpServerExchange{ POST /management-upload}: java.io.IOException: UT000036: Connection terminated parsing multipart data > at io.undertow.server.handlers.form.MultiPartParserDefinition$MultiPartUploadHandler.parseBlocking(MultiPartParserDefinition.java:203) > at org.jboss.as.domain.http.server.DomainApiGenericOperationHandler.handleRequest(DomainApiGenericOperationHandler.java:104) > at io.undertow.server.handlers.encoding.EncodingHandler.handleRequest(EncodingHandler.java:72) > at org.jboss.as.domain.http.server.security.SubjectDoAsHandler$1.run(SubjectDoAsHandler.java:72) > at org.jboss.as.domain.http.server.security.SubjectDoAsHandler$1.run(SubjectDoAsHandler.java:68) > at java.security.AccessController.doPrivileged(Native Method) > at javax.security.auth.Subject.doAs(Subject.java:422) > at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:92) > at org.jboss.as.domain.http.server.security.SubjectDoAsHandler.handleRequest(SubjectDoAsHandler.java:68) > at org.jboss.as.domain.http.server.security.SubjectDoAsHandler.handleRequest(SubjectDoAsHandler.java:63) > at io.undertow.server.handlers.BlockingHandler.handleRequest(BlockingHandler.java:56) > at org.jboss.as.domain.http.server.DomainApiCheckHandler.handleRequest(DomainApiCheckHandler.java:87) > at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:199) > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:774) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > Same artifact was used before with success, nothing changed. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 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 December 2015