[JBoss JIRA] (DROOLS-5486) CEP doesn't evaluate correctly when a bind variable is used as the first temporal parameter in executable model
by Toshiya Kobayashi (Jira)
Toshiya Kobayashi created DROOLS-5486:
-----------------------------------------
Summary: CEP doesn't evaluate correctly when a bind variable is used as the first temporal parameter in executable model
Key: DROOLS-5486
URL: https://issues.redhat.com/browse/DROOLS-5486
Project: Drools
Issue Type: Bug
Components: executable model
Affects Versions: 7.39.0.Final
Reporter: Toshiya Kobayashi
Assignee: Toshiya Kobayashi
With the below test, standard-drl fires but executable-model doesn't.
{code:java}
@Test
public void testAfterOnLongFields2() throws Exception {
String str =
"import " + StockTick.class.getCanonicalName() + ";\n" +
"declare StockTick @timestamp(timeFieldAsLong) end\n" +
"rule R when\n" +
" $a : StockTick( company == \"DROO\" )\n" +
" $b : StockTick( company == \"ACME\", $a.timeFieldAsLong after[5,8] timeFieldAsLong )\n" +
"then\n" +
" System.out.println(\"fired\");\n" +
"end\n";
KieSession ksession = getKieSession(getCepKieModuleModel(), str);
SessionPseudoClock clock = ksession.getSessionClock();
ReteDumper.dumpRete(ksession);
ksession.insert( new StockTick( "ACME" ).setTimeField( 0 ) );
ksession.insert( new StockTick( "DROO" ).setTimeField( 6 ) );
assertEquals( 1, ksession.fireAllRules() );
}
{code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (WFCORE-4962) Add a SecurityMetaData for all deployments
by Jeff Mesnil (Jira)
[ https://issues.redhat.com/browse/WFCORE-4962?page=com.atlassian.jira.plug... ]
Jeff Mesnil updated WFCORE-4962:
--------------------------------
Fix Version/s: 12.0.3.Final
(was: 12.0.2.Final)
> Add a SecurityMetaData for all deployments
> ------------------------------------------
>
> Key: WFCORE-4962
> URL: https://issues.redhat.com/browse/WFCORE-4962
> Project: WildFly Core
> Issue Type: Task
> Components: Security
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Priority: Major
> Fix For: 12.0.3.Final
>
>
> For all deployments we should associate a new class SecurityMetaData with the deployment, initially the purpose of this will be to hold the ServiceName of any Elytron SecurityDomain if one is being used.
> At a later point additional security policy information can be added as we move away from the ApplicationSecurityDomain resources.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (WFCORE-4973) NPE due to timeout in LongOutputTestCase
by Jeff Mesnil (Jira)
[ https://issues.redhat.com/browse/WFCORE-4973?page=com.atlassian.jira.plug... ]
Jeff Mesnil updated WFCORE-4973:
--------------------------------
Fix Version/s: 12.0.3.Final
(was: 12.0.2.Final)
> NPE due to timeout in LongOutputTestCase
> ----------------------------------------
>
> Key: WFCORE-4973
> URL: https://issues.redhat.com/browse/WFCORE-4973
> Project: WildFly Core
> Issue Type: Bug
> Components: Test Suite
> Reporter: Richard Opalka
> Assignee: Richard Opalka
> Priority: Major
> Fix For: 12.0.3.Final
>
>
> [ERROR] Tests run: 5, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 50.287 s <<< FAILURE! - in org.jboss.as.test.integration.management.cli.LongOutputTestCase
> [ERROR] testDisabledOutputPagingViaXml(org.jboss.as.test.integration.management.cli.LongOutputTestCase) Time elapsed: 11.961 s <<< FAILURE!
> java.lang.AssertionError
> at org.junit.Assert.fail(Assert.java:86)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at org.junit.Assert.assertNotNull(Assert.java:712)
> at org.junit.Assert.assertNotNull(Assert.java:722)
> at org.jboss.as.test.integration.management.cli.LongOutputTestCase.testDisabledOutputPaging(LongOutputTestCase.java:394)
> at org.jboss.as.test.integration.management.cli.LongOutputTestCase.testDisabledOutputPagingViaXml(LongOutputTestCase.java:380)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.wildfly.core.testrunner.WildflyTestRunner.run(WildflyTestRunner.java:157)
> at org.junit.runners.Suite.runChild(Suite.java:128)
> at org.junit.runners.Suite.runChild(Suite.java:27)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.apache.maven.surefire.junitcore.JUnitCore.run(JUnitCore.java:55)
> at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.createRequestAndRun(JUnitCoreWrapper.java:137)
> at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.executeEager(JUnitCoreWrapper.java:107)
> at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:83)
> at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:75)
> at org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:158)
> at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:383)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:344)
> at org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:125)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:417)
> [ERROR] testDisabledOutputPagingViaArgument(org.jboss.as.test.integration.management.cli.LongOutputTestCase) Time elapsed: 11.849 s <<< FAILURE!
> java.lang.AssertionError
> at org.junit.Assert.fail(Assert.java:86)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at org.junit.Assert.assertNotNull(Assert.java:712)
> at org.junit.Assert.assertNotNull(Assert.java:722)
> at org.jboss.as.test.integration.management.cli.LongOutputTestCase.testDisabledOutputPaging(LongOutputTestCase.java:394)
> at org.jboss.as.test.integration.management.cli.LongOutputTestCase.testDisabledOutputPagingViaArgument(LongOutputTestCase.java:368)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.wildfly.core.testrunner.WildflyTestRunner.run(WildflyTestRunner.java:157)
> at org.junit.runners.Suite.runChild(Suite.java:128)
> at org.junit.runners.Suite.runChild(Suite.java:27)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.apache.maven.surefire.junitcore.JUnitCore.run(JUnitCore.java:55)
> at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.createRequestAndRun(JUnitCoreWrapper.java:137)
> at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.executeEager(JUnitCoreWrapper.java:107)
> at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:83)
> at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:75)
> at org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:158)
> at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:383)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:344)
> at org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:125)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:417)
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (WFCORE-5028) CallbackHandler from CLI overriding discovered wildfly-config for authentication.
by Jeff Mesnil (Jira)
[ https://issues.redhat.com/browse/WFCORE-5028?page=com.atlassian.jira.plug... ]
Jeff Mesnil updated WFCORE-5028:
--------------------------------
Fix Version/s: 12.0.3.Final
(was: 12.0.2.Final)
> CallbackHandler from CLI overriding discovered wildfly-config for authentication.
> ---------------------------------------------------------------------------------
>
> Key: WFCORE-5028
> URL: https://issues.redhat.com/browse/WFCORE-5028
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI, Security
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Priority: Critical
> Fix For: 12.0.3.Final, 13.0.0.Beta2
>
>
> WFCORE-4976 made an update to ProtocolConnectionUtils so that a supplied CallbackHandler takes priority - this works where a client is using ModelControllerClient.create() and passing in a CallbackHandler as we should take that as an indication that the caller wants control of authentication.
> However by fixing in ProtocolConnectionUtils it has also picked up the case where the CLI passes in the CallbackHandler - that case however should only use the CBH if the information can not be obtained from the AuthenticationConfiguration. This call does not come via ModelControllerClient but both paths meet at ProtocolConnectionUtils.
> Either the adjustment of the AuthenticationContext to give the CallbackHandler should happen in ModelControllerClient - or an additional boolean should be passed into ProtocolConnectionUtils to indicate if the CallbackHandler should be given priority. The latter may be a less invasive evolution of the fix prepared so far.
>
>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (WFLY-13641) WFLYWELD0055: Could not index class [Someclass] from an external bean archive: vfs:/somepath/myear.ear/myejb-0.0.1.jar/META-INF/beans.xml
by Jens Viebig (Jira)
[ https://issues.redhat.com/browse/WFLY-13641?page=com.atlassian.jira.plugi... ]
Jens Viebig commented on WFLY-13641:
------------------------------------
Your assumptions are mostly correct. But the jar inside the ear is an ejb-jar deployed in the main directory, not in the lib subdirectory.
So if its true that this is not supported, should it even try to create an index ? If you have lots of classes in the jar, you get lots of warnings.
I also like to learn what is the impact of these warnings ? What happens if there is no index created ?
With bean-discovery-mode "all" the beans are detected and can be injected in the WAR, but actually this caused problems with our EJBs and the entity manager and switching to "annotated" helped, see for a detailed description:
[https://groups.google.com/forum/#!topic/wildfly/tKBea3ylOJk]
It could be that this bug is somehow working in our favor in this case, so I would love to learn what should be the expected behaviour
> WFLYWELD0055: Could not index class [Someclass] from an external bean archive: vfs:/somepath/myear.ear/myejb-0.0.1.jar/META-INF/beans.xml
> -----------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-13641
> URL: https://issues.redhat.com/browse/WFLY-13641
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 20.0.0.Final
> Reporter: Jens Viebig
> Assignee: Matěj Novotný
> Priority: Major
>
> When referencing a jar with CDI scan mode "annotaded" inside an ear from an external war via jboss-deployment-structure.xml a warning will be printed for every class:
> WFLYWELD0055: Could not index class [Someclass] from an external bean archive: vfs:/somepath/myear.ear/myejb-0.0.1.jar/META-INF/beans.xml
> Seems VFS cannot get hold of the classes.
> The warning is logged in ExternalBeanArchiveProcessor which catches an EOFException from the inputstream loading the class. (Line 284). Seems the input stream is not able to load a single byte from the class
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years