[JBoss JIRA] (WFCORE-1330) Deployment error after reboot [WFLYSRV0137]
by Anchal Sachdev (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1330?page=com.atlassian.jira.plugi... ]
Anchal Sachdev commented on WFCORE-1330:
----------------------------------------
I am facing the same issue. Although I am running my Wildfly 10 server on Linux OS. I checked my logs and the data in /standalone/data/content folder is being deleted because of which I am getting the above-mentioned exception. The log says - WFLYDR0009: Content /data/wildfly-10.1.0.Final/standalone/data/content/e3/43bde5bfc12c80c373224344e37b7fd28c2fb3 is obsolete and will be removed
2017-04-11 03:25:11,451 INFO [org.jboss.as.repository] (ServerService Thread Pool -- 1) WFLYDR0002: Content removed from location /data/wildfly-10.1.0.Final/standalone/data/content/e3/43bde5bfc12c80c373224344e37b7fd28c2fb3/content
2017-04-11 03:25:11,451 DEBUG [org.jboss.as.server] (ServerService Thread Pool -- 1) {"deleted-contents" => ["/data/wildfly-10.1.0.Final/standalone/data/content/e3/43bde5bfc12c80c373224344e37b7fd28c2fb3"]}
Now when I remove the entry for that war from standalone.xml I am able to restart the server, but I need a more permanent solution.
> Deployment error after reboot [WFLYSRV0137]
> -------------------------------------------
>
> Key: WFCORE-1330
> URL: https://issues.jboss.org/browse/WFCORE-1330
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 1.0.2.Final
> Environment: Ubuntu 14.04 LTS 64bit, jre-1.8.0_65
> Several deployed (JavaEE) web applications including non XA datasources that connect to a MySQL instance.
> Reporter: Tobi Tobias
> Assignee: ehsavoie Hugonnet
> Priority: Critical
> Attachments: server.log, server.log
>
>
> I have a working configuration on wildfly 9.0.2 final with several web applications (JavaEE).
> After a couple of days, I deployed another war file via jboss CLI. This application worked correctly and no deployment error occurred.
> But if I restart the server now, I get following error message:
> 10:36:01,893 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([("deployment" => "MM-Controller-0.1.0-SNAPSHOT.war")]) - failure description: "WFLYSRV0137: No deployment content with hash 966847a6f5f5bf8c3470f07ea9e65b7bbcdcd7b7 is available in the deployment content repository for deployment 'MM-Controller-0.1.0-SNAPSHOT.war'. This is a fatal boot error. To correct the problem, either restart with the --admin-only switch set and use the CLI to install the missing content or remove it from the configuration, or remove the deployment from the xml configuration file and restart."
> 10:36:01,990 FATAL [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
> I reproduced this at least 30 times - even with different jars. I always get this error. The server works fine as long as I don't reboot.
> The only way to fix the configuration is to manually remove the deployments from the standalone.xml.
> But this is not an option for me as I want to have the wildfly running as production server where I have several automatic deployments every day.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFLY-8556) Migration of ajp connector via migrate operation fails due missing capabilities
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-8556?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar moved JBEAP-10287 to WFLY-8556:
-------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-8556 (was: JBEAP-10287)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Web (Undertow)
(was: Migration)
(was: Web (Undertow))
Affects Version/s: 11.0.0.Alpha1
(was: 7.1.0.DR16)
Affects Testing: (was: Regression)
> Migration of ajp connector via migrate operation fails due missing capabilities
> -------------------------------------------------------------------------------
>
> Key: WFLY-8556
> URL: https://issues.jboss.org/browse/WFLY-8556
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 11.0.0.Alpha1
> Reporter: Tomaz Cerar
> Assignee: Tomaz Cerar
> Priority: Blocker
> Labels: eap71_beta
>
> Migrating AJP connector fails with \[1\]
> This is regression in comparison to EAP 7.1.0.DR15, caused by [JBEAP-10033].
> Also note, that migrate operation shouldn't rather provide migration warnings than failing as whole.
> \[1\]
> {noformat}
> 10:58:19,440 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0190: Step handler org.jboss.as.controller.extension.ExtensionRemoveHandler@388b2c29 for operation {"operation" => "remove","address" => [("extension" => "org.jboss.as.web")],"operation-headers" => {"caller-type" => "user","access-mechanism" => "NATIVE"}} at address [("extension" => "org.jboss.as.web")] failed handling operation rollback -- java.lang.IllegalStateException: WFLYCTL0363: Capability 'org.wildfly.undertow.listener' is already registered in context 'global'.: java.lang.IllegalStateException: WFLYCTL0363: Capability 'org.wildfly.undertow.listener' is already registered in context 'global'.
> at org.jboss.as.controller.CapabilityRegistry.lambda$registerPossibleCapability$0(CapabilityRegistry.java:522) [wildfly-controller-3.0.0.Beta13-redhat-1.jar:3.0.0.Beta13-redhat-1]
> at java.util.concurrent.ConcurrentHashMap.computeIfPresent(ConcurrentHashMap.java:1769) [rt.jar:1.8.0_121]
> at org.jboss.as.controller.CapabilityRegistry.registerPossibleCapability(CapabilityRegistry.java:516) [wildfly-controller-3.0.0.Beta13-redhat-1.jar:3.0.0.Beta13-redhat-1]
> at org.jboss.as.controller.registry.ConcreteResourceRegistration.registerCapability(ConcreteResourceRegistration.java:679) [wildfly-controller-3.0.0.Beta13-redhat-1.jar:3.0.0.Beta13-redhat-1]
> at org.jboss.as.web.WebConnectorDefinition.registerCapabilities(WebConnectorDefinition.java:231)
> at org.jboss.as.controller.registry.NodeSubregistry.registerChild(NodeSubregistry.java:108) [wildfly-controller-3.0.0.Beta13-redhat-1.jar:3.0.0.Beta13-redhat-1]
> at org.jboss.as.controller.registry.ConcreteResourceRegistration.registerSubModel(ConcreteResourceRegistration.java:225) [wildfly-controller-3.0.0.Beta13-redhat-1.jar:3.0.0.Beta13-redhat-1]
> at org.jboss.as.web.WebExtension.initializeLegacyModel(WebExtension.java:107)
> at org.jboss.as.controller.extension.AbstractLegacyExtension.initialize(AbstractLegacyExtension.java:72) [wildfly-controller-3.0.0.Beta13-redhat-1.jar:3.0.0.Beta13-redhat-1]
> at org.jboss.as.controller.extension.ExtensionAddHandler.initializeExtension(ExtensionAddHandler.java:131) [wildfly-controller-3.0.0.Beta13-redhat-1.jar:3.0.0.Beta13-redhat-1]
> at org.jboss.as.controller.extension.ExtensionRemoveHandler$1.handleRollback(ExtensionRemoveHandler.java:81) [wildfly-controller-3.0.0.Beta13-redhat-1.jar:3.0.0.Beta13-redhat-1]
> at org.jboss.as.controller.AbstractOperationContext$RollbackDelegatingResultHandler.handleResult(AbstractOperationContext.java:1521) [wildfly-controller-3.0.0.Beta13-redhat-1.jar:3.0.0.Beta13-redhat-1]
> at org.jboss.as.controller.AbstractOperationContext$Step.invokeResultHandler(AbstractOperationContext.java:1493) [wildfly-controller-3.0.0.Beta13-redhat-1.jar:3.0.0.Beta13-redhat-1]
> at org.jboss.as.controller.AbstractOperationContext$Step.handleResult(AbstractOperationContext.java:1475) [wildfly-controller-3.0.0.Beta13-redhat-1.jar:3.0.0.Beta13-redhat-1]
> at org.jboss.as.controller.AbstractOperationContext$Step.finalizeInternal(AbstractOperationContext.java:1437) [wildfly-controller-3.0.0.Beta13-redhat-1.jar:3.0.0.Beta13-redhat-1]
> at org.jboss.as.controller.AbstractOperationContext$Step.finalizeStep(AbstractOperationContext.java:1420) [wildfly-controller-3.0.0.Beta13-redhat-1.jar:3.0.0.Beta13-redhat-1]
> at org.jboss.as.controller.AbstractOperationContext$Step.access$400(AbstractOperationContext.java:1284) [wildfly-controller-3.0.0.Beta13-redhat-1.jar:3.0.0.Beta13-redhat-1]
> at org.jboss.as.controller.AbstractOperationContext.executeResultHandlerPhase(AbstractOperationContext.java:856) [wildfly-controller-3.0.0.Beta13-redhat-1.jar:3.0.0.Beta13-redhat-1]
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:683) [wildfly-controller-3.0.0.Beta13-redhat-1.jar:3.0.0.Beta13-redhat-1]
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:441) [wildfly-controller-3.0.0.Beta13-redhat-1.jar:3.0.0.Beta13-redhat-1]
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1397) [wildfly-controller-3.0.0.Beta13-redhat-1.jar:3.0.0.Beta13-redhat-1]
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:421) [wildfly-controller-3.0.0.Beta13-redhat-1.jar:3.0.0.Beta13-redhat-1]
> at org.jboss.as.controller.ModelControllerImpl.lambda$execute$1(ModelControllerImpl.java:243) [wildfly-controller-3.0.0.Beta13-redhat-1.jar:3.0.0.Beta13-redhat-1]
> at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:263) [wildfly-elytron-1.1.0.Beta34-redhat-1.jar:1.1.0.Beta34-redhat-1]
> at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:229) [wildfly-elytron-1.1.0.Beta34-redhat-1.jar:1.1.0.Beta34-redhat-1]
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:243) [wildfly-controller-3.0.0.Beta13-redhat-1.jar:3.0.0.Beta13-redhat-1]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:217) [wildfly-controller-3.0.0.Beta13-redhat-1.jar:3.0.0.Beta13-redhat-1]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$400(ModelControllerClientOperationHandler.java:137) [wildfly-controller-3.0.0.Beta13-redhat-1.jar:3.0.0.Beta13-redhat-1]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:161) [wildfly-controller-3.0.0.Beta13-redhat-1.jar:3.0.0.Beta13-redhat-1]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157) [wildfly-controller-3.0.0.Beta13-redhat-1.jar:3.0.0.Beta13-redhat-1]
> at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:287) [wildfly-elytron-1.1.0.Beta34-redhat-1.jar:1.1.0.Beta34-redhat-1]
> at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:244) [wildfly-elytron-1.1.0.Beta34-redhat-1.jar:1.1.0.Beta34-redhat-1]
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:254) [wildfly-controller-3.0.0.Beta13-redhat-1.jar:3.0.0.Beta13-redhat-1]
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:225) [wildfly-controller-3.0.0.Beta13-redhat-1.jar:3.0.0.Beta13-redhat-1]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:157) [wildfly-controller-3.0.0.Beta13-redhat-1.jar:3.0.0.Beta13-redhat-1]
> at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70) [wildfly-protocol-3.0.0.Beta13-redhat-1.jar:3.0.0.Beta13-redhat-1]
> at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160) [wildfly-protocol-3.0.0.Beta13-redhat-1.jar:3.0.0.Beta13-redhat-1]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_121]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_121]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_121]
> at org.jboss.threads.JBossThread.run(JBossThread.java:320) [jboss-threads-2.2.1.Final-redhat-1.jar:2.2.1.Final-redhat-1]
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFLY-8555) WebToUndertow default-virtual-host remains unchanged after migration from web subsystem having defined default-virtual-server
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-8555?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar moved JBEAP-10286 to WFLY-8555:
-------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-8555 (was: JBEAP-10286)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Web (Undertow)
(was: Migration)
(was: Web (Undertow))
Affects Version/s: 11.0.0.Alpha1
(was: 7.1.0.DR16)
> WebToUndertow default-virtual-host remains unchanged after migration from web subsystem having defined default-virtual-server
> -----------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-8555
> URL: https://issues.jboss.org/browse/WFLY-8555
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 11.0.0.Alpha1
> Reporter: Tomaz Cerar
> Assignee: Tomaz Cerar
> Priority: Blocker
>
> Thanks to [JBEAP-10033] and discussion at [JBEAP-10200] there was discovered issue related to virtual hosts migration which was hidden till now.
> When migrating web -> undertow for migrating virtual hosts. In web there is on subsystem level default-virtual-server option, which per description corresponds more to the one in undertow default-host option on server level and currently it is migrated to it. Still in Undertow there is also default-virtual-host at undertow subsystem level which stays unchanged.
> Now with capabilities implemented on Undertow subsystem it points out that it is actually invalid configuration as the default-virtual-host points to non existing host (in case of the original virtual server being named differently than default-host), resulting in server failing to start afterwards \[1\] without any migration warning shown.
> The migration operation should update both default-virtual-host at subsystem level and default-host at server level.
> As there is no migration warning and the resulting configuration causes server start to fail, marking as blocker.
> \[1\]
> {noformat}
> 14:48:35,386 ERROR [org.jboss.as.controller] (management-handler-thread - 2) WFLYCTL0362: Capabilities required by resource '/subsystem=undertow' are not available:
> org.wildfly.undertow.host.default-server.default-host; There are no known registration points which can provide this capability.
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFCORE-2646) Elytron, management interface, legacy authentication is "checked" even if Elytron authentication is configured
by Ondrej Lukas (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2646?page=com.atlassian.jira.plugi... ]
Ondrej Lukas updated WFCORE-2646:
---------------------------------
Description:
Regression against DR15.
Authentication by legacy security realm is taken in account even if just Elytron authentication should be used. I don't say legacy authentication is used in priority before Elytron (that works as expected). Just that legacy authentication is somehow "initialized". In this case check "There are no user in mngmt-user.properties file" is performed
Reproducer:
* Configure Elytron authentication for management interface
{code}
/subsystem=elytron/filesystem-realm=exampleFsRealm:add(path=fs-realm-users,relative-to=jboss.server.config.dir)
/subsystem=elytron/filesystem-realm=exampleFsRealm/identity=user1:add()
/subsystem=elytron/filesystem-realm=exampleFsRealm/identity=user1:set-password( clear={password="password123"})
/subsystem=elytron/simple-role-decoder=from-roles-attribute:add(attribute=Roles)
/subsystem=elytron/security-domain=exampleFsSD:add(realms=[{realm=exampleFsRealm,role-decoder=from-roles-attribute}],default-realm=exampleFsRealm,permission-mapper=default-permission-mapper)
/subsystem=elytron/http-authentication-factory=example-fs-http-auth:add(http-server-mechanism-factory=global,security-domain=exampleFsSD,mechanism-configurations=[{mechanism-name=BASIC,mechanism-realm-configurations=[{realm-name=exampleApplicationDomain}]}])
/core-service=management/management-interface=http-interface:write-attribute(name=http-authentication-factory, value=example-fs-http-auth)
{code}
* impossible to acces management interface
{code}
curl --user user1:password123 http://localhost.localdomain:9990/management?operation=attribute\&name=se...
{
"outcome" : "failed",
"failure-description" : "WFLYDMHTTP0006: The security realm is not ready to process requests, see http://localhost.localdomain:9990/error",
"rolled-back" : "true"
}
{code}
Access is granted once
* security realm is undefined from management interface
{code}
/core-service=management/management-interface=http-interface:undefine-attribute(name=security-realm)
{code}
* Or user is added into ManagementRealm
{code}
./add-user.sh -u admin -p admin -r ManagementRealm
{code}
{code}
curl --user user1:password123 http://localhost.localdomain:9990/management?operation=attribute\&name=se...
"running"
{code}
was:
Regression against DR15.
Authentication by legacy security realm is taken in account even if just Elytron authentication should be used. I don't say legacy authentication is used in priority before Elytron (that works as expected). Just that legacy authentication is somehow "initialized". In this case check "There are no user in mngmt-user.properties file" is performed
Reproducer:
* Configure Elytron authentication for management interface
{code}
/subsystem=elytron/filesystem-realm=exampleFsRealm:add(path=fs-realm-users,relative-to=jboss.server.config.dir)
/subsystem=elytron/filesystem-realm=exampleFsRealm/identity=user1:add()
/subsystem=elytron/filesystem-realm=exampleFsRealm/identity=user1:set-password( clear={password="password123"})
/subsystem=elytron/simple-role-decoder=from-roles-attribute:add(attribute=Roles)
/subsystem=elytron/security-domain=exampleFsSD:add(realms=[{realm=exampleFsRealm,role-decoder=from-roles-attribute}],default-realm=exampleFsRealm,permission-mapper=default-permission-mapper)
/subsystem=elytron/http-authentication-factory=example-fs-http-auth:add(http-server-mechanism-factory=global,security-domain=exampleFsSD,mechanism-configurations=[{mechanism-name=BASIC,mechanism-realm-configurations=[{realm-name=exampleApplicationDomain}]}])
/core-service=management/management-interface=http-interface:write-attribute(name=http-authentication-factory, value=example-fs-http-auth)
{code}
* impossible to acces management interface
{code}
curl --user user1:password123 http://localhost.localdomain:9990/management?operation=attribute\&name=se...
{
"outcome" : "failed",
"failure-description" : "WFLYDMHTTP0006: The security realm is not ready to process requests, see http://localhost.localdomain:9990/error",
"rolled-back" : "true"
}
{code}
Acces is granted once
* security realm is undefined from management interface
{code}
/core-service=management/management-interface=http-interface:undefine-attribute(name=security-realm)
{code}
* User is added into ManagementRealm
{code}
./add-user.sh -u admin -p admin -r ManagementRealm
{code}
{code}
curl --user user1:password123 http://localhost.localdomain:9990/management?operation=attribute\&name=se...
"running"
{code}
> Elytron, management interface, legacy authentication is "checked" even if Elytron authentication is configured
> ---------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-2646
> URL: https://issues.jboss.org/browse/WFCORE-2646
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management, Security
> Reporter: Martin Choma
> Assignee: Darran Lofthouse
> Priority: Blocker
>
> Regression against DR15.
> Authentication by legacy security realm is taken in account even if just Elytron authentication should be used. I don't say legacy authentication is used in priority before Elytron (that works as expected). Just that legacy authentication is somehow "initialized". In this case check "There are no user in mngmt-user.properties file" is performed
> Reproducer:
> * Configure Elytron authentication for management interface
> {code}
> /subsystem=elytron/filesystem-realm=exampleFsRealm:add(path=fs-realm-users,relative-to=jboss.server.config.dir)
> /subsystem=elytron/filesystem-realm=exampleFsRealm/identity=user1:add()
> /subsystem=elytron/filesystem-realm=exampleFsRealm/identity=user1:set-password( clear={password="password123"})
> /subsystem=elytron/simple-role-decoder=from-roles-attribute:add(attribute=Roles)
> /subsystem=elytron/security-domain=exampleFsSD:add(realms=[{realm=exampleFsRealm,role-decoder=from-roles-attribute}],default-realm=exampleFsRealm,permission-mapper=default-permission-mapper)
> /subsystem=elytron/http-authentication-factory=example-fs-http-auth:add(http-server-mechanism-factory=global,security-domain=exampleFsSD,mechanism-configurations=[{mechanism-name=BASIC,mechanism-realm-configurations=[{realm-name=exampleApplicationDomain}]}])
> /core-service=management/management-interface=http-interface:write-attribute(name=http-authentication-factory, value=example-fs-http-auth)
> {code}
> * impossible to acces management interface
> {code}
> curl --user user1:password123 http://localhost.localdomain:9990/management?operation=attribute\&name=se...
> {
> "outcome" : "failed",
> "failure-description" : "WFLYDMHTTP0006: The security realm is not ready to process requests, see http://localhost.localdomain:9990/error",
> "rolled-back" : "true"
> }
> {code}
> Access is granted once
> * security realm is undefined from management interface
> {code}
> /core-service=management/management-interface=http-interface:undefine-attribute(name=security-realm)
> {code}
> * Or user is added into ManagementRealm
> {code}
> ./add-user.sh -u admin -p admin -r ManagementRealm
> {code}
> {code}
> curl --user user1:password123 http://localhost.localdomain:9990/management?operation=attribute\&name=se...
> "running"
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (ELY-1040) Elytron, incorrect IPv6 address resolution
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-1040?page=com.atlassian.jira.plugin.s... ]
Darran Lofthouse updated ELY-1040:
----------------------------------
Fix Version/s: 1.1.0.Beta35
> Elytron, incorrect IPv6 address resolution
> -------------------------------------------
>
> Key: ELY-1040
> URL: https://issues.jboss.org/browse/ELY-1040
> Project: WildFly Elytron
> Issue Type: Bug
> Reporter: Martin Choma
> Assignee: Darran Lofthouse
> Priority: Critical
> Fix For: 1.1.0.Beta35
>
>
> There is code in Elytron
> {code:java|title=SetMechanismInformationMechanismFactory.java}
> @Override
> public void evaluateRequest(HttpServerRequest request) throws HttpAuthenticationException {
> String host = request.getFirstRequestHeaderValue(HOST);
> String resolvedHostName = null;
> if (host != null) {
> if (host.startsWith("[")) {
> int close = host.indexOf(']');
> if (close > 0) {
> resolvedHostName = host.substring(0, close);
> }
> }
> {code}
> I assume intention of this code is to get from e.g. "[::1]:8080" just "[::1]", but now it gets only "[::1". To achieve this my assumption, there should be rather
> {code}
> resolvedHostName = host.substring(0, close + 1);
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months