[JBoss JIRA] (WFLY-13064) EJB client-side interceptor failure when using HTTPRemoting Protocol
by Francesco Marchioni (Jira)
[ https://issues.redhat.com/browse/WFLY-13064?page=com.atlassian.jira.plugi... ]
Francesco Marchioni closed WFLY-13064.
--------------------------------------
Resolution: Rejected
> EJB client-side interceptor failure when using HTTPRemoting Protocol
> --------------------------------------------------------------------
>
> Key: WFLY-13064
> URL: https://issues.redhat.com/browse/WFLY-13064
> Project: WildFly
> Issue Type: Bug
> Components: EJB, Test Suite
> Affects Versions: 19.0.0.Beta1
> Reporter: Francesco Marchioni
> Assignee: Cheng Fang
> Priority: Major
> Attachments: surefire-reports-RemoteProtocolChangeClientInterceptorTestCase.zip
>
>
> The following [test|https://github.com/wildfly/wildfly/blob/master/testsuite/integration...] fails in counting the EJB Client Interceptor count, when the HTTP Remoting Protocol is used:
> {code:java}
> @Test
> @InSequence(2)
> @OperateOnDeployment("client")
> public void testHttpRemotingProtocol() throws Exception {
> final Hashtable<String, String> props = new Hashtable<>();
> props.put(Context.URL_PKG_PREFIXES, "org.jboss.ejb.client.naming");
> props.put(Context.INITIAL_CONTEXT_FACTORY, "org.jboss.naming.remote.client.InitialContextFactory");
> props.put(Context.PROVIDER_URL, "http-remoting://" + TestSuiteEnvironment.getServerAddress() + ":"
> + (TestSuiteEnvironment.getHttpPort() + Integer.parseInt(getSystemProperty("jboss.socket.binding.port-offset", "100"))));
> StatelessRemote bean = getRemote(new InitialContext(props));
> Assert.assertNotNull(bean);
> // StatelessBean.methodCount field should equal 2 after second invoking (methodCount is a static field and is shared within a single JVM)
> Assert.assertEquals(ProtocolSampleClientInterceptor.COUNT + 2, bean.method());
> }
> {code}
> Stack Trace:
> {code:java}
> 14:46:01 [ERROR] testHttpRemotingProtocol(org.jboss.as.test.multinode.clientinterceptor.protocol.RemoteProtocolChangeClientInterceptorTestCase) Time elapsed: 0.77 s <<< FAILURE!
> 14:46:01 java.lang.AssertionError: expected:<12> but was:<11>
> 14:46:01 at org.junit.Assert.fail(Assert.java:88)
> 14:46:01 at org.junit.Assert.failNotEquals(Assert.java:834)
> 14:46:01 at org.junit.Assert.assertEquals(Assert.java:645)
> 14:46:01 at org.junit.Assert.assertEquals(Assert.java:631)
> 14:46:01 at org.jboss.as.test.multinode.clientinterceptor.protocol.RemoteProtocolChangeClientInterceptorTestCase.testHttpRemotingProtocol(RemoteProtocolChangeClientInterceptorTestCase.java:130)
> {code}
>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 4 months
[JBoss JIRA] (DROOLS-4952) drools-7.31 expert missing/ dropped ProjectClassLoader class?
by Mario Fusco (Jira)
[ https://issues.redhat.com/browse/DROOLS-4952?page=com.atlassian.jira.plug... ]
Mario Fusco updated DROOLS-4952:
--------------------------------
Sprint: (was: 2020 Week 04-06 (from Jan 20))
> drools-7.31 expert missing/ dropped ProjectClassLoader class?
> -------------------------------------------------------------
>
> Key: DROOLS-4952
> URL: https://issues.redhat.com/browse/DROOLS-4952
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.31.0.Final
> Reporter: John Harrison
> Assignee: Mario Fusco
> Priority: Major
>
> I'm compiling/ running rules using expert (drools-7.31) and java 13.0.1, and getting errors like the following:
> {code:java}
> java.lang.NoClassDefFoundError: org/drools/reflective/classloader/ProjectClassLoader
> [context - 1447]: at org.drools.core.impl.KnowledgeBaseFactory.newKnowledgeBase(KnowledgeBaseFactory.java:106)
> [context - 1447]: at org.drools.core.impl.KnowledgeBaseFactory.newKnowledgeBase(KnowledgeBaseFactory.java:80)
> [context - 1447]: at org.drools.core.impl.KnowledgeBaseFactory.newKnowledgeBase(KnowledgeBaseFactory.java:64)
> [context - 1447]: at Reason$Descriptor.reason(Reason.java:459)
> [context - 1447]: at Reason.lambda$run$1(Reason.java:82)
> [context - 1447]: at io.javalin.core.security.SecurityUtil.noopAccessManager(SecurityUtil.kt:22)
> [context - 1447]: at io.javalin.http.JavalinServlet$addHandler$protectedHandler$1.handle(JavalinServlet.kt:116)
> [context - 1447]: at io.javalin.http.JavalinServlet$service$2$1.invoke(JavalinServlet.kt:45)
> [context - 1447]: at io.javalin.http.JavalinServlet$service$2$1.invoke(JavalinServlet.kt:24)
> [context - 1447]: at io.javalin.http.JavalinServlet$service$1.invoke(JavalinServlet.kt:123)
> [context - 1447]: at io.javalin.http.JavalinServlet$service$2.invoke(JavalinServlet.kt:40)
> [context - 1447]: at io.javalin.http.JavalinServlet.service(JavalinServlet.kt:75)
> [context - 1447]: at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> [context - 1447]: at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:867)
> [context - 1447]: at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:542)
> [context - 1447]: at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)
> [context - 1447]: at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1588)
> [context - 1447]: at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)
> [context - 1447]: at io.javalin.core.JavalinServer$start$httpHandler$1.doHandle(JavalinServer.kt:53)
> [context - 1447]: at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203)
> [context - 1447]: at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:480)
> [context - 1447]: at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1557)
> [context - 1447]: at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201)
> [context - 1447]: at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1247)
> [context - 1447]: at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144)
> [context - 1447]: at org.eclipse.jetty.server.handler.HandlerList.handle(HandlerList.java:61)
> [context - 1447]: at org.eclipse.jetty.server.handler.StatisticsHandler.handle(StatisticsHandler.java:174)
> [context - 1447]: at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
> [context - 1447]: at org.eclipse.jetty.server.Server.handle(Server.java:502)
> [context - 1447]: at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:364)
> [context - 1447]: at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:260)
> [context - 1447]: at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:305)
> [context - 1447]: at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)
> [context - 1447]: at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:118)
> [context - 1447]: at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:333)
> [context - 1447]: at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:310)
> [context - 1447]: at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:168)
> [context - 1447]: at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:126)
> [context - 1447]: at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:366)
> [context - 1447]: at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:765)
> [context - 1447]: at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:683)
> [context - 1447]: at java.base/java.lang.Thread.run(Thread.java:830)
> [context - 1447]: Caused by: java.lang.ClassNotFoundException: org.drools.reflective.classloader.ProjectClassLoader
> [context - 1447]: at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:602)
> [context - 1447]: at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
> [context - 1447]: at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
> [context - 1447]: ... 42 more
> {code}
> Is this class missing or removed from the distribution? The related release notes don't mention anything, and things work fine in drools-7.30 (class located in drools-core-7.30.0.Final.jar).
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 4 months
[JBoss JIRA] (DROOLS-5000) Support getContext in Drools' executable model
by Mario Fusco (Jira)
[ https://issues.redhat.com/browse/DROOLS-5000?page=com.atlassian.jira.plug... ]
Mario Fusco reassigned DROOLS-5000:
-----------------------------------
Assignee: Luca Molteni (was: Mario Fusco)
> Support getContext in Drools' executable model
> ----------------------------------------------
>
> Key: DROOLS-5000
> URL: https://issues.redhat.com/browse/DROOLS-5000
> Project: Drools
> Issue Type: Bug
> Components: executable model
> Reporter: Luca Molteni
> Assignee: Luca Molteni
> Priority: Major
>
> jBPM uses this utility method in Knowledge Helper
> package org.drools.bpmn2
> import org.kie.api.runtime.process.ProcessContext
> rule "Auto-activate Hello1" ruleflow-group "Hello"
> when
> then
> System.out.println(drools);
> System.out.println(drools.getContext(ProcessContext.class)); System.out.println(drools.getContext(ProcessContext.class).getProcessInstance());
> drools.getContext(ProcessContext.class).getProcessInstance().signalEvent("Hello1", null);
> end
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 4 months
[JBoss JIRA] (DROOLS-4990) NullPointerException with executable model using accumulate max with null Date field
by Luca Molteni (Jira)
[ https://issues.redhat.com/browse/DROOLS-4990?page=com.atlassian.jira.plug... ]
Luca Molteni reassigned DROOLS-4990:
------------------------------------
Assignee: Luca Molteni (was: Mario Fusco)
> NullPointerException with executable model using accumulate max with null Date field
> ------------------------------------------------------------------------------------
>
> Key: DROOLS-4990
> URL: https://issues.redhat.com/browse/DROOLS-4990
> Project: Drools
> Issue Type: Bug
> Components: core engine, executable model
> Affects Versions: 7.32.0.Final
> Reporter: Martin Weiler
> Assignee: Luca Molteni
> Priority: Major
> Labels: support
>
> Executing a rule containing accumulate max, eg:
> {code}
> rule AccumulateMaxDate
> when
> $max1 : Number() from accumulate(
> StockTick(isSetDueDate == true
> ,$time : dueDate);
> max($time.getTime().getTime()))
> then
> end
> {code}
> fails with a NPE at runtime if the StockDate.dueDate field is null:
> {noformat}
> Caused by: java.lang.NullPointerException
> at defaultpkg.RulesA0DFC3D10EA29F3818B87E11918D8020RuleMethods0.lambda$rule_AccumulateMaxDate$c9e019d8$1(RulesA0DFC3D10EA29F3818B87E11918D8020RuleMethods0.java:34)
> at org.drools.model.functions.Function1$Impl.apply(Function1.java:35)
> at org.drools.model.view.BindViewItem1.eval(BindViewItem1.java:85)
> at org.drools.modelcompiler.constraints.BindingEvaluator.evaluate(BindingEvaluator.java:39)
> at org.drools.modelcompiler.constraints.BindingEvaluator.evaluate(BindingEvaluator.java:35)
> at org.drools.modelcompiler.constraints.LambdaAccumulator$BindingAcc.getAccumulatedObject(LambdaAccumulator.java:154)
> at org.drools.modelcompiler.constraints.LambdaAccumulator.accumulate(LambdaAccumulator.java:88)
> at org.drools.core.rule.SingleAccumulate.accumulate(SingleAccumulate.java:97)
> ... 53 more
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 4 months
[JBoss JIRA] (WFLY-13050) metrics should be optional in observability layer
by Jean Francois Denise (Jira)
[ https://issues.redhat.com/browse/WFLY-13050?page=com.atlassian.jira.plugi... ]
Jean Francois Denise updated WFLY-13050:
----------------------------------------
Description:
With the introduction of microprofile, one could provision both cloud-server,microprofile and exclude any microprofile-* layer.
config and metrics being not optional in observability, they can't be excluded from cloud-server although they can with other server (jaxrs, datasources).
config is required by health, so can't be made optional.
So to offer enough flexibility (eg: exclude metrics but provision health) and an aligned experience across the server layers, metrics should be optional in observability.
was:
With the introduction of microprofile, one could provision both cloud-server,microprofile and exclude any microprofile-* layer.
config and metrics being not optional in observability, they can't be excluded from cloud-server although they can with other server (jaxrs, datasources). This could be solved by excluding observability along with metric/config but in this case health would be excluded too.
So to offer enough flexibility (eg: exclude config but provision health) and an aligned experience across the server layers, config and metrics should be optional in observability.
> metrics should be optional in observability layer
> -------------------------------------------------
>
> Key: WFLY-13050
> URL: https://issues.redhat.com/browse/WFLY-13050
> Project: WildFly
> Issue Type: Enhancement
> Components: Build System
> Reporter: Jean Francois Denise
> Assignee: Jean Francois Denise
> Priority: Major
>
> With the introduction of microprofile, one could provision both cloud-server,microprofile and exclude any microprofile-* layer.
> config and metrics being not optional in observability, they can't be excluded from cloud-server although they can with other server (jaxrs, datasources).
> config is required by health, so can't be made optional.
> So to offer enough flexibility (eg: exclude metrics but provision health) and an aligned experience across the server layers, metrics should be optional in observability.
>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 4 months
[JBoss JIRA] (WFLY-13050) metrics should be optional in observability layer
by Jean Francois Denise (Jira)
[ https://issues.redhat.com/browse/WFLY-13050?page=com.atlassian.jira.plugi... ]
Jean Francois Denise updated WFLY-13050:
----------------------------------------
Summary: metrics should be optional in observability layer (was: config and metrics should be optional in observability layer)
> metrics should be optional in observability layer
> -------------------------------------------------
>
> Key: WFLY-13050
> URL: https://issues.redhat.com/browse/WFLY-13050
> Project: WildFly
> Issue Type: Enhancement
> Components: Build System
> Reporter: Jean Francois Denise
> Assignee: Jean Francois Denise
> Priority: Major
>
> With the introduction of microprofile, one could provision both cloud-server,microprofile and exclude any microprofile-* layer.
> config and metrics being not optional in observability, they can't be excluded from cloud-server although they can with other server (jaxrs, datasources). This could be solved by excluding observability along with metric/config but in this case health would be excluded too.
> So to offer enough flexibility (eg: exclude config but provision health) and an aligned experience across the server layers, config and metrics should be optional in observability.
>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 4 months
[JBoss JIRA] (DROOLS-5004) Select first cell of Test Scenario
by Yeser Amer (Jira)
[ https://issues.redhat.com/browse/DROOLS-5004?page=com.atlassian.jira.plug... ]
Yeser Amer updated DROOLS-5004:
-------------------------------
Sprint: 2020 Week 04-06 (from Jan 20)
> Select first cell of Test Scenario
> ----------------------------------
>
> Key: DROOLS-5004
> URL: https://issues.redhat.com/browse/DROOLS-5004
> Project: Drools
> Issue Type: Bug
> Components: Scenario Simulation and Testing
> Affects Versions: 7.33.0.Final
> Reporter: Jozef Marko
> Assignee: Yeser Amer
> Priority: Blocker
> Labels: drools-tools
>
> Once a Test Scenario file is opened, user is not able to use keyboard to navigate trough the grid. We should fix this by selecting the:
> - First description cell in case of the Model tab
> - First data cell in case of Background tab
> The behavior described above will align behavior of Test Scenario and DMN editors.
> h3. Acceptance criteria
> - User can use keyboard right afterwards opening Test Scenario without need to click to canvas
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 4 months
[JBoss JIRA] (DROOLS-5004) Select first cell of Test Scenario
by Yeser Amer (Jira)
[ https://issues.redhat.com/browse/DROOLS-5004?page=com.atlassian.jira.plug... ]
Yeser Amer updated DROOLS-5004:
-------------------------------
Story Points: 3
> Select first cell of Test Scenario
> ----------------------------------
>
> Key: DROOLS-5004
> URL: https://issues.redhat.com/browse/DROOLS-5004
> Project: Drools
> Issue Type: Bug
> Components: Scenario Simulation and Testing
> Affects Versions: 7.33.0.Final
> Reporter: Jozef Marko
> Assignee: Yeser Amer
> Priority: Blocker
> Labels: drools-tools
>
> Once a Test Scenario file is opened, user is not able to use keyboard to navigate trough the grid. We should fix this by selecting the:
> - First description cell in case of the Model tab
> - First data cell in case of Background tab
> The behavior described above will align behavior of Test Scenario and DMN editors.
> h3. Acceptance criteria
> - User can use keyboard right afterwards opening Test Scenario without need to click to canvas
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 4 months