[JBoss JIRA] (WFCORE-3376) Modules may create loggers on a deployments log context
by Jeff Mesnil (Jira)
[ https://issues.redhat.com/browse/WFCORE-3376?page=com.atlassian.jira.plug... ]
Jeff Mesnil updated WFCORE-3376:
--------------------------------
Fix Version/s: 11.0.0.Beta9
(was: 11.0.0.Beta8)
> Modules may create loggers on a deployments log context
> -------------------------------------------------------
>
> Key: WFCORE-3376
> URL: https://issues.redhat.com/browse/WFCORE-3376
> Project: WildFly Core
> Issue Type: Bug
> Components: Logging
> Reporter: James Perkins
> Assignee: James Perkins
> Priority: Critical
> Fix For: 11.0.0.Beta9
>
>
> Currently WildFly uses a {{ClassLoaderLogContextSelector}} to determine the log context to use when creating loggers. If a deployment has it's own log context, via logging-profile or per-deployment logging, and a dependency on a module, that module may create loggers on the deployments log context. This is due to the fact the the call stack is walked until it finds a log context associated with a class loader.
> What is needed is a way to short-circuit once a non-logging API class loader is found and determine if there is an associated log context with the callers class loader.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 4 months
[JBoss JIRA] (WFCORE-944) truststore path is ignored if provider is not JKS
by Jeff Mesnil (Jira)
[ https://issues.redhat.com/browse/WFCORE-944?page=com.atlassian.jira.plugi... ]
Jeff Mesnil updated WFCORE-944:
-------------------------------
Fix Version/s: 11.0.0.Beta9
(was: 11.0.0.Beta8)
> truststore path is ignored if provider is not JKS
> -------------------------------------------------
>
> Key: WFCORE-944
> URL: https://issues.redhat.com/browse/WFCORE-944
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Arto Huusko
> Priority: Major
> Fix For: 11.0.0.Beta9
>
>
> truststore configuration ignores the path and relative-to parameters if the truststore provider is anything else than JKS.
> This works as documented, but it is not correct. There can be and are truststore implementations that need to load parameters or whatever data from a file, and the current implementation prevents these truststore providers from working.
> We have a custom truststore that is loaded from database, and database access parameters are read from a properties file. When trying to use this with Wildfly 9, the keystore engineLoad parameter is passed in as null, even though path and relative-to are configured.
> Even standard java supports PKCS12 truststores, where the same problem would occur.
> So I would suggest that
> - if provider is JKS, path is mandatory
> - if provider is not JKS, but path is specified, it is passed to the provider
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 4 months
[JBoss JIRA] (WFCORE-4822) Upgrade Management API Version to 12.0
by Jeff Mesnil (Jira)
[ https://issues.redhat.com/browse/WFCORE-4822?page=com.atlassian.jira.plug... ]
Jeff Mesnil updated WFCORE-4822:
--------------------------------
Fix Version/s: 11.0.0.Beta9
(was: 11.0.0.Beta8)
> Upgrade Management API Version to 12.0
> --------------------------------------
>
> Key: WFCORE-4822
> URL: https://issues.redhat.com/browse/WFCORE-4822
> Project: WildFly Core
> Issue Type: Bug
> Components: Management
> Reporter: Jeff Mesnil
> Assignee: Yeray Borges
> Priority: Blocker
> Fix For: 11.0.0.Beta9
>
>
> We need to fix the version state before WildFly 19 is released.
> * The KernelAPIVersion must be bumped to 12.0
> * We also need to release wildly-config-12.0.xsd with the proper host-exclude for
> * WildFlY18, Version.10
> * EAP73, Version.10
> (and add those to KnownRelease too)
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 4 months
[JBoss JIRA] (WFCORE-4485) Support for multiple security realms - Distributed Identities
by Jeff Mesnil (Jira)
[ https://issues.redhat.com/browse/WFCORE-4485?page=com.atlassian.jira.plug... ]
Jeff Mesnil updated WFCORE-4485:
--------------------------------
Fix Version/s: 11.0.0.Beta9
(was: 11.0.0.Beta8)
> Support for multiple security realms - Distributed Identities
> -------------------------------------------------------------
>
> Key: WFCORE-4485
> URL: https://issues.redhat.com/browse/WFCORE-4485
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Security
> Reporter: Farah Juma
> Priority: Major
> Labels: CD17-Deferred, EAP-CD19, Previous_RFE
> Fix For: 11.0.0.Beta9
>
>
> By stacking LoginModules it was possible using PicketBox to attempt to authenticate using one remote store and if that failed try the next store in the list.
> This RFE is to consider the use case where identities could be located across multiple stores and how they are aggregated together.
> Additionally this use case should consider how the authorization information could be loaded from multiple sources and merged.
> This RFE is not about fail over in the event of a realm being unavailable although it may be related.
> This RFE is created as a result of comparing the differences between the PicketBox JAAS architecture and the Elytron architecture so I would not recommend this proceeds without some real world use cases identified.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 4 months
[JBoss JIRA] (DROOLS-4984) Enable the executable model in Optaplanner
by Geoffrey De Smet (Jira)
[ https://issues.redhat.com/browse/DROOLS-4984?page=com.atlassian.jira.plug... ]
Geoffrey De Smet edited comment on DROOLS-4984 at 2/5/20 7:41 AM:
------------------------------------------------------------------
[~rsynek] Drools has 2 systems: "plain DRL exe mode" (AKA legacy mode) and "exe model exe mode" (AKA new mode).
By default, Drools uses the new mode.
But optaplanner currently changes it to use the legacy mode.
After the 7.7 cut-off, luca will switch it to use the new mode, with this jira.
Radovan, *can QA run a benchmark of optaplanner-examples (all use cases at least 1 dataset) to compare performance between the legacy mode and the new mode?*
The flag code is in ScoreDirectorFactoryConfig (do git blame and look for Luca's changes), should be easy to switch.
The performance should be the same, in theory... :)
was (Author: ge0ffrey):
[~rsynek] Drools has 2 systems: "plain DRL exe mode" (AKA legacy mode) and "exe model exe mode" (AKA new mode).
By default, Drools uses the new mode.
But optaplanner currently changes it to use the legacy mode.
After the 7.7 cut-off, luca will switch it to use the new mode, with this jira.
Radovan, *can QA run a benchmark of optaplanner-examples (all use cases at least 1 dataset) to compare performance between the legacy mode and the new mode?*
The flag code is in ScoreDirectorFactoryConfig (do git blame and look for Luca's changes), should be easy to switch.
> Enable the executable model in Optaplanner
> ------------------------------------------
>
> Key: DROOLS-4984
> URL: https://issues.redhat.com/browse/DROOLS-4984
> Project: Drools
> Issue Type: Bug
> Components: executable model
> Reporter: Luca Molteni
> Assignee: Luca Molteni
> Priority: Major
>
> Currently it's disabled
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 4 months
[JBoss JIRA] (DROOLS-4984) Enable the executable model in Optaplanner
by Geoffrey De Smet (Jira)
[ https://issues.redhat.com/browse/DROOLS-4984?page=com.atlassian.jira.plug... ]
Geoffrey De Smet edited comment on DROOLS-4984 at 2/5/20 7:41 AM:
------------------------------------------------------------------
[~rsynek] Drools has 2 systems: "plain DRL exe mode" (AKA legacy mode) and "exe model exe mode" (AKA new mode).
By default, Drools uses the new mode.
But optaplanner currently changes it to use the legacy mode.
After the 7.7 cut-off, luca will switch it to use the new mode, with this jira.
Radovan, *can QA run a benchmark of optaplanner-examples (almost all use cases at least 1 dataset) to compare performance between the legacy mode and the new mode?*
The flag code is in ScoreDirectorFactoryConfig (do git blame and look for Luca's changes), should be easy to switch.
The performance should be the same, in theory... :)
was (Author: ge0ffrey):
[~rsynek] Drools has 2 systems: "plain DRL exe mode" (AKA legacy mode) and "exe model exe mode" (AKA new mode).
By default, Drools uses the new mode.
But optaplanner currently changes it to use the legacy mode.
After the 7.7 cut-off, luca will switch it to use the new mode, with this jira.
Radovan, *can QA run a benchmark of optaplanner-examples (all use cases at least 1 dataset) to compare performance between the legacy mode and the new mode?*
The flag code is in ScoreDirectorFactoryConfig (do git blame and look for Luca's changes), should be easy to switch.
The performance should be the same, in theory... :)
> Enable the executable model in Optaplanner
> ------------------------------------------
>
> Key: DROOLS-4984
> URL: https://issues.redhat.com/browse/DROOLS-4984
> Project: Drools
> Issue Type: Bug
> Components: executable model
> Reporter: Luca Molteni
> Assignee: Luca Molteni
> Priority: Major
>
> Currently it's disabled
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 4 months
[JBoss JIRA] (DROOLS-4984) Enable the executable model in Optaplanner
by Geoffrey De Smet (Jira)
[ https://issues.redhat.com/browse/DROOLS-4984?page=com.atlassian.jira.plug... ]
Geoffrey De Smet commented on DROOLS-4984:
------------------------------------------
[~rsynek] Drools has 2 systems: "plain DRL exe mode" (AKA legacy mode) and "exe model exe mode" (AKA new mode).
By default, Drools uses the new mode.
But optaplanner currently changes it to use the legacy mode.
After the 7.7 cut-off, luca will switch it to use the new mode, with this jira.
Radovan, *can QA run a benchmark of optaplanner-examples (all use cases at least 1 dataset) to compare performance between the legacy mode and the new mode?*
The flag code is in ScoreDirectorFactoryConfig (do git blame and look for Luca's changes), should be easy to switch.
> Enable the executable model in Optaplanner
> ------------------------------------------
>
> Key: DROOLS-4984
> URL: https://issues.redhat.com/browse/DROOLS-4984
> Project: Drools
> Issue Type: Bug
> Components: executable model
> Reporter: Luca Molteni
> Assignee: Luca Molteni
> Priority: Major
>
> Currently it's disabled
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 4 months
[JBoss JIRA] (WFLY-11566) ConstraintDeclarationException on JAX-RS/EJB Methods with List/Set query parameter
by Guillaume Smet (Jira)
[ https://issues.redhat.com/browse/WFLY-11566?page=com.atlassian.jira.plugi... ]
Guillaume Smet commented on WFLY-11566:
---------------------------------------
Yeah so my concern is valid: you don't test at all that the list has been validated by Hibernate Validator: https://github.com/tadamski/wildfly/commit/58d1a5a2599c6924a3040e48712973... .
We also need to test that an invalid list throws a proper error generated by Hibernate Validator. Otherwise we can't be sure that HV has been fired and that would be a problem.
> ConstraintDeclarationException on JAX-RS/EJB Methods with List/Set query parameter
> ----------------------------------------------------------------------------------
>
> Key: WFLY-11566
> URL: https://issues.redhat.com/browse/WFLY-11566
> Project: WildFly
> Issue Type: Bug
> Components: Bean Validation, EJB, REST
> Affects Versions: 14.0.0.Final, 15.0.1.Final
> Reporter: Alexander Wagner
> Assignee: Tomasz Adamski
> Priority: Critical
> Labels: downstream_dependency
> Attachments: WFLY-11566-3.tar
>
>
> You got an exception if you call methods on JAX-RS endpoints which are also e.g. a stateless EJB and have Set or List as query parameters.
> As a workaround we use the "@Context UriInfo info" as parameter an read the parameter manually. As a downside this parameters are missing than in automated api generation with e.g. swagger. Without the @NotEmpty annotation it works fine. Without the generic type parameter ie just List it works fine. Making it a simple CDI bean makes it work fine.
> This issue is caused by [commit - WFLY-9628 Allow to switch to Hibernate Validator 6.0 / Bean Validation 2.0|https://github.com/wildfly/wildfly/commit/02f230d91f55f86ee6cadf53832...]
> Steps to reproduce:
> {code:java}
> @Stateless
> @Path("/")
> public class Resource {
> @POST
> @Path("put/list")
> @Consumes(MediaType.APPLICATION_JSON)
> public String putList(@NotEmpty List<String> a) {
> return "Hello bars " + a.stream().collect(Collectors.joining(", "));
> }
> }
> {code}
> {noformat}
> [mkopecky@dhcp-10-40-5-71 bin]$ curl -d '["a","b","c"]' -H "Content-Type: application/json" -X POST http://localhost:8080/jaxrs-wf/put/list
> javax.validation.ConstraintDeclarationException: HV000151: A method overriding another method must not redefine the parameter constraint configuration, but method Resource$$$view1#putList(List) redefines the configuration of Resource#putList(List).
> [mkopecky@dhcp-10-40-5-71 bin]$
> {noformat}
> {noformat}
> javax.validation.ConstraintDeclarationException: HV000151: A method overriding another method must not redefine the parameter constraint configuration, but method Resource$$$view1#putList(List) redefines the configuration of Resource#putList(List).
> at org.hibernate.validator.internal.metadata.aggregated.rule.OverridingMethodMustNotAlterParameterConstraints.apply(OverridingMethodMustNotAlterParameterConstraints.java:24)
> at org.hibernate.validator.internal.metadata.aggregated.ExecutableMetaData$Builder.assertCorrectnessOfConfiguration(ExecutableMetaData.java:461)
> at org.hibernate.validator.internal.metadata.aggregated.ExecutableMetaData$Builder.build(ExecutableMetaData.java:377)
> at org.hibernate.validator.internal.metadata.aggregated.BeanMetaDataImpl$BuilderDelegate.build(BeanMetaDataImpl.java:788)
> at org.hibernate.validator.internal.metadata.aggregated.BeanMetaDataImpl$BeanMetaDataBuilder.build(BeanMetaDataImpl.java:648)
> at org.hibernate.validator.internal.metadata.BeanMetaDataManager.createBeanMetaData(BeanMetaDataManager.java:192)
> at org.hibernate.validator.internal.metadata.BeanMetaDataManager.lambda$getBeanMetaData$0(BeanMetaDataManager.java:160)
> at java.util.concurrent.ConcurrentMap.computeIfAbsent(ConcurrentMap.java:324)
> at org.hibernate.validator.internal.metadata.BeanMetaDataManager.getBeanMetaData(BeanMetaDataManager.java:159)
> at org.hibernate.validator.internal.engine.ValidationContext$ValidationContextBuilder.forValidateParameters(ValidationContext.java:619)
> at org.hibernate.validator.internal.engine.ValidatorImpl.validateParameters(ValidatorImpl.java:254)
> at org.hibernate.validator.internal.engine.ValidatorImpl.validateParameters(ValidatorImpl.java:224)
> at org.jboss.resteasy.plugins.validation.GeneralValidatorImpl.validateAllParameters(GeneralValidatorImpl.java:177)
> at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:118)
> at org.jboss.resteasy.core.ResourceMethodInvoker.internalInvokeOnTarget(ResourceMethodInvoker.java:509)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTargetAfterFilter(ResourceMethodInvoker.java:399)
> at org.jboss.resteasy.core.ResourceMethodInvoker.lambda$invokeOnTarget$0(ResourceMethodInvoker.java:363)
> at org.jboss.resteasy.core.interception.PreMatchContainerRequestContext.filter(PreMatchContainerRequestContext.java:355)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:365)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:337)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:310)
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:439)
> at org.jboss.resteasy.core.SynchronousDispatcher.lambda$invoke$4(SynchronousDispatcher.java:229)
> at org.jboss.resteasy.core.SynchronousDispatcher.lambda$preprocess$0(SynchronousDispatcher.java:135)
> at org.jboss.resteasy.core.interception.PreMatchContainerRequestContext.filter(PreMatchContainerRequestContext.java:355)
> at org.jboss.resteasy.core.SynchronousDispatcher.preprocess(SynchronousDispatcher.java:138)
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:215)
> at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:227)
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:791)
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:74)
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129)
> at io.opentracing.contrib.jaxrs2.server.SpanFinishingFilter.doFilter(SpanFinishingFilter.java:55)
> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84)
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> at io.undertow.servlet.handlers.ServletChain$1.handleRequest(ServletChain.java:68)
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:132)
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:360)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:830)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> Links:
> * [forum|https://developer.jboss.org/thread/278822]
> * WFLY-11566
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 4 months