[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)
5 years, 4 months
[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)
5 years, 5 months
[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)
5 years, 5 months
[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)
5 years, 5 months
[JBoss JIRA] (WFLY-13422) Make org.jboss.as.remoting optional from naming extension module; others too if possible
by Brian Stansberry (Jira)
[ https://issues.redhat.com/browse/WFLY-13422?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFLY-13422:
------------------------------------
Summary: Make org.jboss.as.remoting optional from naming extension module; others too if possible (was: Make org.jboss.as.remoting optional; others too if possible)
> Make org.jboss.as.remoting optional from naming extension module; others too if possible
> ----------------------------------------------------------------------------------------
>
> Key: WFLY-13422
> URL: https://issues.redhat.com/browse/WFLY-13422
> Project: WildFly
> Issue Type: Enhancement
> Components: Naming
> Reporter: Brian Stansberry
> Assignee: Yeray Borges Santana
> Priority: Major
>
> The org.jboss.as.naming module's dependency on org.jboss.as.remoting is only needed if the "service=remote-naming" child resource is used. So it should be made optional with RemoteNamingResourceDefinition registering an additional package.
> 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.
> I believe there may be other module dependencies that could be made optional as part of this same work, e.g. org.jboss.remoting and org.wildfly.http-client.naming. Maybe others.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 5 months
[JBoss JIRA] (WFLY-13422) Make org.jboss.as.remoting optional; others too if possible
by Brian Stansberry (Jira)
Brian Stansberry created WFLY-13422:
---------------------------------------
Summary: Make org.jboss.as.remoting optional; others too if possible
Key: WFLY-13422
URL: https://issues.redhat.com/browse/WFLY-13422
Project: WildFly
Issue Type: Enhancement
Components: Naming
Reporter: Brian Stansberry
Assignee: Yeray Borges Santana
The org.jboss.as.naming module's dependency on org.jboss.as.remoting is only needed if the "service=remote-naming" child resource is used. So it should be made optional with RemoteNamingResourceDefinition registering an additional package.
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.
I believe there may be other module dependencies that could be made optional as part of this same work, e.g. org.jboss.remoting and org.wildfly.http-client.naming. Maybe others.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 5 months
[JBoss JIRA] (WFCORE-4955) Create a wildfly-network OutboundConnection interface from AbstractOutboundConnectionService; expose via capabilities
by Brian Stansberry (Jira)
Brian Stansberry created WFCORE-4955:
----------------------------------------
Summary: 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: Brian Stansberry
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)
5 years, 5 months