February 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-1337) Provide capabilities for paths

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1337?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1337: ------------------------------------- Fix Version/s: 4.0.0.Beta1 (was: 3.0.0.Beta2) > Provide capabilities for paths > ------------------------------ > > Key: WFCORE-1337 > URL: https://issues.jboss.org/browse/WFCORE-1337 > Project: WildFly Core > Issue Type: Task > Components: Domain Management > Reporter: Brian Stansberry > Fix For: 4.0.0.Beta1 > > > We need to be able to do reference validation for capabilities to avoid problems like WFCORE-1333. > This is going to take careful thought though. The PathManager is a bit of a complex beast. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-972) Provide a way to correlate HTTP management requests

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-972?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFCORE-972: ------------------------------------ Fix Version/s: 4.0.0.Alpha1 (was: 3.0.0.Beta2) > Provide a way to correlate HTTP management requests > --------------------------------------------------- > > Key: WFCORE-972 > URL: https://issues.jboss.org/browse/WFCORE-972 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Heiko Braun > Assignee: Brian Stansberry > Fix For: 4.0.0.Alpha1 > > > {noformat} > public class CorrelationHandler implements HttpHandler { > private static final HttpString HEADER = new HttpString("X-CORR-ID"); > private final HttpHandler next; > public CorrelationHandler(HttpHandler next) { > this.next = next; > } > @Override > public void handleRequest(HttpServerExchange exchange) throws Exception { > String corr = exchange.getRequestHeaders().getFirst(HEADER); > if(corr != null) { > exchange.getResponseHeaders().put(HEADER, corr); > } > next.handleRequest(exchange); > } > } > {noformat} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1548) Access denied when deploying to wildfly 10

by Joey Wang (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1548?page=com.atlassian.jira.plugi... ] Joey Wang commented on WFCORE-1548: ----------------------------------- [~ctomc], do you know why it is not a problem when deploying via web console? The problem happens when deploy from CLI remotely or Wildfly Maven plugin remotely. > Access denied when deploying to wildfly 10 > ------------------------------------------ > > Key: WFCORE-1548 > URL: https://issues.jboss.org/browse/WFCORE-1548 > Project: WildFly Core > Issue Type: Bug > Environment: Wildfly 10, Windows 7, java 1.8_05, maven 3.0.5, maven 3.3.9 > Reporter: Srecko Mandelj > Assignee: James Perkins > Priority: Minor > Attachments: TestMavenPlugin.zip, server.log > > > I have a war application containing web services. I have no problems deploying war to wildfly 8.1. After upgrade to wildfly 10, the plugin doesn't work any more. I get this error when trying to deploy: > {code} > [Server:server-one] 09:36:51,162 INFO [javax.enterprise.resource.webcontainer.jsf.config] (ServerService Thread Pool -- 132) Initializing Mojarra 2.2.12-jbossorg-2 20150729-1131 for context '/ActivatorFrontEnd' > [Server:server-one] 09:36:51,220 SEVERE [javax.enterprise.resource.webcontainer. > jsf.config] (ServerService Thread Pool -- 132) Critical error during deployment: > : com.sun.faces.config.ConfigurationException: java.util.concurrent.ExecutionException: javax.faces.FacesException: java.io.FileNotFoundException: C:\podatki\jboss_configurations\wildfly10\domainController\servers\server-one\tmp\vfs\temp\temp1e3a1daf9121b0e4\content-34b685741ee5aeb4\content-6322725066713898564.tmp (Access is denied) > {code} > It looks like a concurrency issue - one process is trying to use a file that other process is using. If I deploy through web console or via CLI, I don't have this issue. It is somehow related to jsf implementation. If I remove jsf from wildfly configuration file (the module and subsystem), deploy works ok (Mojara is then not triggered and deploy is successful). > I tried to deploy with 1.1.9.Alpha8, but I get the same error. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-459) Account for attribute groups in CLI behavior

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFCORE-459?page=com.atlassian.jira.plugin... ] Kabir Khan updated WFCORE-459: ------------------------------ Fix Version/s: 3.0.0.Beta2 (was: 3.0.0.Beta1) > Account for attribute groups in CLI behavior > -------------------------------------------- > > Key: WFCORE-459 > URL: https://issues.jboss.org/browse/WFCORE-459 > Project: WildFly Core > Issue Type: Feature Request > Components: CLI > Reporter: Brian Stansberry > Assignee: Jean-Francois Denise > Fix For: 3.0.0.Beta2 > > > See http://lists.jboss.org/pipermail/wildfly-dev/2014-December/003414.html > This JIRA is for reflecting the attribute group notion in CLI behavior. > I think this is just reflecting it in the output of the "ls -l" command, although there may be other places I'm not thinking of. For "ls -l" simplest is just to add a GROUP column to the right, and then sort the attributes by group and then by name, but perhaps something else is better. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-396) Look into whether READ_ONLY but not RUNTIME_ONLY domain server ops should be visible to users

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFCORE-396?page=com.atlassian.jira.plugin... ] Kabir Khan updated WFCORE-396: ------------------------------ Fix Version/s: 3.0.0.Beta2 (was: 3.0.0.Beta1) > Look into whether READ_ONLY but not RUNTIME_ONLY domain server ops should be visible to users > --------------------------------------------------------------------------------------------- > > Key: WFCORE-396 > URL: https://issues.jboss.org/browse/WFCORE-396 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Ken Wills > Fix For: 3.0.0.Beta2 > > > Ops registered on a domain server without the RUNTIME_ONLY flag are hidden from users (e.g. in read-operation-names results etc) in order to not delude users into thinking they can do something like :write-attribute directly on a server (instead of modifying host or domain config elements.) > But shouldn't a READ_ONLY flag be sufficient as well? An op that only reads config should be valid. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-377) The management API should provide a command to restart only all servers that are in state 'reload-required'

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFCORE-377?page=com.atlassian.jira.plugin... ] Kabir Khan updated WFCORE-377: ------------------------------ Fix Version/s: 3.0.0.Beta2 (was: 3.0.0.Beta1) > The management API should provide a command to restart only all servers that are in state 'reload-required' > ----------------------------------------------------------------------------------------------------------- > > Key: WFCORE-377 > URL: https://issues.jboss.org/browse/WFCORE-377 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Wolf-Dieter Fink > Labels: cli, domain, management > Fix For: 3.0.0.Beta2 > > > After configuration changes via CLI batch it might be that different processes needs to be restarted. > It is possible to iterate over all servers and check it. > But I think it would be easier to have a command that restart all controllers and servers conditional to the 'relod required' state > - at domain level > - at host level > - at server level > command example : > :restart(ifRequired=true) > :reload(ifRequired=true) -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-266) Deprecate the ParameterValidator constructor variants that accept allowNull and allowExpressions params

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFCORE-266?page=com.atlassian.jira.plugin... ] Kabir Khan updated WFCORE-266: ------------------------------ Fix Version/s: 3.0.0.Beta2 (was: 3.0.0.Beta1) > Deprecate the ParameterValidator constructor variants that accept allowNull and allowExpressions params > ------------------------------------------------------------------------------------------------------- > > Key: WFCORE-266 > URL: https://issues.jboss.org/browse/WFCORE-266 > Project: WildFly Core > Issue Type: Task > Components: Domain Management > Reporter: Brian Stansberry > Fix For: 3.0.0.Beta2 > > > Most of the ParameterValidator implementations that get passed to AttributeDefinition accept params to control whether null and expressions are allowed. These are now redundant, as AttributeDefinition wraps the provided validator with NillableOrExpressionParameterValidator, and it handles that aspect of validation based on the settings of the AD. > So we should deprecate these constructor variants to let people know they aren't needed. Ideally shift the code as well. > CRITICAL: before doing this, make sure the AttributeDefinition variants that support complex types properly wrap any validators that are configured for *element* validation. A quick look shows that ListAttributeDefinition.Builder and MapAttributeDefinition.Builder do. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-185) Api returns internal server error instead of not found for non-existing path

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFCORE-185?page=com.atlassian.jira.plugin... ] Kabir Khan updated WFCORE-185: ------------------------------ Fix Version/s: 3.0.0.Beta2 (was: 3.0.0.Beta1) > Api returns internal server error instead of not found for non-existing path > ---------------------------------------------------------------------------- > > Key: WFCORE-185 > URL: https://issues.jboss.org/browse/WFCORE-185 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Heiko Rupp > Assignee: Brian Stansberry > Labels: rhq > Fix For: 3.0.0.Beta2 > > > When I try to e.g. /subsystem=foo:read-resource the api returns a 500 internal server error. > In http-land, the return code for "not found" is normally 404. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-107) Update whoami operation to return authentication mechanism where verbose=true

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFCORE-107?page=com.atlassian.jira.plugin... ] Kabir Khan updated WFCORE-107: ------------------------------ Fix Version/s: 3.0.0.Beta2 (was: 3.0.0.Beta1) > Update whoami operation to return authentication mechanism where verbose=true > ----------------------------------------------------------------------------- > > Key: WFCORE-107 > URL: https://issues.jboss.org/browse/WFCORE-107 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 3.0.0.Beta2 > > > The admin console currently contains a "logout" handler that follows a round of HTTP message exchanges to trick the web browser into forgetting the credentials it has cached. > This only makes sense where the browser has cached a credential - if we return the authentication mechanism then the console can make a better decision regarding displaying the logout link or could change the implementation so display a message to the user explaining why logout does not make sense. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-13) End users can call non-published management API operations

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFCORE-13?page=com.atlassian.jira.plugin.... ] Kabir Khan updated WFCORE-13: ----------------------------- Fix Version/s: 3.0.0.Beta2 (was: 3.0.0.Beta1) > End users can call non-published management API operations > ---------------------------------------------------------- > > Key: WFCORE-13 > URL: https://issues.jboss.org/browse/WFCORE-13 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Ladislav Thon > Labels: EAP > Fix For: 3.0.0.Beta2 > > > It's not possible to call "non-published" operations (those that are not visible in the resource tree, e.g. {{describe}}) via JMX, while it's entirely possible to call them via CLI (e.g. {{/subsystem=security:describe}}) and other management interfaces. > The problem lies in the fact that {{ModelControllerMBeanHelper.invoke}} method checks {{if (!accessControl.isExecutableOperation(operationName))}} and the {{isExecutableOperation}} method assumes that the operation will be visible in the resource tree. In fact, there is a comment stating _should not happen_, but now we know that it indeed _can_ happen. > What's more, it gives a misleading error message. The {{isExecutableOperation}} returns {{false}} for unknown operations, which results in {{Not authorized to invoke operation}} message. Which is wrong in two different ways simultaneously: 1. the problem isn't authorization, but the fact that the operation can't be found; 2. the user (e.g. in the {{SuperUser}} role) _is_ authorized. > I'm considering this low priority, because 1. JMX is likely to be very rarely used to access the management interface, 2. hiding information isn't nearly as important as leaking them, 3. non-published operations aren't nearly as important as the published ones. It's worth a JIRA nevertheless. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 4 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