[JBoss JIRA] (WFLY-10837) IIOP subsystem requires port binding to be defined which was not necessary in prior WFLY versions
by Petr Kremensky (Jira)
[ https://issues.jboss.org/browse/WFLY-10837?page=com.atlassian.jira.plugin... ]
Petr Kremensky edited comment on WFLY-10837 at 10/11/18 4:06 AM:
-----------------------------------------------------------------
[~tomekadamski] This is what start/write property/stop does with iiop-openjdk subsystem on the source server, maybe this is what breaks the transformation.
{code:diff}
<subsystem xmlns="urn:jboss:domain:iiop-openjdk:1.0">
- <orb socket-binding="iiop" ssl-socket-binding="iiop-ssl"/>
<initializers transactions="spec" security="identity"/>
</subsystem>
{code}
was (Author: pkremens):
[~tomekadamski] This is what start/write property/stop does with iiop-openjdk subsystem on the source server, maybe this is breaks the transformation.
{code:diff}
<subsystem xmlns="urn:jboss:domain:iiop-openjdk:1.0">
- <orb socket-binding="iiop" ssl-socket-binding="iiop-ssl"/>
<initializers transactions="spec" security="identity"/>
</subsystem>
{code}
> IIOP subsystem requires port binding to be defined which was not necessary in prior WFLY versions
> -------------------------------------------------------------------------------------------------
>
> Key: WFLY-10837
> URL: https://issues.jboss.org/browse/WFLY-10837
> Project: WildFly
> Issue Type: Bug
> Components: IIOP
> Reporter: Ondra Chaloupka
> Assignee: Tomasz Adamski
> Priority: Blocker
> Fix For: 14.0.0.Final
>
>
> If the {{standalone-*.xml}} configuration defines to use IIOP subsystem but it does not defines the port binding element
> {code}
> <orb socket-binding="iiop"/>
> {code}
> The server starts with error
> {code}
> ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC000001: Failed to start service jboss.iiop-openjdk.orb-service: org.jboss.msc.service.StartException in service jboss.iiop-openjdk.orb-service: java.lang.IllegalStateException: WFLYIIOP0115: No IIOP socket bindings have been configured
> at org.wildfly.iiop.openjdk.service.CorbaORBService.start(CorbaORBService.java:150)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1736)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1698)
> at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1556)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.IllegalStateException: WFLYIIOP0115: No IIOP socket bindings have been configured
> at org.wildfly.iiop.openjdk.service.CorbaORBService.start(CorbaORBService.java:109)
> ... 8 more
> {code}
> The attribute of the {{socket-binding}} in the model is not defined as {{required}}.
> {code}
> "socket-binding" => {
> "type" => STRING,
> "description" => "The name of the socket binding configuration that specifies the ORB port.",
> "attribute-group" => "orb",
> "expressions-allowed" => false,
> "required" => false,
> "nillable" => true,
> "min-length" => 1L,
> "max-length" => 2147483647L,
> "access-constraints" => {"sensitive" => {"socket-binding-ref" => {"type" => "core"}}},
> "access-type" => "read-write",
> "storage" => "configuration",
> "restart-required" => "all-services"
> }
> {code}
> Up to that declaring the iiop socket binding was not necessary in WildFly 13.0.0.Final. Could that be a backward compatibility problem too?
> Up to that
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (DROOLS-3108) Allow KieScanner to work with a plain file system
by Mario Fusco (Jira)
Mario Fusco created DROOLS-3108:
-----------------------------------
Summary: Allow KieScanner to work with a plain file system
Key: DROOLS-3108
URL: https://issues.jboss.org/browse/DROOLS-3108
Project: Drools
Issue Type: Enhancement
Components: core engine
Reporter: Mario Fusco
Assignee: Mario Fusco
Many users need incremental compilation but doesn't want an instance of maven installed in production. For this reason it is required to allow the KieScanner to also work on a plain file system.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (DROOLS-3107) Provide optional lazy segment memories creation
by Mario Fusco (Jira)
Mario Fusco created DROOLS-3107:
-----------------------------------
Summary: Provide optional lazy segment memories creation
Key: DROOLS-3107
URL: https://issues.jboss.org/browse/DROOLS-3107
Project: Drools
Issue Type: Enhancement
Components: core engine
Reporter: Mario Fusco
Assignee: Mario Fusco
The execution of the very first ksession created from a kbase is (much) slower than the subsequent ones, because of lazy segment memories creation. It is requested to provide an option to eagerly create them at kbase creation time.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (WFLY-11084) inter-app quickstart does not deploy (WildFly 14.0.1)
by Bartosz Baranowski (Jira)
[ https://issues.jboss.org/browse/WFLY-11084?page=com.atlassian.jira.plugin... ]
Bartosz Baranowski commented on WFLY-11084:
-------------------------------------------
Thought EJB lookup was a lazy one? Anyway, if this is the case PR should be rejected and this issue addressed in QS.
> inter-app quickstart does not deploy (WildFly 14.0.1)
> -----------------------------------------------------
>
> Key: WFLY-11084
> URL: https://issues.jboss.org/browse/WFLY-11084
> Project: WildFly
> Issue Type: Bug
> Reporter: Kevin Eagles
> Assignee: Bartosz Baranowski
> Priority: Critical
>
> Using Wildfly 14.0.1.Final
> When deploying inter-app-appA.war, Wildfly complains about the EJB lookup for:
> @ejb(lookup = "java:global/inter-app-appB/BarImpl!org.jboss.as.quickstarts.interapp.shared.Bar")
> Likewise, when deploying inter-app-appB.war, Wildfly complains about the EJB lookup for:
> @ejb(lookup = "java:global/inter-app-appA/FooImpl!org.jboss.as.quickstarts.interapp.shared.Foo")
> To reproduce, from the inter-app quickstart:
> mvn install wildfly:deploy
> Can also reproduce by just doing an mvn install, then manually deploying the jar, then appA, then appB using the HAL Management Console.
> {noformat}
> ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0013: Operation ("add") failed - address: ([("deployment" => "inter-app-appA.war")]) - failure description: {
> "WFLYCTL0412: Required services that are not installed:" => ["jboss.naming.context.java.global.inter-app-appB.\"BarImpl!org.jboss.as.quickstarts.interapp.shared.Bar\""],
> "WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.naming.context.java.module.inter-app-appA.inter-app-appA.env.\"org.jboss.as.quickstarts.interapp.appA.Imports\".bar is missing [jboss.naming.context.java.global.inter-app-appB.\"BarImpl!org.jboss.as.quickstarts.interapp.shared.Bar\"]"]
> }
> 09:56:51,014 ERROR [org.jboss.as.server] (management-handler-thread - 1) WFLYSRV0021: Deploy of deployment "inter-app-appA.war" was rolled back with the following failure message:
> {
> "WFLYCTL0412: Required services that are not installed:" => ["jboss.naming.context.java.global.inter-app-appB.\"BarImpl!org.jboss.as.quickstarts.interapp.shared.Bar\""],
> "WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.naming.context.java.module.inter-app-appA.inter-app-appA.env.\"org.jboss.as.quickstarts.interapp.appA.Imports\".bar is missing [jboss.naming.context.java.global.inter-app-appB.\"BarImpl!org.jboss.as.quickstarts.interapp.shared.Bar\"]"]
> }
> {noformat}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (WFLY-10837) IIOP subsystem requires port binding to be defined which was not necessary in prior WFLY versions
by Petr Kremensky (Jira)
[ https://issues.jboss.org/browse/WFLY-10837?page=com.atlassian.jira.plugin... ]
Petr Kremensky commented on WFLY-10837:
---------------------------------------
[~tomekadamski] This is what start/write property/stop does with iiop-openjdk subsystem on the source server, maybe this is breaks the transformation.
{code:diff}
<subsystem xmlns="urn:jboss:domain:iiop-openjdk:1.0">
- <orb socket-binding="iiop" ssl-socket-binding="iiop-ssl"/>
<initializers transactions="spec" security="identity"/>
</subsystem>
{code}
> IIOP subsystem requires port binding to be defined which was not necessary in prior WFLY versions
> -------------------------------------------------------------------------------------------------
>
> Key: WFLY-10837
> URL: https://issues.jboss.org/browse/WFLY-10837
> Project: WildFly
> Issue Type: Bug
> Components: IIOP
> Reporter: Ondra Chaloupka
> Assignee: Tomasz Adamski
> Priority: Blocker
> Fix For: 14.0.0.Final
>
>
> If the {{standalone-*.xml}} configuration defines to use IIOP subsystem but it does not defines the port binding element
> {code}
> <orb socket-binding="iiop"/>
> {code}
> The server starts with error
> {code}
> ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC000001: Failed to start service jboss.iiop-openjdk.orb-service: org.jboss.msc.service.StartException in service jboss.iiop-openjdk.orb-service: java.lang.IllegalStateException: WFLYIIOP0115: No IIOP socket bindings have been configured
> at org.wildfly.iiop.openjdk.service.CorbaORBService.start(CorbaORBService.java:150)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1736)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1698)
> at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1556)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.IllegalStateException: WFLYIIOP0115: No IIOP socket bindings have been configured
> at org.wildfly.iiop.openjdk.service.CorbaORBService.start(CorbaORBService.java:109)
> ... 8 more
> {code}
> The attribute of the {{socket-binding}} in the model is not defined as {{required}}.
> {code}
> "socket-binding" => {
> "type" => STRING,
> "description" => "The name of the socket binding configuration that specifies the ORB port.",
> "attribute-group" => "orb",
> "expressions-allowed" => false,
> "required" => false,
> "nillable" => true,
> "min-length" => 1L,
> "max-length" => 2147483647L,
> "access-constraints" => {"sensitive" => {"socket-binding-ref" => {"type" => "core"}}},
> "access-type" => "read-write",
> "storage" => "configuration",
> "restart-required" => "all-services"
> }
> {code}
> Up to that declaring the iiop socket binding was not necessary in WildFly 13.0.0.Final. Could that be a backward compatibility problem too?
> Up to that
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (WFLY-10837) IIOP subsystem requires port binding to be defined which was not necessary in prior WFLY versions
by Petr Kremensky (Jira)
[ https://issues.jboss.org/browse/WFLY-10837?page=com.atlassian.jira.plugin... ]
Petr Kremensky commented on WFLY-10837:
---------------------------------------
[~tomekadamski] Did you try to run the [reproducer|https://issues.jboss.org/browse/WFLY-10837?focusedCommentId=13... (I've updated it 7.2.0.CD14.CR1 -> 7.2.0.CD14.CR2)
The version of the subsystem is before target server is started is
{noformat}
<subsystem xmlns="urn:jboss:domain:iiop-openjdk:1.0">
<initializers transactions="spec" security="identity"/>
</subsystem>
{noformat}
so it seems to me that transformer doesn't do its job (I cannot see any transformation of iiop-openjdk after I start the target server with legacy config).
> IIOP subsystem requires port binding to be defined which was not necessary in prior WFLY versions
> -------------------------------------------------------------------------------------------------
>
> Key: WFLY-10837
> URL: https://issues.jboss.org/browse/WFLY-10837
> Project: WildFly
> Issue Type: Bug
> Components: IIOP
> Reporter: Ondra Chaloupka
> Assignee: Tomasz Adamski
> Priority: Blocker
> Fix For: 14.0.0.Final
>
>
> If the {{standalone-*.xml}} configuration defines to use IIOP subsystem but it does not defines the port binding element
> {code}
> <orb socket-binding="iiop"/>
> {code}
> The server starts with error
> {code}
> ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC000001: Failed to start service jboss.iiop-openjdk.orb-service: org.jboss.msc.service.StartException in service jboss.iiop-openjdk.orb-service: java.lang.IllegalStateException: WFLYIIOP0115: No IIOP socket bindings have been configured
> at org.wildfly.iiop.openjdk.service.CorbaORBService.start(CorbaORBService.java:150)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1736)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1698)
> at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1556)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.IllegalStateException: WFLYIIOP0115: No IIOP socket bindings have been configured
> at org.wildfly.iiop.openjdk.service.CorbaORBService.start(CorbaORBService.java:109)
> ... 8 more
> {code}
> The attribute of the {{socket-binding}} in the model is not defined as {{required}}.
> {code}
> "socket-binding" => {
> "type" => STRING,
> "description" => "The name of the socket binding configuration that specifies the ORB port.",
> "attribute-group" => "orb",
> "expressions-allowed" => false,
> "required" => false,
> "nillable" => true,
> "min-length" => 1L,
> "max-length" => 2147483647L,
> "access-constraints" => {"sensitive" => {"socket-binding-ref" => {"type" => "core"}}},
> "access-type" => "read-write",
> "storage" => "configuration",
> "restart-required" => "all-services"
> }
> {code}
> Up to that declaring the iiop socket binding was not necessary in WildFly 13.0.0.Final. Could that be a backward compatibility problem too?
> Up to that
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (WFLY-11084) inter-app quickstart does not deploy (WildFly 14.0.1)
by Brian Stansberry (Jira)
[ https://issues.jboss.org/browse/WFLY-11084?page=com.atlassian.jira.plugin... ]
Brian Stansberry commented on WFLY-11084:
-----------------------------------------
I don't see the bug here. It seems to me that quickstart is broken and it was a bug that it worked.
What the quickstart tells you to do is mvn wildfly:deploy on the top-level module, which results in three separate deploys as the child modules are built:
1) shared
2) appA
3) appB
If the server is behaving correctly, after each step in that sequence you'll either having everything working or the step would fail.
With WF 12 if you build the quickstart, then deploy inter-app-shared.jar and inter-app-appA.war and then access http://localhost:8080/inter-app-appA, it fails:
{code}
javax.servlet.ServletException
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:671)
at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:74)
at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
at io.undertow.servlet.handlers.ServletChain$1.handleRequest(ServletChain.java:67)
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.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
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.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
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:1526)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1526)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1526)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1526)
at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:360)
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:830)
at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.lang.NullPointerException
at org.jboss.weld.bean.builtin.ee.EEResourceProducerField.create(EEResourceProducerField.java:143)
at org.jboss.weld.contexts.unbound.DependentContextImpl.get(DependentContextImpl.java:70)
at org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.get(ContextualInstanceStrategy.java:100)
at org.jboss.weld.bean.ContextualInstance.get(ContextualInstance.java:50)
at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:689)
at org.jboss.weld.manager.BeanManagerImpl.getInjectableReference(BeanManagerImpl.java:789)
at org.jboss.weld.injection.FieldInjectionPoint.inject(FieldInjectionPoint.java:92)
at org.jboss.weld.util.Beans.injectBoundFields(Beans.java:335)
at org.jboss.weld.util.Beans.injectFieldsAndInitializers(Beans.java:346)
at org.jboss.weld.injection.producer.ResourceInjector$1.proceed(ResourceInjector.java:69)
at org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:48)
at org.jboss.weld.injection.producer.ResourceInjector.inject(ResourceInjector.java:71)
at org.jboss.weld.injection.producer.BasicInjectionTarget.inject(BasicInjectionTarget.java:117)
at org.jboss.weld.bean.ManagedBean.create(ManagedBean.java:159)
at org.jboss.weld.contexts.unbound.DependentContextImpl.get(DependentContextImpl.java:70)
at org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.get(ContextualInstanceStrategy.java:100)
at org.jboss.weld.bean.ContextualInstance.get(ContextualInstance.java:50)
at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:689)
at org.jboss.weld.module.web.el.AbstractWeldELResolver.lookup(AbstractWeldELResolver.java:120)
at org.jboss.weld.module.web.el.AbstractWeldELResolver.getValue(AbstractWeldELResolver.java:90)
at org.jboss.as.jsf.injection.weld.ForwardingELResolver.getValue(ForwardingELResolver.java:46)
at javax.el.CompositeELResolver.getValue(CompositeELResolver.java:188)
at com.sun.faces.el.DemuxCompositeELResolver._getValue(DemuxCompositeELResolver.java:176)
at com.sun.faces.el.DemuxCompositeELResolver.getValue(DemuxCompositeELResolver.java:203)
at com.sun.el.parser.AstIdentifier.getValue(AstIdentifier.java:116)
at com.sun.el.parser.AstValue.getBase(AstValue.java:150)
at com.sun.el.parser.AstValue.getValue(AstValue.java:199)
at com.sun.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:226)
at org.jboss.weld.module.web.el.WeldValueExpression.getValue(WeldValueExpression.java:50)
at org.jboss.weld.module.web.el.WeldValueExpression.getValue(WeldValueExpression.java:50)
at com.sun.faces.facelets.el.TagValueExpression.getValue(TagValueExpression.java:109)
at javax.faces.component.ComponentStateHelper.eval(ComponentStateHelper.java:194)
at javax.faces.component.ComponentStateHelper.eval(ComponentStateHelper.java:182)
at javax.faces.component.UIOutput.getValue(UIOutput.java:174)
at javax.faces.component.UIInput.getValue(UIInput.java:293)
at com.sun.faces.renderkit.html_basic.HtmlBasicInputRenderer.getValue(HtmlBasicInputRenderer.java:205)
at com.sun.faces.renderkit.html_basic.HtmlBasicRenderer.getCurrentValue(HtmlBasicRenderer.java:355)
at com.sun.faces.renderkit.html_basic.HtmlBasicRenderer.encodeEnd(HtmlBasicRenderer.java:164)
at javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:920)
at com.sun.faces.renderkit.html_basic.HtmlBasicRenderer.encodeRecursive(HtmlBasicRenderer.java:312)
at com.sun.faces.renderkit.html_basic.GridRenderer.renderRow(GridRenderer.java:185)
at com.sun.faces.renderkit.html_basic.GridRenderer.encodeChildren(GridRenderer.java:129)
at javax.faces.component.UIComponentBase.encodeChildren(UIComponentBase.java:890)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1856)
at javax.faces.render.Renderer.encodeChildren(Renderer.java:176)
at javax.faces.component.UIComponentBase.encodeChildren(UIComponentBase.java:890)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1856)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1859)
at com.sun.faces.application.view.FaceletViewHandlingStrategy.renderView(FaceletViewHandlingStrategy.java:458)
at com.sun.faces.application.view.MultiViewHandler.renderView(MultiViewHandler.java:134)
at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:337)
at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:337)
at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:120)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:219)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:659)
... 41 more
{code}
So, appA was broken (missing dependency) but the appserver failed to detect this and allowed it to deploy, despite having the annotation data necessary to detect the problem.
Similarly, if I then deploy appB, appA starts to work. But then I should not be able to undeploy appB (since that would break appA). But with WF 12, I can. Or, I could leave appB deployed and undeploy appA, and then appB is broken.
If a user wanted this kind of setup to work they would need to deploy/undeploy appA and appB together in a batch.
> inter-app quickstart does not deploy (WildFly 14.0.1)
> -----------------------------------------------------
>
> Key: WFLY-11084
> URL: https://issues.jboss.org/browse/WFLY-11084
> Project: WildFly
> Issue Type: Bug
> Reporter: Kevin Eagles
> Assignee: Bartosz Baranowski
> Priority: Critical
>
> Using Wildfly 14.0.1.Final
> When deploying inter-app-appA.war, Wildfly complains about the EJB lookup for:
> @ejb(lookup = "java:global/inter-app-appB/BarImpl!org.jboss.as.quickstarts.interapp.shared.Bar")
> Likewise, when deploying inter-app-appB.war, Wildfly complains about the EJB lookup for:
> @ejb(lookup = "java:global/inter-app-appA/FooImpl!org.jboss.as.quickstarts.interapp.shared.Foo")
> To reproduce, from the inter-app quickstart:
> mvn install wildfly:deploy
> Can also reproduce by just doing an mvn install, then manually deploying the jar, then appA, then appB using the HAL Management Console.
> {noformat}
> ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0013: Operation ("add") failed - address: ([("deployment" => "inter-app-appA.war")]) - failure description: {
> "WFLYCTL0412: Required services that are not installed:" => ["jboss.naming.context.java.global.inter-app-appB.\"BarImpl!org.jboss.as.quickstarts.interapp.shared.Bar\""],
> "WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.naming.context.java.module.inter-app-appA.inter-app-appA.env.\"org.jboss.as.quickstarts.interapp.appA.Imports\".bar is missing [jboss.naming.context.java.global.inter-app-appB.\"BarImpl!org.jboss.as.quickstarts.interapp.shared.Bar\"]"]
> }
> 09:56:51,014 ERROR [org.jboss.as.server] (management-handler-thread - 1) WFLYSRV0021: Deploy of deployment "inter-app-appA.war" was rolled back with the following failure message:
> {
> "WFLYCTL0412: Required services that are not installed:" => ["jboss.naming.context.java.global.inter-app-appB.\"BarImpl!org.jboss.as.quickstarts.interapp.shared.Bar\""],
> "WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.naming.context.java.module.inter-app-appA.inter-app-appA.env.\"org.jboss.as.quickstarts.interapp.appA.Imports\".bar is missing [jboss.naming.context.java.global.inter-app-appB.\"BarImpl!org.jboss.as.quickstarts.interapp.shared.Bar\"]"]
> }
> {noformat}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (WFLY-11157) Remove unused module dependencies on org.jboss.as.threads
by Brian Stansberry (Jira)
[ https://issues.jboss.org/browse/WFLY-11157?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFLY-11157:
------------------------------------
Description:
A number of modules depend on org.jboss.as.threads but don't use it.
{code}
$ git grep org.jboss.as.threads | grep module.xml
feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/clustering/infinispan/main/module.xml: <module name="org.jboss.as.threads"/>
feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/connector/main/module.xml: <module name="org.jboss.as.threads"/>
feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/ejb3/main/module.xml: <module name="org.jboss.as.threads"/>
feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/jdr/main/module.xml: <module name="org.jboss.as.threads"/>
feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/jpa/main/module.xml: <module name="org.jboss.as.threads"/>
feature-pack/src/main/resources/modules/system/layers/base/org/wildfly/extension/batch/jberet/main/module.xml: <module name="org.jboss.as.threads"/>
servlet-feature-pack/src/main/resources/modules/system/layers/base/org/wildfly/extension/undertow/main/module.xml: <module name="org.jboss.as.threads"/>
{code}
The connector, ejb3 and batch-jberet modules actually use org.jboss.as.threads; the others do not.
was:
A number of modules depend on org.jboss.as.threads but don't use it.
{code}
$ git grep org.jboss.as.threads | grep module.xml
feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/clustering/infinispan/main/module.xml: <module name="org.jboss.as.threads"/>
feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/connector/main/module.xml: <module name="org.jboss.as.threads"/>
feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/ejb3/main/module.xml: <module name="org.jboss.as.threads"/>
feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/jdr/main/module.xml: <module name="org.jboss.as.threads"/>
feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/jpa/main/module.xml: <module name="org.jboss.as.threads"/>
feature-pack/src/main/resources/modules/system/layers/base/org/wildfly/extension/batch/jberet/main/module.xml: <module name="org.jboss.as.threads"/>
servlet-feature-pack/src/main/resources/modules/system/layers/base/org/wildfly/extension/undertow/main/module.xml: <module name="org.jboss.as.threads"/>
{code}
The connector and batch-jberet modules actually use org.jboss.as.threads; the others do not.
> Remove unused module dependencies on org.jboss.as.threads
> ---------------------------------------------------------
>
> Key: WFLY-11157
> URL: https://issues.jboss.org/browse/WFLY-11157
> Project: WildFly
> Issue Type: Task
> Components: Clustering, JDR, JPA / Hibernate, Web (Undertow)
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Priority: Minor
>
> A number of modules depend on org.jboss.as.threads but don't use it.
> {code}
> $ git grep org.jboss.as.threads | grep module.xml
> feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/clustering/infinispan/main/module.xml: <module name="org.jboss.as.threads"/>
> feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/connector/main/module.xml: <module name="org.jboss.as.threads"/>
> feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/ejb3/main/module.xml: <module name="org.jboss.as.threads"/>
> feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/jdr/main/module.xml: <module name="org.jboss.as.threads"/>
> feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/jpa/main/module.xml: <module name="org.jboss.as.threads"/>
> feature-pack/src/main/resources/modules/system/layers/base/org/wildfly/extension/batch/jberet/main/module.xml: <module name="org.jboss.as.threads"/>
> servlet-feature-pack/src/main/resources/modules/system/layers/base/org/wildfly/extension/undertow/main/module.xml: <module name="org.jboss.as.threads"/>
> {code}
> The connector, ejb3 and batch-jberet modules actually use org.jboss.as.threads; the others do not.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months