[JBoss JIRA] (WFLY-13645) Provide a set of EAP XP QuickStarts that can run on OpenShift
by Eduardo Martins (Jira)
[ https://issues.redhat.com/browse/WFLY-13645?page=com.atlassian.jira.plugi... ]
Eduardo Martins updated WFLY-13645:
-----------------------------------
Git Pull Request: (was: https://github.com/wildfly/wildfly-proposals/pull/321)
> Provide a set of EAP XP QuickStarts that can run on OpenShift
> --------------------------------------------------------------
>
> Key: WFLY-13645
> URL: https://issues.redhat.com/browse/WFLY-13645
> Project: WildFly
> Issue Type: Feature Request
> Components: Quickstarts
> Reporter: Eduardo Martins
> Assignee: Eduardo Martins
> Priority: Major
>
> The Quickstarts distributed in JBoss EAP XP should be made compatible with JBoss EAP XP Openshift images and templates.
> Please note that JBoss EAP XP Quickstarts, to be considered Openshift compatible, goes beyond “it is deployed to Openshift without errors”, and “all functionality works when running on Openshift”, the documentation of such Quickstarts also need to include the *supported* Openshift usage instructions (specific asciidoc sections which QE tests), similar to the ones included with JBoss EAP CD Quickstarts.
> Also similar to JBoss EAP CD releases, a live branch of JBoss EAP XP Quickstarts for Openshift should be prepared at the JBoss Developer source repository, which the JBoss EAP XP OpenShift Templates should point to, so users may easily discovery and create new projects with JBoss EAP XP Quickstarts.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (WFLY-13438) Database Timers: instances sporadically fail to start in a cluster
by Cheng Fang (Jira)
[ https://issues.redhat.com/browse/WFLY-13438?page=com.atlassian.jira.plugi... ]
Cheng Fang commented on WFLY-13438:
-----------------------------------
[~marcos-scholtz] I tried to reproduce it with WildFly 20.0.0.Final, but couldn't reproduce it. I restarted the 3-server server group (with full-ha profile) many times without seeing the "reinstate timer" errors.
Did you configure the timer data store with proper transaction isolation level (READ_COMMITTED or SERIALIZABLE)?
https://docs.wildfly.org/20/Developer_Guide.html#EJB3_Clustered_Database_...
> Database Timers: instances sporadically fail to start in a cluster
> ------------------------------------------------------------------
>
> Key: WFLY-13438
> URL: https://issues.redhat.com/browse/WFLY-13438
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 19.1.0.Final
> Reporter: Marcos Scholtz
> Assignee: Cheng Fang
> Priority: Major
>
> We use a postgresql database for persistent timers, to control the execution of scheduled tasks in a cluster. It mainly works, but when operating in a cluster and when a server-group is restarted, sometimes individual instances in the cluster fail to start because of an error when reinstating persistent timers.
> Configuration of the Datasource:
> {code}
> <xa-datasource jndi-name="java:/datasources/MonitoringDS" pool-name="MonitoringDS" enabled="true">
> <xa-datasource-property name="ServerName">
> appserver.local
> </xa-datasource-property>
> <xa-datasource-property name="PortNumber">
> 5432
> </xa-datasource-property>
> <xa-datasource-property name="DatabaseName">
> monitoringdb
> </xa-datasource-property>
> <xa-datasource-class>org.postgresql.xa.PGXADataSource</xa-datasource-class>
> <driver>postgresql</driver>
> <security>
> <user-name>xxx</user-name>
> <password>xxx</password>
> </security>
> </xa-datasource>
> {code}
> Configuration of the timer service:
> {code}
> <timer-service thread-pool-name="default" default-data-store="batch-clustered-store">
> <data-stores>
> <file-data-store name="default-file-store" path="timer-service-data" relative-to="jboss.server.data.dir"/>
> <database-data-store name="batch-clustered-store" datasource-jndi-name="java:/datasources/MonitoringDS" database="'postgresql'" partition="${batch.partition}" refresh-interval="60000" allow-execution="true"/>
> </data-stores>
> </timer-service>
> {code}
> Note we use a system-property on the server-group to determine the partition name.
> Also, we made NO changes to the SQL statements in "timer-sql.properties".
> The timer is generated by a `@Schedule` annotation in an EJB like this:
> {code}
> @Schedule(
> dayOfMonth = "${manual.scheduler.dayofmonth:*}",
> dayOfWeek = "${manual.scheduler.dayofweek:*}",
> hour = "${manual.scheduler.hour:2/6}",
> minute = "${manual.scheduler.minute:2}"
> )
> @TransactionAttribute(TransactionAttributeType.NEVER)
> void doPostboxImport() {
> log.info("Starting Postbox Import");
> BatchRuntime.getJobOperator().start("PostboxImportBatchlet", null);
> }
> {code}
> The error we sporadically get when starting more than one instance at the same time (when all instances try to reinstate timers) is like this:
> {code}
> 14:48:28,117 WARN [com.arjuna.ats.arjuna] (ServerService Thread Pool -- 69) {"tenant": "", "clientId": ""} ARJUNA012078: Abort called illegaly on atomic action 0:ffff7f000001:-27f2652e:5eb2b20f:f
> 14:48:28,118 WARN [org.jboss.as.ejb3.timer] (ServerService Thread Pool -- 69) {"tenant": "", "clientId": ""} WFLYEJB0161: Failed to reinstate timer 'postbox-integration-service.postbox-integration-service.PostboxImport' (id=unavailable) from its persistent state: javax.transaction.NotSupportedException: WFTXN0001: A transaction is already in progress
> at org.wildfly.transaction.client@1.1.9.Final//org.wildfly.transaction.client.ContextTransactionManager.begin(ContextTransactionManager.java:60)
> at org.wildfly.transaction.client@1.1.9.Final//org.wildfly.transaction.client.ContextTransactionManager.begin(ContextTransactionManager.java:54)
> at org.jboss.as.ejb3@19.1.0.Final//org.jboss.as.ejb3.timerservice.TimerServiceImpl.getActivePersistentTimers(TimerServiceImpl.java:984)
> at org.jboss.as.ejb3@19.1.0.Final//org.jboss.as.ejb3.timerservice.TimerServiceImpl.restoreTimers(TimerServiceImpl.java:712)
> at org.jboss.as.ejb3@19.1.0.Final//org.jboss.as.ejb3.timerservice.TimerServiceImpl.activate(TimerServiceImpl.java:223)
> at org.jboss.as.ejb3@19.1.0.Final//org.jboss.as.ejb3.component.EJBComponent.init(EJBComponent.java:595)
> at org.jboss.as.ejb3@19.1.0.Final//org.jboss.as.ejb3.component.stateless.StatelessSessionComponent.init(StatelessSessionComponent.java:110)
> at org.jboss.as.ee@19.1.0.Final//org.jboss.as.ee.component.BasicComponent.start(BasicComponent.java:222)
> at org.jboss.as.ee@19.1.0.Final//org.jboss.as.ee.component.ComponentStartService$1.run(ComponentStartService.java:54)
> at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> 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:1377)
> at java.base/java.lang.Thread.run(Thread.java:834)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.JBossThread.run(JBossThread.java:485)
> 14:48:28,153 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 69) {"tenant": "", "clientId": ""} MSC000001: Failed to start service jboss.deployment.unit."postbox-integration-service-E-SNAPSHOT.war".component.PostboxImport.START: org.jboss.msc.service.StartException in service jboss.deployment.unit."postbox-integration-service-E-SNAPSHOT.war".component.PostboxImport.START: java.lang.RuntimeException: java.lang.NullPointerException
> at org.jboss.as.ee@19.1.0.Final//org.jboss.as.ee.component.ComponentStartService$1.run(ComponentStartService.java:57)
> at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> 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:1377)
> at java.base/java.lang.Thread.run(Thread.java:834)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.JBossThread.run(JBossThread.java:485)
> Caused by: java.lang.RuntimeException: java.lang.NullPointerException
> at org.jboss.as.ejb3@19.1.0.Final//org.jboss.as.ejb3.timerservice.TimerServiceImpl.persistTimer(TimerServiceImpl.java:626)
> at org.jboss.as.ejb3@19.1.0.Final//org.jboss.as.ejb3.timerservice.TimerServiceImpl.createCalendarTimer(TimerServiceImpl.java:537)
> at org.jboss.as.ejb3@19.1.0.Final//org.jboss.as.ejb3.timerservice.TimerServiceImpl.loadAutoTimer(TimerServiceImpl.java:388)
> at org.jboss.as.ejb3@19.1.0.Final//org.jboss.as.ejb3.timerservice.TimerServiceImpl.restoreTimers(TimerServiceImpl.java:774)
> at org.jboss.as.ejb3@19.1.0.Final//org.jboss.as.ejb3.timerservice.TimerServiceImpl.activate(TimerServiceImpl.java:223)
> at org.jboss.as.ejb3@19.1.0.Final//org.jboss.as.ejb3.component.EJBComponent.init(EJBComponent.java:595)
> at org.jboss.as.ejb3@19.1.0.Final//org.jboss.as.ejb3.component.stateless.StatelessSessionComponent.init(StatelessSessionComponent.java:110)
> at org.jboss.as.ee@19.1.0.Final//org.jboss.as.ee.component.BasicComponent.start(BasicComponent.java:222)
> at org.jboss.as.ee@19.1.0.Final//org.jboss.as.ee.component.ComponentStartService$1.run(ComponentStartService.java:54)
> ... 8 more
> Caused by: java.lang.NullPointerException
> at org.jboss.as.ejb3@19.1.0.Final//org.jboss.as.ejb3.timerservice.persistence.database.DatabaseTimerPersistence.addTimer(DatabaseTimerPersistence.java:336)
> at org.jboss.as.ejb3@19.1.0.Final//org.jboss.as.ejb3.timerservice.TimerServiceImpl.persistTimer(TimerServiceImpl.java:607)
> ... 16 more
> {code}
> The error seems similar to the one described in WFLY-13386, but the stack trace and the steps to reproduce it seem different to me, so I'm not sure if it's the same problem. The problem also existed in Wildfly 14 , we just updated to 19.1 (also hoping that his error would be corrected).
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (WFLY-13144) Resource Adapter can't be deleted after restarting server
by Dmitrii Pogorelov (Jira)
[ https://issues.redhat.com/browse/WFLY-13144?page=com.atlassian.jira.plugi... ]
Dmitrii Pogorelov updated WFLY-13144:
-------------------------------------
Description:
The issue is related to the WFLY-6774 issue. I'm working with Teiid and should create/delete resource adapters many times, especially resource adapters based on the same archive. The WFLY-6774 fix works well before the restarting server allowing me to create/delete resource adapters without restarting the server. Once I restart the server and try to remove a resource adapter based on an archive I'll get the following error:
{code}
[standalone@localhost:9990 /] /subsystem=resource-adapters/resource-adapter=jcaDemo_VDB_ID_1:remove{allow-resource-service-restart=true}
{
"outcome" => "failed",
"failure-description" => "WFLYCTL0171: Removing services has lead to unsatisfied dependencies:
Service jboss.resourceadapters.ra.jcaDemo_VDB_ID_1 was depended upon by service jboss.deployment.unit.\"jca-demo-1.0.rar\".INSTALL",
"rolled-back" => true
}
{code}
After showing the error server will rollback the "remove" command deploying the jca-demo-1.0.rar archive again and re-creating the jcaDemo_VDB_ID_1 resource adapter. As a result I can't remove the resource adapter via cli commands, it can be removed only manually (removing the resource adapter in standalone.xml). The bug can be reproduced (at least versions which I checked) on WildFly 11.0.0.Final, WildFly 14.0.1.Final and WildFly 17.0.1.Final.
was:
The issue is related to the WFLY-6774 issue. I'm working with Teiid and should create/delete resource adapters many times, especially resource adapters based on the same archive. The WFLY-6774 fix works well before the restarting server allowing me to create/delete resource adapters without restarting the server. Once I restart the server and try to remove a resource adapter based on an archive I'll get the following error:
{code:noformat}
[standalone@localhost:9990 /] /subsystem=resource-adapters/resource-adapter=jcaDemo_VDB_ID_1:remove{allow-resource-service-restart=true}
{
"outcome" => "failed",
"failure-description" => "WFLYCTL0171: Removing services has lead to unsatisfied dependencies:
Service jboss.resourceadapters.ra.jcaDemo_VDB_ID_1 was depended upon by service jboss.deployment.unit.\"jca-demo-1.0.rar\".INSTALL",
"rolled-back" => true
}
{code}
After showing the error server will rollback the "remove" command deploying the jca-demo-1.0.rar archive again and re-creating the jcaDemo_VDB_ID_1 resource adapter. As a result I can't remove the resource adapter via cli commands, it can be removed only manually (removing the resource adapter in standalone.xml). The bug can be reproduced (at least versions which I checked) on WildFly 11.0.0.Final, WildFly 14.0.1.Final and WildFly 17.0.1.Final.
> Resource Adapter can't be deleted after restarting server
> ---------------------------------------------------------
>
> Key: WFLY-13144
> URL: https://issues.redhat.com/browse/WFLY-13144
> Project: WildFly
> Issue Type: Bug
> Components: JCA
> Affects Versions: 14.0.1.Final, 11.0.0.Final, 17.0.1.Final
> Reporter: Dmitrii Pogorelov
> Assignee: Ivo Studensky
> Priority: Critical
> Attachments: jca-demo-1.0.rar, jcademo-source-code.rar
>
>
> The issue is related to the WFLY-6774 issue. I'm working with Teiid and should create/delete resource adapters many times, especially resource adapters based on the same archive. The WFLY-6774 fix works well before the restarting server allowing me to create/delete resource adapters without restarting the server. Once I restart the server and try to remove a resource adapter based on an archive I'll get the following error:
> {code}
> [standalone@localhost:9990 /] /subsystem=resource-adapters/resource-adapter=jcaDemo_VDB_ID_1:remove{allow-resource-service-restart=true}
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0171: Removing services has lead to unsatisfied dependencies:
> Service jboss.resourceadapters.ra.jcaDemo_VDB_ID_1 was depended upon by service jboss.deployment.unit.\"jca-demo-1.0.rar\".INSTALL",
> "rolled-back" => true
> }
> {code}
> After showing the error server will rollback the "remove" command deploying the jca-demo-1.0.rar archive again and re-creating the jcaDemo_VDB_ID_1 resource adapter. As a result I can't remove the resource adapter via cli commands, it can be removed only manually (removing the resource adapter in standalone.xml). The bug can be reproduced (at least versions which I checked) on WildFly 11.0.0.Final, WildFly 14.0.1.Final and WildFly 17.0.1.Final.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (WFLY-13144) Resource Adapter can't be deleted after restarting server
by Dmitrii Pogorelov (Jira)
[ https://issues.redhat.com/browse/WFLY-13144?page=com.atlassian.jira.plugi... ]
Dmitrii Pogorelov updated WFLY-13144:
-------------------------------------
Steps to Reproduce:
All steps were performed on WildFly 11.0.0.Final but the bug can be also reproduced on WildFly 14.0.1.Final and WildFly 17.0.1.Final (haven't checked newest versions of WildFly yet).
1. I developed a very simple connector which was actually taken from [https://github.com/fmarchioni/mastertheboss/tree/master/jca-demo] (I attached source code of the jca in scope of the issue), compiled it and got the jca-demo-1.0.rar archive.
2. put the jca-demo-1.0.rar archive to deployments folder.
3. start the server.
4. after deploying the jca-demo-1.0.rar run the following cli commands:
{code}
/subsystem=resource-adapters/resource-adapter=jcaDemo_VDB_ID_1:add(archive=jca-demo-1.0.rar, transaction-support=NoTransaction)
/subsystem=resource-adapters/resource-adapter=jcaDemo_VDB_ID_1/connection-definitions=jcaDemo_VDB_ID_1:add(jndi-name=java:/jcaDemo_VDB_ID_1, enabled=true, class-name=com.sample.adapter.HelloWorldManagedConnectionFactory, min-pool-size=0, max-pool-size=20){allow-resource-service-restart=true}
/subsystem=resource-adapters/resource-adapter=jcaDemo_VDB_ID_1:activate
{code}
in server.log you can see the following (the log was taken from WildFly 11.0.0.Final):
{code}
2020-02-20 12:03:33,103 INFO [org.jboss.as.connector.deployers.RaXmlDeployer] (MSC service thread 1-5) IJ020001: Required license terms for file:/C:/DataVirtuality/wildfly-11.0.0.Final/standalone/tmp/vfs/temp/temp840fa23b95ebcc91/content-85ce6bdbfce5b3b5/contents/ 2020-02-20 12:03:33,115 INFO [org.jboss.as.connector.deployment] (MSC service thread 1-5) WFLYJCA0007: Registered connection factory java:/jcaDemo_VDB_ID_1 2020-02-20 12:03:33,121 INFO [org.jboss.as.connector.deployers.RaXmlDeployer] (MSC service thread 1-5) IJ020002: Deployed: file:/C:/DataVirtuality/wildfly-11.0.0.Final/standalone/tmp/vfs/temp/temp840fa23b95ebcc91/content-85ce6bdbfce5b3b5/contents/ 2020-02-20 12:03:33,123 INFO [org.jboss.as.connector.deployment] (MSC service thread 1-6) WFLYJCA0002: Bound JCA ConnectionFactory [java:/jcaDemo_VDB_ID_1]
{code}
5. if you try to run the cli command before restarting the server:
{code}
/subsystem=resource-adapters/resource-adapter=jcaDemo_VDB_ID_1:remove{allow-resource-service-restart=true}
{code}
in the server.log you will see the following:
{code}
2020-02-20 12:03:51,146 INFO [org.jboss.as.connector.deployment] (MSC service thread 1-1) WFLYJCA0011: Unbound JCA ConnectionFactory [java:/jcaDemo_VDB_ID_1]
{code}
6. if you removed the resource adapter during the 5. step and before restarting the server, please, repeat the 4. step to create the resource adapter again.
7. restart the server.
8. try to run the cli command:
{code}
/subsystem=resource-adapters/resource-adapter=jcaDemo_VDB_ID_1:remove{allow-resource-service-restart=true}
{code}
the server will generate the following lines in the server.log:
{code}
2020-02-20 12:05:43,653 INFO [org.jboss.as.server.deployment] (MSC service thread 1-2) WFLYSRV0070: Deployment restart detected for deployment jca-demo-1.0.rar, performing full redeploy instead. 2020-02-20 12:05:43,693 INFO [org.jboss.as.server.deployment] (MSC service thread 1-5) WFLYSRV0028: Stopped deployment jca-demo-1.0.rar (runtime-name: jca-demo-1.0.rar) in 35ms 2020-02-20 12:05:43,698 INFO [org.jboss.as.server.deployment] (MSC service thread 1-5) WFLYSRV0027: Starting deployment of "jca-demo-1.0.rar" (runtime-name: "jca-demo-1.0.rar") 2020-02-20 12:05:44,130 INFO [org.jboss.as.connector.deployers.RADeployer] (MSC service thread 1-3) IJ020001: Required license terms for file:/C:/DataVirtuality/wildfly-11.0.0.Final/standalone/tmp/vfs/temp/tempa8f374a95f0436c6/content-72dc113b1d3ebdfb/contents/ 2020-02-20 12:05:44,139 INFO [org.jboss.as.connector.deployers.RaXmlDeployer] (MSC service thread 1-3) IJ020001: Required license terms for file:/C:/DataVirtuality/wildfly-11.0.0.Final/standalone/tmp/vfs/temp/tempa8f374a95f0436c6/content-72dc113b1d3ebdfb/contents/ 2020-02-20 12:05:44,154 INFO [org.jboss.as.connector.deployment] (MSC service thread 1-3) WFLYJCA0007: Registered connection factory java:/jcaDemo_VDB_ID_1 2020-02-20 12:05:44,161 INFO [org.jboss.as.connector.deployers.RaXmlDeployer] (MSC service thread 1-3) IJ020002: Deployed: file:/C:/DataVirtuality/wildfly-11.0.0.Final/standalone/tmp/vfs/temp/tempa8f374a95f0436c6/content-72dc113b1d3ebdfb/contents/ 2020-02-20 12:05:44,171 INFO [org.jboss.as.connector.deployment] (MSC service thread 1-3) WFLYJCA0002: Bound JCA ConnectionFactory [java:/jcaDemo_VDB_ID_1]
{code}
at the same time the "remove" cli command will return the following response:
{code}
[standalone@localhost:9990 /] /subsystem=resource-adapters/resource-adapter=jcaDemo_VDB_ID_1:remove{allow-resource-service-restart=true}
{
"outcome" => "failed",
"failure-description" => "WFLYCTL0171: Removing services has lead to unsatisfied dependencies:
Service jboss.resourceadapters.ra.jcaDemo_VDB_ID_1 was depended upon by service jboss.deployment.unit.\"jca-demo-1.0.rar\".INSTALL",
"rolled-back" => true
}
{code}
was:
All steps were performed on WildFly 11.0.0.Final but the bug can be also reproduced on WildFly 14.0.1.Final and WildFly 17.0.1.Final (haven't checked newest versions of WildFly yet).
1. I developed a very simple connector which was actually taken from https://github.com/fmarchioni/mastertheboss/tree/master/jca-demo (I attached source code of the jca in scope of the issue), compiled it and got the jca-demo-1.0.rar archive.
2. put the jca-demo-1.0.rar archive to deployments folder.
3. start the server.
4. after deploying the jca-demo-1.0.rar run the following cli commands:
{code:noformat}
/subsystem=resource-adapters/resource-adapter=jcaDemo_VDB_ID_1:add(archive=jca-demo-1.0.rar, transaction-support=NoTransaction)
/subsystem=resource-adapters/resource-adapter=jcaDemo_VDB_ID_1/connection-definitions=jcaDemo_VDB_ID_1:add(jndi-name=java:/jcaDemo_VDB_ID_1, enabled=true, class-name=com.sample.adapter.HelloWorldManagedConnectionFactory, min-pool-size=0, max-pool-size=20){allow-resource-service-restart=true}
/subsystem=resource-adapters/resource-adapter=jcaDemo_VDB_ID_1:activate
{code}
in server.log you can see the following (the log was taken from WildFly 11.0.0.Final):
{code:noformat}
2020-02-20 12:03:33,103 INFO [org.jboss.as.connector.deployers.RaXmlDeployer] (MSC service thread 1-5) IJ020001: Required license terms for file:/C:/DataVirtuality/wildfly-11.0.0.Final/standalone/tmp/vfs/temp/temp840fa23b95ebcc91/content-85ce6bdbfce5b3b5/contents/ 2020-02-20 12:03:33,115 INFO [org.jboss.as.connector.deployment] (MSC service thread 1-5) WFLYJCA0007: Registered connection factory java:/jcaDemo_VDB_ID_1 2020-02-20 12:03:33,121 INFO [org.jboss.as.connector.deployers.RaXmlDeployer] (MSC service thread 1-5) IJ020002: Deployed: file:/C:/DataVirtuality/wildfly-11.0.0.Final/standalone/tmp/vfs/temp/temp840fa23b95ebcc91/content-85ce6bdbfce5b3b5/contents/ 2020-02-20 12:03:33,123 INFO [org.jboss.as.connector.deployment] (MSC service thread 1-6) WFLYJCA0002: Bound JCA ConnectionFactory [java:/jcaDemo_VDB_ID_1]
{code}
5. if you try to run the cli command before restarting the server:
{code:noformat}
/subsystem=resource-adapters/resource-adapter=jcaDemo_VDB_ID_1:remove{allow-resource-service-restart=true}
{code}
in the server.log you will see the following:
{code:noformat}
2020-02-20 12:03:51,146 INFO [org.jboss.as.connector.deployment] (MSC service thread 1-1) WFLYJCA0011: Unbound JCA ConnectionFactory [java:/jcaDemo_VDB_ID_1]
{code}
6. if you removed the resource adapter during the 5. step and before restarting the server, please, repeat the 4. step to create the resource adapter again.
7. restart the server.
8. try to run the cli command:
{code:noformat}
/subsystem=resource-adapters/resource-adapter=jcaDemo_VDB_ID_1:remove{allow-resource-service-restart=true}
{code}
the server will generate the following lines in the server.log:
{code:noformat}
2020-02-20 12:05:43,653 INFO [org.jboss.as.server.deployment] (MSC service thread 1-2) WFLYSRV0070: Deployment restart detected for deployment jca-demo-1.0.rar, performing full redeploy instead. 2020-02-20 12:05:43,693 INFO [org.jboss.as.server.deployment] (MSC service thread 1-5) WFLYSRV0028: Stopped deployment jca-demo-1.0.rar (runtime-name: jca-demo-1.0.rar) in 35ms 2020-02-20 12:05:43,698 INFO [org.jboss.as.server.deployment] (MSC service thread 1-5) WFLYSRV0027: Starting deployment of "jca-demo-1.0.rar" (runtime-name: "jca-demo-1.0.rar") 2020-02-20 12:05:44,130 INFO [org.jboss.as.connector.deployers.RADeployer] (MSC service thread 1-3) IJ020001: Required license terms for file:/C:/DataVirtuality/wildfly-11.0.0.Final/standalone/tmp/vfs/temp/tempa8f374a95f0436c6/content-72dc113b1d3ebdfb/contents/ 2020-02-20 12:05:44,139 INFO [org.jboss.as.connector.deployers.RaXmlDeployer] (MSC service thread 1-3) IJ020001: Required license terms for file:/C:/DataVirtuality/wildfly-11.0.0.Final/standalone/tmp/vfs/temp/tempa8f374a95f0436c6/content-72dc113b1d3ebdfb/contents/ 2020-02-20 12:05:44,154 INFO [org.jboss.as.connector.deployment] (MSC service thread 1-3) WFLYJCA0007: Registered connection factory java:/jcaDemo_VDB_ID_1 2020-02-20 12:05:44,161 INFO [org.jboss.as.connector.deployers.RaXmlDeployer] (MSC service thread 1-3) IJ020002: Deployed: file:/C:/DataVirtuality/wildfly-11.0.0.Final/standalone/tmp/vfs/temp/tempa8f374a95f0436c6/content-72dc113b1d3ebdfb/contents/ 2020-02-20 12:05:44,171 INFO [org.jboss.as.connector.deployment] (MSC service thread 1-3) WFLYJCA0002: Bound JCA ConnectionFactory [java:/jcaDemo_VDB_ID_1]
{code}
at the same time the "remove" cli command will return the following response:
{code:noformat}
[standalone@localhost:9990 /] /subsystem=resource-adapters/resource-adapter=jcaDemo_VDB_ID_1:remove{allow-resource-service-restart=true}
{
"outcome" => "failed",
"failure-description" => "WFLYCTL0171: Removing services has lead to unsatisfied dependencies:
Service jboss.resourceadapters.ra.jcaDemo_VDB_ID_1 was depended upon by service jboss.deployment.unit.\"jca-demo-1.0.rar\".INSTALL",
"rolled-back" => true
}
{code}
> Resource Adapter can't be deleted after restarting server
> ---------------------------------------------------------
>
> Key: WFLY-13144
> URL: https://issues.redhat.com/browse/WFLY-13144
> Project: WildFly
> Issue Type: Bug
> Components: JCA
> Affects Versions: 14.0.1.Final, 11.0.0.Final, 17.0.1.Final
> Reporter: Dmitrii Pogorelov
> Assignee: Ivo Studensky
> Priority: Critical
> Attachments: jca-demo-1.0.rar, jcademo-source-code.rar
>
>
> The issue is related to the WFLY-6774 issue. I'm working with Teiid and should create/delete resource adapters many times, especially resource adapters based on the same archive. The WFLY-6774 fix works well before the restarting server allowing me to create/delete resource adapters without restarting the server. Once I restart the server and try to remove a resource adapter based on an archive I'll get the following error:
> {code}
> [standalone@localhost:9990 /] /subsystem=resource-adapters/resource-adapter=jcaDemo_VDB_ID_1:remove{allow-resource-service-restart=true}
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0171: Removing services has lead to unsatisfied dependencies:
> Service jboss.resourceadapters.ra.jcaDemo_VDB_ID_1 was depended upon by service jboss.deployment.unit.\"jca-demo-1.0.rar\".INSTALL",
> "rolled-back" => true
> }
> {code}
> After showing the error server will rollback the "remove" command deploying the jca-demo-1.0.rar archive again and re-creating the jcaDemo_VDB_ID_1 resource adapter. As a result I can't remove the resource adapter via cli commands, it can be removed only manually (removing the resource adapter in standalone.xml). The bug can be reproduced (at least versions which I checked) on WildFly 11.0.0.Final, WildFly 14.0.1.Final and WildFly 17.0.1.Final.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (WFLY-13144) Resource Adapter can't be deleted after restarting server
by Dmitrii Pogorelov (Jira)
[ https://issues.redhat.com/browse/WFLY-13144?page=com.atlassian.jira.plugi... ]
Dmitrii Pogorelov commented on WFLY-13144:
------------------------------------------
[~shawkins] thx a lot! I tried the idea to remove the connection-definitions before removing the resource-adapter and it worked! The workaround for the workflow which I described in scope of the issue is the following (to remove the jcaDemo_VDB_ID_1 resource adapter after restarting WildFly server):
{code:java}
/subsystem=resource-adapters/resource-adapter=jcaDemo_VDB_ID_1/connection-definitions=jcaDemo_VDB_ID_1:remove{allow-resource-service-restart=true}
/subsystem=resource-adapters/resource-adapter=jcaDemo_VDB_ID_1:remove{allow-resource-service-restart=true} {code}
> Resource Adapter can't be deleted after restarting server
> ---------------------------------------------------------
>
> Key: WFLY-13144
> URL: https://issues.redhat.com/browse/WFLY-13144
> Project: WildFly
> Issue Type: Bug
> Components: JCA
> Affects Versions: 14.0.1.Final, 11.0.0.Final, 17.0.1.Final
> Reporter: Dmitrii Pogorelov
> Assignee: Ivo Studensky
> Priority: Critical
> Attachments: jca-demo-1.0.rar, jcademo-source-code.rar
>
>
> The issue is related to the WFLY-6774 issue. I'm working with Teiid and should create/delete resource adapters many times, especially resource adapters based on the same archive. The WFLY-6774 fix works well before the restarting server allowing me to create/delete resource adapters without restarting the server. Once I restart the server and try to remove a resource adapter based on an archive I'll get the following error:
> {code:noformat}
> [standalone@localhost:9990 /] /subsystem=resource-adapters/resource-adapter=jcaDemo_VDB_ID_1:remove{allow-resource-service-restart=true}
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0171: Removing services has lead to unsatisfied dependencies:
> Service jboss.resourceadapters.ra.jcaDemo_VDB_ID_1 was depended upon by service jboss.deployment.unit.\"jca-demo-1.0.rar\".INSTALL",
> "rolled-back" => true
> }
> {code}
> After showing the error server will rollback the "remove" command deploying the jca-demo-1.0.rar archive again and re-creating the jcaDemo_VDB_ID_1 resource adapter. As a result I can't remove the resource adapter via cli commands, it can be removed only manually (removing the resource adapter in standalone.xml). The bug can be reproduced (at least versions which I checked) on WildFly 11.0.0.Final, WildFly 14.0.1.Final and WildFly 17.0.1.Final.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (WFLY-13645) Provide a set of EAP XP QuickStarts that can run on OpenShift
by Eduardo Martins (Jira)
[ https://issues.redhat.com/browse/WFLY-13645?page=com.atlassian.jira.plugi... ]
Eduardo Martins moved EAP7-1520 to WFLY-13645:
----------------------------------------------
Project: WildFly (was: JBoss EAP Planning for version 7 and above)
Key: WFLY-13645 (was: EAP7-1520)
Issue Type: Feature Request (was: Requirement)
Workflow: GIT Pull Request workflow (was: EAP Agile Workflow 2.0)
Component/s: Quickstarts
(was: Quickstarts)
EAP PT Pre-Checked (PC): (was: TODO)
Target Release: (was: EAP-XP-2.0.0.GA)
EAP PT Community Docs (CD): (was: TODO)
EAP PT Product Docs (PD): (was: New)
EAP PT Test Dev (TD): (was: TODO)
EAP PT Docs Analysis (DA): (was: TODO)
EAP PT Test Plan (TP): (was: TODO)
EAP PT Analysis Document (AD): (was: TODO)
> Provide a set of EAP XP QuickStarts that can run on OpenShift
> --------------------------------------------------------------
>
> Key: WFLY-13645
> URL: https://issues.redhat.com/browse/WFLY-13645
> Project: WildFly
> Issue Type: Feature Request
> Components: Quickstarts
> Reporter: Eduardo Martins
> Assignee: Eduardo Martins
> Priority: Major
>
> The Quickstarts distributed in JBoss EAP XP should be made compatible with JBoss EAP XP Openshift images and templates.
> Please note that JBoss EAP XP Quickstarts, to be considered Openshift compatible, goes beyond “it is deployed to Openshift without errors”, and “all functionality works when running on Openshift”, the documentation of such Quickstarts also need to include the *supported* Openshift usage instructions (specific asciidoc sections which QE tests), similar to the ones included with JBoss EAP CD Quickstarts.
> Also similar to JBoss EAP CD releases, a live branch of JBoss EAP XP Quickstarts for Openshift should be prepared at the JBoss Developer source repository, which the JBoss EAP XP OpenShift Templates should point to, so users may easily discovery and create new projects with JBoss EAP XP Quickstarts.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (DROOLS-5230) Managing a List of structures in Test Scenario editor produces an Exception
by Yeser Amer (Jira)
[ https://issues.redhat.com/browse/DROOLS-5230?page=com.atlassian.jira.plug... ]
Yeser Amer updated DROOLS-5230:
-------------------------------
Fix Version/s: (was: 7.41.0.Final)
> Managing a List of structures in Test Scenario editor produces an Exception
> ---------------------------------------------------------------------------
>
> Key: DROOLS-5230
> URL: https://issues.redhat.com/browse/DROOLS-5230
> Project: Drools
> Issue Type: Bug
> Components: Scenario Simulation and Testing
> Affects Versions: 7.34.0.Final
> Reporter: Tracy Hires
> Assignee: Yeser Amer
> Priority: Critical
> Attachments: Error screen shot.png, test_scenario_list_exception.zip
>
>
> When trying to delete an item from a list of structures with nested structures in the scenario editor, an exception is thrown with a message that is not helpful to the end user.
> Log entry is:
> ```
> ^[[0m^[[31m17:16:51,564 ERROR [org.kie.workbench.common.services.backend.logger.GenericErrorLoggerServiceImpl] (default task-415) Error from user: xxxxx Error ID: -881202734 Location: LibraryPerspective|$ProjectScreen[!Worg.kie.dmn.decision.navigator,EDiagramEditorPropertiesScreen,Eorg.drools.scenariosimulation.TestTools?scesimeditorid=1,!Eorg.drools.scenariosimulation.TestTools?scesimeditorid=2,Eorg.docks.PlaceHolder?name=testRunnerReportingPanel,Worg.kie.guvnor.explorer,],DMNDiagramEditor?path_uri=default://master@dm-ai/XmlValidationBug/src/main/resources/Math%2520Functions.dmn&file_name=Math%20Functions.dmn&has_version_support=true,DMNDiagramEditor?path_uri=default://master@dm-ai/XmlValidationBug/src/main/resources/Divide.dmn&file_name=Divide.dmn&has_version_support=true,org.kie.workbench.common.screens.messageconsole.MessageConsole,,AddAssetsScreen,ScenarioSimulationEditor?path_uri=default://master@dm-ai/XmlValidationBug/src/test/resources/Test%2520Math%2520Functions.scesim&file_name=Test%20Math%20Functions.scesim&has_version_support=true Exception: Uncaught exception: Exception caught: (TypeError) : Cannot read property 'Tc' of undefined Caused by: (TypeError) : Cannot read property 'Tc' of undefined
> ```
> From UI I could see: `Uncaught exception: Exception caught: (TypeError) : Cannot read property 'Tc' of undefined Caused by: (TypeError) : Cannot read property 'Tc' of undefined`
> (Screenshot is attached)
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (WFCORE-5035) Add a new legacy-security artefact / module
by Darran Lofthouse (Jira)
Darran Lofthouse created WFCORE-5035:
----------------------------------------
Summary: Add a new legacy-security artefact / module
Key: WFCORE-5035
URL: https://issues.redhat.com/browse/WFCORE-5035
Project: WildFly Core
Issue Type: Task
Components: Build System, Security
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
Fix For: 13.0.0.Beta2
Where components in WildFly Core depend on PicketBox we should make sure this is via a module which they can optional depend upon so avoid components in WildFly Core having hard dependencies on PicketBox APIs.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (ELY-2007) Bring SecurityIdentity PolicyContextHandler inline with WildFly Core implementation.
by Darran Lofthouse (Jira)
[ https://issues.redhat.com/browse/ELY-2007?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse updated ELY-2007:
----------------------------------
Description: There is an implementation in WildFly Core which uses SecurityDomain.getCurrent() - move this to the Elytron implementation. (was: There is an implementation in WildFly Core but really the implementation is not specific to the integration in the application server so it should be moved into the WildFly Elytron project.)
> Bring SecurityIdentity PolicyContextHandler inline with WildFly Core implementation.
> ------------------------------------------------------------------------------------
>
> Key: ELY-2007
> URL: https://issues.redhat.com/browse/ELY-2007
> Project: WildFly Elytron
> Issue Type: Enhancement
> Components: EE
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Priority: Major
> Fix For: 1.13.0.CR2
>
>
> There is an implementation in WildFly Core which uses SecurityDomain.getCurrent() - move this to the Elytron implementation.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years