[JBoss JIRA] (DROOLS-3092) [DMN Designer] User can not see all the definition editing custom data types
by Daniel José dos Santos (Jira)
[ https://issues.jboss.org/browse/DROOLS-3092?page=com.atlassian.jira.plugi... ]
Daniel José dos Santos updated DROOLS-3092:
-------------------------------------------
Summary: [DMN Designer] User can not see all the definition editing custom data types (was: [DMN Designer] User can not see all the definition editing custom data ypes)
> [DMN Designer] User can not see all the definition editing custom data types
> ----------------------------------------------------------------------------
>
> Key: DROOLS-3092
> URL: https://issues.jboss.org/browse/DROOLS-3092
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.12.0.Final
> Reporter: Daniel José dos Santos
> Assignee: Daniel José dos Santos
> Priority: Major
> Labels: drools-tools
> Attachments: 46597891-4abb2b00-cae2-11e8-9e05-6649abbdeb23.png
>
>
> When editing "Custom Data Types", not all definitions are visible. This behaviour happens in all browsers.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 8 months
[JBoss JIRA] (WFLY-11336) SEVERE error on deploy of ear: "Unable to obtain CDI 1.1 utilities for Mojarra"
by tommaso borgato (Jira)
tommaso borgato created WFLY-11336:
--------------------------------------
Summary: SEVERE error on deploy of ear: "Unable to obtain CDI 1.1 utilities for Mojarra"
Key: WFLY-11336
URL: https://issues.jboss.org/browse/WFLY-11336
Project: WildFly
Issue Type: Bug
Components: CDI / Weld, JSF
Affects Versions: 13.0.0.Final
Reporter: tommaso borgato
Assignee: Dmitrii Tikhomirov
Fix For: 14.0.0.Beta2
Attachments: clusterbench-ee7-bugged.ear, clusterbench-ee7.ear
Affected scenario is [eap-7x-failover-ejb-ejbservlet-undeploy-repl-sync|https://jenkins.hosts.m...].
Every time the server is stated or re-started, we observed the following SEVERE logs just after clusterbench is deployed (clusterbench is an ear that uses JSF); we observed them systematically on each of the 4 nodes composing the cluster:
{noformat}
2018-06-27 02:47:07,439 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 72) WFLYCLINF0002: Started clusterbench-ee7.ear.clusterbench-ee7-web-granular.war cache from web container
2018-06-27 02:47:07,440 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 75) WFLYCLINF0002: Started client-mappings cache from ejb container
2018-06-27 02:47:07,440 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 73) WFLYCLINF0002: Started clusterbench-ee7.ear.clusterbench-ee7-web-default.war cache from web container
2018-06-27 02:47:07,440 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 74) WFLYCLINF0002: Started default-server cache from web container
2018-06-27 02:47:07,439 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 76) WFLYCLINF0002: Started clusterbench-ee7.ear.clusterbench-ee7-web-passivating.war cache from web container
2018-06-27 02:47:07,578 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 75) WFLYCLINF0002: Started clusterbench-ee7.ear/clusterbench-ee7-ejb.jar cache from ejb container
2018-06-27 02:47:07,673 WARN [org.jboss.weld.Bootstrap] (MSC service thread 1-7) WELD-000146: BeforeBeanDiscovery.addAnnotatedType(AnnotatedType<?>) used for class org.jberet.creation.BatchBeanProducer is deprecated from CDI 1.1!
2018-06-27 02:47:07,713 WARN [org.jboss.weld.Bootstrap] (MSC service thread 1-7) WELD-000146: BeforeBeanDiscovery.addAnnotatedType(AnnotatedType<?>) used for class org.hibernate.validator.internal.cdi.interceptor.ValidationInterceptor is deprecated from CDI 1.1!
2018-06-27 02:47:07,739 WARN [org.jboss.weld.Bootstrap] (MSC service thread 1-7) WELD-000146: BeforeBeanDiscovery.addAnnotatedType(AnnotatedType<?>) used for class com.sun.faces.flow.FlowDiscoveryCDIHelper is deprecated from CDI 1.1!
2018-06-27 02:47:08,149 SEVERE [javax.enterprise.resource.webcontainer.jsf.flow] (MSC service thread 1-7) Unable to obtain CDI 1.1 utilities for Mojarra
2018-06-27 02:47:08,163 SEVERE [javax.enterprise.resource.webcontainer.jsf.application.view] (MSC service thread 1-7) Unable to obtain CDI 1.1 utilities for Mojarra
2018-06-27 02:47:08,586 INFO [javax.enterprise.resource.webcontainer.jsf.config] (ServerService Thread Pool -- 76) Initializing Mojarra 2.2.13.SP5 for context '/clusterbench-granular'
2018-06-27 02:47:08,586 INFO [javax.enterprise.resource.webcontainer.jsf.config] (ServerService Thread Pool -- 72) Initializing Mojarra 2.2.13.SP5 for context '/clusterbench'
2018-06-27 02:47:08,587 INFO [javax.enterprise.resource.webcontainer.jsf.config] (ServerService Thread Pool -- 78) Initializing Mojarra 2.2.13.SP5 for context '/clusterbench-passivating'
2018-06-27 02:47:09,860 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 76) WFLYUT0021: Registered web context: '/clusterbench-granular' for server 'default-server'
2018-06-27 02:47:09,863 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 72) WFLYUT0021: Registered web context: '/clusterbench' for server 'default-server'
2018-06-27 02:47:09,863 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 78) WFLYUT0021: Registered web context: '/clusterbench-passivating' for server 'default-server'
2018-06-27 02:47:09,889 INFO [org.jboss.as.server] (ServerService Thread Pool -- 42) WFLYSRV0010: Deployed "clusterbench-ee7.ear" (runtime-name : "clusterbench-ee7.ear")
2018-06-27 02:47:09,989 INFO [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0212: Resuming server
{noformat}
Complete log [here|https://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/job/perflab_eap...]
Already observed a very long time ago: https://issues.jboss.org/browse/WFLY-1946
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 8 months
[JBoss JIRA] (WFLY-10919) INFO message Initialized tracer=JaegerTracer is too verbose
by Juraci Paixão Kröhling (Jira)
[ https://issues.jboss.org/browse/WFLY-10919?page=com.atlassian.jira.plugin... ]
Juraci Paixão Kröhling commented on WFLY-10919:
-----------------------------------------------
[~jamezp], you mentioned in another issue[1] that you'd be able to work on this from the WF-core side. Would the branch I mentioned on my previous comment help you get started?
1 - https://issues.jboss.org/browse/WFLY-10904?focusedCommentId=13623355&page...
> INFO message Initialized tracer=JaegerTracer is too verbose
> -----------------------------------------------------------
>
> Key: WFLY-10919
> URL: https://issues.jboss.org/browse/WFLY-10919
> Project: WildFly
> Issue Type: Bug
> Components: MP OpenTracing
> Affects Versions: 14.0.0.Beta2
> Reporter: Jan Stourac
> Assignee: Juraci Paixão Kröhling
> Priority: Major
>
> Following log message is logged during the deploy operation of a deployment:
> {code}
> 10:52:11,703 INFO [io.jaegertracing.Configuration] (ServerService Thread Pool -- 72) Initialized tracer=JaegerTracer(version=Java-0.30.6, serviceName=helloworld-rs.war, reporter=RemoteReporter(sender=UdpSender(), closeEnqueueTimeout=1000), sampler=RemoteControlledSampler(maxOperations=2000, manager=HttpSamplingManager(hostPort=localhost:5778), sampler=ProbabilisticSampler(tags={sampler.type=probabilistic, sampler.param=0.001})), tags={hostname=dhcp-10-40-5-80.brq.redhat.com, jaeger.version=Java-0.30.6, ip=10.40.5.80}, zipkinSharedRpcSpan=false, expandExceptionLogs=false)
> {code}
> This information is too verbose for INFO level. I propose to do one of following:
> # Remove this log message from INFO level - note that very similar message is also logged on DEBUG level:
> {code}
> 10:52:11,714 DEBUG [org.wildfly.microprofile.opentracing.smallrye] (ServerService Thread Pool -- 72) WFLYTRAC0001: Tracer initialized: JaegerTracer(version=Java-0.30.6, serviceName=helloworld-rs.war, reporter=RemoteReporter(sender=UdpSender(), closeEnqueueTimeout=1000), sampler=RemoteControlledSampler(maxOperations=2000, manager=HttpSamplingManager(hostPort=localhost:5778), sampler=ProbabilisticSampler(tags={sampler.type=probabilistic, sampler.param=0.001})), tags={hostname=dhcp-10-40-5-80.brq.redhat.com, jaeger.version=Java-0.30.6, ip=10.40.5.80}, zipkinSharedRpcSpan=false, expandExceptionLogs=false)
> {code}
> # Simplify the log message on INFO level to something simple, like:
> {code}
> 10:52:11,703 INFO [io.jaegertracing.Configuration] (ServerService Thread Pool -- 72) Initialized tracer for service helloworld-rs.war
> {code}
> This issue is a followup of a WFLY-10904.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 8 months
[JBoss JIRA] (WFLY-10919) INFO message Initialized tracer=JaegerTracer is too verbose
by Juraci Paixão Kröhling (Jira)
[ https://issues.jboss.org/browse/WFLY-10919?page=com.atlassian.jira.plugin... ]
Juraci Paixão Kröhling commented on WFLY-10919:
-----------------------------------------------
I'm currently blocked on this task, as I can't seem to be able to build wildfly-core. Message sent to the wildfly-dev mailing list:
http://lists.jboss.org/pipermail/wildfly-dev/2018-November/006679.html
WIP branch:
https://github.com/jpkrohling/wildfly-core/tree/WFLY-10919-RemoveJaegerCo...
> INFO message Initialized tracer=JaegerTracer is too verbose
> -----------------------------------------------------------
>
> Key: WFLY-10919
> URL: https://issues.jboss.org/browse/WFLY-10919
> Project: WildFly
> Issue Type: Bug
> Components: MP OpenTracing
> Affects Versions: 14.0.0.Beta2
> Reporter: Jan Stourac
> Assignee: Juraci Paixão Kröhling
> Priority: Major
>
> Following log message is logged during the deploy operation of a deployment:
> {code}
> 10:52:11,703 INFO [io.jaegertracing.Configuration] (ServerService Thread Pool -- 72) Initialized tracer=JaegerTracer(version=Java-0.30.6, serviceName=helloworld-rs.war, reporter=RemoteReporter(sender=UdpSender(), closeEnqueueTimeout=1000), sampler=RemoteControlledSampler(maxOperations=2000, manager=HttpSamplingManager(hostPort=localhost:5778), sampler=ProbabilisticSampler(tags={sampler.type=probabilistic, sampler.param=0.001})), tags={hostname=dhcp-10-40-5-80.brq.redhat.com, jaeger.version=Java-0.30.6, ip=10.40.5.80}, zipkinSharedRpcSpan=false, expandExceptionLogs=false)
> {code}
> This information is too verbose for INFO level. I propose to do one of following:
> # Remove this log message from INFO level - note that very similar message is also logged on DEBUG level:
> {code}
> 10:52:11,714 DEBUG [org.wildfly.microprofile.opentracing.smallrye] (ServerService Thread Pool -- 72) WFLYTRAC0001: Tracer initialized: JaegerTracer(version=Java-0.30.6, serviceName=helloworld-rs.war, reporter=RemoteReporter(sender=UdpSender(), closeEnqueueTimeout=1000), sampler=RemoteControlledSampler(maxOperations=2000, manager=HttpSamplingManager(hostPort=localhost:5778), sampler=ProbabilisticSampler(tags={sampler.type=probabilistic, sampler.param=0.001})), tags={hostname=dhcp-10-40-5-80.brq.redhat.com, jaeger.version=Java-0.30.6, ip=10.40.5.80}, zipkinSharedRpcSpan=false, expandExceptionLogs=false)
> {code}
> # Simplify the log message on INFO level to something simple, like:
> {code}
> 10:52:11,703 INFO [io.jaegertracing.Configuration] (ServerService Thread Pool -- 72) Initialized tracer for service helloworld-rs.war
> {code}
> This issue is a followup of a WFLY-10904.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 8 months
[JBoss JIRA] (WFLY-11335) Fix Undertow Deployment Metrics
by Jeff Mesnil (Jira)
[ https://issues.jboss.org/browse/WFLY-11335?page=com.atlassian.jira.plugin... ]
Jeff Mesnil updated WFLY-11335:
-------------------------------
Description:
Undertow deployment metrics are relevant only when /subsystem=undertow's statistics-enabled is true.
When that it not the case (and metrics can not be computed) the metrics' read handler should not return a meaningless value (e.g. 0) as it already specifies an undefined metric value in the metrics' attribute definition.
That change and WFCORE-4190 will prevent exposing Undertow metrics when they do not report actual metric from Undertow underlying runtime.
was:
Undertow metrics are relevant only when /subsystem=undertow's statistics-enabled is true.
When that it not the case (and metrics can not be computer) the metrics' read handler should not return a meaningless value (e.g. 0) as it already specifies an undefined metric value in the metrics' attribute definition.
That change and WFCORE-4190 will prevent exposing Undertow metrics when they do not report actual metric from Undertow underlying runtime.
> Fix Undertow Deployment Metrics
> -------------------------------
>
> Key: WFLY-11335
> URL: https://issues.jboss.org/browse/WFLY-11335
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 14.0.0.Final
> Reporter: Jeff Mesnil
> Assignee: Jeff Mesnil
> Priority: Major
> Fix For: 15.0.0.Beta1
>
>
> Undertow deployment metrics are relevant only when /subsystem=undertow's statistics-enabled is true.
> When that it not the case (and metrics can not be computed) the metrics' read handler should not return a meaningless value (e.g. 0) as it already specifies an undefined metric value in the metrics' attribute definition.
> That change and WFCORE-4190 will prevent exposing Undertow metrics when they do not report actual metric from Undertow underlying runtime.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 8 months
[JBoss JIRA] (WFLY-11335) Fix Undertow Deployment Metrics
by Jeff Mesnil (Jira)
Jeff Mesnil created WFLY-11335:
----------------------------------
Summary: Fix Undertow Deployment Metrics
Key: WFLY-11335
URL: https://issues.jboss.org/browse/WFLY-11335
Project: WildFly
Issue Type: Bug
Components: Web (Undertow)
Affects Versions: 14.0.0.Final
Reporter: Jeff Mesnil
Assignee: Jeff Mesnil
Fix For: 15.0.0.Beta1
Undertow metrics are relevant only when /subsystem=undertow's statistics-enabled is true.
When that it not the case (and metrics can not be computer) the metrics' read handler should not return a meaningless value (e.g. 0) as it already specifies an undefined metric value in the metrics' attribute definition.
That change and WFCORE-4190 will prevent exposing Undertow metrics when they do not report actual metric from Undertow underlying runtime.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 8 months
[JBoss JIRA] (WFLY-5890) Default mod_cluster load metric cpu (AverageSystemLoadMetric) is not supported on Windows
by Jan Kašík (Jira)
[ https://issues.jboss.org/browse/WFLY-5890?page=com.atlassian.jira.plugin.... ]
Jan Kašík commented on WFLY-5890:
---------------------------------
Since containers are more and more popular and CPU load metric is not reliable in this environment and users can choose from other pre-defined load metric, or they can define their own, I am lowering priority of this issue to MAJOR (same as product issue JBEAP-2506).
> Default mod_cluster load metric cpu (AverageSystemLoadMetric) is not supported on Windows
> -----------------------------------------------------------------------------------------
>
> Key: WFLY-5890
> URL: https://issues.jboss.org/browse/WFLY-5890
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.CR5, 14.0.0.Final
> Reporter: Michal Karm Babacek
> Assignee: Radoslav Husar
> Priority: Critical
> Labels: ux
>
> h3. Problem
> Wildfly 10's default load metric changed from *busyness* to *cpu*. Although otherwise fine, this change has a one major drawback: It doesn't work on Windows JDKs: MODCLUSTER-234. This fact has been known and acknowledged since 2011.
> {code}
> <subsystem xmlns="urn:jboss:domain:modcluster:2.0">
> <mod-cluster-config advertise-socket="modcluster" connector="ajp">
> <dynamic-load-provider>
> <load-metric type="cpu"/>
> </dynamic-load-provider>
> </mod-cluster-config>
> </subsystem>
> {code}
> Instead of a valid Load value, subsystem returns 0 and prints: {{MODCLUSTER000045: AverageSystemLoadMetric is not supported on this system and will be disabled.}}
> h3. Example
> {code}
> C:\Users\Administrator>groovy https://gist.githubusercontent.com/Karm/be36292ae52ded419b46/raw/addd6abf...
> load: -1.0
> avail. processors: 4
> {code}
> {code}
> mbabacek@localhost:~$ groovy https://gist.githubusercontent.com/Karm/be36292ae52ded419b46/raw/addd6abf...
> load: 0.67
> avail. processors: 4
> {code}
> h3. Call to action
> IMHO, this is a Major user experience failure, the default should provide meaningful values on all major platforms.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 8 months
[JBoss JIRA] (WFLY-5890) Default mod_cluster load metric cpu (AverageSystemLoadMetric) is not supported on Windows
by Jan Kašík (Jira)
[ https://issues.jboss.org/browse/WFLY-5890?page=com.atlassian.jira.plugin.... ]
Jan Kašík updated WFLY-5890:
----------------------------
Priority: Major (was: Critical)
> Default mod_cluster load metric cpu (AverageSystemLoadMetric) is not supported on Windows
> -----------------------------------------------------------------------------------------
>
> Key: WFLY-5890
> URL: https://issues.jboss.org/browse/WFLY-5890
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.CR5, 14.0.0.Final
> Reporter: Michal Karm Babacek
> Assignee: Radoslav Husar
> Priority: Major
> Labels: ux
>
> h3. Problem
> Wildfly 10's default load metric changed from *busyness* to *cpu*. Although otherwise fine, this change has a one major drawback: It doesn't work on Windows JDKs: MODCLUSTER-234. This fact has been known and acknowledged since 2011.
> {code}
> <subsystem xmlns="urn:jboss:domain:modcluster:2.0">
> <mod-cluster-config advertise-socket="modcluster" connector="ajp">
> <dynamic-load-provider>
> <load-metric type="cpu"/>
> </dynamic-load-provider>
> </mod-cluster-config>
> </subsystem>
> {code}
> Instead of a valid Load value, subsystem returns 0 and prints: {{MODCLUSTER000045: AverageSystemLoadMetric is not supported on this system and will be disabled.}}
> h3. Example
> {code}
> C:\Users\Administrator>groovy https://gist.githubusercontent.com/Karm/be36292ae52ded419b46/raw/addd6abf...
> load: -1.0
> avail. processors: 4
> {code}
> {code}
> mbabacek@localhost:~$ groovy https://gist.githubusercontent.com/Karm/be36292ae52ded419b46/raw/addd6abf...
> load: 0.67
> avail. processors: 4
> {code}
> h3. Call to action
> IMHO, this is a Major user experience failure, the default should provide meaningful values on all major platforms.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 8 months