September 2013 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-2087) Administrator should be prevented from modifying super user and auditor roles.

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2087?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2087: ----------------------------------------------- Darran Lofthouse <darran.lofthouse(a)redhat.com> changed the Status of [bug 1012579|https://bugzilla.redhat.com/show_bug.cgi?id=1012579] from ASSIGNED to POST > Administrator should be prevented from modifying super user and auditor roles. > ------------------------------------------------------------------------------ > > Key: WFLY-2087 > URL: https://issues.jboss.org/browse/WFLY-2087 > Project: WildFly > Issue Type: Sub-task > Components: Domain Management, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Critical > Fix For: 8.0.0.Beta1 > > > These roles have maximum privileges in their area, i.e. super user can do everything and auditor can stop changes to the server being logged. > The administrator role should be prevented from modifying these two roles. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2087) Administrator should be prevented from modifying super user and auditor roles.

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2087?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2087: ----------------------------------------------- Darran Lofthouse <darran.lofthouse(a)redhat.com> changed the Status of [bug 1012579|https://bugzilla.redhat.com/show_bug.cgi?id=1012579] from NEW to ASSIGNED > Administrator should be prevented from modifying super user and auditor roles. > ------------------------------------------------------------------------------ > > Key: WFLY-2087 > URL: https://issues.jboss.org/browse/WFLY-2087 > Project: WildFly > Issue Type: Sub-task > Components: Domain Management, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Critical > Fix For: 8.0.0.Beta1 > > > These roles have maximum privileges in their area, i.e. super user can do everything and auditor can stop changes to the server being logged. > The administrator role should be prevented from modifying these two roles. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2087) Administrator should be prevented from modifying super user and auditor roles.

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2087?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated WFLY-2087: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1012579 > Administrator should be prevented from modifying super user and auditor roles. > ------------------------------------------------------------------------------ > > Key: WFLY-2087 > URL: https://issues.jboss.org/browse/WFLY-2087 > Project: WildFly > Issue Type: Sub-task > Components: Domain Management, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Critical > Fix For: 8.0.0.Beta1 > > > These roles have maximum privileges in their area, i.e. super user can do everything and auditor can stop changes to the server being logged. > The administrator role should be prevented from modifying these two roles. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2166) servlet-connector uses socket-binding's host

by Jeff Mesnil (JIRA)

Jeff Mesnil created WFLY-2166: --------------------------------- Summary: servlet-connector uses socket-binding's host Key: WFLY-2166 URL: https://issues.jboss.org/browse/WFLY-2166 Project: WildFly Issue Type: Bug Components: JMS Reporter: Jeff Mesnil Assignee: Jeff Mesnil The servlet-connector has socket-binding attribute that is used to determine the host & port of the HTTP server so that a client can connect to it. It determines the host by calling the SocketBinding's getDestinationAddress().getHostAddress() method. This may lead to issues if the HTTP server is behind a proxy as the servlet-connector will use the address of the HTTP server and bypass the proxy. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-315) Avoid running out of threads when connecting to the DC from a slave to pull down missing data

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFLY-315?page=com.atlassian.jira.plugin.s... ] Kabir Khan updated WFLY-315: ---------------------------- Description: For WFLY-259 when a slave connects to the DC to pull down missing data, it does this by either getting a lock for the DC, or by joining the permit of the existing DC lock if the request to update a slave's server-config was executed as part of a composite obtaining a lock on the DC. The way it works at present there is a thread per slave which is blocked until the transaction completes. The DC threads are a finite resource, so a large number of slaves trying to pull down dats will cause deadlock was: For AS7-6808 when a slave connects to the DC to pull down missing data, it does this by either getting a lock for the DC, or by joining the permit of the existing DC lock if the request to update a slave's server-config was executed as part of a composite obtaining a lock on the DC. The way it works at present there is a thread per slave which is blocked until the transaction completes. The DC threads are a finite resource, so a large number of slaves trying to pull down dats will cause deadlock > Avoid running out of threads when connecting to the DC from a slave to pull down missing data > --------------------------------------------------------------------------------------------- > > Key: WFLY-315 > URL: https://issues.jboss.org/browse/WFLY-315 > Project: WildFly > Issue Type: Feature Request > Components: Domain Management > Reporter: Kabir Khan > Assignee: Kabir Khan > Fix For: 8.0.0.Beta1 > > > For WFLY-259 when a slave connects to the DC to pull down missing data, it does this by either getting a lock for the DC, or by joining the permit of the existing DC lock if the request to update a slave's server-config was executed as part of a composite obtaining a lock on the DC. > The way it works at present there is a thread per slave which is blocked until the transaction completes. The DC threads are a finite resource, so a large number of slaves trying to pull down dats will cause deadlock -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2165) Error Weld when starting WildFly 8 with Spring 3 - NullPointerException

by Raul Abreu Leite (JIRA)

[ https://issues.jboss.org/browse/WFLY-2165?page=com.atlassian.jira.plugin.... ] Raul Abreu Leite commented on WFLY-2165: ---------------------------------------- Hello Matus Abaffy. Sorry for my delay. Unfortunately I abandoned this project temporarily. But I can help in any way possible. I can attach the war and send the link of the source code from github. How do I do this in private? To reproduce the error, just start the server containing the war (in standalone/deployments, in my case). The server will not start and shows the message NPE. If you need more details, you can ask me. > Error Weld when starting WildFly 8 with Spring 3 - NullPointerException > ----------------------------------------------------------------------- > > Key: WFLY-2165 > URL: https://issues.jboss.org/browse/WFLY-2165 > Project: WildFly > Issue Type: Bug > Components: CDI / Weld > Reporter: Raul Abreu Leite > Assignee: Matus Abaffy > Priority: Critical > Fix For: 8.0.0.Beta1 > > > When I update my application, from Jboss-as 7.1.1.Final to Wildfly 8.0.0.Alpha4, there was an error that I can not fix. > {code:java} > 19:57:20,955 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.deployment.unit."cineserver.war".component."org.springframework.web.context.request.async.StandardServletAsyncWebRequest".WeldInstantiator: org.jboss.msc.service.StartException in service jboss.deployment.unit."cineserver.war".component."org.springframework.web.context.request.async.StandardServletAsyncWebRequest".WeldInstantiator: Failed to start service > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1900) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25] > at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25] > Caused by: java.lang.NullPointerException > at org.jboss.weld.injection.InjectionPointFactory.getParameterInjectionPoints(InjectionPointFactory.java:245) > at org.jboss.weld.injection.AbstractCallableInjectionPoint.<init>(AbstractCallableInjectionPoint.java:49) > at org.jboss.weld.injection.ConstructorInjectionPoint.<init>(ConstructorInjectionPoint.java:59) > at org.jboss.weld.injection.InjectionPointFactory.createConstructorInjectionPoint(InjectionPointFactory.java:173) > at org.jboss.weld.injection.producer.DefaultInstantiator.<init>(DefaultInstantiator.java:46) > at org.jboss.weld.injection.producer.BasicInjectionTarget.initInstantiator(BasicInjectionTarget.java:144) > at org.jboss.weld.injection.producer.BasicInjectionTarget.<init>(BasicInjectionTarget.java:72) > at org.jboss.as.weld.injection.NonContextualComponentInjectionTarget.<init>(NonContextualComponentInjectionTarget.java:48) > at org.jboss.as.weld.injection.NonContextualComponentInjectionTarget.<init>(NonContextualComponentInjectionTarget.java:44) > at org.jboss.as.weld.injection.WeldComponentService.start(WeldComponentService.java:129) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1944) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1877) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2] > ... 3 more > 19:57:21,018 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "cineserver.war")]) - failure description: {"JBAS014671: Failed services" => {"jboss.deployment.unit.\"cineserver.war\".component.\"org.springframework.web.context.request.async.StandardServletAsyncWebRequest\".WeldInstantiator" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"cineserver.war\".component.\"org.springframework.web.context.request.async.StandardServletAsyncWebRequest\".WeldInstantiator: Failed to start service > Caused by: java.lang.NullPointerException"}} > 19:57:21,018 ERROR [org.jboss.as.server] (DeploymentScanner-threads - 1) JBAS015870: Deploy of deployment "cineserver.war" was rolled back with the following failure message: > {"JBAS014671: Failed services" => {"jboss.deployment.unit.\"cineserver.war\".component.\"org.springframework.web.context.request.async.StandardServletAsyncWebRequest\".WeldInstantiator" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"cineserver.war\".component.\"org.springframework.web.context.request.async.StandardServletAsyncWebRequest\".WeldInstantiator: Failed to start service > Caused by: java.lang.NullPointerException"}} > {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2139) ProxyStepHandler/Controller need to check access before attempting to read information

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFLY-2139?page=com.atlassian.jira.plugin.... ] Kabir Khan resolved WFLY-2139. ------------------------------ Resolution: Done > ProxyStepHandler/Controller need to check access before attempting to read information > -------------------------------------------------------------------------------------- > > Key: WFLY-2139 > URL: https://issues.jboss.org/browse/WFLY-2139 > Project: WildFly > Issue Type: Sub-task > Components: Domain Management, Security > Reporter: Kabir Khan > Assignee: Kabir Khan > Fix For: 8.0.0.Beta1 > > > This affects things like recursive :read-resource(-description) :read-children-resources and so on. The problem as it stands is that if you have, say, a host scoped role scoped to host=master, and there is also a slave host controller, and you try to :read-resource(recursive=true,proxies=true), the master will list the slave host controller in its list of child addresses. It will then execute /host=slave:read-resource(recursive=true,proxies=true), which will fail and roll back the tx since the master host scoped role does not have access to that resource. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1765) JDBC object store does not change LOG_STORE_TYPE attribute

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-1765?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-1765: ----------------------------------------------- Ivo Studensky <istudens(a)redhat.com> changed the Status of [bug 1002976|https://bugzilla.redhat.com/show_bug.cgi?id=1002976] from ASSIGNED to POST > JDBC object store does not change LOG_STORE_TYPE attribute > ---------------------------------------------------------- > > Key: WFLY-1765 > URL: https://issues.jboss.org/browse/WFLY-1765 > Project: WildFly > Issue Type: Bug > Components: Transactions > Affects Versions: 8.0.0.Alpha3 > Reporter: Ivo Studensky > Assignee: Ivo Studensky > > The transaction subsystem when set up to JDBC object store should keep a note about it in log-store-type attribute as HornetQ object store does. It seems not to be consistent when one object store does this, but others do not. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1765) JDBC object store does not change LOG_STORE_TYPE attribute

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-1765?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-1765: ----------------------------------------------- Ivo Studensky <istudens(a)redhat.com> made a comment on [bug 1002976|https://bugzilla.redhat.com/show_bug.cgi?id=1002976] Relevant PR: https://github.com/jbossas/jboss-eap/pull/470 > JDBC object store does not change LOG_STORE_TYPE attribute > ---------------------------------------------------------- > > Key: WFLY-1765 > URL: https://issues.jboss.org/browse/WFLY-1765 > Project: WildFly > Issue Type: Bug > Components: Transactions > Affects Versions: 8.0.0.Alpha3 > Reporter: Ivo Studensky > Assignee: Ivo Studensky > > The transaction subsystem when set up to JDBC object store should keep a note about it in log-store-type attribute as HornetQ object store does. It seems not to be consistent when one object store does this, but others do not. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2126) Servlet Invocation WildflySecurityManager Setup

by Eduardo Martins (JIRA)

[ https://issues.jboss.org/browse/WFLY-2126?page=com.atlassian.jira.plugin.... ] Eduardo Martins resolved WFLY-2126. ----------------------------------- Resolution: Won't Fix While the issue is valid, it seems to be just part of a bigger task, which is setup properly security on undertow subsystem, and once that one is worked out, this particular issue may not make sense anymore, thus resolving it with "won't fix" > Servlet Invocation WildflySecurityManager Setup > ------------------------------------------------ > > Key: WFLY-2126 > URL: https://issues.jboss.org/browse/WFLY-2126 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Reporter: Eduardo Martins > Assignee: Eduardo Martins > > WildflySecurityManager needs proper setup on the servlet invocation stack, otherwise WildflySecurityManager.isChecking() returns always false, and such check is used by Wildfly modules/extensions to learn wether there is an active security manager or not. The servlet invocation also needs to be done on a privileged action, otherwise security permissions fail to check. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 8 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira September 2013