[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
[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
[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
[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
[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
[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
[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
[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