May 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-5275) Descope Traits

by Luca Molteni (Jira)

[ https://issues.redhat.com/browse/DROOLS-5275?page=com.atlassian.jira.plug... ] Luca Molteni updated DROOLS-5275: --------------------------------- Sprint: 2020 Week 19-21 (from May 4) (was: 2020 Week 16-18 (from Apr 13)) > Descope Traits > -------------- > > Key: DROOLS-5275 > URL: https://issues.redhat.com/browse/DROOLS-5275 > Project: Drools > Issue Type: Enhancement > Reporter: Luca Molteni > Assignee: Luca Molteni > Priority: Major > -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5288) Execution default-generateModel ... failed: Scope expression for ... is not present!

by Luca Molteni (Jira)

[ https://issues.redhat.com/browse/DROOLS-5288?page=com.atlassian.jira.plug... ] Luca Molteni updated DROOLS-5288: --------------------------------- Sprint: 2020 Week 19-21 (from May 4) > Execution default-generateModel ... failed: Scope expression for ... is not present! > ------------------------------------------------------------------------------------ > > Key: DROOLS-5288 > URL: https://issues.redhat.com/browse/DROOLS-5288 > Project: Drools > Issue Type: Bug > Components: core engine > Reporter: Matteo Mortari > Assignee: Luca Molteni > Priority: Major > Attachments: image-2020-04-30-16-32-07-591.png > > > Reproducer: https://github.com/tarilabs/reproducer20200430 > To reproduce: > {code} > mvn clean compile -X > {code} > Example: > !image-2020-04-30-16-32-07-591.png! -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13358) Tests for WFCORE-4950 - Regression: Legacy Ldap Realm securing EJB with JDK8 not working

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFLY-13358?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFLY-13358: ------------------------------------ Fix Version/s: (was: 19.1.0.Final) > Tests for WFCORE-4950 - Regression: Legacy Ldap Realm securing EJB with JDK8 not working > ---------------------------------------------------------------------------------------- > > Key: WFLY-13358 > URL: https://issues.redhat.com/browse/WFLY-13358 > Project: WildFly > Issue Type: Bug > Components: EJB, Security > Reporter: Darran Lofthouse > Assignee: Ricardo Martin Camarero > Priority: Critical > Labels: downstream_dependency > Fix For: 20.0.0.Beta1 > > > This is likely to actually be a WFCORE issue but as this is fixed a test case to reproduce should be added to the testsuite if appropriate. > So far this seems a fairly generic issue an since WildFly 17 we must have run the testsuite against Java 8 100s if not 1000s of times so it is not appropriate to be reliant on an internal testsuite to detect the issue nine months or more later. > The following issue describes the issue in relation to EAP: - > https://issues.redhat.com/browse/JBEAP-19195 -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4989) JACCAuthzPropagationTestCase failures are intermittent on CI

by Ranabir Chakraborty (Jira)

[ https://issues.redhat.com/browse/WFLY-4989?page=com.atlassian.jira.plugin... ] Ranabir Chakraborty commented on WFLY-4989: ------------------------------------------- [~jamezp] Can you please provide steps to recreate this issue? > JACCAuthzPropagationTestCase failures are intermittent on CI > ------------------------------------------------------------ > > Key: WFLY-4989 > URL: https://issues.redhat.com/browse/WFLY-4989 > Project: WildFly > Issue Type: Bug > Components: Security, Test Suite > Reporter: James Perkins > Priority: Major > Labels: testsuite_stability > > http://brontes.lab.eng.brq.redhat.com/project.html?projectId=WF_PullReque... -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3064) Remove org.jboss.as.test.integration.ejb.container.interceptor.security.SwitchIdentityTestCase test case.

by Ranabir Chakraborty (Jira)

[ https://issues.redhat.com/browse/WFLY-3064?page=com.atlassian.jira.plugin... ] Ranabir Chakraborty reassigned WFLY-3064: ----------------------------------------- Assignee: Ranabir Chakraborty > Remove org.jboss.as.test.integration.ejb.container.interceptor.security.SwitchIdentityTestCase test case. > --------------------------------------------------------------------------------------------------------- > > Key: WFLY-3064 > URL: https://issues.redhat.com/browse/WFLY-3064 > Project: WildFly > Issue Type: Sub-task > Components: Test Suite > Reporter: Darran Lofthouse > Assignee: Ranabir Chakraborty > Priority: Major > > A new test case was added under WFLY-3063 that demonstrates the correct way to do this so now remove the original way that depended on internal APIs. -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13408) Migrate CommandDispatcher to use ProtoStream marshalling

by Ranabir Chakraborty (Jira)

[ https://issues.redhat.com/browse/WFLY-13408?page=com.atlassian.jira.plugi... ] Ranabir Chakraborty commented on WFLY-13408: -------------------------------------------- [~pferraro] can you please add a description for this issue? > Migrate CommandDispatcher to use ProtoStream marshalling > -------------------------------------------------------- > > Key: WFLY-13408 > URL: https://issues.redhat.com/browse/WFLY-13408 > Project: WildFly > Issue Type: Task > Components: Clustering > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Priority: Major > -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-313) [EAP7-1386] Cannot deploy simple jax-rs application to server without microprofile extenstions

by Ronald Sigal (Jira)

[ https://issues.redhat.com/browse/WFWIP-313?page=com.atlassian.jira.plugin... ] Ronald Sigal commented on WFWIP-313: ------------------------------------ I wrote * org.jboss.resteasy.test.microprofile.config.ResteasyConfigFilterTest * org.jboss.resteasy.test.microprofile.config.ResteasyConfigServletContextListenerTest * org.jboss.resteasy.test.microprofile.config.ResteasyConfigServletTest in testsuite/integration-tests > [EAP7-1386] Cannot deploy simple jax-rs application to server without microprofile extenstions > ---------------------------------------------------------------------------------------------- > > Key: WFWIP-313 > URL: https://issues.redhat.com/browse/WFWIP-313 > Project: WildFly WIP > Issue Type: Quality Risk > Reporter: Petr Kremensky > Assignee: Ronald Sigal > Priority: Major > > This one is probably caused by a fact that https://github.com/resteasy/Resteasy/pull/2250 was submitted a long time before the "MicroProfile Config will be available to EAP only when installing the MicroProfile expansion pack" was introduces. I just want to be sure that we're on a same page here and my understanding that this is a valid use case for EAP7-1386 is correct. If so, we might include similar use case into test plan to cover this. > *Reproduce* > Update the standalone.xml configuration file inside the WildFly server - remove all microprofile extensions/subsystems from it, and deploy a simple Jax-rs application - e.g. https://github.com/wildfly/quickstart/tree/master/helloworld-rs > * WildFly 19.0.0.Final with default RESTEasy (3.11.0.Final) > No issues with deployment. > * WildFly 19.0.0.Final with RESTEasy 3.10.0-SNAPSHOT from https://github.com/resteasy/Resteasy/pull/2250 (7f10848) > {noformat} > 07:55:08,542 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 68) MSC000001: Failed to start service jboss.deployment.unit."helloworld-rs.war".undertow-deployment: org.jboss.msc.service.StartException in service jboss.deployment.unit."helloworld-rs.war".undertow-deployment: java.lang.IllegalStateException: No ConfigProviderResolver implementation found! > at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:81) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) > at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982) > at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486) > at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377) > at java.lang.Thread.run(Thread.java:748) > at org.jboss.threads.JBossThread.run(JBossThread.java:485) > Caused by: java.lang.IllegalStateException: No ConfigProviderResolver implementation found! > at org.eclipse.microprofile.config.spi.ConfigProviderResolver.loadSpi(ConfigProviderResolver.java:125) > at org.eclipse.microprofile.config.spi.ConfigProviderResolver.instance(ConfigProviderResolver.java:110) > at org.eclipse.microprofile.config.ConfigProvider.getConfig(ConfigProvider.java:105) > at org.jboss.resteasy.microprofile.config.ResteasyConfigProvider.getConfig(ResteasyConfigProvider.java:11) > at org.jboss.resteasy.plugins.server.servlet.ConfigurationBootstrap.getParameter(ConfigurationBootstrap.java:353) > at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:136) > at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:42) > at io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:117) > at org.wildfly.extension.undertow.security.RunAsLifecycleInterceptor.init(RunAsLifecycleInterceptor.java:78) > at io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:103) > at io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:305) > at io.undertow.servlet.core.ManagedServlet.createServlet(ManagedServlet.java:145) > at io.undertow.servlet.core.DeploymentManagerImpl$2.call(DeploymentManagerImpl.java:585) > at io.undertow.servlet.core.DeploymentManagerImpl$2.call(DeploymentManagerImpl.java:556) > at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:42) > 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:1541) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1541) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1541) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1541) > at io.undertow.servlet.core.DeploymentManagerImpl.start(DeploymentManagerImpl.java:598) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:97) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:78) > ... 8 more > 07:55:08,546 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0013: Operation ("add") failed - address: ([("deployment" => "helloworld-rs.war")]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"helloworld-rs.war\".undertow-deployment" => "java.lang.IllegalStateException: No ConfigProviderResolver implementation found! > Caused by: java.lang.IllegalStateException: No ConfigProviderResolver implementation found!"}} > 07:55:08,547 ERROR [org.jboss.as.server] (management-handler-thread - 1) WFLYSRV0021: Deploy of deployment "helloworld-rs.war" was rolled back with the following failure message: > {"WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"helloworld-rs.war\".undertow-deployment" => "java.lang.IllegalStateException: No ConfigProviderResolver implementation found! > Caused by: java.lang.IllegalStateException: No ConfigProviderResolver implementation found!"}} > {noformat} > Please let me know in case that my expectations about this use case are wrong. -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4955) Create a wildfly-network OutboundConnection interface from AbstractOutboundConnectionService; expose via capabilities

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFCORE-4955?page=com.atlassian.jira.plug... ] Brian Stansberry reassigned WFCORE-4955: ---------------------------------------- Assignee: Yeray Borges Santana (was: Brian Stansberry) > Create a wildfly-network OutboundConnection interface from AbstractOutboundConnectionService; expose via capabilities > --------------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-4955 > URL: https://issues.redhat.com/browse/WFCORE-4955 > Project: WildFly Core > Issue Type: Enhancement > Components: Management, Remoting > Reporter: Brian Stansberry > Assignee: Yeray Borges Santana > Priority: Major > > This is part of an overall effort to eliminate non-optional dependencies on the org.jboss.as.remoting module. Both because depending on extension modules has a code smell but specifically because org.jboss.as.remoting module brings in fairly large dependency tree. > In the EJB subsystem there's deployment descriptor parsing that isn't limited to any particular subset of the EJB3 resource tree and that requires AbstractOutboundConnectionService, and hence the org.jboss.as.remoting module. > Better if that code uses an interface from wildfly-network so there is no hard dependency on org.jboss.as.remoting from the root ejb subsystem resource. If the deployment actually specified an outbound connection, then the connection resource would have to be configured for deployment to succeed, but that's already the case. > AbstractOutboundConnectionService doesn't require any dependencies not already needed by wildfly-network so creating the interface doesn't expand the footprint of its module. > Exposing the AbstractOutboundConnectionService impls via a capability is general best practice -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13423) Make ejb3 extension dependency on org.jboss.as.remoting optional

by Brian Stansberry (Jira)

Brian Stansberry created WFLY-13423: --------------------------------------- Summary: Make ejb3 extension dependency on org.jboss.as.remoting optional Key: WFLY-13423 URL: https://issues.redhat.com/browse/WFLY-13423 Project: WildFly Issue Type: Enhancement Components: EJB Reporter: Brian Stansberry Assignee: Yeray Borges Santana This is part of an overall effort to eliminate non-optional dependencies on the org.jboss.as.remoting module. Both because depending on extension modules has a code smell but specifically because the org.jboss.as.remoting module brings in fairly large dependency tree. The ejb3 subsystem has two general categories of use of the org.jboss.as.remoting module: 1) A number of child resources use it. The ResourceDefinition for those can use registerAdditionalRuntimePackages to record a hard dependency allowing the module.xml to make it optional. 2) AbstractOutboundConnectionService is used by deployment code not limited to particular child resource. But once WFCORE-4955 is done and integrated this can be replaced with use of the new interface from the org.jboss.as.network module with injection done using the capability. -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5220) Make @watch annotation to also work with oopath

by Mario Fusco (Jira)

[ https://issues.redhat.com/browse/DROOLS-5220?page=com.atlassian.jira.plug... ] Mario Fusco updated DROOLS-5220: -------------------------------- Sprint: (was: 2020 Week 16-18 (from Apr 13)) > Make @watch annotation to also work with oopath > ------------------------------------------------ > > Key: DROOLS-5220 > URL: https://issues.redhat.com/browse/DROOLS-5220 > Project: Drools > Issue Type: Bug > Reporter: Mario Fusco > Assignee: Mario Fusco > Priority: Major > > Property reactivity is currently working on oopath as demostrated by this test case: > {code} > @Test > public void testPropertyReactivityWithOOPath() { > String str = > "import " + Person.class.getCanonicalName() + ";" + > "import " + AdultUnit.class.getCanonicalName() + "\n" + > "rule Adult @Unit( AdultUnit.class ) when\n" + > " $p : /persons[name == \"Mario\"]\n" + > "then\n" + > " modify($p) { setAge($p.getAge()+1) };\n" + > "end\n"; > KieContainer kieContainer = getKieContainer( null, str ); > RuleUnitExecutor executor = RuleUnitExecutor.newRuleUnitExecutor( kieContainer ); > Person mario = new Person( "Mario", 45 ); > Person sofia = new Person( "Sofia", 8 ); > DataSource<Person> persons = DataSource.create( mario, sofia ); > AdultUnit unit = new AdultUnit(persons); > assertEquals(1, executor.run( unit ) ); > assertEquals(46, mario.getAge() ); > } > {code} > Conversely what it is not working (it doesn't compile at all) is the use of the @watch annotation like in > {code} > @Test > public void testPropertyReactivityWithOOPathAndWatch() { > String str = > "import " + Person.class.getCanonicalName() + ";" + > "import " + AdultUnit.class.getCanonicalName() + "\n" + > "rule Adult @Unit( AdultUnit.class ) when\n" + > " $p : /persons[$age : age, name == \"Mario\"] @watch( !age )\n" + > "then\n" + > " modify($p) { setAge($age+1) };\n" + > "end\n"; > KieContainer kieContainer = getKieContainer( null, str ); > RuleUnitExecutor executor = RuleUnitExecutor.newRuleUnitExecutor( kieContainer ); > Person mario = new Person( "Mario", 45 ); > Person sofia = new Person( "Sofia", 8 ); > DataSource<Person> persons = DataSource.create( mario, sofia ); > AdultUnit unit = new AdultUnit(persons); > assertEquals(1, executor.run( unit ) ); > assertEquals(46, mario.getAge() ); > } > {code} > Of course this can work only on a one-level oopath. It has to be decided what to do (trigger a compile time error?) when trying to use that annotation on a oopath made of 2 or more chunks. -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 11 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira May 2020