[JBoss JIRA] (DROOLS-5349) Guided Decision Table Attribute Column default value not working
by Jozef Marko (Jira)
[ https://issues.redhat.com/browse/DROOLS-5349?page=com.atlassian.jira.plug... ]
Jozef Marko moved RHPAM-2953 to DROOLS-5349:
--------------------------------------------
Project: Drools (was: Red Hat Process Automation Manager)
Key: DROOLS-5349 (was: RHPAM-2953)
Workflow: GIT Pull Request workflow (was: CDW with docs v1)
Docs QE Status: NEW
Component/s: Guided Decision Table Editor
(was: Business Central)
QE Status: NEW
> Guided Decision Table Attribute Column default value not working
> ------------------------------------------------------------------
>
> Key: DROOLS-5349
> URL: https://issues.redhat.com/browse/DROOLS-5349
> Project: Drools
> Issue Type: Bug
> Components: Guided Decision Table Editor
> Affects Versions: 7.38.0.Final
> Reporter: Jozef Marko
> Assignee: Guilherme Gomes
> Priority: Major
> Labels: guided_decision_table
> Attachments: GuidedDecisionTable-Attribute-boolean-switch-notworking.gif, Screenshot from 2020-05-15 16-24-29.png
>
>
> When adding an Attribute Column (eg: no-loop) and changing it's default value (from true to false or vice-versa) this change is not reflected on the table model nor in the source.
> Please see the gif recording attached.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (DROOLS-5349) Guided Decision Table Attribute Column default value not working
by Jozef Marko (Jira)
[ https://issues.redhat.com/browse/DROOLS-5349?page=com.atlassian.jira.plug... ]
Jozef Marko reassigned DROOLS-5349:
-----------------------------------
Assignee: Jozef Marko (was: Guilherme Gomes)
> Guided Decision Table Attribute Column default value not working
> ------------------------------------------------------------------
>
> Key: DROOLS-5349
> URL: https://issues.redhat.com/browse/DROOLS-5349
> Project: Drools
> Issue Type: Bug
> Components: Guided Decision Table Editor
> Affects Versions: 7.38.0.Final
> Reporter: Jozef Marko
> Assignee: Jozef Marko
> Priority: Major
> Labels: guided_decision_table
> Attachments: GuidedDecisionTable-Attribute-boolean-switch-notworking.gif, Screenshot from 2020-05-15 16-24-29.png
>
>
> When adding an Attribute Column (eg: no-loop) and changing it's default value (from true to false or vice-versa) this change is not reflected on the table model nor in the source.
> Please see the gif recording attached.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (DROOLS-5349) Guided Decision Table Attribute Column default value not working
by Jozef Marko (Jira)
[ https://issues.redhat.com/browse/DROOLS-5349?page=com.atlassian.jira.plug... ]
Jozef Marko updated DROOLS-5349:
--------------------------------
Affects Version/s: 7.38.0.Final
> Guided Decision Table Attribute Column default value not working
> ------------------------------------------------------------------
>
> Key: DROOLS-5349
> URL: https://issues.redhat.com/browse/DROOLS-5349
> Project: Drools
> Issue Type: Bug
> Components: Guided Decision Table Editor
> Affects Versions: 7.38.0.Final
> Reporter: Jozef Marko
> Assignee: Jozef Marko
> Priority: Major
> Labels: guided_decision_table
> Attachments: GuidedDecisionTable-Attribute-boolean-switch-notworking.gif, Screenshot from 2020-05-15 16-24-29.png
>
>
> When adding an Attribute Column (eg: no-loop) and changing it's default value (from true to false or vice-versa) this change is not reflected on the table model nor in the source.
> Please see the gif recording attached.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (DROOLS-5345) Class loading issue in Eclipse Equinox OSGi container
by Mario Fusco (Jira)
[ https://issues.redhat.com/browse/DROOLS-5345?page=com.atlassian.jira.plug... ]
Mario Fusco updated DROOLS-5345:
--------------------------------
Sprint: 2020 Week 19-21 (from May 4)
> Class loading issue in Eclipse Equinox OSGi container
> -----------------------------------------------------
>
> Key: DROOLS-5345
> URL: https://issues.redhat.com/browse/DROOLS-5345
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.37.0.Final
> Reporter: Richard Schurig
> Assignee: Mario Fusco
> Priority: Major
>
> When using Drools inside an *Equinox* OSGi container (Oxygen, org.eclipse.osgi-3.12.0.v20170512-1932.jar) the logic inside {{org.drools.relective.classloader.ProjectClassLoader#isOsgiClassLoader}} does not work properly, i.e. the OSGi runtime is not detected. This leads to "The Eclipse JDT Core jar is not in the classpath" because the shaded and packed compiler classes cannot be found.
> Cause of the problem seems to be the fact that the {{EquinoxClassLoader}} does not implement {{BundleReference}} directly *but so does its superclass*. I tried and patched {{ProjectClassLoader}} with the following snippet and this seems to work:
> {code:java}
> private static boolean isOsgiClassLoader(final ClassLoader cl) {
> Class<?> clc = cl.getClass();
> while (clc != null && !clc.equals(ClassLoader.class)) {
> if (Stream.of(clc.getInterfaces()).map(Class::getSimpleName).anyMatch(name -> name.equals("BundleReference"))) {
> return true;
> }
> clc = clc.getSuperclass();
> }
> return false;
> }
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (WFWIP-319) Can /tmp directory of builder image be cleared?
by Jean Francois Denise (Jira)
[ https://issues.redhat.com/browse/WFWIP-319?page=com.atlassian.jira.plugin... ]
Jean Francois Denise commented on WFWIP-319:
--------------------------------------------
[~mchoma], yes the directory can be removed but its content (licences) must be moved to the /opt/jboss/container/wildfly/s2i/galleon/ directory. This should have been done first place.
> Can /tmp directory of builder image be cleared?
> -----------------------------------------------
>
> Key: WFWIP-319
> URL: https://issues.redhat.com/browse/WFWIP-319
> Project: WildFly WIP
> Issue Type: Bug
> Components: OpenShift
> Reporter: Martin Choma
> Assignee: Jean Francois Denise
> Priority: Optional
>
> This is not XP specific, but I have noticed it during XP work. I am comparing builder images of 7.3.1 and XP and diff is complaining about {{tmp/jboss-eap-7.3.1.GA-image-builder-maven-repository/licenses/}}
> I want to ask if this is necessary to have in builder image. As it is located in /tmp directory I suppose this is just working dir and can be safely deleted?
> {code}
> [jboss@f4e78430d511 licenses]$ pwd
> /tmp/jboss-eap-xp-1.0.0.GA-image-builder-maven-repository/licenses
> [jboss@f4e78430d511 licenses]$ ls
> 'apache license 1.1.txt' 'eclipse public license 1.0.txt' 'gnu lesser general public license v3.0 or later.html' 'mozilla public license 1.1.txt'
> 'apache license 2.0.txt' 'eclipse public license 2.0.txt' 'gnu lesser general public license, version 3.txt' 'mozilla public license 2.0.html'
> 'bsd 3-clause new or revised license.html' 'eclipse public license, version 1.0.txt' 'gnu library general public license v2 only.txt' 'plexus classworlds license.html'
> 'bsd 3-clause no nuclear license.html' 'fsf all permissive license.html' 'gnu library general public license, version 2.txt' 'public domain.txt'
> 'common development and distribution license 1.0.txt' 'gnu general public license v2.0 only, with classpath exception.txt' 'icu license - icu 1.8.1 to icu 57.1.txt' 'the antlr 2.7.7 license.txt'
> 'common development and distribution license 1.1.txt' 'gnu general public license, version 2 with the classpath exception.txt' 'indiana university extreme lab software license 1.1.1.html' 'the asm bsd license.txt'
> 'common development and distribution license.txt' 'gnu general public license, version 2.txt' licenses.css 'the bsd license.txt'
> 'common public license 1.0.txt' 'gnu lesser general public license v2.1 only.txt' licenses.html 'the dom4j license.txt'
> 'creative commons attribution 2.5.html' 'gnu lesser general public license v2.1 or later.html' licenses.xml 'the jaxen license.txt'
> 'creative commons zero v1.0 universal.html' 'gnu lesser general public license v2.1 or later.txt' licenses.xsl 'the jsoup mit license.html'
> 'eclipse distribution license, version 1.0.txt' 'gnu lesser general public license v3.0 only.txt' 'mit license.txt'
> {code}
> [1] https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/view/OpenShift/job...
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (WFWIP-319) Can /tmp directory of builder image be cleared?
by Jean Francois Denise (Jira)
[ https://issues.redhat.com/browse/WFWIP-319?page=com.atlassian.jira.plugin... ]
Jean Francois Denise reassigned WFWIP-319:
------------------------------------------
Assignee: Jean Francois Denise (was: Jeff Mesnil)
> Can /tmp directory of builder image be cleared?
> -----------------------------------------------
>
> Key: WFWIP-319
> URL: https://issues.redhat.com/browse/WFWIP-319
> Project: WildFly WIP
> Issue Type: Bug
> Components: OpenShift
> Reporter: Martin Choma
> Assignee: Jean Francois Denise
> Priority: Optional
>
> This is not XP specific, but I have noticed it during XP work. I am comparing builder images of 7.3.1 and XP and diff is complaining about {{tmp/jboss-eap-7.3.1.GA-image-builder-maven-repository/licenses/}}
> I want to ask if this is necessary to have in builder image. As it is located in /tmp directory I suppose this is just working dir and can be safely deleted?
> {code}
> [jboss@f4e78430d511 licenses]$ pwd
> /tmp/jboss-eap-xp-1.0.0.GA-image-builder-maven-repository/licenses
> [jboss@f4e78430d511 licenses]$ ls
> 'apache license 1.1.txt' 'eclipse public license 1.0.txt' 'gnu lesser general public license v3.0 or later.html' 'mozilla public license 1.1.txt'
> 'apache license 2.0.txt' 'eclipse public license 2.0.txt' 'gnu lesser general public license, version 3.txt' 'mozilla public license 2.0.html'
> 'bsd 3-clause new or revised license.html' 'eclipse public license, version 1.0.txt' 'gnu library general public license v2 only.txt' 'plexus classworlds license.html'
> 'bsd 3-clause no nuclear license.html' 'fsf all permissive license.html' 'gnu library general public license, version 2.txt' 'public domain.txt'
> 'common development and distribution license 1.0.txt' 'gnu general public license v2.0 only, with classpath exception.txt' 'icu license - icu 1.8.1 to icu 57.1.txt' 'the antlr 2.7.7 license.txt'
> 'common development and distribution license 1.1.txt' 'gnu general public license, version 2 with the classpath exception.txt' 'indiana university extreme lab software license 1.1.1.html' 'the asm bsd license.txt'
> 'common development and distribution license.txt' 'gnu general public license, version 2.txt' licenses.css 'the bsd license.txt'
> 'common public license 1.0.txt' 'gnu lesser general public license v2.1 only.txt' licenses.html 'the dom4j license.txt'
> 'creative commons attribution 2.5.html' 'gnu lesser general public license v2.1 or later.html' licenses.xml 'the jaxen license.txt'
> 'creative commons zero v1.0 universal.html' 'gnu lesser general public license v2.1 or later.txt' licenses.xsl 'the jsoup mit license.html'
> 'eclipse distribution license, version 1.0.txt' 'gnu lesser general public license v3.0 only.txt' 'mit license.txt'
> {code}
> [1] https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/view/OpenShift/job...
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (WFCORE-4973) NPE due to timeout in LongOutputTestCase
by Richard Opalka (Jira)
Richard Opalka created WFCORE-4973:
--------------------------------------
Summary: 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
Fix For: 12.0.0.Beta4
[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, 2 months
[JBoss JIRA] (WFLY-13432) Provide capability for Undertow HTTP Upgrade registry
by Richard Achmatowicz (Jira)
[ https://issues.redhat.com/browse/WFLY-13432?page=com.atlassian.jira.plugi... ]
Richard Achmatowicz commented on WFLY-13432:
--------------------------------------------
I have now also modified the messaging-activemq subsystem to make use of the newly defined capability. It remains to update a few subsystems in Wildfly Core, Remoting being one of them.
> Provide capability for Undertow HTTP Upgrade registry
> -----------------------------------------------------
>
> Key: WFLY-13432
> URL: https://issues.redhat.com/browse/WFLY-13432
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 20.0.0.Beta1
> Reporter: Richard Achmatowicz
> Assignee: Richard Achmatowicz
> Priority: Major
>
> The HTTP Upgrade feature of Undertow depends on subsystems such as Remoting and Messaging having access to a registry of upgrade protocols (ChannelUpgradeHandler) provided by Undertow. This needs to be updated to use capabilities.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (WFLY-11034) Integration with grpc (high performance, open-source universal RPC framework)
by Rogerio Ferreira (Jira)
[ https://issues.redhat.com/browse/WFLY-11034?page=com.atlassian.jira.plugi... ]
Rogerio Ferreira commented on WFLY-11034:
-----------------------------------------
There is already a project on OpenLiberty to support gRPC. Can we rely on this?
> Integration with grpc (high performance, open-source universal RPC framework)
> -----------------------------------------------------------------------------
>
> Key: WFLY-11034
> URL: https://issues.redhat.com/browse/WFLY-11034
> Project: WildFly
> Issue Type: Feature Request
> Components: Remoting
> Affects Versions: 14.0.0.Final
> Reporter: Brad Maxwell
> Priority: Major
>
> https://grpc.io/
> grpc should be seamlessly integrated into Wildfly as grpc support for EJB's and other EE components would make it very easy for microservices written in other languages to interact with Wildfly.
> grpc might be a good replacement candidate for corba (binary marshalling, efficiency, good community and support, modern, http/2, streaming, strong contract).
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months