December 2020 - jboss-jira - Jboss List Archives

[Red Hat JIRA] (DROOLS-5729) Reorganize drools unit tests

by Kris Verlaenen (Jira)

[ https://issues.redhat.com/browse/DROOLS-5729?page=com.atlassian.jira.plug... ] Kris Verlaenen updated DROOLS-5729: ----------------------------------- Sprint: 2020 Week 43-45 (from Okt 19), 2020 Week 46-48 (from Nov 9), 2020 Week 49-51 (from Nov 30) (was: 2020 Week 43-45 (from Okt 19), 2020 Week 46-48 (from Nov 9)) > Reorganize drools unit tests > ---------------------------- > > Key: DROOLS-5729 > URL: https://issues.redhat.com/browse/DROOLS-5729 > Project: Drools > Issue Type: Story > Components: core engine > Affects Versions: 7.44.0.Final > Reporter: Toshiya Kobayashi > Assignee: Toshiya Kobayashi > Priority: Major > > Motivation: The motivation is to increase test coverage. For example, unit tests which exist under drools-mvel are not tested against executable-model. "Which module is suitable for the unit test?" depends on each test so we may occasionally need to discuss. But basically drools-test-coverage is a good place for DRL based tests because drools-test-coverage may have all dependencies so is flexible to test with any configurations (e.g. alpha compiler network). > Goals: Increase test coverage. More stable product. > Impact: During this work, we may find new bugs (because of increased tests). Will need to fix them one-by-one as separated JIRAs. -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 5 months

1
0
0 / 0

[Red Hat JIRA] (SWSQE-1254) Create new fedora VM jenkins worker for kiali builds

by Filip Brychta (Jira)

Filip Brychta created SWSQE-1254: ------------------------------------ Summary: Create new fedora VM jenkins worker for kiali builds Key: SWSQE-1254 URL: https://issues.redhat.com/browse/SWSQE-1254 Project: Kiali QE Issue Type: QE Task Reporter: Filip Brychta Assignee: Filip Brychta Our current jenkins worker for kiali builds is running as a pod in OCP 3.11 which uses old docker version. We need newer docker version because of [https://github.com/kiali/kiali/pull/3473] -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 5 months

1
0
0 / 0

[Red Hat JIRA] (WFLY-12375) Server returns 2 JSESSIONID cookies

by Parul Sharma (Jira)

[ https://issues.redhat.com/browse/WFLY-12375?page=com.atlassian.jira.plugi... ] Parul Sharma commented on WFLY-12375: ------------------------------------- [~nicolas.n] This issue is not reproducible. Please confirm if still this issue exists. Thanks > Server returns 2 JSESSIONID cookies > ------------------------------------ > > Key: WFLY-12375 > URL: https://issues.redhat.com/browse/WFLY-12375 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 17.0.1.Final > Reporter: Nicolas NESMON > Assignee: Parul Sharma > Priority: Major > Labels: COOKIES, JSESSIONID > > Please find below the source code of my simplified JAX-RS application: > {code:java} > @ApplicationPath("myApp") > public class Application extends javax.ws.rs.core.Application { > public Application() { > } > @Override > public Set<Object> getSingletons() { > return Collections.singleton(new HelloWorldResource()); > } > } > {code} > {code:java} > @Path("/") > @Produces(MediaType.TEXT_PLAIN) > public class HelloWorldResource { > @Context > private HttpServletRequest httpServletRequest; > @GET > public Response helloWorld() { > HttpSession session = this.httpServletRequest.getSession(false); > return Response.ok(session == null ? "Hello world" : "Bye bye world") > .cookie(new NewCookie("JSESSIONID", "id", "demo", null, null, -1, false)).build(); > } > } > {code} > When deploying this application in WF 17.0.1.Final and running following request: > {noformat} > GET http://localhost:8080/demo/myApp/ > Host: localhost:8080 > User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:68.0) Gecko/20100101 Firefox/68.0 > Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 > Accept-Language: fr,fr-FR;q=0.8,en-US;q=0.5,en;q=0.3 > Accept-Encoding: gzip, deflate > Connection: keep-alive > Upgrade-Insecure-Requests: 1 > Pragma: no-cache > Cache-Control: no-cache > Cookie: JSESSIONID=Hello => without this cookie, I only get the cookie I created. > {noformat} > I get following response > {noformat} > HTTP/1.1 200 OK > Connection: keep-alive > Set-Cookie: JSESSIONID=id;Version=1;Path=/demo > Set-Cookie: JSESSIONID=hello.vpi070236; path=/demo > Content-Type: text/plain;charset=UTF-8 > Content-Length: 11 > Date: Tue, 13 Aug 2019 23:28:15 GMT > {noformat} > As you may notice, there are 2 JSESSIONID cookies in the response: > * The one I was expecting with "id" value since I created it. > * Another one created by the server even if I did not ask for it since in my code I don't create no HTTP session. And by the way this JSESSIONID cookie is created but there no server side session created...weird > Any idea why this second JSESSIONID cookies is created by the server ? > Since my real application don't use HTTP session at all the workaround I found is to set session tracking mode to URL: > {noformat} > <web-app> > <session-config> > <tracking-mode>URL</tracking-mode> > </session-config> > </web-app> > {noformat} > Thanks -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 5 months

1
0
0 / 0

[Red Hat JIRA] (WFLY-14140) (7.3.z) Tests failures in multinode with security manager enabled affect other tests

by Lin Gao (Jira)

[ https://issues.redhat.com/browse/WFLY-14140?page=com.atlassian.jira.plugi... ] Lin Gao reassigned WFLY-14140: ------------------------------ Assignee: Lin Gao (was: Tomasz Adamski) > (7.3.z) Tests failures in multinode with security manager enabled affect other tests > ------------------------------------------------------------------------------------ > > Key: WFLY-14140 > URL: https://issues.redhat.com/browse/WFLY-14140 > Project: WildFly > Issue Type: Bug > Components: Test Suite > Reporter: Lin Gao > Assignee: Lin Gao > Priority: Minor > > In *+testsuite/integration/multinode+*, when security manager is enabled, the xa recovery files failed be deleted because of no permission when tests finished, it affects other tests so that the Periodic Recovery thread will try to recover the failed transactions. > * Failed EjbOverHttpWrongCredentialsTestCase: > {code:java} > 12:45:15,778 WARN [com.arjuna.ats.jta] (pool-20-thread-1) ARJUNA016039: onePhaseCommit on < formatId=131077, gtri > d_length=29, bqual_length=36, tx_uid=0:ffff7f000001:659146d8:5fbc8fc0:e5, node_name=1, branch_uid=0:ffff7f000001:659146d8:5fbc8fc0:eb, subordinatenodename=null, eis_name=unknown eis name > (Subordinate XAResource at http://localhost:8180/wildfly-services) failed with exception -: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.io.FilePermission" "/home/lgao/sources/jboss/wildfly/testsuite/integration/multinode/target/jbossas-multinode-client/standalone/data/ejb-xa-recovery/20005_00000000000000000000ffff7f000001659146d85fbc8fc0000000e531_00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000" "delete")" in code source "(vfs:/content/ejboverhttp-test-client-wrong-credentials.jar <no signer certificates>)" of "ModuleClassLoader for Module "deployment.ejboverhttp-test-client-wrong-credentials.jar" from Service Module Loader") > at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:304) > at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:201) > at java.lang.SecurityManager.checkDelete(SecurityManager.java:1007) > at org.wildfly.security.manager.WildFlySecurityManager.checkDelete(WildFlySecurityManager.java:393) > at sun.nio.fs.UnixPath.checkDelete(UnixPath.java:807) > at sun.nio.fs.UnixFileSystemProvider.implDelete(UnixFileSystemProvider.java:222) > at sun.nio.fs.AbstractFileSystemProvider.delete(AbstractFileSystemProvider.java:103) > at java.nio.file.Files.delete(Files.java:1126) > at org.wildfly.transaction.client.provider.jboss.FileSystemXAResourceRegistry$XAResourceRegistryFile.removeResource(FileSystemXAResourceRegistry.java:298) > at org.wildfly.transaction.client.SubordinateXAResource.commit(SubordinateXAResource.java:188) > at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.topLevelOnePhaseCommit(XAResourceRecord.java:702) > at com.arjuna.ats.arjuna.coordinator.BasicAction.onePhaseCommit(BasicAction.java:2395) > at com.arjuna.ats.arjuna.coordinator.BasicAction.End(BasicAction.java:1497) > at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:96) > at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162) > at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1295) > at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126) > {code} > * Affected EjbOverHttpTestCase: > {code:java} > 12:45:18,745 WARN [com.arjuna.ats.jta] (Periodic Recovery) ARJUNA016027: Local XARecoveryModule.xaRecovery got XA exception ARJUNA016099: Unknown error code:0: javax.transaction.xa.XAException: WFHTTP000005: Invalid response code 404 (full response ClientResponse{responseHeaders={content-length=[74], content-type=[text/html], date=[Tue, 24 Nov 2020 04:45:18 GMT]}, responseCode=404, status='', protocol=HTTP/2.0}) > at org.wildfly.httpclient.transaction.HttpRemoteTransactionPeer.recover(HttpRemoteTransactionPeer.java:107) > at org.wildfly.transaction.client.SubordinateXAResource.recover(SubordinateXAResource.java:237) > at org.wildfly.transaction.client.SubordinateXAResource.recover(SubordinateXAResource.java:233) > at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecoveryFirstPass(XARecoveryModule.java:659) > at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkFirstPass(XARecoveryModule.java:240) > at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkFirstPass(XARecoveryModule.java:182) > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:770) > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:382) > Caused by: java.io.IOException: WFHTTP000005: Invalid response code 404 (full response ClientResponse{responseHeaders={content-length=[74], content-type=[text/html], date=[Tue, 24 Nov 2020 04:45:18 GMT]}, responseCode=404, status='', protocol=HTTP/2.0}) > at org.wildfly.httpclient.common.HttpTargetContext$1$1.lambda$completed$4(HttpTargetContext.java:235) > at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) > at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1990) > at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486) > at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377) > at org.xnio.XnioWorker$WorkerThreadFactory$1$1.run(XnioWorker.java:1280) > at java.lang.Thread.run(Thread.java:748) > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 5 months

1
0
0 / 0

[Red Hat JIRA] (DROOLS-4605) DMN alpha network

by Kris Verlaenen (Jira)

[ https://issues.redhat.com/browse/DROOLS-4605?page=com.atlassian.jira.plug... ] Kris Verlaenen updated DROOLS-4605: ----------------------------------- Sprint: 2020 Week 34-36 (from Aug 17), 2020 Week 46-48 (from Nov 9), 2020 Week 49-51 (from Nov 30) (was: 2020 Week 34-36 (from Aug 17), 2020 Week 46-48 (from Nov 9)) > DMN alpha network > ----------------- > > Key: DROOLS-4605 > URL: https://issues.redhat.com/browse/DROOLS-4605 > Project: Drools > Issue Type: Story > Components: dmn engine > Reporter: Matteo Mortari > Assignee: Luca Molteni > Priority: Major > > *Motivation*: a DMN decision table can be evaluated faster than naive algorithm by translating it into a Rete/Phreak, but the current kie7 approach is suffering from performance bottleneck artificially induced by use of kie7 rule units, which provide more harm than benefit to perfomance (performance is actually worst for most "realistic" cases). > *Goals*: a POC to understand what’s need to be done to support the alpha network compiler (wihout kie7 rule units) in DMN. We currently estimate it will take us 1 to 2 summer sprints and the output will be more epics to implement this feature. > *Impact*: alpha network compiler code refactors for the better use of. > One part of the POC was to hard-code the alpha network for a specific table ([DROOLS-4566]) the remained of the poc is to generalize the approach further to fully assess the impacts thanks to the poc. -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 5 months

1
0
0 / 0

[Red Hat JIRA] (DROOLS-5855) Update Drools MVN Archetype

by Kris Verlaenen (Jira)

[ https://issues.redhat.com/browse/DROOLS-5855?page=com.atlassian.jira.plug... ] Kris Verlaenen updated DROOLS-5855: ----------------------------------- Sprint: 2020 Week 46-48 (from Nov 9), 2020 Week 49-51 (from Nov 30) (was: 2020 Week 46-48 (from Nov 9)) > Update Drools MVN Archetype > --------------------------- > > Key: DROOLS-5855 > URL: https://issues.redhat.com/browse/DROOLS-5855 > Project: Drools > Issue Type: Bug > Components: core engine > Reporter: Luca Molteni > Assignee: Luca Molteni > Priority: Major > > After the MVEL descoping it doesn't work anymore as it doesn't use drools-engine-classic but kieclasspathcontainer uses MVEL -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 5 months

1
0
0 / 0

[Red Hat JIRA] (WFCORE-5202) Update bouncycastle to 1.67

by Boris Unckel (Jira)

Boris Unckel created WFCORE-5202: ------------------------------------ Summary: Update bouncycastle to 1.67 Key: WFCORE-5202 URL: https://issues.redhat.com/browse/WFCORE-5202 Project: WildFly Core Issue Type: Component Upgrade Components: Modules Affects Versions: 14.0.0.Beta2 Reporter: Boris Unckel Assignee: Richard Opalka Update to [Bouncycastle 1.67|https://mvnrepository.com/artifact/org.bouncycastle/bcprov-jdk15on/1.67]. [Releasenotes|https://bouncycastle.org/releasenotes.html] -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 5 months

1
0
0 / 0

[Red Hat JIRA] (DROOLS-5808) XLS to GDST conversion should ensure types work

by Kris Verlaenen (Jira)

[ https://issues.redhat.com/browse/DROOLS-5808?page=com.atlassian.jira.plug... ] Kris Verlaenen updated DROOLS-5808: ----------------------------------- Sprint: 2020 Week 46-48 (from Nov 9), 2020 Week 49-51 (from Nov 30) (was: 2020 Week 46-48 (from Nov 9)) > XLS to GDST conversion should ensure types work > ----------------------------------------------- > > Key: DROOLS-5808 > URL: https://issues.redhat.com/browse/DROOLS-5808 > Project: Drools > Issue Type: Bug > Components: Guided Decision Table Editor > Reporter: Toni Rikkola > Assignee: Toni Rikkola > Priority: Major > Labels: drools-tools > > BigDecimal, BigIntenger, long, float and double do not necessary work unless we add appropriate wrappers. Depends on the dialect that is used in the kbase, the current approach will default to Java dialect since that also works in MVEL. -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 5 months

1
0
0 / 0

[Red Hat JIRA] (DROOLS-5861) Include PMML trusty inside Kie-Server

by Gabriele Cardosi (Jira)

Gabriele Cardosi created DROOLS-5861: ---------------------------------------- Summary: Include PMML trusty inside Kie-Server Key: DROOLS-5861 URL: https://issues.redhat.com/browse/DROOLS-5861 Project: Drools Issue Type: Sub-task Reporter: Gabriele Cardosi Assignee: Gabriele Cardosi Include PMML trusty inside Kie-Server (droolsjbpm-integration/kie-server-parent/) Look for PMML legacy references. See [ApplyPmmlModelCommandExecutor|https://github.com/kiegroup/droolsjbpm-know...] Verify Correct classloading/defaulting. Verify jpmml. For tests, see [README|https://github.com/kiegroup/droolsjbpm-integration/blob/master/kie...] [KieServerDroolsIntegrationTest|https://github.com/kiegroup/droolsjbpm-int...] [DMNPMMLMiningIntegrationTest|https://github.com/kiegroup/droolsjbpm-integ...] Remember to compile/install modules before testing, since underlying Arquilian uses jars from m2 repo -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 5 months

1
0
0 / 0

[Red Hat JIRA] (DROOLS-5742) Reduce the call to getServerInfo() in kie-server integration tests

by Kris Verlaenen (Jira)

[ https://issues.redhat.com/browse/DROOLS-5742?page=com.atlassian.jira.plug... ] Kris Verlaenen updated DROOLS-5742: ----------------------------------- Sprint: 2020 Week 43-45 (from Okt 19), 2020 Week 46-48 (from Nov 9), 2020 Week 49-51 (from Nov 30) (was: 2020 Week 43-45 (from Okt 19), 2020 Week 46-48 (from Nov 9)) > Reduce the call to getServerInfo() in kie-server integration tests > ------------------------------------------------------------------ > > Key: DROOLS-5742 > URL: https://issues.redhat.com/browse/DROOLS-5742 > Project: Drools > Issue Type: Enhancement > Components: kie server > Affects Versions: 7.45.0.Final > Reporter: Toshiya Kobayashi > Assignee: Toshiya Kobayashi > Priority: Minor > > getServerInfo() is called in integration tests 39 times (format x3 transport x2) = 234 times > It's called every time KieServicesClient is created (if config.getCapabilities() == null). > https://github.com/kiegroup/droolsjbpm-integration/blob/master/kie-server... > https://github.com/kiegroup/droolsjbpm-integration/blob/master/kie-server... > So, we can suppress calling getServerInfo() by providing config.capabilities in test cases. -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 5 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira December 2020