[JBoss JIRA] (JGRP-872) TP: cluster name is shipped with each message
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-872?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-872:
--------------------------
Description:
If a cluster name (the name used in Channel.connect()) is long, because we ship it with each message (in the TP header), this blows up the size of the marshalled messages.
Maybe we can canonicalize the cluster name shipped with each message, similar to what we want to do with Addresses, e.g. replace the cluster name with a short.
was:
If a cluster name (the name used in Channel.conect()) is long, because we ship it with each message (in the TP header), this blows up the size of the marshalled messages.
Maybe we can canonicalize the cluster name shipped with each message, similar to what we want to do with Addresses, e.g. replace the cluster name with a short.
> TP: cluster name is shipped with each message
> ---------------------------------------------
>
> Key: JGRP-872
> URL: https://issues.redhat.com/browse/JGRP-872
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Major
> Fix For: 3.3
>
>
> If a cluster name (the name used in Channel.connect()) is long, because we ship it with each message (in the TP header), this blows up the size of the marshalled messages.
> Maybe we can canonicalize the cluster name shipped with each message, similar to what we want to do with Addresses, e.g. replace the cluster name with a short.
--
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 Guillaume Smet (Jira)
[ https://issues.redhat.com/browse/WFLY-11566?page=com.atlassian.jira.plugi... ]
Guillaume Smet commented on WFLY-11566:
---------------------------------------
Thanks for adding the test! I'll go backport this work to the 6.0 branch then.
Are you sure you shouldn't consider both instead of replacing the existing condition? That sounds a bit fishy to me (but I don't really know this code).
> 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
[JBoss JIRA] (SWSQE-1069) Infra - Istio Install - Kiali config changes
by Hayk Hovsepyan (Jira)
[ https://issues.redhat.com/browse/SWSQE-1069?page=com.atlassian.jira.plugi... ]
Hayk Hovsepyan updated SWSQE-1069:
----------------------------------
Description:
In Istio installation there are 2 kiali config map changes required to do:
set true in: "extensions: threescale: enabled: true"
set correct in_cluster_url "tracing: in_cluster_url: http://tracing.istio-system/jaeger"
In "install-istio" job add option to install 3scale istio adapter (default true), as is done in 'install-maistra' job.
was:
In Istio installation there are 2 kiali config map changes required to do:
set true in: "extensions: threescale: enabled: true"
set correct in_cluster_url "tracing: in_cluster_url: http://tracing.istio-system/jaeger"
> Infra - Istio Install - Kiali config changes
> --------------------------------------------
>
> Key: SWSQE-1069
> URL: https://issues.redhat.com/browse/SWSQE-1069
> Project: Kiali QE
> Issue Type: QE Task
> Reporter: Hayk Hovsepyan
> Assignee: Filip Brychta
> Priority: Major
> Labels: infrastructure
>
> In Istio installation there are 2 kiali config map changes required to do:
> set true in: "extensions: threescale: enabled: true"
> set correct in_cluster_url "tracing: in_cluster_url: http://tracing.istio-system/jaeger"
> In "install-istio" job add option to install 3scale istio adapter (default true), as is done in 'install-maistra' job.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 3 months
[JBoss JIRA] (DROOLS-5056) [DMN Designer] Sometimes the nodes inside Decision Service are wrong positioned
by Michael Anstis (Jira)
[ https://issues.redhat.com/browse/DROOLS-5056?page=com.atlassian.jira.plug... ]
Michael Anstis updated DROOLS-5056:
-----------------------------------
Summary: [DMN Designer] Sometimes the nodes inside Decision Service are wrong positioned (was: Sometimes the nodes inside Decision Service are wrong positioned)
> [DMN Designer] Sometimes the nodes inside Decision Service are wrong positioned
> -------------------------------------------------------------------------------
>
> Key: DROOLS-5056
> URL: https://issues.redhat.com/browse/DROOLS-5056
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Reporter: Daniel José dos Santos
> Assignee: Michael Anstis
> Priority: Major
> Labels: drools-tools
> Attachments: issue.mp4
>
>
> Sometimes the nodes inside the Decision Service are positioned outside from the Decision Service when the .DMN is saved an open again.
> I was unable to map exact when this happen, but I noticed that this happens depending on the changes you do in the position and size of the Decision Service and its inner nodes.
> I recorded a video with 2 minutes when the issue happens in the last seconds.
> As it can be notice it takes lots of trials to reproduce the issue.
> Also I was unable to reproduce the issue in the Business Central, so I'm not sure if it is related to DMN Editor in VS Code or DMN Editor itself.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 3 months
[JBoss JIRA] (DROOLS-5056) [DMN Designer] Sometimes the nodes inside Decision Service are wrong positioned
by Michael Anstis (Jira)
[ https://issues.redhat.com/browse/DROOLS-5056?page=com.atlassian.jira.plug... ]
Michael Anstis updated DROOLS-5056:
-----------------------------------
Tester: Jozef Marko
> [DMN Designer] Sometimes the nodes inside Decision Service are wrong positioned
> -------------------------------------------------------------------------------
>
> Key: DROOLS-5056
> URL: https://issues.redhat.com/browse/DROOLS-5056
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Reporter: Daniel José dos Santos
> Assignee: Michael Anstis
> Priority: Major
> Labels: drools-tools
> Attachments: issue.mp4
>
>
> Sometimes the nodes inside the Decision Service are positioned outside from the Decision Service when the .DMN is saved an open again.
> I was unable to map exact when this happen, but I noticed that this happens depending on the changes you do in the position and size of the Decision Service and its inner nodes.
> I recorded a video with 2 minutes when the issue happens in the last seconds.
> As it can be notice it takes lots of trials to reproduce the issue.
> Also I was unable to reproduce the issue in the Business Central, so I'm not sure if it is related to DMN Editor in VS Code or DMN Editor itself.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 3 months