[JBoss JIRA] (DROOLS-2638) Enumerations drop quotes when double quotes are used
by Jozef Marko (Jira)
[ https://issues.redhat.com/browse/DROOLS-2638?page=com.atlassian.jira.plug... ]
Jozef Marko closed DROOLS-2638.
-------------------------------
Resolution: Won't Fix
No progress over two years and no customer ticked linked. Closing as won't fix.
> Enumerations drop quotes when double quotes are used
> ----------------------------------------------------
>
> Key: DROOLS-2638
> URL: https://issues.redhat.com/browse/DROOLS-2638
> Project: Drools
> Issue Type: Bug
> Components: Enumerations Editor
> Affects Versions: 7.42.0.Final
> Reporter: Toni Rikkola
> Assignee: Toni Rikkola
> Priority: Major
> Labels: drools-tools
>
> https://github.com/kiegroup/kie-wb-common/pull/1890
> @Rikkola The issue reported in the JIRA seem to be resolved; however I noticed (given an enumeration defined as Person.name: ['a', '"b, c"', 'd']) that the generated DRL is Person( name == "b, c" ) whereas should it be Person( name == "\"b, c\"" )? Closing and re-opening the decision table keeps the correct values selected in the table. I also tried defining the BRL fragment to use a literal value for the enumeration and this gave the same results (DRL possibly incorrect, but re-opening and editing the column was OK).
> I also checked Guided Rules and the DRL is equally wrong however re-opening the rule also led to the wrong enumeration value being selected in the editor (it selected the first option by default) and the DRL showing the same (i.e. I set it to "b, c" and re-opening the file selected a).
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 2 months
[JBoss JIRA] (WFCORE-5073) When using Galleon to provision Wildfly with core-server+managment layers, the availability of the Admin console is wrongly advertised to the user
by Fabio Burzigotti (Jira)
[ https://issues.redhat.com/browse/WFCORE-5073?page=com.atlassian.jira.plug... ]
Fabio Burzigotti commented on WFCORE-5073:
------------------------------------------
Thanks [~brian.stansberry] for moving the issue to the right project and [~dlofthouse] for raising that point.
> When using Galleon to provision Wildfly with core-server+managment layers, the availability of the Admin console is wrongly advertised to the user
> --------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-5073
> URL: https://issues.redhat.com/browse/WFCORE-5073
> Project: WildFly Core
> Issue Type: Bug
> Components: Management
> Affects Versions: 12.0.2.Final, 13.0.0.Beta2
> Reporter: Fabio Burzigotti
> Assignee: Brian Stansberry
> Priority: Major
>
> When using Galleon to provision a Wildfly instance which would include just the {{core-server}} and {{managment}} layers, the LOG will trace the following lines:
> {code}
> ...
> 15:38:17,219 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Full 20.0.1.Final (WildFly Core 12.0.3.Final) started in 1625ms - Started 86 of 89 services (27 services are lazy, passive or on-demand)
> 15:38:17,221 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://127.0.0.1:9990/management
> 15:38:17,221 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://127.0.0.1:9990
> {code}
> This is a wrong message for the end user because the managment interface will be available at the reported URL but the Admin console won't, returning a HTTP 404 status code.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 2 months
[JBoss JIRA] (WFLY-13719) Error deploying EJB in WildFly when using @EJB
by Cheng Fang (Jira)
[ https://issues.redhat.com/browse/WFLY-13719?page=com.atlassian.jira.plugi... ]
Cheng Fang commented on WFLY-13719:
-----------------------------------
[~soul2zimate] Your draft looks good. I've just checked a few docs-related fields in this issue (affects release notes, migration, etc)
> Error deploying EJB in WildFly when using @EJB
> ----------------------------------------------
>
> Key: WFLY-13719
> URL: https://issues.redhat.com/browse/WFLY-13719
> Project: WildFly
> Issue Type: Bug
> Components: EE, EJB
> Affects Versions: 20.0.1.Final
> Reporter: Chao Wang
> Assignee: Chao Wang
> Priority: Major
> Attachments: reproducer.zip
>
>
> The following example does *not* get deployed on Wildfly 20.0.1.Final (since WFLY 13.0.0.Final):
> ~~~
> public class PleaseIgnoreMeThanks
> { @EJB private NonExistentEjbExampleLocal nonExistentEjbExample; }
> ~~~
> The issue seems to be on the @EJB annotation.
>
> Generated error:
> {code:xml}
> 10:19:19,025 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC000001: Failed to start service jboss.deployment.unit."ejb-in-war.war".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.unit."ejb-in-war.war".INSTALL: WFLYSRV0153: Failed to process phase INSTALL of deployment "ejb-in-war.war"
> at org.jboss.as.server@12.0.3.Final//org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:189)
> at org.jboss.msc@1.4.11.Final//org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1739)
> at org.jboss.msc@1.4.11.Final//org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1701)
> at org.jboss.msc@1.4.11.Final//org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1559)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1363)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: WFLYEJB0406: No EJB found with interface of type 'org.jboss.as.quickstarts.ejbTimer.NonExistentEjbExampleLocal' for binding org.jboss.as.quickstarts.ejbTimer.PleaseIgnoreMeThanks/nonExistentEjbExample
> at org.jboss.as.ejb3@20.0.1.Final//org.jboss.as.ejb3.deployment.processors.EjbInjectionSource.getResourceValue(EjbInjectionSource.java:90)
> at org.jboss.as.ee@20.0.1.Final//org.jboss.as.ee.component.deployers.ModuleJndiBindingProcessor.addJndiBinding(ModuleJndiBindingProcessor.java:269)
> at org.jboss.as.ee@20.0.1.Final//org.jboss.as.ee.component.deployers.ModuleJndiBindingProcessor.deploy(ModuleJndiBindingProcessor.java:200)
> at org.jboss.as.server@12.0.3.Final//org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:182)
> ... 8 more
> ~~{code}
>
> !moz-extension://4f9dc55f-98eb-44f6-97f9-1c9d85f3a188/icons/logo.png!
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 2 months
[JBoss JIRA] (WFLY-13719) Error deploying EJB in WildFly when using @EJB
by Cheng Fang (Jira)
[ https://issues.redhat.com/browse/WFLY-13719?page=com.atlassian.jira.plugi... ]
Cheng Fang updated WFLY-13719:
------------------------------
Affects: Documentation (Ref Guide, User Guide, etc.),Release Notes,Migration
> Error deploying EJB in WildFly when using @EJB
> ----------------------------------------------
>
> Key: WFLY-13719
> URL: https://issues.redhat.com/browse/WFLY-13719
> Project: WildFly
> Issue Type: Bug
> Components: EE, EJB
> Affects Versions: 20.0.1.Final
> Reporter: Chao Wang
> Assignee: Chao Wang
> Priority: Major
> Attachments: reproducer.zip
>
>
> The following example does *not* get deployed on Wildfly 20.0.1.Final (since WFLY 13.0.0.Final):
> ~~~
> public class PleaseIgnoreMeThanks
> { @EJB private NonExistentEjbExampleLocal nonExistentEjbExample; }
> ~~~
> The issue seems to be on the @EJB annotation.
>
> Generated error:
> {code:xml}
> 10:19:19,025 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC000001: Failed to start service jboss.deployment.unit."ejb-in-war.war".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.unit."ejb-in-war.war".INSTALL: WFLYSRV0153: Failed to process phase INSTALL of deployment "ejb-in-war.war"
> at org.jboss.as.server@12.0.3.Final//org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:189)
> at org.jboss.msc@1.4.11.Final//org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1739)
> at org.jboss.msc@1.4.11.Final//org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1701)
> at org.jboss.msc@1.4.11.Final//org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1559)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1363)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: WFLYEJB0406: No EJB found with interface of type 'org.jboss.as.quickstarts.ejbTimer.NonExistentEjbExampleLocal' for binding org.jboss.as.quickstarts.ejbTimer.PleaseIgnoreMeThanks/nonExistentEjbExample
> at org.jboss.as.ejb3@20.0.1.Final//org.jboss.as.ejb3.deployment.processors.EjbInjectionSource.getResourceValue(EjbInjectionSource.java:90)
> at org.jboss.as.ee@20.0.1.Final//org.jboss.as.ee.component.deployers.ModuleJndiBindingProcessor.addJndiBinding(ModuleJndiBindingProcessor.java:269)
> at org.jboss.as.ee@20.0.1.Final//org.jboss.as.ee.component.deployers.ModuleJndiBindingProcessor.deploy(ModuleJndiBindingProcessor.java:200)
> at org.jboss.as.server@12.0.3.Final//org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:182)
> ... 8 more
> ~~{code}
>
> !moz-extension://4f9dc55f-98eb-44f6-97f9-1c9d85f3a188/icons/logo.png!
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 2 months
[JBoss JIRA] (WFLY-13736) [GSS](7.2.z) WFLYWELD0041: WeldContainer is not started when redeploying
by Stuart Douglas (Jira)
[ https://issues.redhat.com/browse/WFLY-13736?page=com.atlassian.jira.plugi... ]
Stuart Douglas reassigned WFLY-13736:
-------------------------------------
Assignee: Stuart Douglas (was: Bartosz Baranowski)
> [GSS](7.2.z) WFLYWELD0041: WeldContainer is not started when redeploying
> ------------------------------------------------------------------------
>
> Key: WFLY-13736
> URL: https://issues.redhat.com/browse/WFLY-13736
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Reporter: Stuart Douglas
> Assignee: Stuart Douglas
> Priority: Major
>
> Deploy 2 applications where:
> - api is a static module containing EJB Local Interface and transfer objects
> - app2.war has an EJB with a Local interface
> - app1.war has a Servlet that uses @EJB to inject the EJB in app2, it also has a CDI bean with @RequestScoped on it (But the CDI bean is not referenced by anything)
> Start JBoss
> touch app2.war to trigger redeployment and it will fail with the error below.
> It seems redeploying app2 triggers app1 to restart a service based on the logs.
> Note the error only occurs when the CDI bean in app1 has the @RequestScoped annotation
> {code}
> 14:26:38,290 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: JBoss EAP 7.2.6.GA (WildFly Core 6.0.21.Final-redhat-00001) started in 4056ms - Started 537 of 720 services (330 services are lazy, passive or on-demand)
> 14:26:43,309 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 73) WFLYUT0022: Unregistered web context: '/app1' from server 'default-server'
> 14:26:43,309 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 7) WFLYUT0022: Unregistered web context: '/app2' from server 'default-server'
> 14:26:43,310 INFO [Servlet] (ServerService Thread Pool -- 73) ***** DESTROY ******
> 14:26:43,353 INFO [org.jboss.as.server.deployment] (MSC service thread 1-7) WFLYSRV0028: Stopped deployment app2.war (runtime-name: app2.war) in 47ms
> 14:26:43,356 INFO [org.jboss.as.server.deployment] (MSC service thread 1-1) WFLYSRV0027: Starting deployment of "app2.war" (runtime-name: "app2.war")
> 14:26:43,410 INFO [org.jboss.weld.deployer] (MSC service thread 1-4) WFLYWELD0003: Processing weld deployment app2.war
> 14:26:43,428 INFO [org.jboss.as.ejb3.deployment] (MSC service thread 1-4) WFLYEJB0473: JNDI bindings for session bean named 'HelloEJB' in deployment unit 'deployment "app2.war"' are as follows:
> java:global/app2/HelloEJB!api.HelloLocal
> java:app/app2/HelloEJB!api.HelloLocal
> java:module/HelloEJB!api.HelloLocal
> ejb:/app2/HelloEJB!api.HelloLocal
> java:global/app2/HelloEJB
> java:app/app2/HelloEJB
> java:module/HelloEJB
> 14:26:43,479 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.deployment.unit."app1.war".component."org.jboss.weld.module.web.servlet.WeldInitialListener".WeldInstantiator: org.jboss.msc.service.StartException in service jboss.deployment.unit."app1.war".component."org.jboss.weld.module.web.servlet.WeldInitialListener".WeldInstantiator: Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1731)
> at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1559)
> 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:1364)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.IllegalStateException: WFLYWELD0041: WeldContainer is not started
> at org.jboss.as.weld.WeldBootstrapService.getBeanManager(WeldBootstrapService.java:185)
> at org.jboss.as.weld.injection.WeldComponentService.start(WeldComponentService.java:97)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1739)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1701)
> ... 6 more
> ...
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 2 months
[JBoss JIRA] (WFLY-13736) [GSS](7.2.z) WFLYWELD0041: WeldContainer is not started when redeploying
by Stuart Douglas (Jira)
[ https://issues.redhat.com/browse/WFLY-13736?page=com.atlassian.jira.plugi... ]
Stuart Douglas moved JBEAP-20035 to WFLY-13736:
-----------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-13736 (was: JBEAP-20035)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: CDI / Weld
(was: CDI / Weld)
Affects Version/s: (was: 7.2.6.GA)
Fix Version/s: (was: 7.2.10.GA)
> [GSS](7.2.z) WFLYWELD0041: WeldContainer is not started when redeploying
> ------------------------------------------------------------------------
>
> Key: WFLY-13736
> URL: https://issues.redhat.com/browse/WFLY-13736
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Reporter: Stuart Douglas
> Assignee: Bartosz Baranowski
> Priority: Major
>
> Deploy 2 applications where:
> - api is a static module containing EJB Local Interface and transfer objects
> - app2.war has an EJB with a Local interface
> - app1.war has a Servlet that uses @EJB to inject the EJB in app2, it also has a CDI bean with @RequestScoped on it (But the CDI bean is not referenced by anything)
> Start JBoss
> touch app2.war to trigger redeployment and it will fail with the error below.
> It seems redeploying app2 triggers app1 to restart a service based on the logs.
> Note the error only occurs when the CDI bean in app1 has the @RequestScoped annotation
> {code}
> 14:26:38,290 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: JBoss EAP 7.2.6.GA (WildFly Core 6.0.21.Final-redhat-00001) started in 4056ms - Started 537 of 720 services (330 services are lazy, passive or on-demand)
> 14:26:43,309 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 73) WFLYUT0022: Unregistered web context: '/app1' from server 'default-server'
> 14:26:43,309 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 7) WFLYUT0022: Unregistered web context: '/app2' from server 'default-server'
> 14:26:43,310 INFO [Servlet] (ServerService Thread Pool -- 73) ***** DESTROY ******
> 14:26:43,353 INFO [org.jboss.as.server.deployment] (MSC service thread 1-7) WFLYSRV0028: Stopped deployment app2.war (runtime-name: app2.war) in 47ms
> 14:26:43,356 INFO [org.jboss.as.server.deployment] (MSC service thread 1-1) WFLYSRV0027: Starting deployment of "app2.war" (runtime-name: "app2.war")
> 14:26:43,410 INFO [org.jboss.weld.deployer] (MSC service thread 1-4) WFLYWELD0003: Processing weld deployment app2.war
> 14:26:43,428 INFO [org.jboss.as.ejb3.deployment] (MSC service thread 1-4) WFLYEJB0473: JNDI bindings for session bean named 'HelloEJB' in deployment unit 'deployment "app2.war"' are as follows:
> java:global/app2/HelloEJB!api.HelloLocal
> java:app/app2/HelloEJB!api.HelloLocal
> java:module/HelloEJB!api.HelloLocal
> ejb:/app2/HelloEJB!api.HelloLocal
> java:global/app2/HelloEJB
> java:app/app2/HelloEJB
> java:module/HelloEJB
> 14:26:43,479 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.deployment.unit."app1.war".component."org.jboss.weld.module.web.servlet.WeldInitialListener".WeldInstantiator: org.jboss.msc.service.StartException in service jboss.deployment.unit."app1.war".component."org.jboss.weld.module.web.servlet.WeldInitialListener".WeldInstantiator: Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1731)
> at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1559)
> 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:1364)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.IllegalStateException: WFLYWELD0041: WeldContainer is not started
> at org.jboss.as.weld.WeldBootstrapService.getBeanManager(WeldBootstrapService.java:185)
> at org.jboss.as.weld.injection.WeldComponentService.start(WeldComponentService.java:97)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1739)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1701)
> ... 6 more
> ...
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 2 months
[JBoss JIRA] (WFLY-13735) Use of thread pools with EJB remote element needs attention
by Richard Achmatowicz (Jira)
Richard Achmatowicz created WFLY-13735:
------------------------------------------
Summary: Use of thread pools with EJB remote element needs attention
Key: WFLY-13735
URL: https://issues.redhat.com/browse/WFLY-13735
Project: WildFly
Issue Type: Bug
Components: EJB
Affects Versions: 21.0.0.Beta1
Reporter: Richard Achmatowicz
Assignee: Cheng Fang
The EJB3RemoteResourceDefinition defines two related attributes:
* an attribute thread-pool-name which is optional and has no default
* an attribute execute-in-worker, which is also optional but has a default "true"
When execute-in-worker == false, the add handler expects the thread pool to be available (the remote connector service introduces a capability dependency on it), but because thread-pool-name is optional, this may not be the case.
If execute-in-worker == false, we need to check and throw an error message if a thread pool attribute value is not available, as we can no longer satisfy this condition (in other words, we cannot delegate the work of processing the method to a thread in the non-existent thread pool).
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 2 months