[JBoss JIRA] (JBTM-2813) Cli operation for listing transactions returns not only transactions but participants too - for JTS inflow txn
by Ondra Chaloupka (JIRA)
[ https://issues.jboss.org/browse/JBTM-2813?page=com.atlassian.jira.plugin.... ]
Ondra Chaloupka moved JBEAP-7736 to JBTM-2813:
----------------------------------------------
Project: JBoss Transaction Manager (was: JBoss Enterprise Application Platform)
Key: JBTM-2813 (was: JBEAP-7736)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: JTS
(was: Transactions)
Affects Version/s: 5.4.0.Final
(was: 7.1.0.DR9)
> Cli operation for listing transactions returns not only transactions but participants too - for JTS inflow txn
> --------------------------------------------------------------------------------------------------------------
>
> Key: JBTM-2813
> URL: https://issues.jboss.org/browse/JBTM-2813
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: JTS
> Affects Versions: 5.4.0.Final
> Reporter: Ondra Chaloupka
> Assignee: Michael Musgrove
> Attachments: JcaInflowTransactionTestCase_rmerrWithRecovery_jts_server.log, tx-object-store_after-prepare.zip, tx-object-store_after-recover.zip
>
>
> This is a follow-up from JBEAP-6307 where change JBTM-2767 (Allow JTS JCA imported transactions to have clearHeuristic called on their participants) was part of it.
> That seems to bring wrong behavior of cli operation for listing transactions when JTS inflow txn is in use. Currently I do observe that operation [1] lists not only transactions as it should but there are listed participants of transaction as well - what is not expected.
> When inflow transaction is prepared then I can see (the testcase contains only one prepared transaction at the time which consists of two test XAResources)
> {code}
> [standalone@localhost:42042 /] /subsystem=transactions/log-store=log-store:probe()
> {"outcome" => "success"}
> [standalone@localhost:42042 /] /subsystem=transactions/log-store=log-store:read-resource()
> {
> "outcome" => "success",
> "result" => {
> "expose-all-logs" => false,
> "type" => "default",
> "transactions" => {
> "0:ffff7f000001:-f30b80c:58480e0a:2c" => undefined,
> "0:ffff7f000001:-f30b80c:58480e0a:26" => undefined,
> "0:ffff7f000001:-f30b80c:58480e0a:2f" => undefined
> }
> }
> }
> {code}
> My test causes that one participant ends in heuristic state thus recovery is processed only for the second one. After recovery is processed the listing changes to
> {code}
> [standalone@localhost:42042 /] /subsystem=transactions/log-store=log-store:probe()
> {"outcome" => "success"}
> [standalone@localhost:42042 /] /subsystem=transactions/log-store=log-store:read-resource()
> {
> "outcome" => "success",
> "result" => {
> "expose-all-logs" => false,
> "type" => "default",
> "transactions" => {
> "0:ffff7f000001:-f30b80c:58480e0a:26" => undefined,
> "0:ffff7f000001:-f30b80c:58480e0a:2f" => undefined
> }
> }
> }
> {code}
> I'm adding the content of {{tx-object-store}} at both phases and the {{server.log}} as well.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 5 months
[JBoss JIRA] (JBTM-2790) Blacktie btadmin ResumeDomainTest failure
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-2790?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson edited comment on JBTM-2790 at 12/7/16 7:21 AM:
--------------------------------------------------------------
Fundamentally the issue is that stomp side sends the message (14046 AKA JMSMessageID aab18eed-9a46-11e6-93e9-525400b0f360) but the C side doesn't receive it:
This is it being sent by the app server:
2016-10-25 01:04:58,828 DEBUG [org.codehaus.stomp.jms.ProtocolConverter] (Thread-16 (ActiveMQ-client-global-threads-20571710)) Locking output handler to ensure that we don't mux signals
This is the C side blocking wait:
2016-10-25 01:04:57,273 [0x000009b4] TRACE (AtmiBrokerLogc :84 ) - stomp_read_line
was (Author: tomjenkinson):
The message to pause the server does not seem to be received at testsui1 14046 is the message ID I think on the app server Stomp sent but I can;t see it getting received.
> Blacktie btadmin ResumeDomainTest failure
> -----------------------------------------
>
> Key: JBTM-2790
> URL: https://issues.jboss.org/browse/JBTM-2790
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: BlackTie, Testing
> Reporter: Amos Feng
> Assignee: Amos Feng
> Priority: Minor
>
> It looks like the ResumeDomainTest.setUp() sends the "pauseDomain' command but can not receive the response from the jboss-as server.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 5 months
[JBoss JIRA] (JBTM-2812) Retain a log if a forget call on a resource fails
by Michael Musgrove (JIRA)
[ https://issues.jboss.org/browse/JBTM-2812?page=com.atlassian.jira.plugin.... ]
Michael Musgrove updated JBTM-2812:
-----------------------------------
Description: When we clear a heuristic from XAResourceRecord we call forget on the resource and then delete the record even if the forget operation fails. The preferred behaviour is to retain the record if the forget fails so that it can be reported via our tooling and so that we still have the option of later retrying the forget operation (also via the tooling). (was: During abort processing (in BasicAction) we attempt to forgetHeuristics and then remove the participant log. The fix for JBTM-2728 changed this behaviour such that the log is retained if the resource forget operation fails. This is a change in behaviour and needs to be reverted.
Note that the resource will still eventually be told to forget during normal recovery processing for orphans (provided we have configured presumed abort semantics):
# our XARecoveryModule asks the resource for its pending branches (via the xa_recover() peration);
# if the xid is one of ours and if we no longer have a record for it then we call rollback on it presumed abort);
# the reosource uses the rollback call to tell us that the branch was already heuristically rolled back so we call forget)
> Retain a log if a forget call on a resource fails
> -------------------------------------------------
>
> Key: JBTM-2812
> URL: https://issues.jboss.org/browse/JBTM-2812
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: JTA
> Affects Versions: 5.4.0.Final
> Reporter: Michael Musgrove
> Assignee: Michael Musgrove
> Fix For: 5.next
>
>
> When we clear a heuristic from XAResourceRecord we call forget on the resource and then delete the record even if the forget operation fails. The preferred behaviour is to retain the record if the forget fails so that it can be reported via our tooling and so that we still have the option of later retrying the forget operation (also via the tooling).
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 5 months
[JBoss JIRA] (JBTM-2812) Retain a log if a forget call on a resource fails
by Michael Musgrove (JIRA)
[ https://issues.jboss.org/browse/JBTM-2812?page=com.atlassian.jira.plugin.... ]
Michael Musgrove updated JBTM-2812:
-----------------------------------
Summary: Retain a log if a forget call on a resource fails (was: Calling forget on an XAResource should always remove the corresponding log)
> Retain a log if a forget call on a resource fails
> -------------------------------------------------
>
> Key: JBTM-2812
> URL: https://issues.jboss.org/browse/JBTM-2812
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: JTA
> Affects Versions: 5.4.0.Final
> Reporter: Michael Musgrove
> Assignee: Michael Musgrove
> Fix For: 5.next
>
>
> During abort processing (in BasicAction) we attempt to forgetHeuristics and then remove the participant log. The fix for JBTM-2728 changed this behaviour such that the log is retained if the resource forget operation fails. This is a change in behaviour and needs to be reverted.
> Note that the resource will still eventually be told to forget during normal recovery processing for orphans (provided we have configured presumed abort semantics):
> # our XARecoveryModule asks the resource for its pending branches (via the xa_recover() peration);
> # if the xid is one of ours and if we no longer have a record for it then we call rollback on it presumed abort);
> # the reosource uses the rollback call to tell us that the branch was already heuristically rolled back so we call forget
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 5 months
[JBoss JIRA] (JBTM-2792) Participant is not rolled-back when RMERR thrown during prepare phase
by Ondra Chaloupka (JIRA)
[ https://issues.jboss.org/browse/JBTM-2792?page=com.atlassian.jira.plugin.... ]
Ondra Chaloupka closed JBTM-2792.
---------------------------------
Resolution: Rejected
See Mike's explanation at
https://issues.jboss.org/browse/JBEAP-7417?focusedCommentId=13334487#comm...
> Participant is not rolled-back when RMERR thrown during prepare phase
> ---------------------------------------------------------------------
>
> Key: JBTM-2792
> URL: https://issues.jboss.org/browse/JBTM-2792
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: JTA
> Affects Versions: 5.3.5.Final
> Reporter: Ondra Chaloupka
> Assignee: Tom Jenkinson
> Priority: Critical
> Attachments: JPAProxyCrashRecoveryTestCase_prepareHalt_jta_server-5.3.3.Final.log, JPAProxyCrashRecoveryTestCase_prepareHalt_jta_server-5.3.5.Final.log
>
>
> I do experience trouble - or maybe different behavior against older version of Narayana - with forgetting transaction log when failure is caused by jdbc driver throws XAException.XAER_RMERR during prepare phase of 2PC.
> The test scenario is following
> {quote}
> * prepare db/jms XA
> * stop connection to db/jms
> * prepare test XA
> * commit db/jms XA (connection is down - jdbc driver throws XAException.XAER_RMERR)
> * client gets javax.transaction.TransactionRolledbackException from server side
> * trying to abort transaction
> * rollback of db resource but connection is down
> * rolback test XA
> * connection is started again
> * expected behaviour: periodic recovery -> rollback db XA
> {quote}
> For current Narayana version (tested with 5.3.5 and 5.4.1.snapshot) the periodic recovery does not rolled back the participant during recovery cycle.
> For Narayana 5.3.3.Final periodic recovery votes for rollback (ROLLBACK)[1].
> Narayan 5.3.5.Final ends with voting for doing nothing (JTATransactionLogXAResourceOrphanFilter.LEAVE_ALONE)[2].
> It seems to me that's caused by fact that directly after transaction commit fails (because of not existing connection) for previous version of Narayana transaction record about participant was removed from txn log [3]. But in current version the transaction record is left in log[4] and orphan filters do not vote for roll-backing in bottom-up phase later on.
> [1]
> {code}
> 2016-11-21 09:01:25,576 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.currentState(0:ffff7f000001:-70f14116:5832a97b:26, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction) - returning StateStatus.OS_UNKNOWN2016-11-21 09:01:25,576 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) No record found for < formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffff7f000001:-70f14116:5832a97b:26, node_name=1, branch_uid=0:ffff7f000001:-70f14116:5832a97b:29, subordinatenodename=null, eis_name=java:jboss/xa-datasources/CrashRecoveryDS >2016-11-21 09:01:25,576 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) XAResourceOrphanFilter com.arjuna.ats.internal.jta.recovery.arjunacore.JTATransactionLogXAResourceOrphanFilter voted ABSTAIN2016-11-21 09:01:25,576 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) node name of < formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffff7f000001:-70f14116:5832a97b:26, node_name=1, branch_uid=0:ffff7f000001:-70f14116:5832a97b:29, subordinatenodename=null, eis_name=java:jboss/xa-datasources/CrashRecoveryDS > is 12016-11-21 09:01:25,576 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) XAResourceOrphanFilter com.arjuna.ats.internal.jta.recovery.arjunacore.JTANodeNameXAResourceOrphanFilter voted ROLLBACK2016-11-21 09:01:25,576 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) subordinate node name of < formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffff7f000001:-70f14116:5832a97b:26, node_name=1, branch_uid=0:ffff7f000001:-70f14116:5832a97b:29, subordinatenodename=null, eis_name=java:jboss/xa-datasources/CrashRecoveryDS > is null2016-11-21 09:01:25,576 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) XAResourceOrphanFilter com.arjuna.ats.internal.jta.recovery.arjunacore.SubordinateJTAXAResourceOrphanFilter voted ABSTAIN2016-11-21 09:01:25,577 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) node name of < formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffff7f000001:-70f14116:5832a97b:26, node_name=1, branch_uid=0:ffff7f000001:-70f14116:5832a97b:29, subordinatenodename=null, eis_name=java:jboss/xa-datasources/CrashRecoveryDS > is 1
> {code}
> [2]
> {code}
> 2016-11-21 09:18:03,008 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) Found record for < formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffff7f000001:-359c90f5:5832ad62:27, node_name=1, branch_uid=0:ffff7f000001:-359c90f5:5832ad62:2a, subordinatenodename=null, eis_name=java:jboss/xa-datasources/CrashRecoveryDS >2016-11-21 09:18:03,008 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) XAResourceOrphanFilter com.arjuna.ats.internal.jta.recovery.arjunacore.JTATransactionLogXAResourceOrphanFilter voted LEAVE_ALONE
> {code}
> [3]
> {code}
> 2016-11-21 09:00:33,981 TRACE [com.arjuna.ats.arjuna] (default task-8) BasicAction::updateState() for action-id 0:ffff7f000001:-70f14116:5832a97b:262016-11-21 09:00:33,981 TRACE [com.arjuna.ats.arjuna] (default task-8) FileSystemStore.remove_committed(0:ffff7f000001:-70f14116:5832a97b:26, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction)2016-11-21 09:00:33,981 TRACE [com.arjuna.ats.arjuna] (default task-8) ShadowingStore.remove_state(0:ffff7f000001:-70f14116:5832a97b:26, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction, StateType.OS_ORIGINAL)
> {code}
> [4]
> {code}
> 2016-11-21 09:17:11,785 TRACE [com.arjuna.ats.arjuna] (default task-8) Packing action status of ActionStatus.ABORTING2016-11-21 09:17:11,785 TRACE [com.arjuna.ats.arjuna] (default task-8) FileSystemStore.write_committed(0:ffff7f000001:-359c90f5:5832ad62:27, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction)2016-11-21 09:17:11,785 TRACE [com.arjuna.ats.arjuna] (default task-8) ShadowingStore.write_state(0:ffff7f000001:-359c90f5:5832ad62:27, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction, StateType.OS_ORIGINAL)2016-11-21 09:17:11,785 TRACE [com.arjuna.ats.arjuna] (default task-8) ShadowingStore.genPathName(0:ffff7f000001:-359c90f5:5832ad62:27, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction, StateType.OS_ORIGINAL)
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 5 months
[JBoss JIRA] (JBTM-2790) Blacktie btadmin ResumeDomainTest failure
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-2790?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson commented on JBTM-2790:
-------------------------------------
The message to pause the server does not seem to be received at testsui1 14046 is the message ID I think on the app server Stomp sent but I can;t see it getting received.
> Blacktie btadmin ResumeDomainTest failure
> -----------------------------------------
>
> Key: JBTM-2790
> URL: https://issues.jboss.org/browse/JBTM-2790
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: BlackTie, Testing
> Reporter: Amos Feng
> Assignee: Amos Feng
> Priority: Minor
>
> It looks like the ResumeDomainTest.setUp() sends the "pauseDomain' command but can not receive the response from the jboss-as server.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 5 months
[JBoss JIRA] (JBTM-2805) Karaf fails to build in CI
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-2805?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated JBTM-2805:
--------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> Karaf fails to build in CI
> --------------------------
>
> Key: JBTM-2805
> URL: https://issues.jboss.org/browse/JBTM-2805
> Project: JBoss Transaction Manager
> Issue Type: Task
> Components: Build System
> Reporter: Tom Jenkinson
> Assignee: Amos Feng
>
> We should try to avoid building Karaf in CI.
> At this point it fails to build.
> {code}
> [INFO] --- maven-resources-plugin:2.7:resources (process-resources) @ apache-karaf-minimal ---
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> [INFO] Copying 4 resources
> [INFO]
> [INFO] --- karaf-maven-plugin:4.1.0-SNAPSHOT:assembly (process-resources) @ apache-karaf-minimal ---
> [INFO] ------------------------------------------------------------------------
> [INFO] Reactor Summary:
> [INFO]
> [INFO] Apache Karaf ....................................... SUCCESS [ 4.795 s]
> [INFO] Apache Karaf :: JAAS ............................... SUCCESS [ 0.017 s]
> [INFO] Apache Karaf :: JAAS :: Boot ....................... SUCCESS [ 2.413 s]
> [INFO] Apache Karaf :: Util ............................... SUCCESS [ 4.843 s]
> [INFO] Apache Karaf :: Main ............................... SUCCESS [ 11.143 s]
> [INFO] Apache Karaf :: Features ........................... SUCCESS [ 0.012 s]
> [INFO] Apache Karaf :: Features :: Extension .............. SUCCESS [ 0.157 s]
> [INFO] Apache Karaf :: Service ............................ SUCCESS [ 0.012 s]
> [INFO] Apache Karaf :: Service :: Guard ................... SUCCESS [ 8.831 s]
> [INFO] Apache Karaf :: Shell .............................. SUCCESS [ 0.010 s]
> [INFO] Apache Karaf :: Shell :: Core ...................... SUCCESS [ 6.523 s]
> [INFO] Apache Karaf :: Tooling ............................ SUCCESS [ 0.013 s]
> [INFO] Apache Karaf :: Tooling :: Maven Karaf Plugin for Services Metadata SUCCESS [ 58.898 s]
> [INFO] Apache Karaf :: Features :: Core ................... SUCCESS [ 5.522 s]
> [INFO] Apache Karaf :: Features :: Command ................ SUCCESS [ 0.845 s]
> [INFO] Apache Karaf :: KAR :: Core ........................ SUCCESS [ 0.869 s]
> [INFO] Apache Karaf :: JAAS :: Config ..................... SUCCESS [ 7.906 s]
> [INFO] Apache Karaf :: JAAS :: Modules .................... SUCCESS [ 18.313 s]
> [INFO] Apache Karaf :: Bundle ............................. SUCCESS [ 0.009 s]
> [INFO] Apache Karaf :: Bundle :: Core ..................... SUCCESS [ 1.076 s]
> [INFO] Apache Karaf :: Bundle :: BlueprintStateService .... SUCCESS [ 0.095 s]
> [INFO] Apache Karaf :: Bundle :: SpringStateService ....... SUCCESS [ 8.690 s]
> [INFO] Apache Karaf :: ConfigAdmin :: Core ................ SUCCESS [ 0.454 s]
> [INFO] Apache Karaf :: Tooling :: Utils ................... SUCCESS [ 2.911 s]
> [INFO] Apache Karaf :: Deployer ........................... SUCCESS [ 0.007 s]
> [INFO] Apache Karaf :: Deployer :: Blueprint .............. SUCCESS [ 2.328 s]
> [INFO] Apache Karaf :: Deployer :: Spring ................. SUCCESS [ 0.166 s]
> [INFO] Apache Karaf :: Demos :: Profiles :: Registry ...... SUCCESS [ 0.031 s]
> [INFO] Apache Karaf :: Profile :: Core .................... SUCCESS [ 9.123 s]
> [INFO] Apache Karaf :: Instance :: Core ................... SUCCESS [ 1.096 s]
> [INFO] Apache Karaf :: Package :: Core .................... SUCCESS [ 0.316 s]
> [INFO] Apache Karaf :: HTTP :: Core ....................... SUCCESS [ 3.623 s]
> [INFO] Apache Karaf :: Service :: Core .................... SUCCESS [ 0.323 s]
> [INFO] Apache Karaf :: Log :: Core ........................ SUCCESS [ 4.122 s]
> [INFO] Apache Karaf :: Deployer :: Features ............... SUCCESS [ 0.568 s]
> [INFO] Apache Karaf :: Deployer :: Karaf Archive (.kar) ... SUCCESS [ 0.491 s]
> [INFO] Apache Karaf :: Deployer :: Wrap Non OSGi Jar ...... SUCCESS [ 0.100 s]
> [INFO] Apache Karaf :: Shell :: Various Commands .......... SUCCESS [ 0.471 s]
> [INFO] Apache Karaf :: Shell :: Console ................... SUCCESS [ 3.362 s]
> [INFO] Apache Karaf :: Shell :: Table ..................... SUCCESS [ 0.111 s]
> [INFO] Apache Karaf :: Shell :: SSH ....................... SUCCESS [ 2.032 s]
> [INFO] Apache Karaf :: JAAS :: Jasypt Encryption .......... SUCCESS [ 2.921 s]
> [INFO] Apache Karaf :: JAAS :: Command .................... SUCCESS [ 0.492 s]
> [INFO] Apache Karaf :: JAAS :: Blueprint .................. SUCCESS [ 0.007 s]
> [INFO] Apache Karaf :: JAAS :: Blueprint :: Config ........ SUCCESS [ 0.081 s]
> [INFO] Apache Karaf :: JAAS :: Blueprint :: Jasypt ........ SUCCESS [ 1.509 s]
> [INFO] Apache Karaf :: Client ............................. SUCCESS [ 0.164 s]
> [INFO] Apache Karaf :: Management ......................... SUCCESS [ 0.008 s]
> [INFO] Apache Karaf :: Management ......................... SUCCESS [ 0.212 s]
> [INFO] Apache Karaf :: System :: Core ..................... SUCCESS [ 0.329 s]
> [INFO] Apache Karaf :: Web :: Core ........................ SUCCESS [ 0.328 s]
> [INFO] Apache Karaf :: Wrapper :: Core .................... SUCCESS [ 0.667 s]
> [INFO] Apache Karaf :: Web Console ........................ SUCCESS [ 0.007 s]
> [INFO] Apache Karaf :: Web Console :: Console ............. SUCCESS [ 3.205 s]
> [INFO] Apache Karaf :: Web Console :: Features Plugin ..... SUCCESS [ 0.559 s]
> [INFO] Apache Karaf :: Web Console :: Gogo Plugin ......... SUCCESS [ 0.617 s]
> [INFO] Apache Karaf :: Web Console :: HTTP Plugin ......... SUCCESS [ 0.567 s]
> [INFO] Apache Karaf :: Web Console :: Instance Plugin ..... SUCCESS [ 0.224 s]
> [INFO] Apache Karaf :: Exception .......................... SUCCESS [ 0.031 s]
> [INFO] Apache Karaf :: Scheduler :: Core .................. SUCCESS [ 3.628 s]
> [INFO] Apache Karaf :: Declarative Services (DS) .......... SUCCESS [ 0.007 s]
> [INFO] Apache Karaf :: SCR :: Shell Commands .............. SUCCESS [ 3.391 s]
> [INFO] Apache Karaf :: SCR :: Management MBeans ........... SUCCESS [ 1.491 s]
> [INFO] Apache Karaf :: SCR :: Bundle State ................ SUCCESS [ 0.176 s]
> [INFO] Apache Karaf :: SCR :: Examples .................... SUCCESS [ 0.006 s]
> [INFO] Apache Karaf :: SCR :: Examples :: Basic Service ... SUCCESS [ 0.060 s]
> [INFO] Apache Karaf :: SCR :: Examples :: Managed Services SUCCESS [ 0.076 s]
> [INFO] Apache Karaf :: SCR :: Examples :: Component Factories SUCCESS [ 0.063 s]
> [INFO] Apache Karaf :: Diagnostic ......................... SUCCESS [ 0.007 s]
> [INFO] Apache Karaf :: Diagnostic :: Boot ................. SUCCESS [ 0.096 s]
> [INFO] Apache Karaf :: Diagnostic :: Core ................. SUCCESS [ 0.748 s]
> [INFO] Apache Karaf :: OBR :: Core ........................ SUCCESS [ 1.771 s]
> [INFO] Apache Karaf :: JNDI :: Core ....................... SUCCESS [ 1.765 s]
> [INFO] Apache Karaf :: JDBC :: Core ....................... SUCCESS [ 0.410 s]
> [INFO] Apache Karaf :: JMS :: Core ........................ SUCCESS [ 6.591 s]
> [INFO] Apache Karaf :: Features ........................... SUCCESS [ 0.006 s]
> [INFO] Apache Karaf :: JPA :: Parent ...................... SUCCESS [ 0.006 s]
> [INFO] Apache Karaf :: JPA :: Hibernate ................... SUCCESS [ 8.436 s]
> [INFO] Apache Karaf :: OSGi Services :: Coordinator ....... SUCCESS [ 1.763 s]
> [INFO] Apache Karaf :: OSGi Services :: EventAdmin ........ SUCCESS [ 1.511 s]
> [INFO] Apache Karaf :: OSGi Services :: Static ConfigAdmin SUCCESS [ 0.087 s]
> [INFO] Apache Karaf :: OSGi Services ...................... SUCCESS [ 0.006 s]
> [INFO] Apache Karaf :: Subsystem :: Core .................. SUCCESS [ 5.008 s]
> [INFO] Apache Karaf :: OSGi Services :: Event ............. SUCCESS [ 1.709 s]
> [INFO] Apache Karaf :: Tooling :: Maven Karaf Plugin ...... SUCCESS [ 7.875 s]
> [INFO] Apache Karaf :: Assemblies ......................... SUCCESS [ 0.008 s]
> [INFO] Apache Karaf :: Assemblies :: Features ............. SUCCESS [ 0.006 s]
> [INFO] Apache Karaf :: Assemblies :: Features :: Base ..... SUCCESS [ 3.828 s]
> [INFO] Apache Karaf :: Assemblies :: Features :: Framework SUCCESS [ 2.555 s]
> [INFO] Apache Karaf :: Assemblies :: Features :: Static ... SUCCESS [ 1.836 s]
> [INFO] Apache Karaf :: Assemblies :: Features :: Standard . SUCCESS [01:12 min]
> [INFO] Apache Karaf :: Assemblies :: Features :: Spring ... SUCCESS [01:19 min]
> [INFO] Apache Karaf :: Assemblies :: Features :: Enterprise SUCCESS [ 42.574 s]
> [INFO] Apache Karaf :: Assemblies :: Demos ................ SUCCESS [ 0.075 s]
> [INFO] Apache Karaf :: Assemblies :: Minimal Distribution . FAILURE [ 0.097 s]
> [INFO] Apache Karaf :: Assemblies :: Default Distribution . SKIPPED
> [INFO] Apache Karaf :: Demos .............................. SKIPPED
> [INFO] Apache Karaf :: Demos :: Web ....................... SKIPPED
> [INFO] Apache Karaf :: Demos :: Branding :: Shell ......... SKIPPED
> [INFO] Apache Karaf :: Demos :: Command :: Extend Console . SKIPPED
> [INFO] Apache Karaf :: Demos :: Demo Dump provider ........ SKIPPED
> [INFO] Apache Karaf :: Demos :: Deployer .................. SKIPPED
> [INFO] Apache Karaf :: Demos :: Deployer :: Kar ........... SKIPPED
> [INFO] Apache Karaf :: Demos :: Deployer :: Bundle ........ SKIPPED
> [INFO] Apache Karaf :: Demos :: Profiles :: Dynamic Assembly SKIPPED
> [INFO] Apache Karaf :: Demos :: Profiles :: Static Assembly SKIPPED
> [INFO] Apache Karaf :: Demos :: Profiles .................. SKIPPED
> [INFO] Apache Karaf :: Archetypes ......................... SKIPPED
> [INFO] Apache Karaf :: Archetypes :: Assembly Archetype ... SKIPPED
> [INFO] Apache Karaf :: Archetypes :: Command Archetype .... SKIPPED
> [INFO] Apache Karaf :: Archetypes :: Feature Archetype .... SKIPPED
> [INFO] Apache Karaf :: Archetypes :: Kar Archetype ........ SKIPPED
> [INFO] Apache Karaf :: Archetypes :: Bundle Archetype ..... SKIPPED
> [INFO] Apache Karaf :: Archetypes :: Blueprint Archetype .. SKIPPED
> [INFO] Apache Karaf :: Integration Tests .................. SKIPPED
> [INFO] ------------------------------------------------------------------------
> [INFO] BUILD FAILURE
> [INFO] ------------------------------------------------------------------------
> [INFO] Total time: 07:17 min
> [INFO] Finished at: 2016-11-29T00:19:34+00:00
> [INFO] Final Memory: 165M/1003M
> [INFO] ------------------------------------------------------------------------
> [ERROR] Failed to execute goal org.apache.karaf.tooling:karaf-maven-plugin:4.1.0-SNAPSHOT:assembly (process-resources) on project apache-karaf-minimal: Unable to parse configuration of mojo org.apache.karaf.tooling:karaf-maven-plugin:4.1.0-SNAPSHOT:assembly for parameter pidsToExtract: Cannot assign configuration entry 'pidsToExtract' with value '!jmx.acl.*,
> [ERROR] !org.apache.karaf.command.acl.*,
> [ERROR] *' of type java.lang.String to property of type java.util.List
> [ERROR] -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please read the following articles:
> [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/PluginConfigurationExcep...
> [ERROR]
> [ERROR] After correcting the problems, you can resume the build with the command
> [ERROR] mvn <goals> -rf :apache-karaf-minimal
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 5 months