August 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (HAWKULARQE-157) [QE] - JMAN4-203 - Fuse integration - add Fuse server entity representation in MIQ

by Hayk Hovsepyan (JIRA)

Hayk Hovsepyan created HAWKULARQE-157: ----------------------------------------- Summary: [QE] - JMAN4-203 - Fuse integration - add Fuse server entity representation in MIQ Key: HAWKULARQE-157 URL: https://issues.jboss.org/browse/HAWKULARQE-157 Project: Hawkular QE Issue Type: Task Reporter: Hayk Hovsepyan Assignee: Michael Foley See [JMAN4-203|https://issues.jboss.org/browse/JMAN4-203] -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-975) Default distinguishedNameAttribute value of LdapExtLoginModule causes not working referrals on MS Active Directory

by Jiri Ondrusek (JIRA)

[ https://issues.jboss.org/browse/SECURITY-975?page=com.atlassian.jira.plug... ] Jiri Ondrusek moved JBEAP-12683 to SECURITY-975: ------------------------------------------------ Project: PicketBox (was: JBoss Enterprise Application Platform) Key: SECURITY-975 (was: JBEAP-12683) Workflow: classic default workflow (was: CDW with loose statuses v1) Component/s: PicketBox (was: Security) Affects Version/s: PicketBox_5_0_2.Final (was: 7.0.0.ER4) > Default distinguishedNameAttribute value of LdapExtLoginModule causes not working referrals on MS Active Directory > ------------------------------------------------------------------------------------------------------------------ > > Key: SECURITY-975 > URL: https://issues.jboss.org/browse/SECURITY-975 > Project: PicketBox > Issue Type: Bug > Components: PicketBox > Affects Versions: PicketBox_5_0_2.Final > Reporter: Jiri Ondrusek > Assignee: Jiri Ondrusek > > In case when crossRef object to different domain is configured on MS Active Directory for handling referrals and JBoss EAP 7 uses LdapExtLoginModule then default value ('distinguishedName') of distinguishedNameAttribute option causes wrong handling of referrals which leads to authentication fail for referral users. > Referral object is returned by original LDAP server (LDAP server which includes crossRef to different domain) but user is obtained through value of distinguishedName attribute from that response. It leads to authentication attempt with referral user against original LDAP server instead of referenced LDAP server which results to failed authentication. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3147) Getting org.osgi.framework.AdminPermission check failed with security manager

by Martin Choma (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3147?page=com.atlassian.jira.plugi... ] Martin Choma commented on WFCORE-3147: -------------------------------------- I can't reproduce. I have * removed permissions.xml (because I am in impression this is problem of subsystem) * emptied jboss-web.xml, because I don't have necessary undertow configuration. But I get {code} 10:23:15,675 ERROR [io.undertow.servlet] (ServerService Thread Pool -- 66) Error while starting Framework: java.lang.RuntimeException: Could not find framework at org.eclipse.equinox.servletbridge.FrameworkLauncher.findFrameworkURLs(FrameworkLauncher.java:443) at org.eclipse.equinox.servletbridge.FrameworkLauncher.start(FrameworkLauncher.java:400) at org.eclipse.equinox.servletbridge.BridgeServlet.init(BridgeServlet.java:65) at javax.servlet.GenericServlet.init(GenericServlet.java:244) at io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:117) at org.wildfly.extension.undertow.security.RunAsLifecycleInterceptor.init(RunAsLifecycleInterceptor.java:78) at io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:103) at io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:250) at io.undertow.servlet.core.ManagedServlet.createServlet(ManagedServlet.java:133) at io.undertow.servlet.core.DeploymentManagerImpl$2.call(DeploymentManagerImpl.java:565) at io.undertow.servlet.core.DeploymentManagerImpl$2.call(DeploymentManagerImpl.java:536) at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:42) at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1506) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1506) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1506) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1506) at io.undertow.servlet.core.DeploymentManagerImpl.start(DeploymentManagerImpl.java:578) at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:100) at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:81) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.run(FutureTask.java:266) 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:748) at org.jboss.threads.JBossThread.run(JBossThread.java:320) 10:23:15,677 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 66) MSC000001: Failed to start service jboss.undertow.deployment.default-server.default-host./sampleApp: org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./sampleApp: java.lang.RuntimeException: Could not find framework at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:84) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.run(FutureTask.java:266) 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:748) at org.jboss.threads.JBossThread.run(JBossThread.java:320) Caused by: java.lang.RuntimeException: Could not find framework at org.eclipse.equinox.servletbridge.FrameworkLauncher.start(FrameworkLauncher.java:421) at org.eclipse.equinox.servletbridge.BridgeServlet.init(BridgeServlet.java:65) at javax.servlet.GenericServlet.init(GenericServlet.java:244) at io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:117) at org.wildfly.extension.undertow.security.RunAsLifecycleInterceptor.init(RunAsLifecycleInterceptor.java:78) at io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:103) at io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:250) at io.undertow.servlet.core.ManagedServlet.createServlet(ManagedServlet.java:133) at io.undertow.servlet.core.DeploymentManagerImpl$2.call(DeploymentManagerImpl.java:565) at io.undertow.servlet.core.DeploymentManagerImpl$2.call(DeploymentManagerImpl.java:536) at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:42) at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1506) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1506) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1506) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1506) at io.undertow.servlet.core.DeploymentManagerImpl.start(DeploymentManagerImpl.java:578) at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:100) at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:81) ... 6 more {code} Maybe if you upload your standalone.xml it could help. > Getting org.osgi.framework.AdminPermission check failed with security manager > ----------------------------------------------------------------------------- > > Key: WFCORE-3147 > URL: https://issues.jboss.org/browse/WFCORE-3147 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 3.0.0.Beta30 > Reporter: Martin Choma > Assignee: Darran Lofthouse > Priority: Trivial > Attachments: sampleApp.war > > > Despite permission is granted in standalone.xml > {code} > <minimum-set> > <permission class="org.osgi.framework.AdminPermission" name="(id=0)" actions="context"/> > </minimum-set> > {code} > During deployment there is exception > {code} > java.security.AccessControlException: WFSM000001: Permission check failed (permission "("org.osgi.framework.AdminPermission" "(id=0)" "context")" in code source "(vfs:/content/myapp.war/WEB-INF/lib/org.eclipse.equinox.servletbridge_1.2.100.v20120209-2014.jar > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2207) Use of AUTH does not result in a SecurityException if another client does not use AUTH

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2207?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2207: -------------------------------- No problem! As you may have seen, I released 4.0.5 yesterday. Cheers > Use of AUTH does not result in a SecurityException if another client does not use AUTH > -------------------------------------------------------------------------------------- > > Key: JGRP-2207 > URL: https://issues.jboss.org/browse/JGRP-2207 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.0.4 > Reporter: Mirko Streckenbach > Assignee: Bela Ban > Fix For: 4.0.5 > > Attachments: JGroupsAuthExample.java, JGroupsAuthExample.java > > > If there are two members in a cluster, one with AUTH configured and started first, so it can become the coordinator and a second without AUTH, the documentation implies that the second should receive a SecurityException. Instead, it creates it's own cluster. This works as expected if the second member uses AUTH, but has a different SecurityToken. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBMETA-398) The jboss-web_7_1.xsd and 7.2.xsd file cause validation errors in Eclipse

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBMETA-398?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on JBMETA-398: ------------------------------------------------ Radovan Netuka <rnetuka(a)redhat.com> changed the Status of [bug 1208342|https://bugzilla.redhat.com/show_bug.cgi?id=1208342] from ASSIGNED to POST > The jboss-web_7_1.xsd and 7.2.xsd file cause validation errors in Eclipse > ------------------------------------------------------------------------- > > Key: JBMETA-398 > URL: https://issues.jboss.org/browse/JBMETA-398 > Project: JBoss Metadata > Issue Type: Bug > Components: web > Affects Versions: 7.2.0.Final > Reporter: Radovan Netuka > Assignee: Radovan Netuka > > The jboss-web_7_2.xsd file cause validation errors in eclipse. > The following error from line 261: > src-ct.2.1: Complex Type Definition Representation Error for type 'symbolic-linked-allowedType'. When <simpleContent> is used, the base type must be a complexType whose content type is simple, or, only if restriction is specified, a complex type with mixed content and emptiable particle, or, only if extension is specified, a simple type. 'boolean' satisfies none of these conditions > This also happens in jboss-web_7_1.xsd -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9216) Upgrade wildfly-arquillian from 2.1.0.Alpha1 to 2.1.0.Beta1

by James Perkins (JIRA)

James Perkins created WFLY-9216: ----------------------------------- Summary: Upgrade wildfly-arquillian from 2.1.0.Alpha1 to 2.1.0.Beta1 Key: WFLY-9216 URL: https://issues.jboss.org/browse/WFLY-9216 Project: WildFly Issue Type: Component Upgrade Components: Test Suite Reporter: James Perkins Assignee: James Perkins This upgrade will require some minor test changes. During deployments the exceptions thrown seem to nested a bit differently than some tests expect. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9217) Upgrade wildfly-arquillian from 2.1.0.Alpha1 to 2.1.0.Beta1

by James Perkins (JIRA)

James Perkins created WFLY-9217: ----------------------------------- Summary: Upgrade wildfly-arquillian from 2.1.0.Alpha1 to 2.1.0.Beta1 Key: WFLY-9217 URL: https://issues.jboss.org/browse/WFLY-9217 Project: WildFly Issue Type: Component Upgrade Components: Test Suite Reporter: James Perkins Assignee: James Perkins This upgrade will require some minor test changes. During deployments the exceptions thrown seem to nested a bit differently than some tests expect. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3178) Upgrade jboss-logging-tools to version 2.1.0.Final

by James Perkins (JIRA)

James Perkins created WFCORE-3178: ------------------------------------- Summary: Upgrade jboss-logging-tools to version 2.1.0.Final Key: WFCORE-3178 URL: https://issues.jboss.org/browse/WFCORE-3178 Project: WildFly Core Issue Type: Component Upgrade Components: Logging Reporter: James Perkins Assignee: James Perkins Upgrade the logging annotations and processor to 2.1.0.Final -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3120) Tests broken as part of WildFly Core 3.0.0.Beta16

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3120?page=com.atlassian.jira.plugi... ] Brian Stansberry reopened WFCORE-3120: -------------------------------------- Fix was reverted due to seeing failures of the test in CI. > Tests broken as part of WildFly Core 3.0.0.Beta16 > ------------------------------------------------- > > Key: WFCORE-3120 > URL: https://issues.jboss.org/browse/WFCORE-3120 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Ken Wills > Assignee: Ken Wills > Fix For: 3.0.0.CR1 > > > These tests were moved to wildfly-core previously. > Tests shown here are going to be ignored or otherwise modified in order to get the core 3.0.0.Beta16 release integrated. > org.jboss.as.test.integration.domain.elytron.SlaveHostControllerElytronAuthenticationTestCase.testSlaveRegistration > org.jboss.as.test.integration.security.perimeter.CLISecurityTestCase.testConnect -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3177) The BootLoggingPatchingStateTestCase fails if the message assertion is flipped

by James Perkins (JIRA)

James Perkins created WFCORE-3177: ------------------------------------- Summary: The BootLoggingPatchingStateTestCase fails if the message assertion is flipped Key: WFCORE-3177 URL: https://issues.jboss.org/browse/WFCORE-3177 Project: WildFly Core Issue Type: Bug Components: Patching , Test Suite Reporter: James Perkins Assignee: Alexey Loubyansky Priority: Blocker Fix For: 3.0.0.CR1 The {{BootLoggingPatchingStateTestCase}} tests two patches which use a different version and product id for the patch. The tests currently pass because of the order of the [{{Collection.containsAll()}}|https://github.com/wildfly/wildfly-core/blob/0b51f7c1cce7286bf4f4e3f5c9250bf351bbdf1b/testsuite/patching/src/test/java/org/jboss/as/test/patching/BootLoggingPatchingStateTestCase.java#L151]. However if this is flipped the tests fail. It appears that the messages logged always contain the "WildFly" product id. Also the UUID for the failing examples seems to not be logged either. Example of logged messages for the "lp1" patch in the test: {code} WildFly cumulative patch ID is: 936c95a3-f08e-4fc0-9917-f7feead4ef25, one-off patches include: 00699c2c-84a5-4bdb-b469-8c2fd66afe2a, c6df609e-1620-4369-af48-8041d4be093f WildFly cumulative patch ID is: 936c95a3-f08e-4fc0-9917-f7feead4ef25, one-off patches include: 00699c2c-84a5-4bdb-b469-8c2fd66afe2a, c6df609e-1620-4369-af48-8041d4be093f {code} It looks like the same message is logged twice. However the following is what's expected: {code} lp1 cumulative patch ID is: base, one-off patches include: 50a820e4-3659-437d-86f2-fa1d64728adb WildFly cumulative patch ID is: 936c95a3-f08e-4fc0-9917-f7feead4ef25, one-off patches include: 00699c2c-84a5-4bdb-b469-8c2fd66afe2a, c6df609e-1620-4369-af48-8041d4be093f {code} I'm not sure if this is just an issue with the test or if there is a bug in patching. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 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 August 2017