[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)
5 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)
5 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)
5 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)
5 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)
5 years, 7 months
[JBoss JIRA] (WFLY-13929) Intermittent failures in DeploymentOverlayCLITestCase
by Jeff Mesnil (Jira)
[ https://issues.redhat.com/browse/WFLY-13929?page=com.atlassian.jira.plugi... ]
Jeff Mesnil commented on WFLY-13929:
------------------------------------
WFLY-13870 (merged on Sept. 15th) brought in component upgrade for Undertow 2.2.0.Final and XNIO 3.8.2.Final.
[~flavia.rainone] could you please check if there are changes in these component upgrades that would explain these failures?
> Intermittent failures in DeploymentOverlayCLITestCase
> -----------------------------------------------------
>
> Key: WFLY-13929
> URL: https://issues.redhat.com/browse/WFLY-13929
> Project: WildFly
> Issue Type: Bug
> Components: Management
> Reporter: Brian Stansberry
> Assignee: Jeff Mesnil
> Priority: Major
>
> Two tests in DeploymentOverlayCLITestCase are failing intermittently but fairly often, e.g.
> https://ci.wildfly.org/viewLog.html?buildId=225079&tab=buildResultsDiv&bu...
> {code}
> java.lang.RuntimeException: java.io.IOException: User limit of inotify instances reached or too many open files
> at org.xnio.nio.WatchServiceFileSystemWatcher.<init>(WatchServiceFileSystemWatcher.java:75)
> at org.xnio.nio.NioXnio.createFileSystemWatcher(NioXnio.java:241)
> at io.undertow.server.handlers.resource.PathResourceManager.registerResourceChangeListener(PathResourceManager.java:256)
> at org.wildfly.extension.undertow.deployment.ServletResourceManager.registerResourceChangeListener(ServletResourceManager.java:117)
> at io.undertow.server.handlers.resource.CachingResourceManager.registerResourceChangeListener(CachingResourceManager.java:131)
> at io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:310)
> at io.undertow.servlet.core.ManagedServlet.forceInit(ManagedServlet.java:212)
> at io.undertow.servlet.handlers.ServletChain.forceInit(ServletChain.java:130)
> at io.undertow.servlet.handlers.ServletChain$1.handleRequest(ServletChain.java:63)
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.RedirectDirHandler.handleRequest(RedirectDirHandler.java:68)
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:132)
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68)
> at io.undertow.servlet.handlers.SendErrorPageHandler.handleRequest(SendErrorPageHandler.java:52)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:269)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:78)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:133)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:130)
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1530)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1530)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1530)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1530)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:249)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:78)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:99)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:387)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:841)
> 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)
> Caused by: java.io.IOException: User limit of inotify instances reached or too many open files
> at sun.nio.fs.LinuxWatchService.<init>(LinuxWatchService.java:64)
> at sun.nio.fs.LinuxFileSystem.newWatchService(LinuxFileSystem.java:47)
> at org.xnio.nio.WatchServiceFileSystemWatcher.<init>(WatchServiceFileSystemWatcher.java:73)
> ... 49 more
> </pre></body></html>
> at org.jboss.as.test.integration.common.HttpRequest.execute(HttpRequest.java:61)
> at org.jboss.as.test.integration.common.HttpRequest.get(HttpRequest.java:82)
> at org.jboss.as.test.integration.management.cli.DeploymentOverlayCLITestCase.simpleOverrideInEarAtWarLevelExplodedTest(DeploymentOverlayCLITestCase.java:415)
> at org.jboss.as.test.integration.management.cli.DeploymentOverlayCLITestCase.testSimpleOverrideInEarAtWarLevelExploded(DeploymentOverlayCLITestCase.java:383)
> {code}
> Tests started failing fairly often on September 17.
> https://ci.wildfly.org/project.html?projectId=WF_PullRequest&buildTypeId=...
> The first failure was against a PR that hasn't been merged yet, so it's likely the problem is in master, not one of the PRs shown on that page.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
[JBoss JIRA] (DROOLS-5687) NullPointerException on second consecutive declared type update
by Mario Fusco (Jira)
[ https://issues.redhat.com/browse/DROOLS-5687?page=com.atlassian.jira.plug... ]
Mario Fusco updated DROOLS-5687:
--------------------------------
Sprint: 2020 Week 40-42 (from Sep 28)
> NullPointerException on second consecutive declared type update
> ---------------------------------------------------------------
>
> Key: DROOLS-5687
> URL: https://issues.redhat.com/browse/DROOLS-5687
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.43.0.Final
> Reporter: Matteo Casalino
> Assignee: Mario Fusco
> Priority: Major
> Attachments: npe-consecutives-declare-update.zip
>
>
> When updating a {{KieContainer}} with {{updateToVersion}} with a change in a declared type two consecutive times, a {{NullPointerException}} is raised.
> Minimal example DRL triggering the issue (notice at least two declared types are needed):
> {noformat}
> declare FactType1
> x : int
> end
> declare FactType2
> y : int
> end
> {noformat}
> first update:
> {noformat}
> declare FactType1
> x : int
> z : int
> end
> declare FactType2
> y : int
> end
> {noformat}
> second update:
> {noformat}
> declare FactType1
> x : int
> z : int
> w : int
> end
> declare FactType2
> y : int
> end
> {noformat}
> The second update will raise the following exception:
> {noformat}
> java.lang.NullPointerException
> at org.drools.compiler.kie.util.ChangeSetBuilder.build(ChangeSetBuilder.java:106)
> at org.drools.compiler.kie.builder.impl.InternalKieModule.getChanges(InternalKieModule.java:132)
> at org.drools.compiler.kie.builder.impl.KieContainerImpl.update(KieContainerImpl.java:241)
> at org.drools.compiler.kie.builder.impl.KieContainerImpl.update(KieContainerImpl.java:237)
> at org.drools.compiler.kie.builder.impl.KieContainerImpl.updateToVersion(KieContainerImpl.java:195)
> at org.example.reproducer.KjarUpdateTest.update(KjarUpdateTest.java:37)
> at org.example.reproducer.KjarUpdateTest.testConsecutiveUpdates(KjarUpdateTest.java:48)
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months