[JBoss JIRA] (WFCORE-4844) CommandLineArgumentUsage custom usage
by Jean Francois Denise (Jira)
Jean Francois Denise created WFCORE-4844:
--------------------------------------------
Summary: CommandLineArgumentUsage custom usage
Key: WFCORE-4844
URL: https://issues.redhat.com/browse/WFCORE-4844
Project: WildFly Core
Issue Type: Enhancement
Components: Management
Reporter: Jean Francois Denise
Assignee: Jean Francois Denise
process-controller/CommandLineArgumentUsage should would allow to benefit from its command arguments formatting for custom launch (eg: bootable jar).
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 3 months
[JBoss JIRA] (DROOLS-2317) FEEL Syntax error on function(bkm) containing `for` keyword
by Lukasz Hanik (Jira)
[ https://issues.redhat.com/browse/DROOLS-2317?page=com.atlassian.jira.plug... ]
Lukasz Hanik commented on DROOLS-2317:
--------------------------------------
@[~fedor.gavrilov], [~tari_manga],
Could you take a look at [^DROOLS-2317.dmn]? It seems still affected by this (or very similar) issue:
{{'Encapsulated input.Input for user.Value' for name 'input' on node 'Decision': syntax error near 'for'}}
> FEEL Syntax error on function(bkm) containing `for` keyword
> -----------------------------------------------------------
>
> Key: DROOLS-2317
> URL: https://issues.redhat.com/browse/DROOLS-2317
> Project: Drools
> Issue Type: Bug
> Components: dmn engine
> Reporter: Matteo Mortari
> Assignee: Fedor Gavrilov
> Priority: Major
> Attachments: DROOLS-2317.dmn, Dynamic composition.dmn
>
>
> Attached model
> {code:java}
> Error compiling FEEL expression 'for item in Order.items return Federal Tax for Item( item )' for name 'Calculate Federal Taxes' on node 'Calculate Federal Taxes': syntax error near 'for'
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 3 months
[JBoss JIRA] (JBJCA-1402) Failure to set query timeout for validation may result in long blocks of the pool
by Stephen Fikes (Jira)
[ https://issues.redhat.com/browse/JBJCA-1402?page=com.atlassian.jira.plugi... ]
Stephen Fikes updated JBJCA-1402:
---------------------------------
Description:
Validation queries run [without any explicit query timeout|https://github.com/ironjacamar/ironjacamar/blob/ironjacamar-1.4.1...]. If the validation query blocks (as it will with most drivers when a connection is invalid/stale), this can block the entire pool in certain cases (e.g. {{background-validation}} locks the pool during validation). Even with {{validate-on-match}}, the failure to enforce a short timeout can significantly impact time to get a connection if one or more failed connections are found in the pool.
Setting a driver level query timeout is not a suitable workaround because this impacts normal queries that may be expected to run for significant periods. The timeout for normal queries needs to be different from what is tolerated for validation queries (which should respond nearly instantaneously or else the connection is likely broken).
Minimally, an explicit query timeout should be supplied.
It might also be useful if a pool property or perhaps a system property could support a configurable timeout period (e.g. to account for potential latency in some systems). The Apache Tomcat pool support something of this nature with the [validationQueryTimeout|https://tomcat.apache.org/tomcat-9.0-doc/jdbc-pool...] property.
was:
Validation queries run [without any explicit query timeout|https://github.com/ironjacamar/ironjacamar/blob/ironjacamar-1.4.1...]. If the validation query blocks (as it will with most drivers when a connection is invalid/stale), this can block the entire pool in certain cases (e.g. {{background-validation}} locks the pool during validation). Even with {{validate-on-match}}, the failure to enforce a short timeout can significantly impact time to get a connection if one or more failed connections are found in the pool.
Setting a driver level query timeout is not a suitable workaround because this impacts normal queries that may be expected to run for significant periods. The timeout for normal queries needs to be different from what is tolerated for validation queries (which should respond nearly instantaneously or else the connection is likely broken).
An explicit query timeout should be supplied. It might also be useful if a pool property or perhaps a system property could support a configurable timeout period (e.g. to account for potential latency in some systems). The Apache Tomcat pool support something of this nature with the [validationQueryTimeout|https://tomcat.apache.org/tomcat-9.0-doc/jdbc-pool...] property.
> Failure to set query timeout for validation may result in long blocks of the pool
> ---------------------------------------------------------------------------------
>
> Key: JBJCA-1402
> URL: https://issues.redhat.com/browse/JBJCA-1402
> Project: IronJacamar
> Issue Type: Bug
> Components: Core
> Affects Versions: 1.4.10
> Reporter: Stephen Fikes
> Priority: Major
>
> Validation queries run [without any explicit query timeout|https://github.com/ironjacamar/ironjacamar/blob/ironjacamar-1.4.1...]. If the validation query blocks (as it will with most drivers when a connection is invalid/stale), this can block the entire pool in certain cases (e.g. {{background-validation}} locks the pool during validation). Even with {{validate-on-match}}, the failure to enforce a short timeout can significantly impact time to get a connection if one or more failed connections are found in the pool.
> Setting a driver level query timeout is not a suitable workaround because this impacts normal queries that may be expected to run for significant periods. The timeout for normal queries needs to be different from what is tolerated for validation queries (which should respond nearly instantaneously or else the connection is likely broken).
> Minimally, an explicit query timeout should be supplied.
> It might also be useful if a pool property or perhaps a system property could support a configurable timeout period (e.g. to account for potential latency in some systems). The Apache Tomcat pool support something of this nature with the [validationQueryTimeout|https://tomcat.apache.org/tomcat-9.0-doc/jdbc-pool...] property.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 3 months
[JBoss JIRA] (JBJCA-1402) Failure to set query timeout for validation may result in long blocks of the pool
by Stephen Fikes (Jira)
[ https://issues.redhat.com/browse/JBJCA-1402?page=com.atlassian.jira.plugi... ]
Stephen Fikes updated JBJCA-1402:
---------------------------------
Description:
Validation queries run [without any explicit query timeout|https://github.com/ironjacamar/ironjacamar/blob/ironjacamar-1.4.1...]. If the validation query blocks (as it will with most drivers when a connection is invalid/stale), this can block the entire pool in certain cases (e.g. {{background-validation}} locks the pool during validation). Even with {{validate-on-match}}, the failure to enforce a short timeout can significantly impact time to get a connection if one or more failed connections are found in the pool.
Setting a driver level query timeout is not a suitable workaround because this impacts normal queries that may be expected to run for significant periods. The timeout for normal queries needs to be different from what is tolerated for validation queries (which should respond nearly instantaneously or else the connection is likely broken).
Minimally, an explicit query timeout should be supplied.
It might also be useful if a pool property or perhaps a system property could support a configurable timeout period (e.g. to account for potential latency in some systems). The Apache Tomcat pool supports something of this nature with the [validationQueryTimeout|https://tomcat.apache.org/tomcat-9.0-doc/jdbc-pool...] property.
was:
Validation queries run [without any explicit query timeout|https://github.com/ironjacamar/ironjacamar/blob/ironjacamar-1.4.1...]. If the validation query blocks (as it will with most drivers when a connection is invalid/stale), this can block the entire pool in certain cases (e.g. {{background-validation}} locks the pool during validation). Even with {{validate-on-match}}, the failure to enforce a short timeout can significantly impact time to get a connection if one or more failed connections are found in the pool.
Setting a driver level query timeout is not a suitable workaround because this impacts normal queries that may be expected to run for significant periods. The timeout for normal queries needs to be different from what is tolerated for validation queries (which should respond nearly instantaneously or else the connection is likely broken).
Minimally, an explicit query timeout should be supplied.
It might also be useful if a pool property or perhaps a system property could support a configurable timeout period (e.g. to account for potential latency in some systems). The Apache Tomcat pool support something of this nature with the [validationQueryTimeout|https://tomcat.apache.org/tomcat-9.0-doc/jdbc-pool...] property.
> Failure to set query timeout for validation may result in long blocks of the pool
> ---------------------------------------------------------------------------------
>
> Key: JBJCA-1402
> URL: https://issues.redhat.com/browse/JBJCA-1402
> Project: IronJacamar
> Issue Type: Bug
> Components: Core
> Affects Versions: 1.4.10
> Reporter: Stephen Fikes
> Priority: Major
>
> Validation queries run [without any explicit query timeout|https://github.com/ironjacamar/ironjacamar/blob/ironjacamar-1.4.1...]. If the validation query blocks (as it will with most drivers when a connection is invalid/stale), this can block the entire pool in certain cases (e.g. {{background-validation}} locks the pool during validation). Even with {{validate-on-match}}, the failure to enforce a short timeout can significantly impact time to get a connection if one or more failed connections are found in the pool.
> Setting a driver level query timeout is not a suitable workaround because this impacts normal queries that may be expected to run for significant periods. The timeout for normal queries needs to be different from what is tolerated for validation queries (which should respond nearly instantaneously or else the connection is likely broken).
> Minimally, an explicit query timeout should be supplied.
> It might also be useful if a pool property or perhaps a system property could support a configurable timeout period (e.g. to account for potential latency in some systems). The Apache Tomcat pool supports something of this nature with the [validationQueryTimeout|https://tomcat.apache.org/tomcat-9.0-doc/jdbc-pool...] property.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 3 months
[JBoss JIRA] (JBJCA-1402) Failure to set query timeout for validation may result in long blocks of the pool
by Stephen Fikes (Jira)
Stephen Fikes created JBJCA-1402:
------------------------------------
Summary: Failure to set query timeout for validation may result in long blocks of the pool
Key: JBJCA-1402
URL: https://issues.redhat.com/browse/JBJCA-1402
Project: IronJacamar
Issue Type: Bug
Components: Core
Affects Versions: 1.4.10
Reporter: Stephen Fikes
Validation queries run [without any explicit query timeout|https://github.com/ironjacamar/ironjacamar/blob/ironjacamar-1.4.1...]. If the validation query blocks (as it will with most drivers when a connection is invalid/stale), this can block the entire pool in certain cases (e.g. {{background-validation}} locks the pool during validation). Even with {{validate-on-match}}, the failure to enforce a short timeout can significantly impact time to get a connection if one or more failed connections are found in the pool.
Setting a driver level query timeout is not a suitable workaround because this impacts normal queries that may be expected to run for significant periods. The timeout for normal queries needs to be different from what is tolerated for validation queries (which should respond nearly instantaneously or else the connection is likely broken).
An explicit query timeout should be supplied. It might also be useful if a pool property or perhaps a system property could support a configurable timeout period (e.g. to account for potential latency in some systems). The Apache Tomcat pool support something of this nature with the [validationQueryTimeout|https://tomcat.apache.org/tomcat-9.0-doc/jdbc-pool...] property.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 3 months
[JBoss JIRA] (WFCORE-4172) Add support for TLS 1.3
by Farah Juma (Jira)
[ https://issues.redhat.com/browse/WFCORE-4172?page=com.atlassian.jira.plug... ]
Farah Juma commented on WFCORE-4172:
------------------------------------
[~harishjboss1] Support for TLS 1.3 will be available in the upcoming WildFly 19 release. I would not recommend trying to merge this to an older WildFly version since this feature depends on changes in other components as well (Elytron, Undertow, XNIO).
> Add support for TLS 1.3
> -----------------------
>
> Key: WFCORE-4172
> URL: https://issues.redhat.com/browse/WFCORE-4172
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Security
> Reporter: Farah Juma
> Assignee: Farah Juma
> Priority: Major
> Labels: affects-model, eap-7.2.0-deferred
> Fix For: 11.0.0.Beta6
>
>
> It presently appears as though TLS 1.3 support could be available from Java 11.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 3 months
[JBoss JIRA] (WFLY-11566) ConstraintDeclarationException on JAX-RS/EJB Methods with List/Set query parameter
by Tomasz Adamski (Jira)
[ https://issues.redhat.com/browse/WFLY-11566?page=com.atlassian.jira.plugi... ]
Tomasz Adamski commented on WFLY-11566:
---------------------------------------
You mean in Resteasy? This is just my suggestion looking at the code, but it would be good if someone from the project look at it. [~ron_sigal] would you be able to take a look?
> 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)
6 years, 3 months