June 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-1620) Unmarshalling <text> DMN elements containing CDATA fails on IBM JDK

by Tibor Zimányi (JIRA)

Tibor Zimányi created DROOLS-1620: ------------------------------------- Summary: Unmarshalling <text> DMN elements containing CDATA fails on IBM JDK Key: DROOLS-1620 URL: https://issues.jboss.org/browse/DROOLS-1620 Project: Drools Issue Type: Bug Components: dmn engine Affects Versions: 7.0.0.Final Reporter: Tibor Zimányi Assignee: Edson Tirelli Fix For: 7.1.0.Final When running test UnmarshalMarshalTest.testDish() on IBM JDK, the test fails with following output [1]. Unmarshall call here [2] produces UnaryTests with empty _text_ attributes, so whole CDATA content is ignored during unmarshalling. [1] https://gist.github.com/baldimir/e65a8755aeebef17508788213676fcb2 [2] https://github.com/kiegroup/drools/blob/158ae2f284f080f75016fedc2f8426568... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2979) Unignore RemoveManagementRealmTestCase

by Petr Kremensky (JIRA)

Petr Kremensky created WFCORE-2979: -------------------------------------- Summary: Unignore RemoveManagementRealmTestCase Key: WFCORE-2979 URL: https://issues.jboss.org/browse/WFCORE-2979 Project: WildFly Core Issue Type: Task Components: CLI Reporter: Petr Kremensky Assignee: Jean-Francois Denise Unignore it once CLI is based on aesh-readline. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2974) CLI completion after one or more spaces gives confusing result

by Chao Wang (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2974?page=com.atlassian.jira.plugi... ] Chao Wang commented on WFCORE-2974: ----------------------------------- I agree this is an edge case and a deferred fix prevents risk for 7.1. > CLI completion after one or more spaces gives confusing result > -------------------------------------------------------------- > > Key: WFCORE-2974 > URL: https://issues.jboss.org/browse/WFCORE-2974 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Affects Versions: 3.0.0.Beta26 > Reporter: Chao Wang > Assignee: Jean-Francois Denise > Priority: Minor > > CLI completion after one or more spaces gives confusing result. > {noformat} > [standalone@localhost:9990 /] /sub[space]TabKey Here > above completion returns result: > [standalone@localhost:9990 /] /sub ystem= > It seems the space before TabKey is recognized as character 's'. > Go on for a second TabKey, it will not list any subsystem candidates. > {noformat} > I think the first completion is not necessary as the {{sub}} with a following space is not a valid path. It'd better stop there rather than return completion result {{/sub ystem=}}. But this is a minor case. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8967) EJB subsystem thread-pool statistics largest-thread-count is counting threads instead of show the peak of parallel use

by Wolf-Dieter Fink (JIRA)

Wolf-Dieter Fink created WFLY-8967: -------------------------------------- Summary: EJB subsystem thread-pool statistics largest-thread-count is counting threads instead of show the peak of parallel use Key: WFLY-8967 URL: https://issues.jboss.org/browse/WFLY-8967 Project: WildFly Issue Type: Bug Components: EJB Affects Versions: 11.0.0.CR1 Reporter: Wolf-Dieter Fink The description of "largest-thread-count" is => "The largest number of threads that have ever simultaneously been in the pool." But the behaviour at runtime shows that it is handled similar to task-count. If only one thread is used it will increased for every invocation until max-threads. As result the largest-thread-count is == max-threads after a short time. The helpful metrict to check whether the threads are exhaused is missing! -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8966) EJB subsystem thread-pool statistics largest-thread-count is counting threads instead of show the peak of parallel use

by Wolf-Dieter Fink (JIRA)

Wolf-Dieter Fink created WFLY-8966: -------------------------------------- Summary: EJB subsystem thread-pool statistics largest-thread-count is counting threads instead of show the peak of parallel use Key: WFLY-8966 URL: https://issues.jboss.org/browse/WFLY-8966 Project: WildFly Issue Type: Bug Components: EJB Affects Versions: 11.0.0.CR1 Reporter: Wolf-Dieter Fink The description of "largest-thread-count" is => "The largest number of threads that have ever simultaneously been in the pool." But the behaviour at runtime shows that it is handled similar to task-count. If only one thread is used it will increased for every invocation until max-threads. As result the largest-thread-count is == max-threads after a short time. The helpful metrict to check whether the threads are exhaused is missing! -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2974) CLI completion after one or more spaces gives confusing result

by Jean-Francois Denise (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2974?page=com.atlassian.jira.plugi... ] Jean-Francois Denise commented on WFCORE-2974: ---------------------------------------------- [~soul2zimate], I checked and that is an old wrong behaviour. This is caused by the CLI parser to ignore the space that exists in an operation: e.g.: / subsystem = xxx / name = zzz : read-resource() The side effect is that all whitespaces are skip, so having an invalid whitespace in the middle of a type or name is treated the same way. That is really a corner case and I would not fix it for 7.1. > CLI completion after one or more spaces gives confusing result > -------------------------------------------------------------- > > Key: WFCORE-2974 > URL: https://issues.jboss.org/browse/WFCORE-2974 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Affects Versions: 3.0.0.Beta26 > Reporter: Chao Wang > Assignee: Jean-Francois Denise > Priority: Minor > > CLI completion after one or more spaces gives confusing result. > {noformat} > [standalone@localhost:9990 /] /sub[space]TabKey Here > above completion returns result: > [standalone@localhost:9990 /] /sub ystem= > It seems the space before TabKey is recognized as character 's'. > Go on for a second TabKey, it will not list any subsystem candidates. > {noformat} > I think the first completion is not necessary as the {{sub}} with a following space is not a valid path. It'd better stop there rather than return completion result {{/sub ystem=}}. But this is a minor case. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1619) Compile error on a multibyte-name variable as a positional query parameter

by Toshiya Kobayashi (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1619?page=com.atlassian.jira.plugi... ] Toshiya Kobayashi reassigned DROOLS-1619: ----------------------------------------- Assignee: Matteo Mortari (was: Mario Fusco) > Compile error on a multibyte-name variable as a positional query parameter > -------------------------------------------------------------------------- > > Key: DROOLS-1619 > URL: https://issues.jboss.org/browse/DROOLS-1619 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 7.1.0.Beta2 > Reporter: Toshiya Kobayashi > Assignee: Matteo Mortari > Labels: support > > Drools raises a compile error on a multibyte-name variable as a positional query parameter. > {noformat} > query testquery(int $a, Person $t) > $t := Person(age > $a) > end > rule "hoge" > when > testquery(30, $あああ;) > then > System.out.println($あああ.getName()); > end > {noformat} > {noformat} > java.lang.RuntimeException: Error while creating KieBase[Message [id=1, kieBase=defaultKieBase, level=ERROR, path=Sample.drl, line=11, column=0 > text=Unable to compile expression: $あああ], Message [id=2, kieBase=defaultKieBase, level=ERROR, path=Sample.drl, line=9, column=0 > text=Rule Compilation error $あああ cannot be resolved]] > at org.drools.compiler.kie.builder.impl.KieContainerImpl.getKieBase(KieContainerImpl.java:527) > at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:687) > at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:629) > at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:611) > at com.sample.DroolsTest.main(DroolsTest.java:18) > {noformat} > It is considered as "not variable" in QueryElementBuilder.isVariable() since BRMS 6.4. > https://github.com/kiegroup/drools/blob/6.5.x/drools-compiler/src/main/ja... > https://github.com/kiegroup/drools/blob/6.5.x/drools-core/src/main/java/o... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1619) Compile error on a multibyte-name variable as a positional query parameter

by Toshiya Kobayashi (JIRA)

Toshiya Kobayashi created DROOLS-1619: ----------------------------------------- Summary: Compile error on a multibyte-name variable as a positional query parameter Key: DROOLS-1619 URL: https://issues.jboss.org/browse/DROOLS-1619 Project: Drools Issue Type: Bug Components: core engine Affects Versions: 7.1.0.Beta2 Reporter: Toshiya Kobayashi Assignee: Mario Fusco Drools raises a compile error on a multibyte-name variable as a positional query parameter. {noformat} query testquery(int $a, Person $t) $t := Person(age > $a) end rule "hoge" when testquery(30, $あああ;) then System.out.println($あああ.getName()); end {noformat} {noformat} java.lang.RuntimeException: Error while creating KieBase[Message [id=1, kieBase=defaultKieBase, level=ERROR, path=Sample.drl, line=11, column=0 text=Unable to compile expression: $あああ], Message [id=2, kieBase=defaultKieBase, level=ERROR, path=Sample.drl, line=9, column=0 text=Rule Compilation error $あああ cannot be resolved]] at org.drools.compiler.kie.builder.impl.KieContainerImpl.getKieBase(KieContainerImpl.java:527) at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:687) at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:629) at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:611) at com.sample.DroolsTest.main(DroolsTest.java:18) {noformat} It is considered as "not variable" in QueryElementBuilder.isVariable() since BRMS 6.4. https://github.com/kiegroup/drools/blob/6.5.x/drools-compiler/src/main/ja... https://github.com/kiegroup/drools/blob/6.5.x/drools-core/src/main/java/o... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2978) Verify that WFCORE-2923 fix is valid

by ehsavoie Hugonnet (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2978?page=com.atlassian.jira.plugi... ] ehsavoie Hugonnet updated WFCORE-2978: -------------------------------------- Summary: Verify that WFCORE-2923 fix is valid (was: Verify that JBEAP-11343 fix is valid) > Verify that WFCORE-2923 fix is valid > ------------------------------------- > > Key: WFCORE-2978 > URL: https://issues.jboss.org/browse/WFCORE-2978 > Project: WildFly Core > Issue Type: Bug > Components: Logging, Security > Reporter: ehsavoie Hugonnet > Assignee: ehsavoie Hugonnet > Priority: Blocker > > [1:39 PM] Emmanuel Hugonnet: @BrianStansberry hi, could you take a look at https://github.com/wildfly/wildfly-core/pull/2514 > [1:40 PM] Emmanuel Hugonnet: I've a bit of a doubt because i couldn't create a dependency on the credentialstore since auditlog handlers are not services > [1:41 PM] Brian Stansberry: ok. it does seem a bit nasty because of that > [1:41 PM] Brian Stansberry: at a glance > [1:41 PM] Emmanuel Hugonnet: yes > [1:41 PM] Brian Stansberry: a very quick glance > [1:42 PM] Brian Stansberry: ah , but SyslogAuditLogHandler is not an OSH so I won't comment until I really understand :) > [1:43 PM] Emmanuel Hugonnet: yes ;) > [2:04 PM] Brian Stansberry: I don't think that will be reliable; there's no guarantee that store will be started > [2:07 PM] Kabir Khan: I don't think the syslog handler tries to write until boot is done > [2:07 PM] Kabir Khan: could it be possible to lazy init those suppliers? > [2:11 PM] Emmanuel Hugonnet: I guess we would only need the attribute value and a serviceregistry > [2:12 PM] Emmanuel Hugonnet: I'm wondering if this is not lazy per default > [2:12 PM] Emmanuel Hugonnet: as the service is only called when the credential is required as far as I can see > [2:13 PM] Brian Stansberry: yes, it is lazy > [2:43 PM] Kabir Khan: @ehsavoie I think the problem @BrianStansberry mentions is whether the services have stabilised so the CR is ready by the time the syslog write happens > [2:44 PM] Emmanuel Hugonnet: @KabirKhan yes but I don't have any service in the audit log tree to be able to require for the CR to be ready > [2:45 PM] Kabir Khan: @ehsavoie I can try to discuss it on the pm call, perhaps we can do without it for the beta > [2:47 PM] Emmanuel Hugonnet: or I could add a service to get this one on > [2:48 PM] Emmanuel Hugonnet: a bit like what is done for security realms > [2:53 PM] Kabir Khan: That could be good for the future, but I think for Beta it should be ok as it is > [2:57 PM] Brian Stansberry: @KabirKhan @ehsavoie +1 > [2:57 PM] Brian Stansberry: I think it is fine at boot as no logging will happen until MSC has stabilized > [2:57 PM] Brian Stansberry: and probably post boot too > [2:57 PM] Emmanuel Hugonnet: well the boot test is ok > [2:58 PM] Kabir Khan: but we should have a blocker jira to investigate whether our assumptions are correct > [2:58 PM] Emmanuel Hugonnet: ok > [2:58 PM] Brian Stansberry: the scenario is a management op adds the credential store and the syslog handler, and then the syslog handler wants to log before the store service is up > [2:58 PM] Brian Stansberry: but, for audit logging we don't log until op commit/rollback > [2:58 PM] Brian Stansberry: and by then MSC is going to be stablized > [3:06 PM] Kabir Khan: that should be: 'we think we don't log', so that needs checking :) -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2978) Verify that JBEAP-11343 fix is valid

by ehsavoie Hugonnet (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2978?page=com.atlassian.jira.plugi... ] ehsavoie Hugonnet moved JBEAP-11675 to WFCORE-2978: --------------------------------------------------- Project: WildFly Core (was: JBoss Enterprise Application Platform) Key: WFCORE-2978 (was: JBEAP-11675) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Logging Security (was: Security) Target Release: (was: 7.1.0.GA) Affects Version/s: (was: 7.1.0.DR19) > Verify that JBEAP-11343 fix is valid > ------------------------------------ > > Key: WFCORE-2978 > URL: https://issues.jboss.org/browse/WFCORE-2978 > Project: WildFly Core > Issue Type: Bug > Components: Logging, Security > Reporter: ehsavoie Hugonnet > Assignee: ehsavoie Hugonnet > Priority: Blocker > > [1:39 PM] Emmanuel Hugonnet: @BrianStansberry hi, could you take a look at https://github.com/wildfly/wildfly-core/pull/2514 > [1:40 PM] Emmanuel Hugonnet: I've a bit of a doubt because i couldn't create a dependency on the credentialstore since auditlog handlers are not services > [1:41 PM] Brian Stansberry: ok. it does seem a bit nasty because of that > [1:41 PM] Brian Stansberry: at a glance > [1:41 PM] Emmanuel Hugonnet: yes > [1:41 PM] Brian Stansberry: a very quick glance > [1:42 PM] Brian Stansberry: ah , but SyslogAuditLogHandler is not an OSH so I won't comment until I really understand :) > [1:43 PM] Emmanuel Hugonnet: yes ;) > [2:04 PM] Brian Stansberry: I don't think that will be reliable; there's no guarantee that store will be started > [2:07 PM] Kabir Khan: I don't think the syslog handler tries to write until boot is done > [2:07 PM] Kabir Khan: could it be possible to lazy init those suppliers? > [2:11 PM] Emmanuel Hugonnet: I guess we would only need the attribute value and a serviceregistry > [2:12 PM] Emmanuel Hugonnet: I'm wondering if this is not lazy per default > [2:12 PM] Emmanuel Hugonnet: as the service is only called when the credential is required as far as I can see > [2:13 PM] Brian Stansberry: yes, it is lazy > [2:43 PM] Kabir Khan: @ehsavoie I think the problem @BrianStansberry mentions is whether the services have stabilised so the CR is ready by the time the syslog write happens > [2:44 PM] Emmanuel Hugonnet: @KabirKhan yes but I don't have any service in the audit log tree to be able to require for the CR to be ready > [2:45 PM] Kabir Khan: @ehsavoie I can try to discuss it on the pm call, perhaps we can do without it for the beta > [2:47 PM] Emmanuel Hugonnet: or I could add a service to get this one on > [2:48 PM] Emmanuel Hugonnet: a bit like what is done for security realms > [2:53 PM] Kabir Khan: That could be good for the future, but I think for Beta it should be ok as it is > [2:57 PM] Brian Stansberry: @KabirKhan @ehsavoie +1 > [2:57 PM] Brian Stansberry: I think it is fine at boot as no logging will happen until MSC has stabilized > [2:57 PM] Brian Stansberry: and probably post boot too > [2:57 PM] Emmanuel Hugonnet: well the boot test is ok > [2:58 PM] Kabir Khan: but we should have a blocker jira to investigate whether our assumptions are correct > [2:58 PM] Emmanuel Hugonnet: ok > [2:58 PM] Brian Stansberry: the scenario is a management op adds the credential store and the syslog handler, and then the syslog handler wants to log before the store service is up > [2:58 PM] Brian Stansberry: but, for audit logging we don't log until op commit/rollback > [2:58 PM] Brian Stansberry: and by then MSC is going to be stablized > [3:06 PM] Kabir Khan: that should be: 'we think we don't log', so that needs checking :) -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira June 2017