[JBoss JIRA] (WFLY-7492) Value of parameter "restart-required" for some attributes in Elytron subsystem resources does not match reality
by Ondrej Kotek (JIRA)
[ https://issues.jboss.org/browse/WFLY-7492?page=com.atlassian.jira.plugin.... ]
Ondrej Kotek updated WFLY-7492:
-------------------------------
Description:
Some attributes of some resources in {{elytron}} subsystem defines in its description that there is not necessary to do {{reload}} or {{restart}}. But reality is different. Trying to change such attributes you are informed that {{reload}} is necessary:
{noformat}
configurable-sasl-server-factory/filters
configurable-sasl-server-factory/properties
custom-role-mapper/*
aggregate-http-server-mechanism-factory/http-server-factories
constant-permission-mapper/permissions
filesystem-realm/levels
filesystem-realm/name-rewriter
ldap-key-store/attributes/new-item-template
service-loader-http-server-mechanism-factory/module
aggregate-principal-decoder/principal-decoders
simple-permission-mapper/permission-mappings
chained-name-rewriter/name-rewriters
custom-permission-mapper/*
configurable-http-server-mechanism-factory/properties
custom-name-rewriter/*
aggregate-sasl-server-factory/sasl-server-factories
aggregate-name-rewriter/name-rewriters
ldap-realm/identity-mapping/*
mechanism-provider-filtering-sasl-server-factory/filters
custom-principal-decoder/*
custom-realm-mapper/*
jdbc-realm/principal-query
key-managers/credential-reference
service-loader-sasl-server-factory/module
concatenating-principal-decoder/principal-decoders
credential-store/alias/*
custom-modifiable-realm/*
custom-credential-security-factory/*
key-store/credential-reference
custom-role-decoder/*
aggregate-role-mapper/role-mappers
custom-realm/*
{noformat}
The attributes are defined as {{"restart-required" => "no-services"}}, see e.g. {{/subsystem=elytron/concatenating-principal-decoder=concatPrincDecoder:read-resource-description}}
was:
{{principal-decoders}} attribute of {{concatenating-principal-decoder}} defines in its description that there is not necessary to do {{reload}} or {{restart}}. But reality is different. Trying to change such attributes you are informed that {{reload}} is necessary.
The attribute is defined as {{"restart-required" => "no-services"}}, see {{/subsystem=elytron/concatenating-principal-decoder=concatPrincDecoder:read-resource-description}}
> Value of parameter "restart-required" for some attributes in Elytron subsystem resources does not match reality
> ---------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-7492
> URL: https://issues.jboss.org/browse/WFLY-7492
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Ondrej Kotek
> Assignee: Darran Lofthouse
> Labels: user_experience
>
> Some attributes of some resources in {{elytron}} subsystem defines in its description that there is not necessary to do {{reload}} or {{restart}}. But reality is different. Trying to change such attributes you are informed that {{reload}} is necessary:
> {noformat}
> configurable-sasl-server-factory/filters
> configurable-sasl-server-factory/properties
> custom-role-mapper/*
> aggregate-http-server-mechanism-factory/http-server-factories
> constant-permission-mapper/permissions
> filesystem-realm/levels
> filesystem-realm/name-rewriter
> ldap-key-store/attributes/new-item-template
> service-loader-http-server-mechanism-factory/module
> aggregate-principal-decoder/principal-decoders
> simple-permission-mapper/permission-mappings
> chained-name-rewriter/name-rewriters
> custom-permission-mapper/*
> configurable-http-server-mechanism-factory/properties
> custom-name-rewriter/*
> aggregate-sasl-server-factory/sasl-server-factories
> aggregate-name-rewriter/name-rewriters
> ldap-realm/identity-mapping/*
> mechanism-provider-filtering-sasl-server-factory/filters
> custom-principal-decoder/*
> custom-realm-mapper/*
> jdbc-realm/principal-query
> key-managers/credential-reference
> service-loader-sasl-server-factory/module
> concatenating-principal-decoder/principal-decoders
> credential-store/alias/*
> custom-modifiable-realm/*
> custom-credential-security-factory/*
> key-store/credential-reference
> custom-role-decoder/*
> aggregate-role-mapper/role-mappers
> custom-realm/*
> {noformat}
> The attributes are defined as {{"restart-required" => "no-services"}}, see e.g. {{/subsystem=elytron/concatenating-principal-decoder=concatPrincDecoder:read-resource-description}}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (WFLY-7492) Value of parameter "restart-required" for some attributes in Elytron subsystem resources does not match reality
by Ondrej Kotek (JIRA)
[ https://issues.jboss.org/browse/WFLY-7492?page=com.atlassian.jira.plugin.... ]
Ondrej Kotek updated WFLY-7492:
-------------------------------
Summary: Value of parameter "restart-required" for some attributes in Elytron subsystem resources does not match reality (was: Value of parameter "restart-required" for principal-decoders attribute does not match reality for concatenating-principal-decoder in CLI (Elytron subsystem))
> Value of parameter "restart-required" for some attributes in Elytron subsystem resources does not match reality
> ---------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-7492
> URL: https://issues.jboss.org/browse/WFLY-7492
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Ondrej Kotek
> Assignee: Darran Lofthouse
> Labels: user_experience
>
> {{principal-decoders}} attribute of {{concatenating-principal-decoder}} defines in its description that there is not necessary to do {{reload}} or {{restart}}. But reality is different. Trying to change such attributes you are informed that {{reload}} is necessary.
> The attribute is defined as {{"restart-required" => "no-services"}}, see {{/subsystem=elytron/concatenating-principal-decoder=concatPrincDecoder:read-resource-description}}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (WFLY-7371) JAXRS endpoint - CDI injection to constructor doesn't work
by Alessio Soldano (JIRA)
[ https://issues.jboss.org/browse/WFLY-7371?page=com.atlassian.jira.plugin.... ]
Alessio Soldano reassigned WFLY-7371:
-------------------------------------
Assignee: Ron Sigal (was: Stuart Douglas)
> JAXRS endpoint - CDI injection to constructor doesn't work
> ----------------------------------------------------------
>
> Key: WFLY-7371
> URL: https://issues.jboss.org/browse/WFLY-7371
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, REST
> Affects Versions: 10.1.0.Final
> Reporter: Tomas Remes
> Assignee: Ron Sigal
>
> Deploying app with following JAXRS endpoint
> {code}
> @Path("/test")
> public class MyTimeResource {
> private final LocalDateTime dateTime;
> @Inject
> public MyTimeResource(LocalDateTime dateTime){
> this.dateTime = dateTime;
> };
> }
> {code}
> is failing with following stack trace:
> {noformat}
> Caused by: java.lang.RuntimeException: RESTEASY003190: Could not find constructor for class: org.example.microprofile.MyTimeResource
> at org.jboss.resteasy.spi.metadata.ResourceBuilder.constructor(ResourceBuilder.java:692)
> at org.jboss.resteasy.plugins.server.resourcefactory.POJOResourceFactory.registered(POJOResourceFactory.java:42)
> at org.jboss.resteasy.core.ResourceMethodRegistry.addResourceFactory(ResourceMethodRegistry.java:208)
> at org.jboss.resteasy.core.ResourceMethodRegistry.addResourceFactory(ResourceMethodRegistry.java:194)
> at org.jboss.resteasy.core.ResourceMethodRegistry.addResourceFactory(ResourceMethodRegistry.java:180)
> at org.jboss.resteasy.core.ResourceMethodRegistry.addResourceFactory(ResourceMethodRegistry.java:157)
> at org.jboss.resteasy.core.ResourceMethodRegistry.addPerRequestResource(ResourceMethodRegistry.java:76)
> at org.jboss.resteasy.spi.ResteasyDeployment.registration(ResteasyDeployment.java:409)
> at org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:250)
> at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:113)
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:36)
> at io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:117)
> at org.wildfly.extension.undertow.security.RunAsLifecycleInterceptor.init(RunAsLifecycleInterceptor.java:78)
> at io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:103)
> at io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:250)
> at io.undertow.servlet.core.ManagedServlet.createServlet(ManagedServlet.java:133)
> at io.undertow.servlet.core.DeploymentManagerImpl$2.call(DeploymentManagerImpl.java:546)
> at io.undertow.servlet.core.DeploymentManagerImpl$2.call(DeploymentManagerImpl.java:517)
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:42)
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
> at io.undertow.servlet.core.DeploymentManagerImpl.start(DeploymentManagerImpl.java:559)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:101)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:82)
> ... 6 more
> {noformat}
> Note that app contains beans.xml so the JAXRS resource should be really managed by CDI.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (WFLY-7512) Elytron resources runtime updates without reload
by Martin Choma (JIRA)
[ https://issues.jboss.org/browse/WFLY-7512?page=com.atlassian.jira.plugin.... ]
Martin Choma moved JBEAP-6964 to WFLY-7512:
-------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-7512 (was: JBEAP-6964)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Security
(was: Security)
Affects Version/s: 11.0.0.Alpha1
(was: 7.1.0.DR7)
> Elytron resources runtime updates without reload
> ------------------------------------------------
>
> Key: WFLY-7512
> URL: https://issues.jboss.org/browse/WFLY-7512
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Martin Choma
>
> When updating elytron resources, server ends up in {{reload-required}} state. For example
> {code}
> [standalone@localhost:9990 /] /subsystem=elytron/kerberos-security-factory=krbSF:write-attribute(name=debug, value=true)
> {
> "outcome" => "success",
> "response-headers" => {
> "operation-requires-reload" => true,
> "process-state" => "reload-required"
> }
> }
> {code}
> Make it possible for all (most - some may be impossible) resources to support runtime updates.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (WFCORE-1953) Elytron allow-resource-service-restart=true handling
by Martin Choma (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1953?page=com.atlassian.jira.plugi... ]
Martin Choma moved JBEAP-6963 to WFCORE-1953:
---------------------------------------------
Project: WildFly Core (was: JBoss Enterprise Application Platform)
Key: WFCORE-1953 (was: JBEAP-6963)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Domain Management
(was: Security)
Affects Version/s: 3.0.0.Alpha11
(was: 7.1.0.DR7)
> Elytron allow-resource-service-restart=true handling
> ----------------------------------------------------
>
> Key: WFCORE-1953
> URL: https://issues.jboss.org/browse/WFCORE-1953
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 3.0.0.Alpha11
> Reporter: Martin Choma
>
> Elytron can not handle {{allow-resource-service-restart=true}} header properly on many places.
> For example if I try to update http-authentication-factory with {{allow-resource-service-restart=true}} header, I get
> {code}
> [standalone@localhost:9990 /] /subsystem=elytron/http-authentication-factory=application-http-authentication:write-attribute(name=http-server-mechanism-factory, value=global){allow-resource-service-restart=true}
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.UnsupportedOperationException",
> "rolled-back" => true
> }
> {code}
> And exception in server log
> {code:title=server.log}
> 11:22:20,312 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) WFLYCTL0013: Operation ("write-attribute") failed - address: ([
> ("subsystem" => "elytron"),
> ("http-authentication-factory" => "application-http-authentication")
> ]): java.lang.UnsupportedOperationException
> at org.jboss.as.controller.RestartParentWriteAttributeHandler.recreateParentService(RestartParentWriteAttributeHandler.java:145)
> at org.jboss.as.controller.RestartParentWriteAttributeHandler.recreateParentService(RestartParentWriteAttributeHandler.java:126)
> at org.jboss.as.controller.RestartParentWriteAttributeHandler.applyUpdateToRuntime(RestartParentWriteAttributeHandler.java:72)
> at org.jboss.as.controller.AbstractWriteAttributeHandler$1.execute(AbstractWriteAttributeHandler.java:104)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:940)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:683)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:382)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1363)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:410)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:232)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:213)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:136)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:153)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:422)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:149)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153)
> at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70)
> at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {code}
> Similar behaviour can be seen in:
> * {{kerberos-security-factory}}
> * {{filesystem-realm}}
> * {{constant-principal-decoder}}
> On the other hand I don't see this issue in {{security-domain}}
> Possible solutions:
> * restart services
> ** possibility of reload big part of server anyway; either management part or application part
> * live updates
> ** if resource would accept runtime updates resource won't need to reload
> ** most user friendly, most work
> ** tracked as own issue JBEAP-6961
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (JGRP-2120) Headers.resize() called unnecessarily
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2120?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2120:
---------------------------
Fix Version/s: 3.6.12
> Headers.resize() called unnecessarily
> -------------------------------------
>
> Key: JGRP-2120
> URL: https://issues.jboss.org/browse/JGRP-2120
> Project: JGroups
> Issue Type: Bug
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 3.6.12, 4.0
>
>
> Each message has space for 4 headers. When a 5th header needs to be added, the array needs to be resized. This is something we want to avoid as much as possible.
> However, the following scenario can lead to resizing:
> * A bundler writes a message list with (say) 3 headers
> * A message list always ignores the transport header, as it is only used to carry the cluster name, but that name is available in the batch header, too.
> * Therefore, the size of the headers written is 2 and the transport header is not written
> * On the receiver side, when reading the batch, we create and read 2 headers
> ** This is OK, as message batches are matched against the receiver's cluster name using the cluster name shipped in the batch itself and not in the message
> ** Message batches are therefore passed up without the individual messages carrying a transport header
> * However, single messages need to carry a transport header as it will be used to do the cluster name matching
> * Now, if a batch contains messages tagged as {{OOB|DONT_BUNDLE}}, they will be removed from the batch and sent up the stack as separate messages, each in a separate thread.
> * To do this, each of these messages is added a transport header (created using the batch's cluster name).
> * However, this necessitates a resizing as the headers array has a length of only 2, but we now need 3 headers
> Note that we don't run into this in 4.0, as Infinispan 9 (which uses 4) doesn't use {{DONT_BUNDLE}} any longer. It is still an unnecessary memory allocation and needs to be optimized.
> However, we should fix it in 3.6 as we still use {{DONT_BUNDLE}} in Infinispan 8.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (JGRP-2120) Headers.resize() called unnecessarily
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2120?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-2120.
----------------------------
Resolution: Done
Fixed by passing the cluster name to the SingleMessageHandlerWithClusterName; it (rather than the clustername in the transport header) is used to discard messages from different clusters.
This means that a message without a transport header, say of size 1, will not get added a transport header: the headers array doesn't need to be resized.
> Headers.resize() called unnecessarily
> -------------------------------------
>
> Key: JGRP-2120
> URL: https://issues.jboss.org/browse/JGRP-2120
> Project: JGroups
> Issue Type: Bug
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 4.0
>
>
> Each message has space for 4 headers. When a 5th header needs to be added, the array needs to be resized. This is something we want to avoid as much as possible.
> However, the following scenario can lead to resizing:
> * A bundler writes a message list with (say) 3 headers
> * A message list always ignores the transport header, as it is only used to carry the cluster name, but that name is available in the batch header, too.
> * Therefore, the size of the headers written is 2 and the transport header is not written
> * On the receiver side, when reading the batch, we create and read 2 headers
> ** This is OK, as message batches are matched against the receiver's cluster name using the cluster name shipped in the batch itself and not in the message
> ** Message batches are therefore passed up without the individual messages carrying a transport header
> * However, single messages need to carry a transport header as it will be used to do the cluster name matching
> * Now, if a batch contains messages tagged as {{OOB|DONT_BUNDLE}}, they will be removed from the batch and sent up the stack as separate messages, each in a separate thread.
> * To do this, each of these messages is added a transport header (created using the batch's cluster name).
> * However, this necessitates a resizing as the headers array has a length of only 2, but we now need 3 headers
> Note that we don't run into this in 4.0, as Infinispan 9 (which uses 4) doesn't use {{DONT_BUNDLE}} any longer. It is still an unnecessary memory allocation and needs to be optimized.
> However, we should fix it in 3.6 as we still use {{DONT_BUNDLE}} in Infinispan 8.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (WFLY-7511) Undertow 'session-id-length' not working properly
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-7511?page=com.atlassian.jira.plugin.... ]
Stuart Douglas moved JBEAP-6959 to WFLY-7511:
---------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-7511 (was: JBEAP-6959)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Web (Undertow)
(was: Web (Undertow))
Affects Version/s: (was: 7.0.0.CR2)
> Undertow 'session-id-length' not working properly
> -------------------------------------------------
>
> Key: WFLY-7511
> URL: https://issues.jboss.org/browse/WFLY-7511
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Reporter: Stuart Douglas
> Assignee: Stuart Douglas
> Priority: Minor
>
> Attribute {{session-id-length}} of servlet-container:
> {code}
> /subsystem=undertow/servlet-container=default:read-resource-description[session-id-length]
> {code}
> does not work exactly the way its description says:
> {code}
> "description" => "The length of the generated session ID. Longer session ID's are more secure.",
> {code}
> When I change it's value to {{X}}, actual result value of servlet session ID is {{((X + 2) / 3) * 4}}, [see this line of code|https://github.com/undertow-io/undertow/blob/master/core/src/main/ja...]. I am not sure what is the reason of this (probably to get some close greater number that can be divided by 4?).
> Please there should be either:
> - changed code so result session ID has length that corresponds to what user set
> - or update attribute description to explain user properly what is actually set
> Note: [here is the Jira for which this feature has been introduced into Wildfly|https://issues.jboss.org/browse/WFLY-3642].
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months