February 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-7987) Remove operations should warn the user if the resource has any dependents

by Guillermo González de Agüero (JIRA)

[ https://issues.jboss.org/browse/WFLY-7987?page=com.atlassian.jira.plugin.... ] Guillermo González de Agüero commented on WFLY-7987: ---------------------------------------------------- Hi [~brian.stansberry]. My original report on this issue was based on a wrong assumption that services = capabilities, so I think I'd better close this. For the new capabilities requests, I understand I should open one issue for each one, so it can be correctly categorized, right? I want to confirm just to prevent spamming Jira with too much issues. Thanks! > Remove operations should warn the user if the resource has any dependents > ------------------------------------------------------------------------- > > Key: WFLY-7987 > URL: https://issues.jboss.org/browse/WFLY-7987 > Project: WildFly > Issue Type: Task > Components: Web (Undertow) > Affects Versions: 10.1.0.Final > Reporter: Guillermo González de Agüero > Assignee: Stuart Douglas > > Services may have dependents that can't work if they are not present. Removal operations should prevent, or least warn the user then he is about to remove a service that may have side effects. > Take a look at this example: > {code:shell} > [standalone@localhost:9990 /] /subsystem=undertow/configuration=filter/response-header=test:add(header-name=X-test, header-value=test) > {"outcome" => "success"} > [standalone@localhost:9990 /] /subsystem=undertow/server=default-server/host=default-host/filter-ref=test:add() > {"outcome" => "success"} > [standalone@localhost:9990 /] /subsystem=undertow/configuration=filter/response-header=test:remove() > { > "outcome" => "success", > "response-headers" => { > "operation-requires-reload" => true, > "process-state" => "reload-required" > } > } > [standalone@localhost:9990 /] :reload() > { > "outcome" => "success", > "result" => undefined > } > [standalone@localhost:9990 /] /core-service=management:read-boot-errors() > { > "outcome" => "success", > "result" => [{ > "failed-operation" => { > "operation" => "add", > "address" => [ > ("subsystem" => "undertow"), > ("server" => "default-server"), > ("host" => "default-host"), > ("filter-ref" => "test") > ] > }, > "failure-description" => "{\"WFLYCTL0412: Required services that are not installed:\" => [\"jboss.undertow.filter.test\"],\"WFLYCTL0180: Services with missing/unavailable dependencies\" => [\"jboss.undertow.server.default-server.default-host.filter-ref.test is missing [jboss.undertow.filter.test]\"]}", > "services-missing-dependencies" => ["jboss.undertow.server.default-server.default-host.filter-ref.test is missing [jboss.undertow.filter.test]"] > }] > } > {code} > A new Undertow filter is created and assigned to a host. The filter is then removed, but the host still needs it. > The problem is only seen after a server reload. The same thing happens when you remove, i.e. the default Servlet Container or the Bean pool of the EJB subsystem. > My proposal is to at least add a response head to the remove operations listing affected (dependent) services. This would complement the new WildFly 11 capability registry. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2265) Subsystem transformation tests throw ISE during resource transformation if resource has override registrations

by Paul Ferraro (JIRA)

Paul Ferraro created WFCORE-2265: ------------------------------------ Summary: Subsystem transformation tests throw ISE during resource transformation if resource has override registrations Key: WFCORE-2265 URL: https://issues.jboss.org/browse/WFCORE-2265 Project: WildFly Core Issue Type: Bug Components: Domain Management, Test Suite Affects Versions: 3.0.0.Alpha22 Reporter: Paul Ferraro Assignee: Paul Ferraro The problematic logic looks to in: org.jboss.as.subsystem.test.TransformationUtils.modelToResource(...), which will copy resource definition with wildcard overrides into the model twice. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ELY-920) Disable testing of PKCS#12 CredentialStore due to CI failures

by Darran Lofthouse (JIRA)

Darran Lofthouse created ELY-920: ------------------------------------ Summary: Disable testing of PKCS#12 CredentialStore due to CI failures Key: ELY-920 URL: https://issues.jboss.org/browse/ELY-920 Project: WildFly Elytron Issue Type: Bug Components: Testsuite Reporter: Darran Lofthouse Assignee: Darran Lofthouse Priority: Critical Fix For: 1.1.0.Beta23 -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2264) Missing capability tab completion on object type attributes

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2264?page=com.atlassian.jira.plugi... ] Darran Lofthouse reassigned WFCORE-2264: ---------------------------------------- Assignee: Jean-Francois Denise > Missing capability tab completion on object type attributes > ----------------------------------------------------------- > > Key: WFCORE-2264 > URL: https://issues.jboss.org/browse/WFCORE-2264 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Affects Versions: 3.0.0.Alpha22 > Environment: Reproducible using current WildFly master > Reporter: Darran Lofthouse > Assignee: Jean-Francois Denise > Fix For: 3.0.0.Alpha23 > > > The following command is valid: - > {{./core-service=management/management-interface=http-interface:write-attribute(name=http-upgrade.sasl-authentication-factory, value=management-sasl-authentication)}} > However tab completion is not possible to discover the available capabilities for the value. > I suspect the dot notation to reference the sasl-authentication-factory sub attribute is not followed. > (I am initially raising against the CLI but I don't know how the name parameter is handled here so could be a general management issue) -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2264) Missing capability tab completion on object type attributes

by Darran Lofthouse (JIRA)

Darran Lofthouse created WFCORE-2264: ---------------------------------------- Summary: Missing capability tab completion on object type attributes Key: WFCORE-2264 URL: https://issues.jboss.org/browse/WFCORE-2264 Project: WildFly Core Issue Type: Bug Components: CLI Affects Versions: 3.0.0.Alpha22 Environment: Reproducible using current WildFly master Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 3.0.0.Alpha23 The following command is valid: - {{./core-service=management/management-interface=http-interface:write-attribute(name=http-upgrade.sasl-authentication-factory, value=management-sasl-authentication)}} However tab completion is not possible to discover the available capabilities for the value. I suspect the dot notation to reference the sasl-authentication-factory sub attribute is not followed. (I am initially raising against the CLI but I don't know how the name parameter is handled here so could be a general management issue) -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2264) Missing capability tab completion on object type attributes

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2264?page=com.atlassian.jira.plugi... ] Darran Lofthouse reassigned WFCORE-2264: ---------------------------------------- Assignee: (was: Darran Lofthouse) > Missing capability tab completion on object type attributes > ----------------------------------------------------------- > > Key: WFCORE-2264 > URL: https://issues.jboss.org/browse/WFCORE-2264 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Affects Versions: 3.0.0.Alpha22 > Environment: Reproducible using current WildFly master > Reporter: Darran Lofthouse > Fix For: 3.0.0.Alpha23 > > > The following command is valid: - > {{./core-service=management/management-interface=http-interface:write-attribute(name=http-upgrade.sasl-authentication-factory, value=management-sasl-authentication)}} > However tab completion is not possible to discover the available capabilities for the value. > I suspect the dot notation to reference the sasl-authentication-factory sub attribute is not followed. > (I am initially raising against the CLI but I don't know how the name parameter is handled here so could be a general management issue) -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8026) read-resource operation of jaxrs subsystem doesn't work if HttpServletDispatcher is used

by R Searls (JIRA)

R Searls created WFLY-8026: ------------------------------ Summary: read-resource operation of jaxrs subsystem doesn't work if HttpServletDispatcher is used Key: WFLY-8026 URL: https://issues.jboss.org/browse/WFLY-8026 Project: WildFly Issue Type: Bug Components: REST Affects Versions: 10.1.0.Final Reporter: R Searls Assignee: R Searls Priority: Minor There are a set of "Bootstap" classes which when present in the web.xml file require jaxrs (i.e. resteasy) components to be configured using Resteasy Configuration Switches. (see https://docs.jboss.org/resteasy/docs/3.0.4.Final/userguide/html/Installat... ) Adding the following switch to the web.xml should solve the issue. 2 resteasy config switches need to be added dynamically when a jaxrs Application subclass is found in the web.xml file. This addresses the issue flagged in https://issues.jboss.org/browse/JBEAP-8064 -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7031) Redirect Port Fails to Redirect to 3rd Party HTTP Port

by Bhaskara Undi (JIRA)

[ https://issues.jboss.org/browse/WFLY-7031?page=com.atlassian.jira.plugin.... ] Bhaskara Undi commented on WFLY-7031: ------------------------------------- Hi Daniele, Thank you very much and it is working for me. I really appreciate your help. Regards, Bhaskara. On Fri, Feb 3, 2017 at 12:52 AM, Daniele Pirola (JIRA) <issues(a)jboss.org> -- Regards, Bhaskara Undi 858-429-8345 > Redirect Port Fails to Redirect to 3rd Party HTTP Port > ------------------------------------------------------ > > Key: WFLY-7031 > URL: https://issues.jboss.org/browse/WFLY-7031 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 10.0.0.CR1 > Reporter: Joe Carder > Assignee: Tomaz Cerar > Priority: Minor > > When setting a redirect socket to port not opened by Wildfly (IE: a port opened by Apache HTTPD or IIS), Wildfly throws the following exception: > ERROR [io.undertow.request] (default task-2) UT005001: An exception occurred processing the request: java.lang.IllegalStateException: UT010053: No confidential port is available to redirect the current request. > With the redirect socket to a port opened by JBoss, it works as expected. I'm not 100% sure this is a bug, or functional decision made for Wildfly 10 and is working as expected. However, in Previous Widlfly version (Widlfly 8) it was possible to set the redirect port to a third party service without out issue. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7957) Redirecting to external ports such as 443 is not working

by Bhaskara Undi (JIRA)

[ https://issues.jboss.org/browse/WFLY-7957?page=com.atlassian.jira.plugin.... ] Bhaskara Undi commented on WFLY-7957: ------------------------------------- Here I got the solution from Daniele Pirola Modify the ajp-listener specifying the attribute scheme like this: {{ <ajp-listener name="ajp" socket-binding="ajp" *scheme="https"*/>}} Now https call works fine and also redirect from http to https. Please try to publish this solution/configuration in Wildfly10.1.0 documentation, if possible. > Redirecting to external ports such as 443 is not working > -------------------------------------------------------- > > Key: WFLY-7957 > URL: https://issues.jboss.org/browse/WFLY-7957 > Project: WildFly > Issue Type: Bug > Components: Web Sockets > Affects Versions: 10.1.0.Final > Environment: Windows Server 2012 R2 Standard, 64bit > Reporter: Bhaskara Undi > Assignee: Stuart Douglas > > 2017-01-24 10:57:17,812 ERROR [io.undertow.request] (default task-1) UT005001: An exception occurred processing the request: java.lang.IllegalStateException: UT010053: No confidential port is available to redirect the current request. > at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.getRedirectURI(ServletConfidentialityConstraintHandler.java:80) > at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:49) > at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) > at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59) > at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)......... > ------------------ > <server-identities> > <ssl> > <keystore path="edustgkeystore.jks" relative-to="jboss.server.config.dir" keystore-password="pass" alias="server"/> > </ssl> > </server-identities> > ----------------------------- > <subsystem xmlns="urn:jboss:domain:undertow:3.1"> > <buffer-cache name="default"/> > <server name="default-server"> > <ajp-listener name="listen-ajp" socket-binding="ajp"/> > <http-listener name="default" socket-binding="http" redirect-socket="https-ext" enable-http2="true"/> > <https-listener name="https" socket-binding="https" security-realm="SSLRealm" enable-http2="true"/> > ------------------------------- > <socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:0}"> > <socket-binding name="management-http" interface="management" port="${jboss.management.http.port:9990}"/> > <socket-binding name="management-https" interface="management" port="${jboss.management.https.port:9993}"/> > <socket-binding name="ajp" port="${jboss.ajp.port:8009}"/> > <socket-binding name="http" port="${jboss.http.port:8080}"/> > <socket-binding name="https" port="${jboss.https.port:8443}"/> -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7031) Redirect Port Fails to Redirect to 3rd Party HTTP Port

by Bhaskara Undi (JIRA)

[ https://issues.jboss.org/browse/WFLY-7031?page=com.atlassian.jira.plugin.... ] Bhaskara Undi commented on WFLY-7031: ------------------------------------- Hi Daniele, Thank you very much for you fix. It is working for me. I really appreciate for help. Please put this configuration in the Wildfly10.1.0 documentation, if possible. > Redirect Port Fails to Redirect to 3rd Party HTTP Port > ------------------------------------------------------ > > Key: WFLY-7031 > URL: https://issues.jboss.org/browse/WFLY-7031 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 10.0.0.CR1 > Reporter: Joe Carder > Assignee: Tomaz Cerar > Priority: Minor > > When setting a redirect socket to port not opened by Wildfly (IE: a port opened by Apache HTTPD or IIS), Wildfly throws the following exception: > ERROR [io.undertow.request] (default task-2) UT005001: An exception occurred processing the request: java.lang.IllegalStateException: UT010053: No confidential port is available to redirect the current request. > With the redirect socket to a port opened by JBoss, it works as expected. I'm not 100% sure this is a bug, or functional decision made for Wildfly 10 and is working as expected. However, in Previous Widlfly version (Widlfly 8) it was possible to set the redirect port to a third party service without out issue. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 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 February 2017