[JBoss JIRA] (WFLY-2785) master reload on windows using bind IP without a reverse DNS entry (or a wrong one)
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-2785?page=com.atlassian.jira.plugin.... ]
Brian Stansberry commented on WFLY-2785:
----------------------------------------
You should discuss this with Emanuel Muckenhuber.
> master reload on windows using bind IP without a reverse DNS entry (or a wrong one)
> -----------------------------------------------------------------------------------
>
> Key: WFLY-2785
> URL: https://issues.jboss.org/browse/WFLY-2785
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Server
> Affects Versions: 8.0.0.CR1
> Environment: windows
> Reporter: Aleksandar Kostadinov
> Assignee: Aleksandar Kostadinov
> Labels: addressing, domain, socket
> Attachments: server_logs.zip
>
>
> When running on windows and the server management port bind IP address does not have a proper reverse DNS entry or an entry in the hosts file, then there is trouble reloading the server. It is possible that same issue may affect other domain server management operations but I didn't identify any others (and didn't try).
> Basically the problem is that windows reverse resolves such IPs to the computer name. On reload without restarting the managed servers, they receive as a host to reconnect to the computer name instead of the IP address and connection cannot be established.
> Here is how to reproduce:
> # on a windows machine add some local IP address without a reverse entry (e.g. 192.0.2.15)
> # launch domain server from wildfly, e.g.: bin/domain.sh -bpublic=192.0.2.15 -bmanagement=192.0.2.15
> # issue this cli command: reload --restart-servers=false --host=master
> # see logs for messages from server-one and server-two (I'll attach an archive with such logs)
> The fix I found for the issue is:{CODE}
> diff --git a/host-controller/src/main/java/org/jboss/as/host/controller/ManagedServer.java b/host-controller/src/main/java/org/jboss/as/host/controller/ManagedServer.java
> index 308df0e..c6a88e8 100644
> --- a/host-controller/src/main/java/org/jboss/as/host/controller/ManagedServer.java
> +++ b/host-controller/src/main/java/org/jboss/as/host/controller/ManagedServer.java
> @@ -30,7 +30,6 @@ import static org.jboss.as.host.controller.HostControllerLogger.ROOT_LOGGER;
>
> import java.io.IOException;
> import java.io.OutputStream;
> -import java.net.InetAddress;
> import java.net.InetSocketAddress;
> import java.util.Collections;
> import java.util.LinkedHashMap;
> @@ -769,7 +768,7 @@ class ManagedServer {
> public boolean execute(ManagedServer server) throws Exception {
> assert Thread.holdsLock(ManagedServer.this); // Call under lock
> // Reconnect
> - final String hostName = InetAddress.getByName(managementSocket.getHostName()).getHostName();
> + final String hostName = managementSocket.getHostString();
> final int port = managementSocket.getPort();
> processControllerClient.reconnectProcess(serverProcessName, NetworkUtils.formatPossibleIpv6Address(hostName), port, bootConfiguration.isManagementSubsystemEndpoint(), authKey);
> return true;
> {CODE}
> I see that the line causing the troubles was [committed|https://github.com/wildfly/wildfly/commit/7effc2eca6cfd5d031a05...] as part of AS7-3613. I looked at the issue and I don't see how this altering of hostname can help with getting a good URI. Yes, it can help if it guaranteed that a hostname will always be returned but fact is that on linux, if reverse record is missing or improper, this still returns an IP so this line of code IMO can only cause harm. Am I missing something?
> Moreover it doesn't seems right to me to change server identification overriding user choice to select an IP instead of a hostname just to fix some URIs.
> IMO if user/administrator used an IP, then server should to use it as an IP, not reverse resolve it to a host and then use it. It simply leads to confusion.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 3 months
[JBoss JIRA] (WFLY-2762) Injection of application-provided CDI bean into extension-provided bean fails
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-2762?page=com.atlassian.jira.plugin.... ]
Jason Greene commented on WFLY-2762:
------------------------------------
Ok done :)
> Injection of application-provided CDI bean into extension-provided bean fails
> -----------------------------------------------------------------------------
>
> Key: WFLY-2762
> URL: https://issues.jboss.org/browse/WFLY-2762
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: CDI / Weld
> Affects Versions: 8.0.0.CR1
> Reporter: Gunnar Morling
> Assignee: Jozef Hartinger
> Priority: Blocker
> Fix For: 8.0.0.Final
>
>
> When an application provides a CDI bean, injection of this bean into another bean provided by a portable extension (which is attached to this application) fails.
> The specific use case is the PE for Hibernate Validator which contains a class {{ValidationInterceptor}} with an injection point of type {{j.v.Validator}}. If the application happens to provide a producer for that type, deployment of the application fails with the following error message:
> {quote}
> WELD-001408: Unsatisfied dependencies for type Validator with qualifiers @Default
> at injection point \[UnbackedAnnotatedField\] @Inject private org.hibernate.validator.internal.cdi.interceptor.ValidationInterceptor.validator
> {quote}
> A test case can be found [here|https://github.com/gunnarmorling/hibernate-validator/tree/injection-...]. To execute it, pull that branch and run:
> {code}
> mvn clean install -pl integration -Dit.test=InjectionIssueIT
> {code}
> The deployment of that Arquillian test fails with the error above.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 3 months
[JBoss JIRA] (WFLY-2735) read-operation-names causes NullPointerException
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-2735?page=com.atlassian.jira.plugin.... ]
Brian Stansberry updated WFLY-2735:
-----------------------------------
Summary: read-operation-names causes NullPointerException (was: read-operation-names casues NullPointerException)
> read-operation-names causes NullPointerException
> ------------------------------------------------
>
> Key: WFLY-2735
> URL: https://issues.jboss.org/browse/WFLY-2735
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Affects Versions: 8.0.0.Final
> Reporter: Stan Silvert
> Assignee: Brian Stansberry
>
> CLI command> /core-service=*/:read-operation-names
> 08:27:16,461 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) JBAS014612: Operation ("read-operation-names") failed - address: ([("cor
> e-service" => "*")]): java.lang.NullPointerException
> at org.jboss.as.controller.operations.global.ReadOperationNamesHandler.execute(ReadOperationNamesHandler.java:78) [wildfly-controller-8.0.0.Final-SNAPSHOT.jar:8.0
> .0.Final-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:591) [wildfly-controller-8.0.0.Final-SNAPSHOT.jar:8.0.0.Final-SNAPSH
> OT]
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:469) [wildfly-controller-8.0.0.Final-SNAPSHOT.jar:8.0.0.Final-SNA
> PSHOT]
> at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:273) [wildfly-controller-8.0.0.Final-SNAPSHOT.jar:8.0.0.Fin
> al-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:268) [wildfly-controller-8.0.0.Final-SNAPSHOT.jar:8.0.0.Final-S
> NAPSHOT]
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:272) [wildfly-controller-8.0.0.Final-SNAPSHOT.jar:8.0.0.Final-SNAPSHOT]
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:146) [wildfly-controller-8.0.0.Final-SNAPSHOT.jar:8.0.0.Final-SNAPSHOT]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:174) [wildfly-c
> ontroller-8.0.0.Final-SNAPSHOT.jar:8.0.0.Final-SNAPSHOT]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:105) [wildfly-
> controller-8.0.0.Final-SNAPSHOT.jar:8.0.0.Final-SNAPSHOT]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:125) [wildfly-con
> troller-8.0.0.Final-SNAPSHOT.jar:8.0.0.Final-SNAPSHOT]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:121) [wildfly-con
> troller-8.0.0.Final-SNAPSHOT.jar:8.0.0.Final-SNAPSHOT]
> at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_15]
> at javax.security.auth.Subject.doAs(Subject.java:415) [rt.jar:1.7.0_15]
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:94) [wildfly-controller-8.0.0.Final-SNAPSHOT.jar:8.0.0.Final-SNAPSHOT]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:121) [wildfly-c
> ontroller-8.0.0.Final-SNAPSHOT.jar:8.0.0.Final-SNAPSHOT]
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:283) [wildfly-protocol-8.0.0.Final-SNAPSHOT.jar:8.0.0.Final-SNAPSHO
> T]
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:504) [wildfly-protocol-8.0.0.Final-SNAPSHOT.jar:8.0.0.Final-S
> NAPSHOT]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_15]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_15]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_15]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 3 months
[JBoss JIRA] (WFLY-2735) read-operation-names causes NullPointerException
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-2735?page=com.atlassian.jira.plugin.... ]
Brian Stansberry updated WFLY-2735:
-----------------------------------
Affects Version/s: 8.0.0.CR1
(was: 8.0.0.Final)
> read-operation-names causes NullPointerException
> ------------------------------------------------
>
> Key: WFLY-2735
> URL: https://issues.jboss.org/browse/WFLY-2735
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Affects Versions: 8.0.0.CR1
> Reporter: Stan Silvert
> Assignee: Brian Stansberry
>
> CLI command> /core-service=*/:read-operation-names
> 08:27:16,461 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) JBAS014612: Operation ("read-operation-names") failed - address: ([("cor
> e-service" => "*")]): java.lang.NullPointerException
> at org.jboss.as.controller.operations.global.ReadOperationNamesHandler.execute(ReadOperationNamesHandler.java:78) [wildfly-controller-8.0.0.Final-SNAPSHOT.jar:8.0
> .0.Final-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:591) [wildfly-controller-8.0.0.Final-SNAPSHOT.jar:8.0.0.Final-SNAPSH
> OT]
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:469) [wildfly-controller-8.0.0.Final-SNAPSHOT.jar:8.0.0.Final-SNA
> PSHOT]
> at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:273) [wildfly-controller-8.0.0.Final-SNAPSHOT.jar:8.0.0.Fin
> al-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:268) [wildfly-controller-8.0.0.Final-SNAPSHOT.jar:8.0.0.Final-S
> NAPSHOT]
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:272) [wildfly-controller-8.0.0.Final-SNAPSHOT.jar:8.0.0.Final-SNAPSHOT]
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:146) [wildfly-controller-8.0.0.Final-SNAPSHOT.jar:8.0.0.Final-SNAPSHOT]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:174) [wildfly-c
> ontroller-8.0.0.Final-SNAPSHOT.jar:8.0.0.Final-SNAPSHOT]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:105) [wildfly-
> controller-8.0.0.Final-SNAPSHOT.jar:8.0.0.Final-SNAPSHOT]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:125) [wildfly-con
> troller-8.0.0.Final-SNAPSHOT.jar:8.0.0.Final-SNAPSHOT]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:121) [wildfly-con
> troller-8.0.0.Final-SNAPSHOT.jar:8.0.0.Final-SNAPSHOT]
> at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_15]
> at javax.security.auth.Subject.doAs(Subject.java:415) [rt.jar:1.7.0_15]
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:94) [wildfly-controller-8.0.0.Final-SNAPSHOT.jar:8.0.0.Final-SNAPSHOT]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:121) [wildfly-c
> ontroller-8.0.0.Final-SNAPSHOT.jar:8.0.0.Final-SNAPSHOT]
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:283) [wildfly-protocol-8.0.0.Final-SNAPSHOT.jar:8.0.0.Final-SNAPSHO
> T]
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:504) [wildfly-protocol-8.0.0.Final-SNAPSHOT.jar:8.0.0.Final-S
> NAPSHOT]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_15]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_15]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_15]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 3 months
[JBoss JIRA] (WFLY-270) Use logger instead of [stdout] for JGroups GMS logger
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-270?page=com.atlassian.jira.plugin.s... ]
Radoslav Husar updated WFLY-270:
--------------------------------
Fix Version/s: (was: 8.0.0.CR1)
(was: 8.0.0.Final)
Affects Version/s: 8.0.0.Alpha1
> Use logger instead of [stdout] for JGroups GMS logger
> -----------------------------------------------------
>
> Key: WFLY-270
> URL: https://issues.jboss.org/browse/WFLY-270
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Clustering
> Affects Versions: 8.0.0.Alpha1
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Priority: Trivial
>
> ...and possibly remove the unnecessary dash lines on the way.
> {noformat}
> [JBossINF] 12:11:12,677 INFO [org.jboss.as.osgi] (MSC service thread 1-15) JBAS011907: Register module: Module "deployment.clusterbench-ee6.ear.clusterbench-ee6-ejb.jar:main" from Service Module Loader
> [JBossINF] 12:11:13,142 INFO [stdout] (ChannelService lifecycle - 1)
> [JBossINF] 12:11:13,142 INFO [stdout] (ChannelService lifecycle - 1) -------------------------------------------------------------------
> [JBossINF] 12:11:13,142 INFO [stdout] (ChannelService lifecycle - 1) GMS: address=perf18/web, cluster=web, physical address=10.16.90.54:55200
> [JBossINF] 12:11:13,143 INFO [stdout] (ChannelService lifecycle - 1) -------------------------------------------------------------------
> [JBossINF] 12:11:13,209 INFO [stdout] (ChannelService lifecycle - 1)
> [JBossINF] 12:11:13,209 INFO [stdout] (ChannelService lifecycle - 1) -------------------------------------------------------------------
> [JBossINF] 12:11:13,209 INFO [stdout] (ChannelService lifecycle - 1) GMS: address=perf18/ejb, cluster=ejb, physical address=10.16.90.54:55200
> [JBossINF] 12:11:13,210 INFO [stdout] (ChannelService lifecycle - 1) -------------------------------------------------------------------
> [JBossINF] 12:11:13,441 INFO [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (MSC service thread 1-5) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be pasivated.
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 3 months