[JBoss JIRA] (JGRP-2305) Get rid of need for java.net.preferIPv4Stack
by Bela Ban (Jira)
Bela Ban created JGRP-2305:
------------------------------
Summary: Get rid of need for java.net.preferIPv4Stack
Key: JGRP-2305
URL: https://issues.jboss.org/browse/JGRP-2305
Project: JGroups
Issue Type: Enhancement
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 4.0.16
New address picking scheme:
* If all addresses in the config file are IPv4: use IPv4 addresses if available, else use IPv6 addresses
* If all addresses are IPv6: use IPv6
* If there is one IPv6 address: use IPv6
* If we have an IPv4 address, but the stack is not dual (but just IPv6) -> use IPv6-mapped addresses
Document the exact semantics
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 9 months
[JBoss JIRA] (WFLY-11115) bumpTimeout method usage in InMemorySessionManager
by Jan Stourac (Jira)
[ https://issues.jboss.org/browse/WFLY-11115?page=com.atlassian.jira.plugin... ]
Jan Stourac updated WFLY-11115:
-------------------------------
Affects Version/s: 14.0.1.Final
15.0.0.Alpha1
> bumpTimeout method usage in InMemorySessionManager
> --------------------------------------------------
>
> Key: WFLY-11115
> URL: https://issues.jboss.org/browse/WFLY-11115
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 14.0.1.Final, 15.0.0.Alpha1
> Reporter: Adam Krajcik
> Assignee: Stuart Douglas
> Priority: Major
>
> Possible bug as mentioned in https://developer.jboss.org/thread/278634. As mentioned in the thread, use of bumpTimeout may cause a session that may never expire.
> From [~jstourac]:
> {quote}
> The list of methods where 'bumpTimeout' is actually used in [InMemorySessionManager|https://github.com/undertow-io/undertow/blob/maste...] to following: createSession(), setMaxInactiveInterval(), getAttribute(), getAttributeNames(), setAttribute(), removeAttribute(). From this list usage in following methods is suspicious: getAttribute(), getAttributeNames(), setAttribute(), removeAttribute().
> All occurrences were added by [this commit|https://github.com/undertow-io/undertow/commit/be768b6cb98c13f02df...] with initial session timeout implementation.
> The truth is the [Servlet 4.0, section 7.5|https://javaee.github.io/servlet-spec/downloads/servlet-4.0/servlet-4_0_FINAL.pdf] specification (Servlet 3.1 is almost identical) specifies that timeout depends on user activity only:
> "This means that the only mechanism that can be used to indicate when a client is no longer active is a time out period."
> {quote}
> Response from [~stuartdouglas] from mail:
> {quote}
> We could probably change that to just update the timeout in requestDone().
> {quote}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 9 months
[JBoss JIRA] (WFLY-11137) Make undertow extension module's dependency on org.jboss.as.security module optional
by Yeray Borges (Jira)
[ https://issues.jboss.org/browse/WFLY-11137?page=com.atlassian.jira.plugin... ]
Yeray Borges edited comment on WFLY-11137 at 10/18/18 2:58 AM:
---------------------------------------------------------------
[~brian.stansberry] Yes, the mechanism is always added independently wether the security subsystem is present, indeed the mechanism is added in the handler that adds all container configuration, it is executed always.
Initially I thought if we had those mechanisms configurable via the undertow servlet container, then we could have the negotation dependency optional, so if they are not configured, we would not need the negotiation dependency. However, does make sense add SPNEGO and DIGEST mechanisms in [ServletContainerAdd|https://github.com/yersan/wildfly/blob/master/underto...] if we have the security subsystem disabled? Maybe [~dlofthouse] has an accurate information about that, I'm going to investigate it further.
If security subsystem is disabled and we are using Elytron for Authentication/Authorization I understand those mechanisms are added/managed by Elytron and then could not be necesary there
was (Author: yersan):
[~brian.stansberry] Yes, the mechanism is always added independently wether the security subsystem is present, indeed the mechanism is added in the handler that adds all container configuration, it is executed always.
Initially I thought if we had those mechanisms configurable via the undertow servlet container, then we could have the negotation dependency optional, so if they are not configured, we would not need the negotiation dependency. However, does make sense add SPNEGO and DIGEST mechanisms in [ServletContainerAdd|https://github.com/yersan/wildfly/blob/master/underto...] if we have the security subsystem disabled? Maybe [~dlofthouse] have an accurate information about that, I'm going to investigate it further.
If security subsystem is disabled and we are using Elytron for Authentication/Authorization I understand those mechanisms are added/managed by Elytron and then could not be necesary there
> Make undertow extension module's dependency on org.jboss.as.security module optional
> ------------------------------------------------------------------------------------
>
> Key: WFLY-11137
> URL: https://issues.jboss.org/browse/WFLY-11137
> Project: WildFly
> Issue Type: Task
> Components: Security, Web (Undertow)
> Reporter: Brian Stansberry
> Assignee: Yeray Borges
> Priority: Major
> Fix For: 15.0.0.Alpha1
>
>
> Don't require the legacy security subsystem module if it's not actually used.
> Usage looks like this:
> {code}
> wildfly bstansberry$ cd undertow/
> undertow bstansberry$ git grep org.jboss.as.security
> src/main/java/org/wildfly/extension/undertow/deployment/UndertowDeploymentInfoService.java:import org.jboss.as.security.plugins.SecurityDomainContext;
> src/main/java/org/wildfly/extension/undertow/deployment/UndertowDeploymentProcessor.java:import org.jboss.as.security.deployment.AbstractSecurityDeployer;
> src/main/java/org/wildfly/extension/undertow/deployment/UndertowDeploymentProcessor.java:import org.jboss.as.security.deployment.SecurityAttachments;
> src/main/java/org/wildfly/extension/undertow/deployment/UndertowDeploymentProcessor.java:import org.jboss.as.security.plugins.SecurityDomainContext;
> src/main/java/org/wildfly/extension/undertow/deployment/UndertowDeploymentProcessor.java:import org.jboss.as.security.service.JaccService;
> src/main/java/org/wildfly/extension/undertow/deployment/UndertowDeploymentProcessor.java:import org.jboss.as.security.service.SecurityDomainService;
> src/main/java/org/wildfly/extension/undertow/security/DigestCredentialImpl.java:import org.jboss.as.security.DigestCredential;
> src/main/java/org/wildfly/extension/undertow/security/JAASIdentityManagerImpl.java:import org.jboss.as.security.plugins.SecurityDomainContext;
> src/main/java/org/wildfly/extension/undertow/security/SecurityContextThreadSetupAction.java:import org.jboss.as.security.plugins.SecurityDomainContext;
> src/main/java/org/wildfly/extension/undertow/security/jacc/WarJACCDeployer.java:import org.jboss.as.security.deployment.AbstractSecurityDeployer;
> src/main/java/org/wildfly/extension/undertow/security/jacc/WarJACCDeployer.java:import org.jboss.as.security.service.JaccService;
> src/main/java/org/wildfly/extension/undertow/security/jacc/WarJACCService.java:import org.jboss.as.security.service.JaccService;
> {code}
> Dropping the use of SecurityAttachments from UndertowDeploymentProcessor and instead having it check for the presence of the org.wildfly.legacy-security capability will go a long way here. After that, most if not all of the other uses only get called either as a result of that check being true, or some config attribute that directly or indirectly references a security domain. IOW the other uses are only needed if the security subsystem is known to be configured.
> Per Intellij, DigestCredentialImpl is unused.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 9 months
[JBoss JIRA] (WFLY-11137) Make undertow extension module's dependency on org.jboss.as.security module optional
by Yeray Borges (Jira)
[ https://issues.jboss.org/browse/WFLY-11137?page=com.atlassian.jira.plugin... ]
Yeray Borges commented on WFLY-11137:
-------------------------------------
[~brian.stansberry] Yes, the mechanism is always added independently wether the security subsystem is present, indeed the mechanism is added in the handler that adds all container configuration, it is executed always.
Initially I thought if we had those mechanisms configurable via the undertow servlet container, then we could have the negotation dependency optional, so if they are not configured, we would not need the negotiation dependency. However, does make sense add SPNEGO and DIGEST mechanisms in [ServletContainerAdd|https://github.com/yersan/wildfly/blob/master/underto...] if we have the security subsystem disabled? Maybe [~dlofthouse] have an accurate information about that, I'm going to investigate it further.
If security subsystem is disabled and we are using Elytron for Authentication/Authorization I understand those mechanisms are added/managed by Elytron and then could not be necesary there
> Make undertow extension module's dependency on org.jboss.as.security module optional
> ------------------------------------------------------------------------------------
>
> Key: WFLY-11137
> URL: https://issues.jboss.org/browse/WFLY-11137
> Project: WildFly
> Issue Type: Task
> Components: Security, Web (Undertow)
> Reporter: Brian Stansberry
> Assignee: Yeray Borges
> Priority: Major
> Fix For: 15.0.0.Alpha1
>
>
> Don't require the legacy security subsystem module if it's not actually used.
> Usage looks like this:
> {code}
> wildfly bstansberry$ cd undertow/
> undertow bstansberry$ git grep org.jboss.as.security
> src/main/java/org/wildfly/extension/undertow/deployment/UndertowDeploymentInfoService.java:import org.jboss.as.security.plugins.SecurityDomainContext;
> src/main/java/org/wildfly/extension/undertow/deployment/UndertowDeploymentProcessor.java:import org.jboss.as.security.deployment.AbstractSecurityDeployer;
> src/main/java/org/wildfly/extension/undertow/deployment/UndertowDeploymentProcessor.java:import org.jboss.as.security.deployment.SecurityAttachments;
> src/main/java/org/wildfly/extension/undertow/deployment/UndertowDeploymentProcessor.java:import org.jboss.as.security.plugins.SecurityDomainContext;
> src/main/java/org/wildfly/extension/undertow/deployment/UndertowDeploymentProcessor.java:import org.jboss.as.security.service.JaccService;
> src/main/java/org/wildfly/extension/undertow/deployment/UndertowDeploymentProcessor.java:import org.jboss.as.security.service.SecurityDomainService;
> src/main/java/org/wildfly/extension/undertow/security/DigestCredentialImpl.java:import org.jboss.as.security.DigestCredential;
> src/main/java/org/wildfly/extension/undertow/security/JAASIdentityManagerImpl.java:import org.jboss.as.security.plugins.SecurityDomainContext;
> src/main/java/org/wildfly/extension/undertow/security/SecurityContextThreadSetupAction.java:import org.jboss.as.security.plugins.SecurityDomainContext;
> src/main/java/org/wildfly/extension/undertow/security/jacc/WarJACCDeployer.java:import org.jboss.as.security.deployment.AbstractSecurityDeployer;
> src/main/java/org/wildfly/extension/undertow/security/jacc/WarJACCDeployer.java:import org.jboss.as.security.service.JaccService;
> src/main/java/org/wildfly/extension/undertow/security/jacc/WarJACCService.java:import org.jboss.as.security.service.JaccService;
> {code}
> Dropping the use of SecurityAttachments from UndertowDeploymentProcessor and instead having it check for the presence of the org.wildfly.legacy-security capability will go a long way here. After that, most if not all of the other uses only get called either as a result of that check being true, or some config attribute that directly or indirectly references a security domain. IOW the other uses are only needed if the security subsystem is known to be configured.
> Per Intellij, DigestCredentialImpl is unused.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 9 months
[JBoss JIRA] (WFLY-11202) Default ResourceBundle fails to load
by Brian Stansberry (Jira)
[ https://issues.jboss.org/browse/WFLY-11202?page=com.atlassian.jira.plugin... ]
Brian Stansberry commented on WFLY-11202:
-----------------------------------------
Thanks for the report! The component upgrade fixes it.
> Default ResourceBundle fails to load
> ------------------------------------
>
> Key: WFLY-11202
> URL: https://issues.jboss.org/browse/WFLY-11202
> Project: WildFly
> Issue Type: Bug
> Components: EE
> Affects Versions: 14.0.1.Final
> Reporter: Andrew Schmidt
> Assignee: Brian Stansberry
> Priority: Major
> Attachments: resourcebundle.zip
>
>
> Wildfly 14 no longer loads the default message bundle when a locale is specified and the specific locale has no properties file.
> For example, in the attached project, I have a messages.properties file, Wildfly 13 and previous releases would simply load the messages.properties if there is no messages_en.properties. But in wildfly 14 this is no longer the case (it appears it provides a different resourcebundle)
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 9 months
[JBoss JIRA] (WFLY-11202) Default ResourceBundle fails to load
by Brian Stansberry (Jira)
[ https://issues.jboss.org/browse/WFLY-11202?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFLY-11202:
------------------------------------
Component/s: EE
> Default ResourceBundle fails to load
> ------------------------------------
>
> Key: WFLY-11202
> URL: https://issues.jboss.org/browse/WFLY-11202
> Project: WildFly
> Issue Type: Bug
> Components: EE
> Affects Versions: 14.0.1.Final
> Reporter: Andrew Schmidt
> Assignee: Brian Stansberry
> Priority: Major
> Attachments: resourcebundle.zip
>
>
> Wildfly 14 no longer loads the default message bundle when a locale is specified and the specific locale has no properties file.
> For example, in the attached project, I have a messages.properties file, Wildfly 13 and previous releases would simply load the messages.properties if there is no messages_en.properties. But in wildfly 14 this is no longer the case (it appears it provides a different resourcebundle)
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 9 months
[JBoss JIRA] (WFLY-11202) Default ResourceBundle fails to load
by Brian Stansberry (Jira)
[ https://issues.jboss.org/browse/WFLY-11202?page=com.atlassian.jira.plugin... ]
Brian Stansberry commented on WFLY-11202:
-----------------------------------------
This is https://github.com/eclipse-ee4j/yasson/issues/62. A bump from yasson 1.0.1 to 1.0.2 should fix it.
> Default ResourceBundle fails to load
> ------------------------------------
>
> Key: WFLY-11202
> URL: https://issues.jboss.org/browse/WFLY-11202
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 14.0.1.Final
> Reporter: Andrew Schmidt
> Assignee: Jason Greene
> Priority: Major
> Attachments: resourcebundle.zip
>
>
> Wildfly 14 no longer loads the default message bundle when a locale is specified and the specific locale has no properties file.
> For example, in the attached project, I have a messages.properties file, Wildfly 13 and previous releases would simply load the messages.properties if there is no messages_en.properties. But in wildfly 14 this is no longer the case (it appears it provides a different resourcebundle)
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 9 months
[JBoss JIRA] (WFLY-11202) Default ResourceBundle fails to load
by Brian Stansberry (Jira)
[ https://issues.jboss.org/browse/WFLY-11202?page=com.atlassian.jira.plugin... ]
Brian Stansberry reassigned WFLY-11202:
---------------------------------------
Assignee: Brian Stansberry (was: Jason Greene)
> Default ResourceBundle fails to load
> ------------------------------------
>
> Key: WFLY-11202
> URL: https://issues.jboss.org/browse/WFLY-11202
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 14.0.1.Final
> Reporter: Andrew Schmidt
> Assignee: Brian Stansberry
> Priority: Major
> Attachments: resourcebundle.zip
>
>
> Wildfly 14 no longer loads the default message bundle when a locale is specified and the specific locale has no properties file.
> For example, in the attached project, I have a messages.properties file, Wildfly 13 and previous releases would simply load the messages.properties if there is no messages_en.properties. But in wildfly 14 this is no longer the case (it appears it provides a different resourcebundle)
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 9 months