Regression keyword did not set blocker ? so setting it.

Regression or not, to me "-b [fe80::3e97:eff:fe96:48c8]" is wrong, as you're supposed to provide a host address, not a URL. You should use "-b fe80::3e97:eff:fe96:48c8", which I believe would simply work.

The reason for the failure is not found in the stacktrace and is an OperationFailedException from org.jboss.as.webservices.dmr.AddressValidator when the <wsdl-host> element is read from the model (note, the validator was added recently). The default value in the model for that element is ${jboss.bind.address:127.0.0.1}, which takes the value passed with the command line -b option.

To improve error reporting, the AS core should properly better handle OperationFailedException. No WS issue here AFAICS.

(In reply to Alessio Soldano from comment #2)
> 
> To improve error reporting, the AS core should properly better handle
> OperationFailedException. No WS issue here AFAICS.

Please explain what is going wrong. Is some OperationStepHandler doing some validation after it has already installed some services, with the result that the handler doesn't install some other services?

I agree that "-b [fe80::3e97:eff:fe96:48c8]" is wrong.

Actually looking better at the log, I see the following line, which was not reported here and which basically tells that the WS subsystem could not be added and started:

18:19:37,525 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 48) JBAS014613: Operation ("add") failed - address: ([("subsystem" => "webservices")]) - failure description: "JBWS022117: Invalid address provided: [::1]"

Brian, the actual exception is the following, if you're interested:

org.jboss.as.controller.OperationFailedException: JBWS022117: Invalid address provided: [::1] [ "JBWS022117: Invalid address provided: [::1]" ]
 	at org.jboss.as.webservices.dmr.AddressValidator.validateParameter(AddressValidator.java:48)
 	at org.jboss.as.controller.operations.validation.NillableOrExpressionParameterValidator.validateParameter(NillableOrExpressionParameterValidator.java:75)
 	at org.jboss.as.controller.AttributeDefinition.resolveValue(AttributeDefinition.java:363)
 	at org.jboss.as.controller.AttributeDefinition.resolveModelAttribute(AttributeDefinition.java:321)
 	at org.jboss.as.controller.AttributeDefinition.resolveModelAttribute(AttributeDefinition.java:295)
 	at org.jboss.as.webservices.dmr.WSSubsystemAdd.createServerConfig(WSSubsystemAdd.java:108)
 	at org.jboss.as.webservices.dmr.WSSubsystemAdd.performBoottime(WSSubsystemAdd.java:90)
 	at org.jboss.as.controller.AbstractBoottimeAddStepHandler.performRuntime(AbstractBoottimeAddStepHandler.java:69)
 	at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:76)
 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:601)
[...]

I had to add a stacktrace print in ws subsystem to print the exception above.
The NPE is a consequence of the WS subsystem not having started.

I think WSSubsystemAdd should defer the following until after the createServiceConfig() call:

context.addStep(new AbstractDeploymentChainStep() {
            protected void execute(DeploymentProcessorTarget processorTarget) {
                // add the DUP for dealing with WS deployments
                WSDeploymentActivator.activate(processorTarget, appclient);
            }
        }, OperationContext.Stage.RUNTIME);

Basically, do all the validation stuff before doing anything that will change state.

It would be nicer if the validation failure automatically resulted in everything subsequent (e.g. execution of the step that adds those DUPs) not happening. That would be the case if this were a normal op from the CLI or console -- unless the caller added the rollback-on-runtime-failure=true header, the OFE would result in the stop of execution and rollback. But in boot we don't rollback automatically and abort, so weirder problems can happen. (IMO we should provide a config option to roll back / abort at boot.)


A separate issue is nothing appearing in the logs. I thought I'd improved that in 6.2 such that OFEs are logged at boot. (Post boot they are not as they are considered client mistakes that get reported to the client.) But even trying this with WF master I don't see the OFE in the logs.

I don't think the move of the code block mentioned above is really related to the NPE. The reason for the NPE is that a service which would have been installed by the WSSubsystemAdd is actually not installed. The thread that eventually ends up into the NPE is processing the EndpointConfigAdd, which is a step handler processing a child of webservices subsystem.

I agree too that "-b [fe80::3e97:eff:fe96:48c8]" is wrong, we filled it because it is regression to things we could do/use. Not saying it was the right thing:)

Are we going to change this BZ to something like "Improve logging and perform validation before changing the state to prevent hiding the root cause" ?

Turns out the logging is fine; the root cause is the first error in the log:

21:10:59,039 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 60) JBAS014613: Operation ("add") failed - address: ([("subsystem" => "webservices")]) - failure description: "JBWS022117: Invalid address provided: [::1]"

I changed the command line parsing to strip the [].

Thanks for investigation and fix! I cannot hit any problems with EAP 6.3.0.DR4. Setting as verified.

We've noticed that when property jboss.bind.address is set:
./standalone.sh -c standalone.xml -Djava.net.preferIPv4Stack=false -Djava.net.preferIPv6Addresses=true -Djboss.bind.address=[::1] -Djboss.bind.address.management=[::1]

then it fails with the same error. Would it be possible to fix it for this use? It seems that [] is not stripped from properties: jboss.bind.address, jboss.bind.address.management, jboss.bind.address.unsecure,

Just my 2 cents: if we're going to be lenient on this and getting host addresses from ipv6 urls having brackets, we should at least try to educate users e.g. by printing a WARN telling them they should have not provided urls, but host addresses and in any case we're interpreting what they meant..

Thanks Brian! I'll set this bz as verified and add comment to related jira - https://issues.jboss.org/browse/WFLY-3077.