May 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-13431) Give a better error message for standard configuration tests

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFLY-13431?page=com.atlassian.jira.plugi... ] Brian Stansberry moved WFCORE-4952 to WFLY-13431: ------------------------------------------------- Project: WildFly (was: WildFly Core) Key: WFLY-13431 (was: WFCORE-4952) Component/s: Test Suite (was: Test Suite) > Give a better error message for standard configuration tests > ------------------------------------------------------------ > > Key: WFLY-13431 > URL: https://issues.redhat.com/browse/WFLY-13431 > Project: WildFly > Issue Type: Enhancement > Components: Test Suite > Reporter: James Perkins > Assignee: James Perkins > Priority: Minor > Fix For: 20.0.0.Beta1 > > > The {{StandardConfigsXMLValidationUnitTestCase}} tests validate the default configuration files. These are written into a file as a single line. This makes it a little more difficult to determine where the error is. > A simple fix for this is to just write a new line after each line. This will give a better error message as to which line the issue is one. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (DROOLS-4136) R&D how to run scenario simulation tests inside VSCode

by Eder Ignatowicz (Jira)

[ https://issues.redhat.com/browse/DROOLS-4136?page=com.atlassian.jira.plug... ] Eder Ignatowicz closed DROOLS-4136. ----------------------------------- Resolution: Won't Do > R&D how to run scenario simulation tests inside VSCode > ------------------------------------------------------ > > Key: DROOLS-4136 > URL: https://issues.redhat.com/browse/DROOLS-4136 > Project: Drools > Issue Type: Task > Reporter: Eder Ignatowicz > Assignee: Yeser Amer > Priority: Major > > The main goal of this JIRA is to research what are the best approaches in order to run scenario simulation tests inside VSCode client-side only distribution. > Eder's first ideas: > [1] Run kie-server inside a docker image and run scenario tests via REST API > [2] Show the result of test execution inside scenario simulation editor > <add your idea here> > On future: [1] + investigate if it's possible to show tests execution results inside another junit vscode extension -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (DROOLS-4136) R&D how to run scenario simulation tests inside VSCode

by Eder Ignatowicz (Jira)

[ https://issues.redhat.com/browse/DROOLS-4136?page=com.atlassian.jira.plug... ] Eder Ignatowicz reopened DROOLS-4136: ------------------------------------- > R&D how to run scenario simulation tests inside VSCode > ------------------------------------------------------ > > Key: DROOLS-4136 > URL: https://issues.redhat.com/browse/DROOLS-4136 > Project: Drools > Issue Type: Task > Reporter: Eder Ignatowicz > Assignee: Yeser Amer > Priority: Major > > The main goal of this JIRA is to research what are the best approaches in order to run scenario simulation tests inside VSCode client-side only distribution. > Eder's first ideas: > [1] Run kie-server inside a docker image and run scenario tests via REST API > [2] Show the result of test execution inside scenario simulation editor > <add your idea here> > On future: [1] + investigate if it's possible to show tests execution results inside another junit vscode extension -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (DROOLS-4136) R&D how to run scenario simulation tests inside VSCode

by Eder Ignatowicz (Jira)

[ https://issues.redhat.com/browse/DROOLS-4136?page=com.atlassian.jira.plug... ] Eder Ignatowicz resolved DROOLS-4136. ------------------------------------- Resolution: Done > R&D how to run scenario simulation tests inside VSCode > ------------------------------------------------------ > > Key: DROOLS-4136 > URL: https://issues.redhat.com/browse/DROOLS-4136 > Project: Drools > Issue Type: Task > Reporter: Eder Ignatowicz > Assignee: Yeser Amer > Priority: Major > > The main goal of this JIRA is to research what are the best approaches in order to run scenario simulation tests inside VSCode client-side only distribution. > Eder's first ideas: > [1] Run kie-server inside a docker image and run scenario tests via REST API > [2] Show the result of test execution inside scenario simulation editor > <add your idea here> > On future: [1] + investigate if it's possible to show tests execution results inside another junit vscode extension -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-4958) Create the ModelTestModelControllerService variants for the EAP 7.3.0 controllers and subsystems

by Yeray Borges Santana (Jira)

Yeray Borges Santana created WFCORE-4958: -------------------------------------------- Summary: Create the ModelTestModelControllerService variants for the EAP 7.3.0 controllers and subsystems Key: WFCORE-4958 URL: https://issues.redhat.com/browse/WFCORE-4958 Project: WildFly Core Issue Type: Task Components: Management Reporter: Yeray Borges Santana Assignee: Yeray Borges Santana These are used in the legacy-test frameworks -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (WFLY-13430) Feature for checking module installation in JBoss

by Joao Paulo Goncalves (Jira)

Joao Paulo Goncalves created WFLY-13430: ------------------------------------------- Summary: Feature for checking module installation in JBoss Key: WFLY-13430 URL: https://issues.redhat.com/browse/WFLY-13430 Project: WildFly Issue Type: Feature Request Reporter: Joao Paulo Goncalves Assignee: Brian Stansberry Using CLI tool or Administrative Console is not possible at this moment to check if a custom added module was added correctly, especially in domain mode. The only alternative available is to add host per host. This approach takes time, and for unused users there isn't some visual (GUI) to help them. JBoss CLI approach: module --add --source=jar1,jar2 --target=/path-of-module --host=your-host OR module --add --source=jar1,jar2 --target=/path-of-module --host=all (deploy the module in all hosts that belongs to the domain) -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (WFLY-13259) Memory leak in Hibernate pending-puts cache when L2 cache is enabled

by Sorin Potra (Jira)

[ https://issues.redhat.com/browse/WFLY-13259?page=com.atlassian.jira.plugi... ] Sorin Potra commented on WFLY-13259: ------------------------------------ [~smarlow] In previous versions of WildFly (up to 10.1) we used a similar call which was working fine: Cache cache = em.getEntityManagerFactory().getCache(); if (cache != null) { cache.evict(cls, pk); } So basically we were evicting a newly created entity (which was not in L2 cache anyway). However this does not seem to work anymore in WildFly 13 and above. We could try to call evictAll() or evict(Class) but this would also evict other entities which might affect performance so if we do this we need to run a round of performance testing. > Memory leak in Hibernate pending-puts cache when L2 cache is enabled > -------------------------------------------------------------------- > > Key: WFLY-13259 > URL: https://issues.redhat.com/browse/WFLY-13259 > Project: WildFly > Issue Type: Enhancement > Components: JPA / Hibernate > Affects Versions: 18.0.1.Final, 19.0.0.Final > Reporter: Sorin Potra > Assignee: Scott Marlow > Priority: Optional > Attachments: PathToGCRoots_strong_refs.PNG, afterOOM.hprof.zip, beforeOOM.hprof.zip, pending-puts-leak.PNG, simple-hibernate-war-client.zip, simple-hibernate-war-client.zip.2020-03-25, simple-hibernate-war.war, simple-hibernate-war.war.2020-03-25, simple-hibernate-war.zip, simple-hibernate-war.zip.2020-03-25 > > > Under certain conditions, described below, WildFly / Hibernate can leak memory into the pending-puts cache eventually causing an OutOfMemoryError. Attached you can find a web application and a standalone client that can be used to reproduce the problem. The web app defines two entities: a Parent and a Child. There is a bidirectional one-to-many relationship between the Parent and the Child. JPA L2 cache is enabled (Infinispan is the cache provider). > Repeatedly executing a transaction that creates a new Child and adds it to the list of children in the Parent will cause the memory usage to increase steadily until OOM is encountered. If the execution of these transactions is stopped before reaching OOM, the memory will be reclaimed after a few minutes of inactivity. > Attached you can find the following: > - simple-hibernate-war.war - the web app that can be deployed in WildFly to reproduce the issue. > - simple-hibernate-war.zip - the source code for the above web app. The servlet that is invoked by the client to create and persist a new Child is com.microfocus.sa.web.AddChildServlet > - simple-hibernate-war-client.zip - the standalone client that can be used to invoke the AddChildServlet. After unzipping the archive, the client can be run with the following command from the client folder: > > java -cp bin com.microfocus.sa.client.AddChildClient > > If you need to run the client multiple times, you have to restart WildFly in between the runs, to start from a fresh state (the web app uses the h2 in memory databasewhich is reset at each restart). > - pending-puts-leak.PNG - a screeshot from Memory Analyzer showing a leaked SessionImpl instance -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-4957) Reduce heap footprint of single attribute write-attribute handlers

by Paul Ferraro (Jira)

Paul Ferraro created WFCORE-4957: ------------------------------------ Summary: Reduce heap footprint of single attribute write-attribute handlers Key: WFCORE-4957 URL: https://issues.redhat.com/browse/WFCORE-4957 Project: WildFly Core Issue Type: Bug Components: Management Affects Versions: 12.0.0.Beta2 Reporter: Paul Ferraro Assignee: Paul Ferraro AbstractWriteAttributeHandler creates a HashMap (with default capacity) for every instance, even if the handler is only used for one attribute. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (WFLY-13319) Wildfly 19 MP-JWT & EJB Integration

by Darran Lofthouse (Jira)

[ https://issues.redhat.com/browse/WFLY-13319?page=com.atlassian.jira.plugi... ] Darran Lofthouse updated WFLY-13319: ------------------------------------ Component/s: EJB > Wildfly 19 MP-JWT & EJB Integration > ----------------------------------- > > Key: WFLY-13319 > URL: https://issues.redhat.com/browse/WFLY-13319 > Project: WildFly > Issue Type: Feature Request > Components: EJB, MP JWT, Test Suite > Affects Versions: 19.0.0.Final > Reporter: Radu Cimpean > Assignee: Darran Lofthouse > Priority: Major > Fix For: 20.0.0.Beta1 > > Attachments: server-cli.txt, web.xml > > > ===Previous configuration & situation=== > As written https://groups.google.com/forum/#!topic/wildfly/L1BxATschCU, > We were running wildfly 18 and used jwt for securing the application. We did this via a series of cli commands (see server-cli.txt) to configure the server, as well as referencing the created domains in the web.xml. > Under jboss-web.xml we are referencing the "ejb-domain" created in the CLIs. The web.xml (see attachments) protects the resource wit the role referenced in the CLIs (role present in the token) > All our jax-rs resources are annotated with @Stateless and are calling EJBs which in turn are @Statless and declare allowed roles. > ===Current situation=== > We've upgraded to wildfly 19 in hopes of using microprofile jwt. To do this, we've annotated the Application class with > @LoginConfig(authMethod = "MP-JWT", realmName = "MP-JWT-REALM"), removed the login-config from the web.xml, and removed the security-domain from jboss-web.xml (since otherwise I would receive an error: ELY01148: A SecurityDomain has already been associated with the specified ClassLoader"). > After also removing the security-constraint tag from the web.xml I was able to get to the resource and noticed that the JWTToken was properly injected (all claims and entries are there), and the SecurityContext injected in the resource also contained the jwt specific values. From what I can tell, in the context of the jax-rs classloader, I am authenticated. > I would, however, always receive a "Invocation on method... is not allowed" the second the resource would try calling a bean, even if the role matched. Upon checking the logs, and what the injected SessionContext contained, I noticed the principal was anonymous and had no roles allowed. > I therefore believe that the credentials are somehow not being properly passed. > Is there a documented way of properly integrating jax-rs&ejb with microprofile jwt? -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (WFLY-13319) Wildfly 19 MP-JWT & EJB Integration

by Darran Lofthouse (Jira)

[ https://issues.redhat.com/browse/WFLY-13319?page=com.atlassian.jira.plugi... ] Darran Lofthouse commented on WFLY-13319: ----------------------------------------- So for this issue I do now have a test case which matches the scenario you describe, presently the MicroProfile JWT integration will result in a virtual security domain being activated for the complete deployment but we are not presently activating the correct security interceptors for the EJB deployments to correctly handle the @RolesAllowed authorization checks so I have converted this to a feature request to add that support. > Wildfly 19 MP-JWT & EJB Integration > ----------------------------------- > > Key: WFLY-13319 > URL: https://issues.redhat.com/browse/WFLY-13319 > Project: WildFly > Issue Type: Feature Request > Components: MP JWT, Test Suite > Affects Versions: 19.0.0.Final > Reporter: Radu Cimpean > Assignee: Darran Lofthouse > Priority: Major > Fix For: 20.0.0.Beta1 > > Attachments: server-cli.txt, web.xml > > > ===Previous configuration & situation=== > As written https://groups.google.com/forum/#!topic/wildfly/L1BxATschCU, > We were running wildfly 18 and used jwt for securing the application. We did this via a series of cli commands (see server-cli.txt) to configure the server, as well as referencing the created domains in the web.xml. > Under jboss-web.xml we are referencing the "ejb-domain" created in the CLIs. The web.xml (see attachments) protects the resource wit the role referenced in the CLIs (role present in the token) > All our jax-rs resources are annotated with @Stateless and are calling EJBs which in turn are @Statless and declare allowed roles. > ===Current situation=== > We've upgraded to wildfly 19 in hopes of using microprofile jwt. To do this, we've annotated the Application class with > @LoginConfig(authMethod = "MP-JWT", realmName = "MP-JWT-REALM"), removed the login-config from the web.xml, and removed the security-domain from jboss-web.xml (since otherwise I would receive an error: ELY01148: A SecurityDomain has already been associated with the specified ClassLoader"). > After also removing the security-constraint tag from the web.xml I was able to get to the resource and noticed that the JWTToken was properly injected (all claims and entries are there), and the SecurityContext injected in the resource also contained the jwt specific values. From what I can tell, in the context of the jax-rs classloader, I am authenticated. > I would, however, always receive a "Invocation on method... is not allowed" the second the resource would try calling a bean, even if the role matched. Upon checking the logs, and what the injected SessionContext contained, I noticed the principal was anonymous and had no roles allowed. > I therefore believe that the credentials are somehow not being properly passed. > Is there a documented way of properly integrating jax-rs&ejb with microprofile jwt? -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira May 2020