February 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-278) Revisit error message for an authentication failure.

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-278?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFCORE-278: ------------------------------------ Fix Version/s: 1.0.0.Beta1 (was: 1.0.0.Alpha19) > Revisit error message for an authentication failure. > ---------------------------------------------------- > > Key: WFCORE-278 > URL: https://issues.jboss.org/browse/WFCORE-278 > Project: WildFly Core > Issue Type: Bug > Components: CLI, Domain Management, Remoting, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.0.0.Beta1 > > > After authentication fails in the CLI the following error message is output: - > {code} > Unable to authenticate against controller at localhost:9990: Authentication failed: the server presented no authentication mechanisms > {code} > This text is a bit misleading, what it actually means is all mechanisms presented have either been excluded or attempted and now no further mechanisms are available to try. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4235) JDR capture OS version

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-4235?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated WFLY-4235: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1195516 > JDR capture OS version > ---------------------- > > Key: WFLY-4235 > URL: https://issues.jboss.org/browse/WFLY-4235 > Project: WildFly > Issue Type: Feature Request > Components: JDR > Reporter: Brad Maxwell > Assignee: Brad Maxwell > > JDR should capture OS version if available -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4217) JDR include system properties, jndi view, deployment module information

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-4217?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated WFLY-4217: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1195509 > JDR include system properties, jndi view, deployment module information > ----------------------------------------------------------------------- > > Key: WFLY-4217 > URL: https://issues.jboss.org/browse/WFLY-4217 > Project: WildFly > Issue Type: Enhancement > Components: JDR > Affects Versions: 9.0.0.Alpha1 > Reporter: Brad Maxwell > Assignee: Brad Maxwell > > JDR include system properties, jndi view, deployment module information -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4168) jdr.sh CommandLineMain does not run jdr on the application server

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-4168?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated WFLY-4168: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1195507 > jdr.sh CommandLineMain does not run jdr on the application server > ----------------------------------------------------------------- > > Key: WFLY-4168 > URL: https://issues.jboss.org/browse/WFLY-4168 > Project: WildFly > Issue Type: Bug > Components: JDR > Affects Versions: 9.0.0.Alpha1 > Reporter: Brad Maxwell > Assignee: Brad Maxwell > > jdr.sh CommandLineMain does not run jdr on the application server > JDR run via the CLI / Managemenet API - runs the JDR report in the Application Server's JVM > /subsystem=jdr:generate-jdr-report() > Running jdr.sh / jdr.bat runs the JDR report in the JDR JVM > jdr.sh / jdr.bat should run the JDR report in the Application Server's JVM if it is running. If it is not running, then it should just collect the files that are available. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4167) AS7Plugin dump-services command is failing

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-4167?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated WFLY-4167: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1195504 > AS7Plugin dump-services command is failing > ------------------------------------------ > > Key: WFLY-4167 > URL: https://issues.jboss.org/browse/WFLY-4167 > Project: WildFly > Issue Type: Bug > Components: JDR > Affects Versions: 9.0.0.Alpha1 > Reporter: Brad Maxwell > Assignee: Brad Maxwell > Fix For: 9.0.0.Beta1 > > > Run JDR, the dump-services.json is always empty. This is because the operation is not being set when JDR tries to invoke the operation. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3605) Move the JMX subsystem out of core

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-3605?page=com.atlassian.jira.plugin.... ] Tomaz Cerar reassigned WFLY-3605: --------------------------------- Assignee: Brian Stansberry (was: Tomaz Cerar) Assigning to you until we decide what to do here > Move the JMX subsystem out of core > ---------------------------------- > > Key: WFLY-3605 > URL: https://issues.jboss.org/browse/WFLY-3605 > Project: WildFly > Issue Type: Task > Components: JMX > Reporter: Darran Lofthouse > Assignee: Brian Stansberry > Fix For: 9.0.0.Beta1 > > > There are some dependency issues to resolve but the JMX subsystem should not automatically be included in the core distribution. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2729) Improve reporting when persistent session restore fails

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-2729?page=com.atlassian.jira.plugin.... ] Tomaz Cerar resolved WFLY-2729. ------------------------------- Assignee: Stuart Douglas (was: Tomaz Cerar) Resolution: Done > Improve reporting when persistent session restore fails > ------------------------------------------------------- > > Key: WFLY-2729 > URL: https://issues.jboss.org/browse/WFLY-2729 > Project: WildFly > Issue Type: Enhancement > Components: CDI / Weld > Affects Versions: 8.0.0.CR1 > Environment: Ubuntu Linux > Reporter: Paa Kojo Konduah Amos > Assignee: Stuart Douglas > Fix For: 9.0.0.Beta1 > > Attachments: BdfHJ0fCUAAdRW5.png > > > when you right clean on Server to clean it. it throws an Error -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4256) JDR should collect patch info & server-environment

by Brad Maxwell (JIRA)

[ https://issues.jboss.org/browse/WFLY-4256?page=com.atlassian.jira.plugin.... ] Brad Maxwell updated WFLY-4256: ------------------------------- Summary: JDR should collect patch info & server-environment (was: JDR should collect patch info) > JDR should collect patch info & server-environment > -------------------------------------------------- > > Key: WFLY-4256 > URL: https://issues.jboss.org/browse/WFLY-4256 > Project: WildFly > Issue Type: Enhancement > Components: JDR > Reporter: Brad Maxwell > Assignee: Brad Maxwell > > JDR should include the patch info showing patches applied -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4354) EJBs can't inherit a JDK8 default method

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-4354?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-4354: ----------------------------------------------- Fernando Nasser <fnasser(a)redhat.com> changed the Status of [bug 1193119|https://bugzilla.redhat.com/show_bug.cgi?id=1193119] from POST to MODIFIED > EJBs can't inherit a JDK8 default method > ---------------------------------------- > > Key: WFLY-4354 > URL: https://issues.jboss.org/browse/WFLY-4354 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 9.0.0.Alpha1 > Reporter: Jan Martiska > Assignee: David Lloyd > Attachments: defaultmethodejb.jar > > > If an EJB bean inherits a default method from an interface and doesn't override it, attempt to call this method fails with: > {noformat} > org.jboss.invocation.CannotProceedException: INV000002: Invocation cannot proceed (end of interceptor chain has been hit) > {noformat} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-488) Failures of undeploy of a partially failed deployment

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-488?page=com.atlassian.jira.plugin... ] Brian Stansberry commented on WFCORE-488: ----------------------------------------- Here's where I expect to end up with this (reflected in the linked pull request): 1) It would be good to know how the deployment ended up not installed on one server, but installed elsewhere. Hopefully with a reproducer. Unless a rollout plan specified that, that's a bug. But we should treat that as a separate bug. 2) Once a server gets out of sync with the domain config (say because you made a change with a rollout plan that allowed this), you can get failures like you report if you try and make further changes. Options are: a) stop the server that is inconsistent before making the changes b) specify a rollout plan that will not rollback if 1 server fails in the given server group. See "Rollout plans" in https://developer.jboss.org/wiki/JBossAS7Command-lineOperationRequestFormat and https://docs.jboss.org/author/display/WFLY9/Admin+Guide#AdminGuide-Operat... . The linked PR includes tests of 2)b). It worked as expected. Alternatives to the current behavior are to no longer send config changes to servers that are out of sync and basically force the user to restart them. That can introduce it's own problems though, and requires a lot of care. I'm not sure it's a good idea. See WFCORE-368. 3) There was a bug that resulted in "server-groups" data not getting reported to the client when this failure occurs, contrary to what's specified in https://docs.jboss.org/author/display/WFLY9/Admin+Guide#AdminGuide-MultiS.... The data was received properly on the master HC, but it misinterpreted what occurred as a failure applying the change to the slave HCs and assumed no server results were available, so it did not include them. The linked PR fixes this. 4) The linked PR also changes how the top level "failure-description" for the response is generated, attempting to extract useful data from the server results and including it in the top level failure-description. This will help improve the error reporting from CLI high level commands and similar clients, where the full response may not be displayed to the user, only the failure-description. 5) If I learn of any possibility for another 8.x release, I'll be happy to backport any commits on this to the 8.x branch. > Failures of undeploy of a partially failed deployment > ----------------------------------------------------- > > Key: WFCORE-488 > URL: https://issues.jboss.org/browse/WFCORE-488 > Project: WildFly Core > Issue Type: Bug > Components: CLI, Domain Management > Reporter: Arcadiy Ivanov > Assignee: Alexey Loubyansky > > {noformat} > [domain@localhost:9990 /] undeploy 2e3b75f2-88ff-4eb9-a8b1-9107c452309e.ear --all-relevant-server-groups > Undeploy failed: JBAS010839: Operation failed or was rolled back on all servers. > {noformat} > There are several issues at play here: > # Insufficient information is displayed along with JBAS010839 > # No actual failure logged either in DC or in individual host's logs > # Failure to find a deployment unit on a particular host should not result in a failure of a domain-wide undeploy in DeploymentUndeployHandler > I'll start in a reverse order of causation: > In DeploymentUndeployHandler.execute > {noformat} > public void execute(OperationContext context, ModelNode operation) throws OperationFailedException { > ModelNode model = context.readResourceForUpdate(PathAddress.EMPTY_ADDRESS).getModel(); > ... > {noformat} > OperationContextImpl.readResourceForUpdate calls OperationContextImpl.requireChild: > {noformat} > private static Resource requireChild(final Resource resource, final PathElement childPath, final PathAddress fullAddress) { > if (resource.hasChild(childPath)) { > return resource.requireChild(childPath); > } else { > PathAddress missing = PathAddress.EMPTY_ADDRESS; > for (PathElement search : fullAddress) { > missing = missing.append(search); > if (search.equals(childPath)) { > break; > } > } > throw ControllerMessages.MESSAGES.managementResourceNotFound(missing); > } > } > {noformat} > The exception generated by {{throw ControllerMessages.MESSAGES.managementResourceNotFound(missing);}}: > # does not propagate from the host to DC and to CLI > # is not logged with any level (not even TRACE) either on host or DC > # should be handled within DeploymentUndeployHandler not to fail the undeploy operation in case of a partially failed deployment (e.g. EAR with unsatisfied CDI dependencies). -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 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 2015