[JBoss JIRA] (WFCORE-5143) Bouncycastle - Failing tests in RESTEasy TS
by Darran Lofthouse (Jira)
[ https://issues.redhat.com/browse/WFCORE-5143?page=com.atlassian.jira.plug... ]
Darran Lofthouse commented on WFCORE-5143:
------------------------------------------
I need to run some tests, for KeyCloak I believe the main requirement is going to be - for our zip distribution the org.bouncycastle module must be present.
For the provisioned cases I am going to test but the KeyCloak feature pack should trigger the dependency as it is installed I hope.
> Bouncycastle - Failing tests in RESTEasy TS
> -------------------------------------------
>
> Key: WFCORE-5143
> URL: https://issues.redhat.com/browse/WFCORE-5143
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Affects Versions: 13.0.0.Beta6
> Reporter: Emmanuel Hugonnet
> Assignee: Emmanuel Hugonnet
> Priority: Blocker
> Fix For: 13.0.0.Beta7
>
>
> [~ehugonnet] please set the component. I cannot find anything suitable.
> I noticed it in the context of a bootable JAR execution but [~jfdenise] confirmed this happens with WF 21 Beta1.
> This is about some tests in the RESTEasy TS which has been adapted to execute against bootable JARs through a specific profile [1].
> The tests are running successfully with WildFly 20.0.1.Final (the {{ejb}} layer needs to be removed for this experiment to be run [2]) but fail against 21.0.0.Beta1, so it is a regression.
> There are 108 tests failing but this JIRA is reporting just one as a reference, see "Steps to reproduce" in order to have a full list:
> {code}
> org.jboss.resteasy.test.providers.mediatype.BlacklistedMediaTypeTest.org.jboss.resteasy.test.providers.mediatype.BlacklistedMediaTypeTest
> Error Details
> Cannot deploy BlacklistedMediaTypeTest.war: {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-1" => {"WFLYCTL0080: Failed services" => {"jboss.module.service.\"deployment.BlacklistedMediaTypeTest.war\".main" => "WFLYSRV0179: Failed to load module: deployment.BlacklistedMediaTypeTest.war
> Caused by: org.jboss.modules.ModuleNotFoundException: org.bouncycastle"}}}}
> {code}
> *Steps to reproduce*:
> 1. clone https://github.com/fabiobrz/Resteasy/tree/bootable-jar-support
> 2. build RESTEasy:
> {code}
> $ mvn install -Dmaven.test.skip=true -Dmaven.repo.local=/home/my-local-repo
> {code}
> 3. cd to testsuite directory:
> {code}
> cd testsuite
> {code}
> 4. run the test against WF 21.0.0.Beta1 with bootable JAR:
> {code}
> mvn clean verify -am -pl integration-tests -Dmaven.repo.local=/home/my-local-repo -Dserver.version=21.0.0.Beta1 -Dtest=org.jboss.resteasy.test.providers.mediatype.BlacklistedMediaTypeTest -Ddisable.microprofile.tests -Dserver.home=foo -Dts.bootable
> {code}
> The test should *fail*
> 5. run the test against WF 20.0.1.Final with bootable JAR:
> {code}
> mvn clean verify -am -pl integration-tests -Dmaven.repo.local=/home/my-local-repo -Dserver.version=20.0.1.Final -Dtest=org.jboss.resteasy.test.providers.mediatype.BlacklistedMediaTypeTest -Ddisable.microprofile.tests -Dserver.home=foo -Dts.bootable
> {code}
> The test should *pass*
> [1]
> https://github.com/resteasy/Resteasy/pull/2526/files#diff-8c7ea03eb619e46...
> [2]
> https://github.com/resteasy/Resteasy/pull/2526/files#diff-8c7ea03eb619e46...
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
3 years, 7 months
[JBoss JIRA] (DROOLS-5689) Test Scenario DMN included models decision support
by Jan Stastny (Jira)
Jan Stastny created DROOLS-5689:
-----------------------------------
Summary: Test Scenario DMN included models decision support
Key: DROOLS-5689
URL: https://issues.redhat.com/browse/DROOLS-5689
Project: Drools
Issue Type: Enhancement
Components: Scenario Simulation and Testing
Affects Versions: 7.44.0.Final
Reporter: Jan Stastny
Assignee: Yeser Amer
Attachments: reproducer.zip
Test scenario does not currently fully support DMN models with included DMN model.
Currently just Data types are correctly included, but issue is with Decisions. When running a test scenario where such imported decision is referenced in the decision being tested it results in SKIPPED evaluation of the decision and similar log entry:
{code:java}
12:27:45,784 ERROR [org.kie.dmn.core.impl.DMNRuntimeImpl] (default task-20) Required dependency 'input-a' not found on node 'LessThanZero'
12:27:45,784 ERROR [org.kie.dmn.core.impl.DMNRuntimeImpl] (default task-20) Unable to evaluate decision 'NotLessThanZero' as it depends on decision 'a.LessThanZero'
{code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
3 years, 7 months
[JBoss JIRA] (ELY-2026) UnsupportedOperationException in SSLEngine using jdk 251+
by Darran Lofthouse (Jira)
[ https://issues.redhat.com/browse/ELY-2026?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse commented on ELY-2026:
---------------------------------------
[~rhn-support-rmartinc] Has this test been run against the latest 1.x releases of WildFly Elytron?
> UnsupportedOperationException in SSLEngine using jdk 251+
> ---------------------------------------------------------
>
> Key: ELY-2026
> URL: https://issues.redhat.com/browse/ELY-2026
> Project: WildFly Elytron
> Issue Type: Bug
> Components: SSL
> Affects Versions: 1.10.9.Final
> Reporter: Ricardo Martin Camarero
> Assignee: Darran Lofthouse
> Priority: Major
>
> Some SSLEngines provided by elytron does not implement the new TLS methods that jdk-8 251+ incorporated from jdk-11. That makes some tests in the wildfly-http-client to fail with the following exception:
> {code}
> 12:07:31,031 ERROR (XNIO-3 I/O-1) [org.xnio.listener] <ChannelListeners.java:94> XNIO001007: A channel event listener threw an exception: java.lang.RuntimeException:
> java.lang.reflect.InvocationTargetException
> at io.undertow.protocols.alpn.JDK9AlpnProvider.getSelectedProtocol(JDK9AlpnProvider.java:99)
> at io.undertow.client.ALPNClientSelector$2.handleEvent(ALPNClientSelector.java:81)
> at io.undertow.client.ALPNClientSelector$2.handleEvent(ALPNClientSelector.java:77)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
> at io.undertow.protocols.ssl.SslConduit$SslReadReadyHandler.readReady(SslConduit.java:1211)
> at io.undertow.protocols.ssl.SslConduit$SslWriteReadyHandler.writeReady(SslConduit.java:1286)
> at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:94)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:591)
> Caused by: java.lang.reflect.InvocationTargetException
> 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 io.undertow.protocols.alpn.JDK9AlpnProvider.getSelectedProtocol(JDK9AlpnProvider.java:97)
> ... 8 more
> Caused by: java.lang.UnsupportedOperationException
> at org.wildfly.security.ssl.JDKSpecific.getApplicationProtocol(JDKSpecific.java:35)
> at org.wildfly.security.ssl.AbstractDelegatingSSLEngine.getApplicationProtocol(AbstractDelegatingSSLEngine.java:166)
> ... 13 more
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
3 years, 7 months
[JBoss JIRA] (ELY-2026) UnsupportedOperationException in SSLEngine using jdk 251+
by Ricardo Martin Camarero (Jira)
Ricardo Martin Camarero created ELY-2026:
--------------------------------------------
Summary: UnsupportedOperationException in SSLEngine using jdk 251+
Key: ELY-2026
URL: https://issues.redhat.com/browse/ELY-2026
Project: WildFly Elytron
Issue Type: Bug
Components: SSL
Affects Versions: 1.10.9.Final
Reporter: Ricardo Martin Camarero
Assignee: Darran Lofthouse
Some SSLEngines provided by elytron does not implement the new TLS methods that jdk-8 251+ incorporated from jdk-11. That makes some tests in the wildfly-http-client to fail with the following exception:
{code}
12:07:31,031 ERROR (XNIO-3 I/O-1) [org.xnio.listener] <ChannelListeners.java:94> XNIO001007: A channel event listener threw an exception: java.lang.RuntimeException:
java.lang.reflect.InvocationTargetException
at io.undertow.protocols.alpn.JDK9AlpnProvider.getSelectedProtocol(JDK9AlpnProvider.java:99)
at io.undertow.client.ALPNClientSelector$2.handleEvent(ALPNClientSelector.java:81)
at io.undertow.client.ALPNClientSelector$2.handleEvent(ALPNClientSelector.java:77)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
at io.undertow.protocols.ssl.SslConduit$SslReadReadyHandler.readReady(SslConduit.java:1211)
at io.undertow.protocols.ssl.SslConduit$SslWriteReadyHandler.writeReady(SslConduit.java:1286)
at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:94)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:591)
Caused by: java.lang.reflect.InvocationTargetException
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 io.undertow.protocols.alpn.JDK9AlpnProvider.getSelectedProtocol(JDK9AlpnProvider.java:97)
... 8 more
Caused by: java.lang.UnsupportedOperationException
at org.wildfly.security.ssl.JDKSpecific.getApplicationProtocol(JDKSpecific.java:35)
at org.wildfly.security.ssl.AbstractDelegatingSSLEngine.getApplicationProtocol(AbstractDelegatingSSLEngine.java:166)
... 13 more
{code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
3 years, 7 months
[JBoss JIRA] (DROOLS-5688) Cleanup/refactoring public API
by Gabriele Cardosi (Jira)
[ https://issues.redhat.com/browse/DROOLS-5688?page=com.atlassian.jira.plug... ]
Gabriele Cardosi updated DROOLS-5688:
-------------------------------------
Labels: TrustyAI (was: )
> Cleanup/refactoring public API
> ------------------------------
>
> Key: DROOLS-5688
> URL: https://issues.redhat.com/browse/DROOLS-5688
> Project: Drools
> Issue Type: Enhancement
> Reporter: Gabriele Cardosi
> Assignee: Gabriele Cardosi
> Priority: Major
> Labels: TrustyAI
>
> Refactor "public" API (i.e. API to be used by final user) moving them in the "API" module.
>
> Main classes involved:
> PMMLRuntimeFactory (drools)
> PmmlPredictionModel (kogito - remove direct access to KiePMMLModel; create an "end-user" DTO representation of KiePMMLModel)
>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
3 years, 7 months
[JBoss JIRA] (DROOLS-5688) Cleanup/refactoring public API
by Gabriele Cardosi (Jira)
Gabriele Cardosi created DROOLS-5688:
----------------------------------------
Summary: Cleanup/refactoring public API
Key: DROOLS-5688
URL: https://issues.redhat.com/browse/DROOLS-5688
Project: Drools
Issue Type: Enhancement
Reporter: Gabriele Cardosi
Assignee: Gabriele Cardosi
Refactor "public" API (i.e. API to be used by final user) moving them in the "API" module.
Main classes involved:
PMMLRuntimeFactory (drools)
PmmlPredictionModel (kogito - remove direct access to KiePMMLModel; create an "end-user" DTO representation of KiePMMLModel)
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
3 years, 7 months
[JBoss JIRA] (WFLY-13928) EndpointService should determine if a security-domain is elytron or legacy using capabilities, not MSC
by Darran Lofthouse (Jira)
[ https://issues.redhat.com/browse/WFLY-13928?page=com.atlassian.jira.plugi... ]
Darran Lofthouse commented on WFLY-13928:
-----------------------------------------
[~brian.stansberry] Actually we do have an existing Jira issue for the correct approach to identify the Elytron security domain to use but it will require some refactoring of the web services deployment unit processors.
Overall I don't want us to be repeating the logic to resolve the security domain across multiple subsystems, once logic is duplicated we have the overhead of maintaining it in multiple locations and the risk they will subtly get out of sync.
Instead I want us to move to a collaborative approach where prior to entering Phase.INSTALL subsystems collaboratively build up a security policy which will be recorded in this attachment:
org.jboss.as.server.security.SecurityMetaData
By the time we enter Phase.INSTALL the policy should be complete and all DUPs regardless of the order they are executed should make use of the agreed policy, no exceptions, no further modifications. Should the SecurityMetaData not be present or not be populated then the deployment is using legacy security which is the block of code destined to be deleted in the future.
The one issue that we do have that has prevented reaching this objective so far is within the (effectively single DUP) block of web services DUPs the deployment gets marked as a web application quite late in Phase.INSTALL. This then has a knock on effect that web application security domain resolution can't be triggered until we know the deployment is a web application. For all other test cases in the testsuite it has been possible to pull the web application security domain resolution all the way to I believe it was the Configure Module phase.
We don't really have clear documentation of the expectations of the Phases, the Javadoc seems to have been started and where we can derive information from the names it is more in relation which class loaders are available rather than the expectations of each phase - but overall as Phase.INSTALL is effectively the final phase where everything is installed to be cleaner decisions should have been made before entering this phase.
I think this is a side effect of a phased architecture as well, as subsequent modifications are made you tend to ask the question "What does this need to be after?" and "What does this need to be before?" - this has a tendency to push subsequent insertions later into the chain.
> EndpointService should determine if a security-domain is elytron or legacy using capabilities, not MSC
> ------------------------------------------------------------------------------------------------------
>
> Key: WFLY-13928
> URL: https://issues.redhat.com/browse/WFLY-13928
> Project: WildFly
> Issue Type: Task
> Components: Web Services
> Reporter: Brian Stansberry
> Assignee: Jim Ma
> Priority: Minor
>
> This is a follow on to https://github.com/wildfly/wildfly/pull/13597/files
> EndpointService's isElytronSecurityDomain and isLegacySecurityDomain are checking if things are present by doing MSC service lookups. Generally that's unreliable; but it works in this case because all subsystems install their services before deployment processing begins, and EndpointService is part of deployment processing.
> Still, the services that are being looked up are associated with a capability. So these methods can just use CapabilityServiceSupport.hasCapability to see if that capability is present.
> Semi-related, in various places related to security domain integration EndpointService is using different strategies for creating a ServiceName for the security-related service. Some of those would be eliminated by the main change I discuss above. The others should consolidate on using CapabilityServiceSupport. getCapabilityServiceName.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
3 years, 7 months
[JBoss JIRA] (WFLY-13928) EndpointService should determine if a security-domain is elytron or legacy using capabilities, not MSC
by Darran Lofthouse (Jira)
[ https://issues.redhat.com/browse/WFLY-13928?page=com.atlassian.jira.plugi... ]
Darran Lofthouse commented on WFLY-13928:
-----------------------------------------
[~jim.ma] Do you have a link to the Jira that was raised to follow up from our previous discussions?
> EndpointService should determine if a security-domain is elytron or legacy using capabilities, not MSC
> ------------------------------------------------------------------------------------------------------
>
> Key: WFLY-13928
> URL: https://issues.redhat.com/browse/WFLY-13928
> Project: WildFly
> Issue Type: Task
> Components: Web Services
> Reporter: Brian Stansberry
> Assignee: Jim Ma
> Priority: Minor
>
> This is a follow on to https://github.com/wildfly/wildfly/pull/13597/files
> EndpointService's isElytronSecurityDomain and isLegacySecurityDomain are checking if things are present by doing MSC service lookups. Generally that's unreliable; but it works in this case because all subsystems install their services before deployment processing begins, and EndpointService is part of deployment processing.
> Still, the services that are being looked up are associated with a capability. So these methods can just use CapabilityServiceSupport.hasCapability to see if that capability is present.
> Semi-related, in various places related to security domain integration EndpointService is using different strategies for creating a ServiceName for the security-related service. Some of those would be eliminated by the main change I discuss above. The others should consolidate on using CapabilityServiceSupport. getCapabilityServiceName.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
3 years, 7 months
[JBoss JIRA] (WFCORE-2687) Expose the current step operation's name and parameters via the OperationContext
by Lukas Vydra (Jira)
[ https://issues.redhat.com/browse/WFCORE-2687?page=com.atlassian.jira.plug... ]
Lukas Vydra reassigned WFCORE-2687:
-----------------------------------
Assignee: Lukas Vydra
> Expose the current step operation's name and parameters via the OperationContext
> --------------------------------------------------------------------------------
>
> Key: WFCORE-2687
> URL: https://issues.redhat.com/browse/WFCORE-2687
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Management
> Reporter: Brian Stansberry
> Assignee: Lukas Vydra
> Priority: Major
>
> Remove the need to pass the 'operation' ModelNode to a method for it to be able to learn about the currently effective operation.
> OperationContext already exposes getCurrentAddress(). Add getCurrentOperationName() and getCurrentOperationParameter(String name).
> The latter returns null if !operation.has(name) otherwise it returns whatever the node was. Or perhaps return undefined with an overloaded variant with a boolean param that lets the caller turn on getting null.
> The getCurrentOperationParameter should reject 'name', 'address', 'operation-headers' etc as legal param names; only expose true parameters.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
3 years, 7 months