April 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-2656) DeploymentTestCase.testFilesystemScannerRegistration fails intermittently

by ehsavoie Hugonnet (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2656?page=com.atlassian.jira.plugi... ] ehsavoie Hugonnet commented on WFCORE-2656: ------------------------------------------- [~brian.stansberry]you are correct I 'see' a rollback of the CapabilityRegistry after the 'failure' of the RT : 2017-04-18 09:43:01,668 TRACE [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) Executing "read-children-resources" [] 2017-04-18 09:43:01,668 TRACE [org.jboss.threads.interrupt-handler] (MSC service thread 1-8) Interrupting thread "Thread[DeploymentScanner-threads - 1,5,DeploymentScanner-threads]" 2017-04-18 09:43:01,668 TRACE [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) Rolling back on cancellation of operation read-children-resources on address [] in stage MODEL 2017-04-18 09:43:01,668 TRACE [org.jboss.as.controller.management-operation] (management-handler-thread - 1) persisting org.jboss.as.controller.registry.BasicResource@4fcba122 from org.jboss.as.controller.ModelControllerImpl$ManagementModelImpl@3c98ea29 2017-04-18 09:43:01,668 INFO [org.jboss.as.controller] (DeploymentScanner-threads - 1) Rollbacking current registry > DeploymentTestCase.testFilesystemScannerRegistration fails intermittently > ------------------------------------------------------------------------- > > Key: WFCORE-2656 > URL: https://issues.jboss.org/browse/WFCORE-2656 > Project: WildFly Core > Issue Type: Bug > Components: Deployment Scanner, Domain Management > Reporter: Brian Stansberry > Assignee: Brian Stansberry > > https://ci.wildfly.org/project.html?projectId=WildFlyCore_PullRequest&tes... > I fear this has something to do with the capability registry and nothing to do with the scanner itself. It started happening when I added a capability to the scanner so it could consume a capability for the path it references. > The test does a quick add/remove/add of a scanner resource and it's the 2nd add that fails with a dupicate capability error. But the remove mean the dup is gone. It's intermittent so I fear some race, but there's nothing obvious. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-2397) Elytron simple-regex-realm-mapper "pattern" attribute has wrong description.

by Chao Wang (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2397?page=com.atlassian.jira.plugi... ] Chao Wang reassigned WFCORE-2397: --------------------------------- Assignee: Chao Wang (was: Darran Lofthouse) > Elytron simple-regex-realm-mapper "pattern" attribute has wrong description. > ---------------------------------------------------------------------------- > > Key: WFCORE-2397 > URL: https://issues.jboss.org/browse/WFCORE-2397 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Hynek Švábek > Assignee: Chao Wang > Fix For: 4.0.0.Alpha1 > > > Elytron simple-regex-realm-mapper "pattern" attribute has wrong description [1]. > *Actual description* > {code} > The regular expression to use for this NameRewriter. > {code} > *Expected description* > Some like that (from DMR): > {code} > The regular expression which must contain at least one capture group to extract the realm from the name. > {code} > [1] https://github.com/wildfly-security/elytron-subsystem/blob/580569d17cb6c3... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-2680) http-interface.http-upgrade should not be marked as "restart-required" => "no-services"

by Martin Choma (JIRA)

Martin Choma created WFCORE-2680: ------------------------------------ Summary: http-interface.http-upgrade should not be marked as "restart-required" => "no-services" Key: WFCORE-2680 URL: https://issues.jboss.org/browse/WFCORE-2680 Project: WildFly Core Issue Type: Bug Components: Domain Management Reporter: Martin Choma Assignee: Brian Stansberry Although {{http-upgrade}} attribute is marked as {{"restart-required" => "no-services"}} in model, when I try change it, server gets into reload required state, anyway. {code} [standalone@localhost:9990 /] /core-service=management/management-interface=http-interface:write-attribute(name=http-upgrade.sasl-authentication-factory, value=application-sasl-authentication) { "outcome" => "success", "response-headers" => { "operation-requires-reload" => true, "process-state" => "reload-required" } } {code} This issue foolows-up JBEAP-9137, where all other {{http-interface}} where marked as {{"restart-required" => "all-services"}}. So seems to me {{http-upgrade}} was ommited just by mistake. {code} "http-upgrade" => { "type" => OBJECT, "description" => "HTTP Upgrade specific configuration", "expressions-allowed" => false, "required" => false, "nillable" => true, "value-type" => { "enabled" => { "type" => BOOLEAN, "description" => "Flag that indicates HTTP Upgrade is enabled, which allows HTTP requests to be upgraded to native remoting connections", "expressions-allowed" => false, "required" => false, "nillable" => true, "default" => false }, "sasl-authentication-factory" => { "type" => STRING, "description" => "The server side SASL authentication policy to use to secure the interface where the connection is after a HTTP upgrade.", "expressions-allowed" => false, "required" => false, "nillable" => true, "capability-reference" => "org.wildfly.security.sasl-authentication-factory", "min-length" => 1L, "max-length" => 2147483647L } }, "access-type" => "read-write", "storage" => "configuration", "restart-required" => "no-services" } {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-2056) wildfly-openssl - wfssl.dll is not automatically loaded on Windows

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2056?page=com.atlassian.jira.plugi... ] Stuart Douglas resolved WFCORE-2056. ------------------------------------ Fix Version/s: 3.0.0.Alpha15 Resolution: Done > wildfly-openssl - wfssl.dll is not automatically loaded on Windows > ------------------------------------------------------------------ > > Key: WFCORE-2056 > URL: https://issues.jboss.org/browse/WFCORE-2056 > Project: WildFly Core > Issue Type: Bug > Components: Security, Server > Environment: Windows 8.1 Pro, 64b > OpenSSL taken from JBCS 2.4.6 (OpenSSL 1.0.1e) > Reporter: Stuart Douglas > Assignee: Stuart Douglas > Labels: wilfly-openssl > Fix For: 3.0.0.Alpha15 > > > It seems that libraries to support OpenSSL via {{wildfly-openssl}} does not bind automatically under the Windows right now. > When I am on Linux, to setup OpenSSL, all I need to do is to have installed OpenSSL on my machine or provide path to my custom OpenSSL libs via "org.wildfly.openssl.path" property. Then I start EAP, set up "openssl.TLS" provider and I am ready to go. > On windows although this seems to be a little bit complicated. When I start EAP with path to my OpenSSL libraries (JBCS OpenSSL) and set up "openssl.TLS" provider, after reload operation I get following error message: > {code} > 2016-11-28 12:27:44,512 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC000001: Failed to start service jboss.server.controller.management.security_realm.ApplicationRealm.ssl-context: org.jboss.msc.service.StartException in service jboss.server.controller.management.security_realm.ApplicationRealm.ssl-context: WFLYDM0018: Unable to start service > at org.jboss.as.domain.management.security.SSLContextService.start(SSLContextService.java:108) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1963) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1896) > at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) > at java.lang.Thread.run(Unknown Source) > Caused by: java.security.NoSuchAlgorithmException: Error constructing implementation (algorithm: openssl.TLS, provider: openssl, class: org.wildfly.openssl.OpenSSLContextSPI$OpenSSLTLSContextSpi) > at java.security.Provider$Service.newInstance(Unknown Source) > at sun.security.jca.GetInstance.getInstance(Unknown Source) > at sun.security.jca.GetInstance.getInstance(Unknown Source) > at javax.net.ssl.SSLContext.getInstance(Unknown Source) > at org.jboss.as.domain.management.security.SSLContextService.start(SSLContextService.java:97) > ... 5 more > Caused by: java.lang.RuntimeException: java.lang.reflect.InvocationTargetException > at org.wildfly.openssl.SSL.init(SSL.java:81) > at org.wildfly.openssl.OpenSSLContextSPI.<init>(OpenSSLContextSPI.java:119) > at org.wildfly.openssl.OpenSSLContextSPI$OpenSSLTLSContextSpi.<init>(OpenSSLContextSPI.java:427) > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source) > at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source) > at java.lang.reflect.Constructor.newInstance(Unknown Source) > ... 10 more > Caused by: java.lang.reflect.InvocationTargetException > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) > at java.lang.reflect.Method.invoke(Unknown Source) > at org.wildfly.openssl.SSL.init(SSL.java:76) > ... 16 more > Caused by: java.lang.UnsatisfiedLinkError: no wfssl in java.library.path > at java.lang.ClassLoader.loadLibrary(Unknown Source) > at java.lang.Runtime.loadLibrary0(Unknown Source) > at java.lang.System.loadLibrary(Unknown Source) > at org.wildfly.openssl.SSL$LibraryLoader.load(SSL.java:188) > ... 21 more > {code} > It seems that "wfssl" library that serves to search and bind OpenSSL libs does not load automatically although it is already present as a module in EAP. When I specify also {{org.wildfly.openssl.libwfssl.path}} property with path to the {{wfssl.dll}} file in the EAP modules, then OpenSSL is successfully initialized during the EAP startup and https requests from clients seems to be working too. > My expectation here is that when "wfssl.dll" library is present as a module in EAP on Windows, it is loaded automatically and user does not have to specify its location. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-2679) Intermittent failures in RemoveManagementRealmTestCase.testAnyCommand

by Brian Stansberry (JIRA)

Brian Stansberry created WFCORE-2679: ---------------------------------------- Summary: Intermittent failures in RemoveManagementRealmTestCase.testAnyCommand Key: WFCORE-2679 URL: https://issues.jboss.org/browse/WFCORE-2679 Project: WildFly Core Issue Type: Bug Components: CLI, Test Suite Reporter: Brian Stansberry Assignee: Jean-Francois Denise Test is failing intermittently in calls to ctrlCAndWaitForClose() https://ci.wildfly.org/project.html?projectId=WildFlyCore&buildTypeId=&ta... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-2678) LDAP credential is revealed when error occurs at startup

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2678?page=com.atlassian.jira.plugi... ] Brian Stansberry moved JBEAP-10370 to WFCORE-2678: -------------------------------------------------- Project: WildFly Core (was: JBoss Enterprise Application Platform) Key: WFCORE-2678 (was: JBEAP-10370) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Domain Management (was: Domain Management) Affects Version/s: (was: 6.4.0.GA) > LDAP credential is revealed when error occurs at startup > -------------------------------------------------------- > > Key: WFCORE-2678 > URL: https://issues.jboss.org/browse/WFCORE-2678 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Environment: - EAP 6.4.13 > Reporter: Hisanobu Okuda > Assignee: Brian Stansberry > > When an error occurs at startup, LDAP credential is shown in the log file. It should not appear. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (WFLY-8568) Elytron outflow-security-domains doesn't work for Servlet-to-EJB calls

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-8568?page=com.atlassian.jira.plugin.... ] Stuart Douglas reassigned WFLY-8568: ------------------------------------ Assignee: David Lloyd (was: Stuart Douglas) > Elytron outflow-security-domains doesn't work for Servlet-to-EJB calls > ---------------------------------------------------------------------- > > Key: WFLY-8568 > URL: https://issues.jboss.org/browse/WFLY-8568 > Project: WildFly > Issue Type: Bug > Components: EJB, Security, Web (Undertow) > Reporter: Josef Cacek > Assignee: David Lloyd > Priority: Blocker > > Security context propagation with using Elytron {{outflow-security-domains}} attribute in security domain doesn't work for Servlet-to-EJB calls. > This could also be a test configuration issue, but as there is not yet documentation covering this area, I can't guess what could be wrong in the scenario. > 1. I have 2 similar web applications with servlets and EJBs: > * the `secured-webapp` is mapped to `web-tests` security domain > * the `second` application is mapped to `second-domain` security domain > 2. Undertow and EJB subsystems maps the application domains `web-tests` and `second-domain` to Elytron domains with the same name. > 3. trust between the domains is defined in following way: > {code} > /subsystem=elytron/security-domain=second-domain:write-attribute(name=outflow-security-domains,value=[web-tests]) > /subsystem=elytron/security-domain=second-domain:write-attribute(name=trusted-security-domains, value=[web-tests]) > /subsystem=elytron/security-domain=web-tests:write-attribute(name=trusted-security-domains, value=[second-domain]) > {code} > 4. the test itself calls servlet from the `second` web application and it calls protected EJB from the `secured-webapp`. > The EJB call fails with EJBAccessException > {noformat} > 14:30:04,631 ERROR [org.jboss.as.ejb3.invocation] (default task-3) WFLYEJB0034: EJB Invocation failed on component HelloBean for method public abstract java.lang.String org.jboss.test.ejb.Hello.sayHello(): javax.ejb.EJBAccessException: WFLYEJB0364: Invocation on method: public abstract java.lang.String org.jboss.test.ejb.Hello.sayHello() of bean: HelloBean is not allowed > {noformat} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (WFLY-8589) Tests in the same module should not use different base packages

by Stuart Douglas (JIRA)

Stuart Douglas created WFLY-8589: ------------------------------------ Summary: Tests in the same module should not use different base packages Key: WFLY-8589 URL: https://issues.jboss.org/browse/WFLY-8589 Project: WildFly Issue Type: Bug Components: Test Suite Reporter: Stuart Douglas Assignee: Stuart Douglas Tests should either all use org.jboss.as or org.wildfly as the base package in the same module. Having both adds confusion as it is not clear where a given test will be. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (WFLY-8588) Tests in the same module should not use different base packages

by Stuart Douglas (JIRA)

Stuart Douglas created WFLY-8588: ------------------------------------ Summary: Tests in the same module should not use different base packages Key: WFLY-8588 URL: https://issues.jboss.org/browse/WFLY-8588 Project: WildFly Issue Type: Bug Reporter: Stuart Douglas Assignee: Jason Greene Tests should either all use org.jboss.as or org.wildfly as the base package in the same module. Having both adds confusion as it is not clear where a given test will be. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (WFLY-8588) Tests in the same module should not use different base packages

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-8588?page=com.atlassian.jira.plugin.... ] Stuart Douglas reassigned WFLY-8588: ------------------------------------ Assignee: Stuart Douglas (was: Jason Greene) > Tests in the same module should not use different base packages > --------------------------------------------------------------- > > Key: WFLY-8588 > URL: https://issues.jboss.org/browse/WFLY-8588 > Project: WildFly > Issue Type: Bug > Reporter: Stuart Douglas > Assignee: Stuart Douglas > > Tests should either all use org.jboss.as or org.wildfly as the base package in the same module. Having both adds confusion as it is not clear where a given test will be. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

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 April 2017