[JBoss JIRA] (DROOLS-5285) Implement maven-dependency-plugin inside drools project
by Gabriele Cardosi (Jira)
Gabriele Cardosi created DROOLS-5285:
----------------------------------------
Summary: Implement maven-dependency-plugin inside drools project
Key: DROOLS-5285
URL: https://issues.redhat.com/browse/DROOLS-5285
Project: Drools
Issue Type: Task
Reporter: Gabriele Cardosi
Assignee: Gabriele Cardosi
Replace the plugin currently used to check/enfore dependencies with the "maven-dependency-plugin" inside the "drools" project.
See drools-wb/pom.xml as configuration example
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years
[JBoss JIRA] (REMJMX-166) IllegalThreadStateException after idle jmx connection
by Darran Lofthouse (Jira)
[ https://issues.redhat.com/browse/REMJMX-166?page=com.atlassian.jira.plugi... ]
Darran Lofthouse updated REMJMX-166:
------------------------------------
Fix Version/s: 1.1.4.CR1
> IllegalThreadStateException after idle jmx connection
> -----------------------------------------------------
>
> Key: REMJMX-166
> URL: https://issues.redhat.com/browse/REMJMX-166
> Project: Remoting JMX
> Issue Type: Bug
> Components: Connection
> Affects Versions: 3.0.2.Final, 3.0.3.Final
> Environment: org.jboss.remotingjmx:remoting-jmx:3.0.3.Final + java8
> Reporter: Märt Bakhoff
> Assignee: Brad Maxwell
> Priority: Blocker
> Labels: downstream_dependency
> Fix For: 1.1.4.CR1, 3.0.4.Final, 3.1.0.Beta1
>
> Attachments: REMJMX-160.jar, REMJMX-166.jar
>
>
> Start wildfly-17.0.1/bin/standalone.sh, then run this code snippet:
> {noformat}
> JMXServiceURL url = new JMXServiceURL("service:jmx:remote+http://127.0.0.1:9990");
> try (JMXConnector connector = new RemotingConnectorProvider().newJMXConnector(url, Collections.emptyMap())) {
> connector.connect();
> MBeanServerConnection beanServer = connector.getMBeanServerConnection();
> RuntimeMXBean bean = ManagementFactory.newPlatformMXBeanProxy(beanServer, ManagementFactory.RUNTIME_MXBEAN_NAME, RuntimeMXBean.class);
> Thread.sleep(70_000);
> System.out.println("uptime: " + bean.getUptime());
> }
> {noformat}
> The following exception is always thrown:
> {noformat}
> Exception in thread "XNIO-1 task-12" java.lang.IllegalThreadStateException
> at java.lang.ThreadGroup.addUnstarted(ThreadGroup.java:867)
> at java.lang.Thread.init(Thread.java:405)
> at java.lang.Thread.init(Thread.java:349)
> at java.lang.Thread.<init>(Thread.java:599)
> at org.jboss.remotingjmx.protocol.v2.ClientExecutorManager$1.newThread(ClientExecutorManager.java:56)
> at java.util.concurrent.ThreadPoolExecutor$Worker.<init>(ThreadPoolExecutor.java:619)
> at java.util.concurrent.ThreadPoolExecutor.addWorker(ThreadPoolExecutor.java:932)
> at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1378)
> at org.jboss.remotingjmx.protocol.v2.ClientExecutorManager.execute(ClientExecutorManager.java:64)
> at org.jboss.remotingjmx.protocol.v2.ClientCommon$MessageReceiver.handleMessage(ClientCommon.java:118)
> at org.jboss.remoting3.remote.RemoteConnectionChannel.lambda$handleMessageData$3(RemoteConnectionChannel.java:430)
> at org.jboss.remoting3.EndpointImpl$TrackingExecutor.lambda$execute$0(EndpointImpl.java:926)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> The cause is in org.jboss.remotingjmx.protocol.v2.ClientExecutorManager.<init>. It creates a thread pool with Executors.newCachedThreadPool that has the default keepAliveTime of 60s.
> The thread factory is using a daemon thread group REMOTING_JMX that will self-destruct when the cached thread is terminated.
> The same code works when using older org.jboss.remotingjmx:remoting-jmx:3.0.1.Final. The regression is likely caused by commit https://github.com/jbossas/remoting-jmx/commit/2d6ae6c26da43304b752fc48f1...
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years
[JBoss JIRA] (WFLY-13414) Upgrade WildFly Core 11.1.1.Final
by Jeff Mesnil (Jira)
[ https://issues.redhat.com/browse/WFLY-13414?page=com.atlassian.jira.plugi... ]
Jeff Mesnil updated WFLY-13414:
-------------------------------
Description:
Artifacts for WildFly Core 11.1.0.Final were corrupted during the build.
We will upgrade to WildFly Core 11.1.1.Final (that contains no changes compared to 11.1.0.Final)
> Upgrade WildFly Core 11.1.1.Final
> ---------------------------------
>
> Key: WFLY-13414
> URL: https://issues.redhat.com/browse/WFLY-13414
> Project: WildFly
> Issue Type: Component Upgrade
> Components: Management
> Reporter: Jeff Mesnil
> Assignee: Jeff Mesnil
> Priority: Blocker
> Fix For: 19.1.0.Final
>
>
> Artifacts for WildFly Core 11.1.0.Final were corrupted during the build.
> We will upgrade to WildFly Core 11.1.1.Final (that contains no changes compared to 11.1.0.Final)
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years
[JBoss JIRA] (WFCORE-4950) Regression: Legacy Ldap Realm securing EJB with JDK8 not working
by Ricardo Martin Camarero (Jira)
[ https://issues.redhat.com/browse/WFCORE-4950?page=com.atlassian.jira.plug... ]
Ricardo Martin Camarero commented on WFCORE-4950:
-------------------------------------------------
Checking the changes in the {{module.xml}} file for that module:
1. The {{sun.jdk}} was removed in [WFCORE-3705|https://github.com/wildfly/wildfly-core/commit/b48ea664f81299...] when new jdk modules were integrated.
2. But later {{java.naming}} was added in a workaround for [WFLY-10394|https://github.com/wildfly/wildfly-core/commit/8d52d23e3158723...] and it includes the class {{com.sun.jndi.ldap.LdapCtxFactory}}.
3. But {{java.naming}} was removed later in [WFCORE-4531|https://github.com/wildfly/wildfly-core/commit/08bbe43df448b4...].
4. But between 2 and 3 the module {{jdk.security.auth}} was added in [WFCORE-3889|https://github.com/wildfly/wildfly-core/commit/81b9a7c64b9a27...], which in jdk requires transitive the {{java.naming}} ([see this|https://hg.openjdk.java.net/jdk/jdk11/file/1ddf9a99e4ad/src/jdk.secu...]). That makes it work in jdk-11 (removing that module I see the same exception using jdk-11).
So I'm going to add back the {{java.naming}} module, I think that it is included in jdk-11 because of the transitive tag but not in jdk-8 (jboss-modules seems to not add that transitive inclusion). I'll send the PR and we can argue about it later.
> Regression: Legacy Ldap Realm securing EJB with JDK8 not working
> ----------------------------------------------------------------
>
> Key: WFCORE-4950
> URL: https://issues.redhat.com/browse/WFCORE-4950
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Affects Versions: 12.0.0.Beta1
> Reporter: Ricardo Martin Camarero
> Assignee: Ricardo Martin Camarero
> Priority: Critical
>
> WFCORE issue related to JBEAP-19195. The root exception is the following:
> {noformat}
> javax.naming.NamingException: WFLYNAM0027: Failed instantiate InitialContextFactory com.sun.jndi.ldap.LdapCtxFactory from classloader ModuleClassLoader for Module "org.wildfly.extension.io" version 12.0.0.Beta1 from local module loader @5f2108b5 (finder: local module finder @31a5c39e (roots: /home/rmartinc/wildfly-20.0.0.Beta1-SNAPSHOT/modules,/home/rmartinc/wildfly-20.0.0.Beta1-SNAPSHOT/modules/system/layers/base)) [Root exception is java.lang.ClassNotFoundException: com.sun.jndi.ldap.LdapCtxFactory from [Module "org.wildfly.extension.io" version 12.0.0.Beta1 from local module loader @5f2108b5 (finder: local module finder @31a5c39e (roots: /home/rmartinc/wildfly-20.0.0.Beta1-SNAPSHOT/modules,/home/rmartinc/wildfly-20.0.0.Beta1-SNAPSHOT/modules/system/layers/base))]]
> at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:120)
> at org.jboss.as.naming.InitialContext.init(InitialContext.java:101)
> at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
> at org.jboss.as.naming.InitialContext.<init>(InitialContext.java:91)
> at org.jboss.as.naming.InitialContextFactory.getInitialContext(InitialContextFactory.java:43)
> at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
> at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313)
> at javax.naming.InitialContext.init(InitialContext.java:244)
> at javax.naming.InitialContext.<init>(InitialContext.java:216)
> at javax.naming.directory.InitialDirContext.<init>(InitialDirContext.java:101)
> at org.jboss.as.domain.management.connections.ldap.LdapConnectionManagerService.getConnection(LdapConnectionManagerService.java:272)
> at org.jboss.as.domain.management.connections.ldap.LdapConnectionManagerService.getConnection(LdapConnectionManagerService.java:184)
> at org.jboss.as.domain.management.connections.ldap.LdapConnectionManagerService.getConnection(LdapConnectionManagerService.java:180)
> at org.jboss.as.domain.management.security.LdapConnectionHandler.getConnection(LdapConnectionHandler.java:78)
> at org.jboss.as.domain.management.security.LdapUserSearcherFactory$LdapUserSearcherImpl.search(LdapUserSearcherFactory.java:125)
> at org.jboss.as.domain.management.security.LdapUserSearcherFactory$LdapUserSearcherImpl.search(LdapUserSearcherFactory.java:66)
> at org.jboss.as.domain.management.security.LdapCacheService$NoCacheCache.search(LdapCacheService.java:232)
> at org.jboss.as.domain.management.security.UserLdapCallbackHandler$SecurityRealmImpl.getRealmIdentity(UserLdapCallbackHandler.java:339)
> at org.jboss.as.domain.management.security.SecurityRealmService$SharedStateSecurityRealm.getRealmIdentity(SecurityRealmService.java:776)
> at org.wildfly.security.auth.server.ServerAuthenticationContext.assignName(ServerAuthenticationContext.java:1197)
> at org.wildfly.security.auth.server.ServerAuthenticationContext$UnassignedState.setPrincipal(ServerAuthenticationContext.java:1726)
> at org.wildfly.security.auth.server.ServerAuthenticationContext.setAuthenticationPrincipal(ServerAuthenticationContext.java:410)
> at org.wildfly.security.auth.server.ServerAuthenticationContext.setAuthenticationName(ServerAuthenticationContext.java:384)
> at org.wildfly.security.auth.server.ServerAuthenticationContext.setAuthenticationName(ServerAuthenticationContext.java:368)
> at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:912)
> at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handle(ServerAuthenticationContext.java:853)
> at org.wildfly.security.auth.callback.SocketAddressQueryCallbackHandler.handle(SocketAddressQueryCallbackHandler.java:57)
> at org.wildfly.security.sasl.util.TrustManagerSaslServerFactory.lambda$createSaslServer$0(TrustManagerSaslServerFactory.java:105)
> at org.wildfly.security.sasl.plain.PlainSaslServer.evaluateResponse(PlainSaslServer.java:118)
> at org.wildfly.security.sasl.util.AuthenticationCompleteCallbackSaslServerFactory$1.evaluateResponse(AuthenticationCompleteCallbackSaslServerFactory.java:58)
> at org.wildfly.security.sasl.util.AuthenticationTimeoutSaslServerFactory$DelegatingTimeoutSaslServer.evaluateResponse(AuthenticationTimeoutSaslServerFactory.java:110)
> at org.wildfly.security.sasl.util.SecurityIdentitySaslServerFactory$1.evaluateResponse(SecurityIdentitySaslServerFactory.java:59)
> at org.xnio.sasl.SaslUtils.evaluateResponse(SaslUtils.java:245)
> at org.xnio.sasl.SaslUtils.evaluateResponse(SaslUtils.java:217)
> at org.jboss.remoting3.remote.ServerConnectionOpenListener$AuthStepRunnable.run(ServerConnectionOpenListener.java:484)
> at org.jboss.remoting3.EndpointImpl$TrackingExecutor.lambda$execute$0(EndpointImpl.java:991)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1348)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.ClassNotFoundException: com.sun.jndi.ldap.LdapCtxFactory from [Module "org.wildfly.extension.io" version 12.0.0.Beta1 from local module loader @5f2108b5 (finder: local module finder @31a5c39e (roots: /home/rmartinc/wildfly-20.0.0.Beta1-SNAPSHOT/modules,/home/rmartinc/wildfly-20.0.0.Beta1-SNAPSHOT/modules/system/layers/base))]
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:255)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:410)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398)
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:116)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:348)
> at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:115)
> ... 40 more
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years
[JBoss JIRA] (DROOLS-5284) MVELTest.testTypeCoercionLongDivByInt fails with IBM JDK 8
by Toshiya Kobayashi (Jira)
[ https://issues.redhat.com/browse/DROOLS-5284?page=com.atlassian.jira.plug... ]
Toshiya Kobayashi edited comment on DROOLS-5284 at 4/30/20 3:45 AM:
--------------------------------------------------------------------
First of all, the expression in the unit test is not good. Java cannot compile this because Math.round() can accept only double or float.
{code:java}
15 * Math.round( new BigDecimal("49.4") ) / 100
{code}
Then, MVEL kindly tries to find a "BestCandidate" method for this.
https://github.com/mvel/mvel/blob/mvel2-2.4.7.Final/src/main/java/org/mve...
So MVEL picks up
{code:java}
public static int java.lang.Math.round(float)
{code}
or
{code:java}
public static long java.lang.Math.round(double)
{code}
(Assuming MVEL can coerce BigDecimal to float or double).
However, these 2 methods have no superiority in terms of scoring for "BestCandidate". Both get score "4".
https://github.com/mvel/mvel/blob/mvel2-2.4.7.Final/src/main/java/org/mve...
So the result depends on which method was picked first from a method list (The method list is given by Class.getMethods()).
In case of OpenJDK, Math.round(double) is picked. -> Finally, the expression results in (Long / Long) which returns Double by MathProcessor.
In case of IBM JDK Math.round(float) is picked. -> Finally, the expression results in (Integer / Integer) which returns Integer by IntDiv.
I think I can tweak the selection logic as Double is preferred coercion for BigDecimal.
was (Author: tkobayashi):
First of all, the expression in the unit test is not good. Java cannot compile this because Math.round() can accept only double or float.
{code:java}
15 * Math.round( new BigDecimal("49.4") ) / 100
{code}
Then, MVEL kindly tries to find a "BestCandidate" method for this.
https://github.com/mvel/mvel/blob/mvel2-2.4.7.Final/src/main/java/org/mve...
So MVEL picks up
{code:java}
public static int java.lang.Math.round(float)
{code}
or
{code:java}
public static long java.lang.Math.round(double)
{code}
(Assuming MVEL can coerce BigDecimal to float or double).
However, these 2 methods has no superiority in terms of scoring for "BestCandidate". Both get score "4".
https://github.com/mvel/mvel/blob/mvel2-2.4.7.Final/src/main/java/org/mve...
So the result depends on which method was picked first (The method lists are given by Class.getMethods()).
In case of OpenJDK, Math.round(double) is picked. -> Finally, the expression results in (Long / Long) which returns Double by MathProcessor.
In case of IBM JDK Math.round(float) is picked. -> Finally, the expression results in (Integer / Integer) which returns Integer by IntDiv.
I think I can tweak the selection logic as Double is preferred coercion for BigDecimal.
> MVELTest.testTypeCoercionLongDivByInt fails with IBM JDK 8
> ----------------------------------------------------------
>
> Key: DROOLS-5284
> URL: https://issues.redhat.com/browse/DROOLS-5284
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.36.0.Final
> Reporter: Toshiya Kobayashi
> Assignee: Toshiya Kobayashi
> Priority: Major
>
> MVELTest.testTypeCoercionLongDivByInt fails with IBM JDK 8
> {noformat}
> [ERROR] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.97 s <<< FAILURE! - in org.drools.compiler.integrationtests.MVELTest
> [ERROR] testTypeCoercionLongDivByInt(org.drools.compiler.integrationtests.MVELTest) Time elapsed: 0.962 s <<< FAILURE!
> java.lang.AssertionError: expected:<7.350000> but was:<7>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:118)
> at org.junit.Assert.assertEquals(Assert.java:144)
> at org.drools.compiler.integrationtests.MVELTest.testTypeCoercionLongDivByInt(MVELTest.java:1150)
> ...
> [INFO]
> [INFO] Results:
> [INFO]
> [ERROR] Failures:
> [ERROR] MVELTest.testTypeCoercionLongDivByInt:1150 expected:<7.350000> but was:<7>
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years
[JBoss JIRA] (DROOLS-5284) MVELTest.testTypeCoercionLongDivByInt fails with IBM JDK 8
by Toshiya Kobayashi (Jira)
[ https://issues.redhat.com/browse/DROOLS-5284?page=com.atlassian.jira.plug... ]
Toshiya Kobayashi edited comment on DROOLS-5284 at 4/30/20 3:42 AM:
--------------------------------------------------------------------
First of all, the expression in the unit test is not good. Java cannot compile this because Math.round() can accept only double or float.
{code:java}
15 * Math.round( new BigDecimal("49.4") ) / 100
{code}
Then, MVEL kindly try to find a "BestCandidate" method for this.
https://github.com/mvel/mvel/blob/mvel2-2.4.7.Final/src/main/java/org/mve...
So MVEL picks up
{code:java}
public static int java.lang.Math.round(float)
{code}
or
{code:java}
public static long java.lang.Math.round(double)
{code}
(Assuming MVEL can coerce BigDecimal to float or double).
However, these 2 methods has no superiority in terms of scoring for "BestCandidate". Both get score "4".
https://github.com/mvel/mvel/blob/mvel2-2.4.7.Final/src/main/java/org/mve...
So the result depends on which method was picked first (The method lists are given by Class.getMethods()).
In case of OpenJDK, Math.round(double) is picked. -> Finally, the expression results in (Long / Long) which returns Double by MathProcessor.
In case of IBM JDK Math.round(float) is picked. -> Finally, the expression results in (Integer / Integer) which returns Integer by IntDiv.
I think I can tweak the selection logic as Double is preferred coercion for BigDecimal.
was (Author: tkobayashi):
First of all, the expression in the unit test is not good. Java cannot compile this because Math.round() can accept only double or float.
{code:java}
15 * Math.round( new BigDecimal("49.4") ) / 100
{code}
Then, MVEL kindly find a "BestCandidate" method for this.
https://github.com/mvel/mvel/blob/mvel2-2.4.7.Final/src/main/java/org/mve...
So MVEL picks up
{code:java}
public static int java.lang.Math.round(float)
{code}
or
{code:java}
public static long java.lang.Math.round(double)
{code}
(Assuming MVEL can coerce BigDecimal to float or double).
However, these 2 methods has no superiority in terms of scoring for "BestCandidate". Both get score "4".
https://github.com/mvel/mvel/blob/mvel2-2.4.7.Final/src/main/java/org/mve...
So the result depends on which method was picked first (The method lists are given by Class.getMethods()).
In case of OpenJDK, Math.round(double) is picked. -> Finally, the expression results in (Long / Long) which returns Double by MathProcessor.
In case of IBM JDK Math.round(float) is picked. -> Finally, the expression results in (Integer / Integer) which returns Integer by IntDiv.
I think I can tweak the selection logic as Double is preferred coercion for BigDecimal.
> MVELTest.testTypeCoercionLongDivByInt fails with IBM JDK 8
> ----------------------------------------------------------
>
> Key: DROOLS-5284
> URL: https://issues.redhat.com/browse/DROOLS-5284
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.36.0.Final
> Reporter: Toshiya Kobayashi
> Assignee: Toshiya Kobayashi
> Priority: Major
>
> MVELTest.testTypeCoercionLongDivByInt fails with IBM JDK 8
> {noformat}
> [ERROR] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.97 s <<< FAILURE! - in org.drools.compiler.integrationtests.MVELTest
> [ERROR] testTypeCoercionLongDivByInt(org.drools.compiler.integrationtests.MVELTest) Time elapsed: 0.962 s <<< FAILURE!
> java.lang.AssertionError: expected:<7.350000> but was:<7>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:118)
> at org.junit.Assert.assertEquals(Assert.java:144)
> at org.drools.compiler.integrationtests.MVELTest.testTypeCoercionLongDivByInt(MVELTest.java:1150)
> ...
> [INFO]
> [INFO] Results:
> [INFO]
> [ERROR] Failures:
> [ERROR] MVELTest.testTypeCoercionLongDivByInt:1150 expected:<7.350000> but was:<7>
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years