[JBoss JIRA] (WFCORE-2746) Move elytron management security tests from full to core
by Ken Wills (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2746?page=com.atlassian.jira.plugi... ]
Ken Wills updated WFCORE-2746:
------------------------------
Summary: Move elytron management security tests from full to core (was: Move elytron management security tests from core to full)
> Move elytron management security tests from full to core
> --------------------------------------------------------
>
> Key: WFCORE-2746
> URL: https://issues.jboss.org/browse/WFCORE-2746
> Project: WildFly Core
> Issue Type: Task
> Components: Domain Management, Security, Test Suite
> Reporter: Brian Stansberry
>
> Since until recently the elytron subsystem wasn't part of the core feature pack, a lot of integration tests of its use ended up in the WildFly full testsuite instead of in core. This task is to get tests that are only testing core functionality moved into the core testsuite. Because that's the right thing to do, but also because it's useful in practice by eliminating a cause for messy coordinated changes to core and full such that code changes in core can be tested.
> There are a number of aspects to this, for which I'll create subtasks.
> Following is an initial list of tests that should be moved. *This is meant to be a living list, with things added as they are noticed.* So anyone should feel free to edit this JIRA description to add things to the list.
> org.jboss.as.test.integration.security.perimeter.* [2]
> org.jboss.as.test.manualmode.mgmt.elytron.HttpMgmtInterfaceElytronAuthenticationTestCase
> -org.jboss.as.test.integration.domain.AbstractSlaveHCAuthenticationTestCase and subclasses.[1]-
> org.jboss.as.test.integration.security.credentialreference [2] (This is using h2 / datasources, so not moving).
> [1] One subclass of this is not related to elytron but should be moved to core too. I haven't looked closely but it uses vault, which may be why it is in full. But we can use vault in the core testsuite now.
> [2] Currently using Arquillian.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 12 months
[JBoss JIRA] (DROOLS-1540) Drools does not work with spring-boot-devtools
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1540?page=com.atlassian.jira.plugi... ]
Mario Fusco resolved DROOLS-1540.
---------------------------------
Resolution: Rejected
This is not a Drools issue. The problem is that when using devtools the Message instance doesn't come from the launcher classloader, but from a different one named org.springframework.boot.devtools.restart.classloader.RestartClassLoader and then Drools is no longer able to match it.
I think you can maybe workaround the problem as explained here https://docs.spring.io/spring-boot/docs/current/reference/html/using-boot... but I strongly suggested to introduce tools like this that change the classes of your domain objects at runtime.
> Drools does not work with spring-boot-devtools
> ----------------------------------------------
>
> Key: DROOLS-1540
> URL: https://issues.jboss.org/browse/DROOLS-1540
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.5.0.Final
> Reporter: G Xiong
> Assignee: Mario Fusco
> Priority: Critical
> Attachments: complete.zip
>
>
> Drools does work with spring-boot-devtools.
> If you add in pom.xml the following, no rules will be fired in Drools.
> <dependency>
> <groupId>org.springframework.boot</groupId>
> <artifactId>spring-boot-devtools</artifactId>
> </dependency>
> if you comment out this, then rules will be fired in Drools.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 12 months