April 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-5237) Wrong property reactivity with non getter chain of argume

by Toshiya Kobayashi (Jira)

[ https://issues.redhat.com/browse/DROOLS-5237?page=com.atlassian.jira.plug... ] Toshiya Kobayashi updated DROOLS-5237: -------------------------------------- Summary: Wrong property reactivity with non getter chain of argume (was: Wrong property reactivity with non getter chain outside of modify block) > Wrong property reactivity with non getter chain of argume > --------------------------------------------------------- > > Key: DROOLS-5237 > URL: https://issues.redhat.com/browse/DROOLS-5237 > Project: Drools > Issue Type: Bug > Components: executable model > Affects Versions: 7.36.0.Final > Reporter: Toshiya Kobayashi > Assignee: Toshiya Kobayashi > Priority: Major > > The rule below causes infinite loop with executable model because "name" is considered as modified property. > {noformat} > rule R1 when > $p : Person( name == "Mario" ) > then > System.out.println("name.length = " + $p.getName().length()); > modify($p) { setAge(41) }; > end > {noformat} > In standard-drl (DialectUtil.parseModifiedProperties), "getter + otherMethod" chain is considered that the property is modified. > https://github.com/kiegroup/drools/blob/master/drools-compiler/src/main/j... > Executable model follows the approach in this commit: > https://github.com/kiegroup/drools/commit/fc924465437919d5b6bd99849ee595e... > but executable model evaluates method calls outside of modify block while standard-drl evaluates only inside modify block. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (WFLY-13381) Unable to disable security on EJB over Http endpoint

by Flavia Rainone (Jira)

Flavia Rainone created WFLY-13381: ------------------------------------- Summary: Unable to disable security on EJB over Http endpoint Key: WFLY-13381 URL: https://issues.redhat.com/browse/WFLY-13381 Project: WildFly Issue Type: Bug Reporter: Flavia Rainone Assignee: Flavia Rainone For EJB over remote+http / http-remoting , removing the security-realm from the http-connector disables security and allows any remote client to connect to the endpoint without authenticating. {code} <subsystem xmlns="urn:jboss:domain:remoting:4.0"> <http-connector name="http-remoting-connector" connector-ref="default" security-realm="ApplicationRealm"/> </subsystem> {code} For EJB over Http it goes over the http-invoker in undertow, removing the ApplicationRealm {code} <subsystem xmlns="urn:jboss:domain:undertow:7.0" default-server="default-server" default-virtual-host="default-host" default-servlet-container="default" default-security-domain="other"> ... <host name="default-host" alias="localhost"> <location name="/" handler="welcome-content"/> <http-invoker security-realm="ApplicationRealm"/> </host> </server> {code} It fails with: {code} 18:10:16,660 ERROR [org.jboss.as.ejb3.invocation] (default task-1) WFLYEJB0034: EJB Invocation failed on component Hello for method public abstract java.lang.String com.jboss.examples.ejb.Hello.sayHello(java.lang.String): java.lang.IllegalArgumentException: Parameter 'identity' may not be null at org.wildfly.common.Assert.checkNotNullParamChecked(Assert.java:71) at org.wildfly.common.Assert.checkNotNullParam(Assert.java:49) at org.wildfly.security.auth.server.SecurityDomain.forIdentity(SecurityDomain.java:187) at org.jboss.as.security.service.SimpleSecurityManager.push(SimpleSecurityManager.java:313) at org.jboss.as.ejb3.security.SecurityContextInterceptor$1.run(SecurityContextInterceptor.java:52) at org.jboss.as.ejb3.security.SecurityContextInterceptor$1.run(SecurityContextInterceptor.java:49) at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:97) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:57) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:67) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:60) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:438) at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:619) at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:57) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:53) at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198) at org.jboss.as.ejb3.remote.AssociationImpl.invokeWithIdentity(AssociationImpl.java:556) at org.jboss.as.ejb3.remote.AssociationImpl.invokeMethod(AssociationImpl.java:537) at org.jboss.as.ejb3.remote.AssociationImpl.lambda$receiveInvocationRequest$0(AssociationImpl.java:195) 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) {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (DROOLS-5243) [DMN Designer] Boxed Expressionss - Decision Table - Users cannot insert output columns by using the header

by Guilherme Gomes (Jira)

[ https://issues.redhat.com/browse/DROOLS-5243?page=com.atlassian.jira.plug... ] Guilherme Gomes updated DROOLS-5243: ------------------------------------ Description: Users cannot insert new output columns by using the Decision Table header. See how to *reproduce*: !bug.gif|width=600! However, users can insert new output columns by using regular table cells. See the *workaround*: !workaround.gif|width=600! was: Users cannot insert new output columns by using the Decision Table header. See how to *reproduce*: !bug.gif|width=600! However, users are able to insert new columns by using regular table cells. See the *workaround*: !workaround.gif|width=600! > [DMN Designer] Boxed Expressionss - Decision Table - Users cannot insert output columns by using the header > ----------------------------------------------------------------------------------------------------------- > > Key: DROOLS-5243 > URL: https://issues.redhat.com/browse/DROOLS-5243 > Project: Drools > Issue Type: Bug > Components: DMN Editor > Reporter: Guilherme Gomes > Assignee: Daniel José dos Santos > Priority: Critical > Labels: drools-tools > Attachments: bug.gif, workaround.gif > > > Users cannot insert new output columns by using the Decision Table header. See how to *reproduce*: > !bug.gif|width=600! > However, users can insert new output columns by using regular table cells. See the *workaround*: > !workaround.gif|width=600! -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (LOGMGR-263) Logger Lookup is much slower as with JDK 8

by James Perkins (Jira)

[ https://issues.redhat.com/browse/LOGMGR-263?page=com.atlassian.jira.plugi... ] James Perkins updated LOGMGR-263: --------------------------------- Fix Version/s: 2.1.15.Final 2.2.0.Final 3.0.0.Final > Logger Lookup is much slower as with JDK 8 > ------------------------------------------ > > Key: LOGMGR-263 > URL: https://issues.redhat.com/browse/LOGMGR-263 > Project: JBoss Log Manager > Issue Type: Bug > Environment: WildFly 17, OpenJDK 11 > Reporter: Andreas Liebscher > Assignee: James Perkins > Priority: Critical > Fix For: 2.1.15.Final, 2.2.0.Final, 3.0.0.Final > > Attachments: ClassInEar.java, LogContextCacher.java, getlogger-stack.txt, grafik1570016303722 (1).png, grafik1570016303722.png, grafik1570016791285.png, logger-demo.war, responsetimes.png > > > During upgrading a Java EE application from WildFly 13 with JDK 8 to WildFly 17 with JDK 11 we had a serious performance issue. We identified the usage of the logging framework SLF4J with the pattern `Logger log = LoggerFactory.getLogger(XXX.class)` was the reason when a lot of calls to `getLogger` occur in parallel. As workaround we added `static` to some code hotspots to get back the performance we were used to. Also WildFly 13 with JDK 8 got a performance improvement with the added `static` keyword. > Please check the VisualVM output as prove of JDKSpecific got slower: -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (LOGMGR-263) Logger Lookup is much slower as with JDK 8

by James Perkins (Jira)

[ https://issues.redhat.com/browse/LOGMGR-263?page=com.atlassian.jira.plugi... ] James Perkins updated LOGMGR-263: --------------------------------- Git Pull Request: https://github.com/jboss-logging/jboss-logmanager/pull/295, https://github.com/jboss-logging/jboss-logmanager/pull/296, https://github.com/jboss-logging/jboss-logmanager/pull/297 (was: https://github.com/jboss-logging/jboss-logmanager/pull/295) > Logger Lookup is much slower as with JDK 8 > ------------------------------------------ > > Key: LOGMGR-263 > URL: https://issues.redhat.com/browse/LOGMGR-263 > Project: JBoss Log Manager > Issue Type: Bug > Environment: WildFly 17, OpenJDK 11 > Reporter: Andreas Liebscher > Assignee: James Perkins > Priority: Critical > Attachments: ClassInEar.java, LogContextCacher.java, getlogger-stack.txt, grafik1570016303722 (1).png, grafik1570016303722.png, grafik1570016791285.png, logger-demo.war, responsetimes.png > > > During upgrading a Java EE application from WildFly 13 with JDK 8 to WildFly 17 with JDK 11 we had a serious performance issue. We identified the usage of the logging framework SLF4J with the pattern `Logger log = LoggerFactory.getLogger(XXX.class)` was the reason when a lot of calls to `getLogger` occur in parallel. As workaround we added `static` to some code hotspots to get back the performance we were used to. Also WildFly 13 with JDK 8 got a performance improvement with the added `static` keyword. > Please check the VisualVM output as prove of JDKSpecific got slower: -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (DROOLS-5243) [DMN Designer] Boxed Expressionss - Decision Table - Users cannot insert output columns by using the header

by Guilherme Gomes (Jira)

Guilherme Gomes created DROOLS-5243: --------------------------------------- Summary: [DMN Designer] Boxed Expressionss - Decision Table - Users cannot insert output columns by using the header Key: DROOLS-5243 URL: https://issues.redhat.com/browse/DROOLS-5243 Project: Drools Issue Type: Task Components: DMN Editor Reporter: Guilherme Gomes Assignee: Daniel José dos Santos Attachments: bug.gif, workaround.gif Users cannot insert new output columns by using the Decision Table header. See how to *reproduce*: !bug.gif|width=600! However, users are able to insert new columns by using regular table cells. See the *workaround*: ! workaround.gif |width=600! -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (DROOLS-5243) [DMN Designer] Boxed Expressionss - Decision Table - Users cannot insert output columns by using the header

by Guilherme Gomes (Jira)

[ https://issues.redhat.com/browse/DROOLS-5243?page=com.atlassian.jira.plug... ] Guilherme Gomes updated DROOLS-5243: ------------------------------------ Description: Users cannot insert new output columns by using the Decision Table header. See how to *reproduce*: !bug.gif|width=600! However, users are able to insert new columns by using regular table cells. See the *workaround*: ! workaround.gif|width=600! was: Users cannot insert new output columns by using the Decision Table header. See how to *reproduce*: !bug.gif|width=600! However, users are able to insert new columns by using regular table cells. See the *workaround*: ! workaround.gif |width=600! > [DMN Designer] Boxed Expressionss - Decision Table - Users cannot insert output columns by using the header > ----------------------------------------------------------------------------------------------------------- > > Key: DROOLS-5243 > URL: https://issues.redhat.com/browse/DROOLS-5243 > Project: Drools > Issue Type: Task > Components: DMN Editor > Reporter: Guilherme Gomes > Assignee: Daniel José dos Santos > Priority: Critical > Labels: drools-tools > Attachments: bug.gif, workaround.gif > > > Users cannot insert new output columns by using the Decision Table header. See how to *reproduce*: > !bug.gif|width=600! > However, users are able to insert new columns by using regular table cells. See the *workaround*: > ! workaround.gif|width=600! -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (DROOLS-5243) [DMN Designer] Boxed Expressionss - Decision Table - Users cannot insert output columns by using the header

by Guilherme Gomes (Jira)

[ https://issues.redhat.com/browse/DROOLS-5243?page=com.atlassian.jira.plug... ] Guilherme Gomes updated DROOLS-5243: ------------------------------------ Description: Users cannot insert new output columns by using the Decision Table header. See how to *reproduce*: !bug.gif|width=600! However, users are able to insert new columns by using regular table cells. See the *workaround*: !workaround.gif|width=600! was: Users cannot insert new output columns by using the Decision Table header. See how to *reproduce*: !bug.gif|width=600! However, users are able to insert new columns by using regular table cells. See the *workaround*: ! workaround.gif|width=600! > [DMN Designer] Boxed Expressionss - Decision Table - Users cannot insert output columns by using the header > ----------------------------------------------------------------------------------------------------------- > > Key: DROOLS-5243 > URL: https://issues.redhat.com/browse/DROOLS-5243 > Project: Drools > Issue Type: Task > Components: DMN Editor > Reporter: Guilherme Gomes > Assignee: Daniel José dos Santos > Priority: Critical > Labels: drools-tools > Attachments: bug.gif, workaround.gif > > > Users cannot insert new output columns by using the Decision Table header. See how to *reproduce*: > !bug.gif|width=600! > However, users are able to insert new columns by using regular table cells. See the *workaround*: > !workaround.gif|width=600! -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (DROOLS-5243) [DMN Designer] Boxed Expressionss - Decision Table - Users cannot insert output columns by using the header

by Guilherme Gomes (Jira)

[ https://issues.redhat.com/browse/DROOLS-5243?page=com.atlassian.jira.plug... ] Guilherme Gomes updated DROOLS-5243: ------------------------------------ Issue Type: Bug (was: Task) > [DMN Designer] Boxed Expressionss - Decision Table - Users cannot insert output columns by using the header > ----------------------------------------------------------------------------------------------------------- > > Key: DROOLS-5243 > URL: https://issues.redhat.com/browse/DROOLS-5243 > Project: Drools > Issue Type: Bug > Components: DMN Editor > Reporter: Guilherme Gomes > Assignee: Daniel José dos Santos > Priority: Critical > Labels: drools-tools > Attachments: bug.gif, workaround.gif > > > Users cannot insert new output columns by using the Decision Table header. See how to *reproduce*: > !bug.gif|width=600! > However, users are able to insert new columns by using regular table cells. See the *workaround*: > !workaround.gif|width=600! -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (LOGMGR-263) Logger Lookup is much slower as with JDK 8

by James Perkins (Jira)

[ https://issues.redhat.com/browse/LOGMGR-263?page=com.atlassian.jira.plugi... ] James Perkins updated LOGMGR-263: --------------------------------- Git Pull Request: https://github.com/jboss-logging/jboss-logmanager/pull/295 > Logger Lookup is much slower as with JDK 8 > ------------------------------------------ > > Key: LOGMGR-263 > URL: https://issues.redhat.com/browse/LOGMGR-263 > Project: JBoss Log Manager > Issue Type: Bug > Environment: WildFly 17, OpenJDK 11 > Reporter: Andreas Liebscher > Assignee: James Perkins > Priority: Critical > Attachments: ClassInEar.java, LogContextCacher.java, getlogger-stack.txt, grafik1570016303722 (1).png, grafik1570016303722.png, grafik1570016791285.png, logger-demo.war, responsetimes.png > > > During upgrading a Java EE application from WildFly 13 with JDK 8 to WildFly 17 with JDK 11 we had a serious performance issue. We identified the usage of the logging framework SLF4J with the pattern `Logger log = LoggerFactory.getLogger(XXX.class)` was the reason when a lot of calls to `getLogger` occur in parallel. As workaround we added `static` to some code hotspots to get back the performance we were used to. Also WildFly 13 with JDK 8 got a performance improvement with the added `static` keyword. > Please check the VisualVM output as prove of JDKSpecific got slower: -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

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 April 2020