[JBoss JIRA] (DROOLS-1048) Change github url from github.com/droolsjbpm/ to github.com/kiegroup/
by Geoffrey De Smet (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1048?page=com.atlassian.jira.plugi... ]
Geoffrey De Smet commented on DROOLS-1048:
------------------------------------------
Extra requirement: *All repository names must match the artifactId of the root pom.*
- repo droolsjbpm-knowledge must be renamed to ...
- pom drools-multiproject must be renamed to drools (to match rep drools)
etc
This is important for automated scripts such as xmvn (which builds RPM's) etc.
> Change github url from github.com/droolsjbpm/ to github.com/kiegroup/
> ---------------------------------------------------------------------
>
> Key: DROOLS-1048
> URL: https://issues.jboss.org/browse/DROOLS-1048
> Project: Drools
> Issue Type: Task
> Components: build
> Reporter: Geoffrey De Smet
> Assignee: Petr Široký
> Priority: Critical
>
> [~mark.proctor] asked me to make an inventory of what would need to happen if we ever migrate from github.com/droolsjbpm/ to github.com/kiegroup/. Technically this issue is very simply (just change it in GitHub), but organizationally this issue is difficult and dangerous: it needs to be done with care.
> Preparation:
> 1) Get some experience
> - Make a dummy repository in droolsjbpm, add some files and a few branches, fork it to your user account, add a PR on it, clone it 2 times:
> -- Once from droolsjbpm
> -- Once from your user account with droolsjbpm addes as upstream ("git remote add upstream ...github.com/droolsjbpm/...")
> - Add some local changes on both dirs.
> - On GitHub, go into the repository settings, in the danger zone and move it from droolsjbpm to kiegroup.
> - Try using it from your 2 local clones ("git pull --rebase" or "git fetch upstream"). Copy paste the error messages for later use.
> -- Fix it locally without recloning, without losing the local changes, etc. Record these steps clearly in a recipe to share with everyone else later.
> -- Once it's fixed, see if you can do git operations without having to specify origin for the direct droolsjbpm clone. See also the git option "-u" - you'll likely have to add in the recipe as an extra step.
> -- What happened to the open PR?
> 2) Clean up our repositories in droolsjbpm. There are a few dead ones that we should not be moving.
> 3) Set up roles and users of github.com/kiegroup.
> 4) Reach out
> - Talk to each type of person involved:
> -- R&D developer
> -- QA
> -- Productization
> -- Product docs
> -- Community
> - Make an inventory of references to "github.com/droolsjbpm"
> -- Do a find in path on all our files for "github.com/droolsjbpm")
> -- Which webapps reference it?
> --- jenkins
> --- jira
> --- www.openhub.net
> --- gitter
> --- stackoverflow
> --- google forums / mailing lists
> --- ...
> - Set a date when you'll be moving the first repository.
> -- Clearly communicate on all channels to let everyone know. This includes:
> --- Public mailing lists and fora: Drools, OptaPlanner, jBPM, ...
> --- Internal mailing lists: sme-brms, pm lists, bsig, etc
> --- IRC channel topics
> --- Social media (Twitter accounts etc)
> --- ...
> - Clearly communicate:
> -- What you'll do
> -- When you'll do it
> -- How strong the freeze is: Can they make local changes meanwhile? Will they lose the open PR's? How will this affect their forks and branches? Answer all these questions proactively, based on your experience. Cropped screenshots are good!
> -- A recipe: What they need to do - step by step for dummies - after the merge is done.
> -- Get someone to review this mail before it goes out.
> - You can't overcommunicate this, but you can undercommunicate it. And there's always going to be 1 person who complains he wasn't told about it and it messes up his work.
> 5) Do it:
> - You can do one repository at a time, or do multiple at the same time.
> -- I'd recommend to start with just 1 to get a feel for it.
> - Do them in reverse order of the repository-list.txt!
> - DELETE THE OLD REPOSITORY. DO NOT COPY IT, BUT MOVE IT.
> -- After the move, we want anyone that's trying to pull from droolsjbpm to clearly *fail* pulling, but without losing local changes.
> -- Some people will not have read your mail, they need to fail when pulling, otherwise they'll find themselves asking in 5 months why we haven't done any changes in 5 months.
> - In droolsjbpm, create a repository called all_repositories_have_moved_to_github_com_kiegroup and make sure it's on the top of the list of the droolsjbpm repositories. Add a link in it's readme.adoc. This is for people who follow dead links from stackoverflow etc.
> - Migrations like this should really happen during the weekend to reduce the impact on the rest of the team, ask your manager to swap a weekday for a weekend day.
> 6) Clean up the fallout
> - Go through your inventory and replace the references as far as humanly reasonable (stackoverflow is likely to be unreasonably, but openhub is not).
> Anyway, that's my 2 cents (from my experience when moving svn to Git and splitting up the monastical build 5 years ago). Do this right and this will be almost a non-event (5 years ago it went pretty well on the engineering side, but less on the product side). Mess this up and this can be a disaster that will antagonize a lot of people...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFLY-5566) org.jboss.as.test.clustering.xsite.XSiteSimpleTestCase#testPutToBackupNotRelayed
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-5566?page=com.atlassian.jira.plugin.... ]
Radoslav Husar closed WFLY-5566.
--------------------------------
Assignee: Radoslav Husar (was: Dmitrii Tikhomirov)
Resolution: Rejected
Labels: (was: clustering_revalidate)
Ok, looked at the code now, each server is using its own mcast group, so they should not cluster. This configuration makes them clustered which is wrong.
> org.jboss.as.test.clustering.xsite.XSiteSimpleTestCase#testPutToBackupNotRelayed
> --------------------------------------------------------------------------------
>
> Key: WFLY-5566
> URL: https://issues.jboss.org/browse/WFLY-5566
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Test Suite
> Affects Versions: 10.0.0.CR2
> Reporter: Ivan Straka
> Assignee: Radoslav Husar
>
> There is org.jboss.as.test.clustering.xsite.XSiteSimpleTestCase#testPutToBackupNotRelayed failing with exception:
> {code:java}
> Error Message
> expected:<500> but was:<200>
> Stacktrace
> java.lang.AssertionError: expected:<500> but was:<200>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:743)
> at org.junit.Assert.assertEquals(Assert.java:118)
> at org.junit.Assert.assertEquals(Assert.java:555)
> at org.junit.Assert.assertEquals(Assert.java:542)
> at org.jboss.as.test.clustering.xsite.XSiteSimpleTestCase.testPutToBackupNotRelayed(XSiteSimpleTestCase.java:202)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFLY-6011) Remote branch of a transaction gets rolled back incorrectly.
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-6011?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-6011:
-----------------------------------------------
Dominik Pospisil <dpospisi(a)redhat.com> changed the Status of [bug 1298161|https://bugzilla.redhat.com/show_bug.cgi?id=1298161] from POST to MODIFIED
> Remote branch of a transaction gets rolled back incorrectly.
> -------------------------------------------------------------
>
> Key: WFLY-6011
> URL: https://issues.jboss.org/browse/WFLY-6011
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Reporter: Jason Greene
> Assignee: David Lloyd
>
> The use case is as follow:
> Client makes a call to a bean on server-1
> bean (server-1) inserts a row into table-1
> bean (server-1) calls to a bean on server-2
> bean (server-2) inserts a row into table-2
> bean (server-2) goes to sleep for 3 minutes
> periodic recovery (server-1) flags the remote branchof the transaction (on server-2) as in doubt and rolls it back.
> (server-1 log)
> {noformat}
> 11:53:37,991 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) RecoveryXids _whenFirstSeen toRecover no RecoveryOnlyEJBXAResource{receiverContext=EJBReceiverContext{clientContext=org.jboss.ejb.client.EJBClientContext@322f7790, receiver=Remoting connection EJB receiver [connection=Remoting connection <2c1ab3f6>,channel=jboss.ejb,nodename=server2]}, transactionOriginNodeIdentifier='server1'} 1452599607985 === 1452599617991
> 11:53:37,991 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) Have 1 Xids to recover on this pass.
> 11:53:37,992 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) No record found for < formatId=131077, gtrid_length=35, bqual_length=43, tx_uid=0:ffffc0a80164:-fa2e9db:5694e833:2c, node_name=server1, branch_uid=0:ffffc0a80164:-fa2e9db:5694e833:39, subordinatenodename=server2, eis_name=unknown eis name >
> 11:53:37,992 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) XAResourceOrphanFilter com.arjuna.ats.internal.jta.recovery.arjunacore.JTATransactionLogXAResourceOrphanFilter voted ABSTAIN
> 11:53:37,993 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) node name of < formatId=131077, gtrid_length=35, bqual_length=43, tx_uid=0:ffffc0a80164:-fa2e9db:5694e833:2c, node_name=server1, branch_uid=0:ffffc0a80164:-fa2e9db:5694e833:39, subordinatenodename=server2, eis_name=unknown eis name > is server1
> 11:53:37,993 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) XAResourceOrphanFilter com.arjuna.ats.internal.jta.recovery.arjunacore.JTANodeNameXAResourceOrphanFilter voted ROLLBACK
> 11:53:37,993 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) subordinate node name of < formatId=131077, gtrid_length=35, bqual_length=43, tx_uid=0:ffffc0a80164:-fa2e9db:5694e833:2c, node_name=server1, branch_uid=0:ffffc0a80164:-fa2e9db:5694e833:39, subordinatenodename=server2, eis_name=unknown eis name > is server2
> 11:53:37,993 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) Checking whether Xid < formatId=131077, gtrid_length=35, bqual_length=43, tx_uid=0:ffffc0a80164:-fa2e9db:5694e833:2c, node_name=server1, branch_uid=0:ffffc0a80164:-fa2e9db:5694e833:39, subordinatenodename=server2, eis_name=unknown eis name > exists in ObjectStore.
> 11:53:37,993 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) Looking for 0:ffffc0a80164:-fa2e9db:5694e833:2c and /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction/SubordinateAtomicAction/JCA
> 11:53:37,993 INFO [com.arjuna.ats.jta] (Periodic Recovery) ARJUNA016013: Rolling back < formatId=131077, gtrid_length=35, bqual_length=43, tx_uid=0:ffffc0a80164:-fa2e9db:5694e833:2c, node_name=server1, branch_uid=0:ffffc0a80164:-fa2e9db:5694e833:39, subordinatenodename=server2, eis_name=unknown eis name >
> {noformat}
> (server-2 log)
> {noformat}
> 11:53:37,997 TRACE [com.arjuna.ats.jta] (EJB default - 5) TransactionImple.getStatus: javax.transaction.Status.STATUS_ACTIVE
> 11:53:37,998 TRACE [com.arjuna.ats.arjuna] (EJB default - 5) BasicAction::phase2Abort() for action-id 0:ffffc0a80164:-41fcd6d0:5694e85a:34
> 11:53:37,998 TRACE [com.arjuna.ats.arjuna] (EJB default - 5) BasicAction::doAbort (XAResourceRecord < resource:XAResourceWrapperImpl@3de8e444[xaResource=org.jboss.jca.adapters.jdbc.xa.XAManagedConnection@6440856e pad=false overrideRmValue=false productName=PostgreSQL productVersion=9.4.1 jndiName=java:jboss/datasources/testJBossDS], txid:< formatId=131077, gtrid_length=35, bqual_length=43, tx_uid=0:ffffc0a80164:-fa2e9db:5694e833:2c, node_name=server1, branch_uid=0:ffffc0a80164:-41fcd6d0:5694e85a:3e, subordinatenodename=server2, eis_name=java:jboss/datasources/testJBossDS >, heuristic: TwoPhaseOutcome.FINISH_OK, product: PostgreSQL/9.4.1, jndiName: java:jboss/datasources/testJBossDS com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord@32ff4c6d >)
> 11:53:37,998 TRACE [com.arjuna.ats.jta] (EJB default - 5) XAResourceRecord.topLevelAbort for XAResourceRecord < resource:XAResourceWrapperImpl@3de8e444[xaResource=org.jboss.jca.adapters.jdbc.xa.XAManagedConnection@6440856e pad=false overrideRmValue=false productName=PostgreSQL productVersion=9.4.1 jndiName=java:jboss/datasources/testJBossDS], txid:< formatId=131077, gtrid_length=35, bqual_length=43, tx_uid=0:ffffc0a80164:-fa2e9db:5694e833:2c, node_name=server1, branch_uid=0:ffffc0a80164:-41fcd6d0:5694e85a:3e, subordinatenodename=server2, eis_name=java:jboss/datasources/testJBossDS >, heuristic: TwoPhaseOutcome.FINISH_OK, product: PostgreSQL/9.4.1, jndiName: java:jboss/datasources/testJBossDS com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord@32ff4c6d >, record id=0:ffffc0a80164:-41fcd6d0:5694e85a:3f
> 11:53:37,998 TRACE [org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService$MyXaMCF] (EJB default - 5) Unlock: HeldByCurrentThread: Yes, Locked: Yes, HoldCount: 1, QueueLength: 0
> 11:53:37,998 TRACE [org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService$MyXaMCF] (EJB default - 5) Owner: Thread[EJB default - 5,5,EJB default]
> 11:53:37,999 TRACE [com.arjuna.ats.arjuna] (EJB default - 5) BasicAction::doAbort() result for action-id (0:ffffc0a80164:-41fcd6d0:5694e85a:34) on record id: (0:ffffc0a80164:-41fcd6d0:5694e85a:3f) is (TwoPhaseOutcome.FINISH_OK) node id: (server2)
> 11:53:37,999 TRACE [com.arjuna.ats.arjuna] (EJB default - 5) BasicAction::updateState() for action-id 0:ffffc0a80164:-41fcd6d0:5694e85a:34
> 11:53:37,999 TRACE [com.arjuna.ats.jta] (EJB default - 5) SynchronizationImple.afterCompletion
> {noformat}
> bean (server-2) wake up
> bean (server-1) updates the row in table-1
> at this point the parent transaction gets committed without an error
> {noformat}
> 11:55:31,104 TRACE [com.arjuna.ats.arjuna] (EJB default - 3) BasicAction::removeChildThread () action 0:ffffc0a80164:-fa2e9db:5694e833:2c removing TSThread:1
> 11:55:31,104 TRACE [com.arjuna.ats.arjuna] (EJB default - 3) BasicAction::removeChildThread () action 0:ffffc0a80164:-fa2e9db:5694e833:2c removing TSThread:1 result = true
> 11:55:31,104 TRACE [com.arjuna.ats.arjuna] (EJB default - 3) TransactionReaper::remove ( BasicAction: 0:ffffc0a80164:-fa2e9db:5694e833:2c status: ActionStatus.COMMITTED )
> {noformat}
> client call ends
> When I look at the table in the database I see a row in table-1 but no row in table-2. I would expect to see both tables empty.
> When I switch to JTS and run the same use case it all works as expected.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFLY-5995) Initial calculation of the first expiration time for a scheduled timer is wrong if a start date is set
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-5995?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-5995:
-----------------------------------------------
Dominik Pospisil <dpospisi(a)redhat.com> changed the Status of [bug 1298651|https://bugzilla.redhat.com/show_bug.cgi?id=1298651] from POST to MODIFIED
> Initial calculation of the first expiration time for a scheduled timer is wrong if a start date is set
> ------------------------------------------------------------------------------------------------------
>
> Key: WFLY-5995
> URL: https://issues.jboss.org/browse/WFLY-5995
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 8.2.1.Final, 9.0.2.Final, 10.0.0.CR5
> Reporter: Wolf-Dieter Fink
> Assignee: Wolf-Dieter Fink
> Labels: timers, timerservice
> Fix For: 10.0.0.Final
>
>
> If a scheduled timer should be created with the following parameters:
> ScheduleExpression[second=0 minute=0/5 hour=20-22 dayOfWeek=* dayOfMonth=* month=* year=* start=Thu Jan 14 09:45:35 GMT+1 2016]
> The first schedule should be
> Thu Jan 17 20:00:20 GMT+1 2016
> but is calculated as
> Sun Jan 17 20:45:35 GMT+1 2016
> The minutes are not correctly set according to the schedule and the given start date.
> This happen for seconds/minutes if the ScheduleExpression limit the range.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFLY-5566) org.jboss.as.test.clustering.xsite.XSiteSimpleTestCase#testPutToBackupNotRelayed
by Ivan Straka (JIRA)
[ https://issues.jboss.org/browse/WFLY-5566?page=com.atlassian.jira.plugin.... ]
Ivan Straka commented on WFLY-5566:
-----------------------------------
I have just run it with property num_initial_members set to 4 and it has failed. IMHO all 4 of them are not supposed to make a cluster (they do) and that is the problem. The value is replicated and it shouldn't be.
> org.jboss.as.test.clustering.xsite.XSiteSimpleTestCase#testPutToBackupNotRelayed
> --------------------------------------------------------------------------------
>
> Key: WFLY-5566
> URL: https://issues.jboss.org/browse/WFLY-5566
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Test Suite
> Affects Versions: 10.0.0.CR2
> Reporter: Ivan Straka
> Assignee: Dmitrii Tikhomirov
> Labels: clustering_revalidate
>
> There is org.jboss.as.test.clustering.xsite.XSiteSimpleTestCase#testPutToBackupNotRelayed failing with exception:
> {code:java}
> Error Message
> expected:<500> but was:<200>
> Stacktrace
> java.lang.AssertionError: expected:<500> but was:<200>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:743)
> at org.junit.Assert.assertEquals(Assert.java:118)
> at org.junit.Assert.assertEquals(Assert.java:555)
> at org.junit.Assert.assertEquals(Assert.java:542)
> at org.jboss.as.test.clustering.xsite.XSiteSimpleTestCase.testPutToBackupNotRelayed(XSiteSimpleTestCase.java:202)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFLY-5566) org.jboss.as.test.clustering.xsite.XSiteSimpleTestCase#testPutToBackupNotRelayed
by Ivan Straka (JIRA)
[ https://issues.jboss.org/browse/WFLY-5566?page=com.atlassian.jira.plugin.... ]
Ivan Straka updated WFLY-5566:
------------------------------
Comment: was deleted
(was: I think, all 4 of them are not supposed to make a cluster. IMHO that is the problem. I have just run it with property num_initial_members set to 4 and it has failed.)
> org.jboss.as.test.clustering.xsite.XSiteSimpleTestCase#testPutToBackupNotRelayed
> --------------------------------------------------------------------------------
>
> Key: WFLY-5566
> URL: https://issues.jboss.org/browse/WFLY-5566
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Test Suite
> Affects Versions: 10.0.0.CR2
> Reporter: Ivan Straka
> Assignee: Dmitrii Tikhomirov
> Labels: clustering_revalidate
>
> There is org.jboss.as.test.clustering.xsite.XSiteSimpleTestCase#testPutToBackupNotRelayed failing with exception:
> {code:java}
> Error Message
> expected:<500> but was:<200>
> Stacktrace
> java.lang.AssertionError: expected:<500> but was:<200>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:743)
> at org.junit.Assert.assertEquals(Assert.java:118)
> at org.junit.Assert.assertEquals(Assert.java:555)
> at org.junit.Assert.assertEquals(Assert.java:542)
> at org.jboss.as.test.clustering.xsite.XSiteSimpleTestCase.testPutToBackupNotRelayed(XSiteSimpleTestCase.java:202)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFLY-5566) org.jboss.as.test.clustering.xsite.XSiteSimpleTestCase#testPutToBackupNotRelayed
by Ivan Straka (JIRA)
[ https://issues.jboss.org/browse/WFLY-5566?page=com.atlassian.jira.plugin.... ]
Ivan Straka commented on WFLY-5566:
-----------------------------------
I think, all 4 of them are not supposed to make a cluster. IMHO that is the problem. I have just run it with property num_initial_members set to 4 and it has failed.
> org.jboss.as.test.clustering.xsite.XSiteSimpleTestCase#testPutToBackupNotRelayed
> --------------------------------------------------------------------------------
>
> Key: WFLY-5566
> URL: https://issues.jboss.org/browse/WFLY-5566
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Test Suite
> Affects Versions: 10.0.0.CR2
> Reporter: Ivan Straka
> Assignee: Dmitrii Tikhomirov
> Labels: clustering_revalidate
>
> There is org.jboss.as.test.clustering.xsite.XSiteSimpleTestCase#testPutToBackupNotRelayed failing with exception:
> {code:java}
> Error Message
> expected:<500> but was:<200>
> Stacktrace
> java.lang.AssertionError: expected:<500> but was:<200>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:743)
> at org.junit.Assert.assertEquals(Assert.java:118)
> at org.junit.Assert.assertEquals(Assert.java:555)
> at org.junit.Assert.assertEquals(Assert.java:542)
> at org.jboss.as.test.clustering.xsite.XSiteSimpleTestCase.testPutToBackupNotRelayed(XSiteSimpleTestCase.java:202)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFCORE-1377) WFLYCTL0201: Unknown attribute 'server-state' using HTTP management API
by Martin Choma (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1377?page=com.atlassian.jira.plugi... ]
Martin Choma commented on WFCORE-1377:
--------------------------------------
Thank you for clarification.
> WFLYCTL0201: Unknown attribute 'server-state' using HTTP management API
> -----------------------------------------------------------------------
>
> Key: WFCORE-1377
> URL: https://issues.jboss.org/browse/WFCORE-1377
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 2.1.0.CR1
> Reporter: Martin Choma
> Assignee: Brian Stansberry
>
> Unable to get server-state using http management API
> {noformat}
> [mchoma@localhost bin]$ curl --digest -L -D - http://localhost:9990/management --header "Content-Type: application/json" -d '{"operation":"read-attribute", "address" : [[{ "host" : "master" },{ "server" : "server-one" }]], "name" : "server-state","json.pretty":1}' -u admin:admin
> HTTP/1.1 401 Unauthorized
> Connection: keep-alive
> WWW-Authenticate: Digest realm="ManagementRealm",domain="/management",nonce="sI2Bu4kJcGgNMTQ1NTYxMDE3OTU2MVc91LWa8HnWzIKZ5I8UIlo=",opaque="00000000000000000000000000000000",algorithm=MD5,qop="auth"
> Content-Length: 77
> Content-Type: text/html
> Date: Tue, 16 Feb 2016 08:09:39 GMT
> HTTP/1.1 500 Internal Server Error
> Connection: keep-alive
> Authentication-Info: nextnonce="sI2Bu4kJcGgNMTQ1NTYxMDE3OTU2MVc91LWa8HnWzIKZ5I8UIlo=",qop="auth",rspauth="8e575a86f8dae40426abd49bbc8f8b8a",cnonce="YmNiNmM4YjA0NmZlYjQ5MzAwMDAyNjIxMDAwODNhODE=",nc=00000001
> Content-Type: application/json; charset=utf-8
> Content-Length: 131
> Date: Tue, 16 Feb 2016 08:09:39 GMT
> {
> "outcome" : "failed",
> "failure-description" : "WFLYCTL0201: Unknown attribute 'server-state'",
> "rolled-back" : true
> {noformat}
> Running analogous CLI command works OK.
> {noformat}
> [domain@127.0.0.1:9999 /] /host=slave/server=main-three:read-attribute(name=server-state)
> {
> "outcome" => "success",
> "result" => "running"
> }
> {noformat}
> Can't get server status neither with
> {noformat}
> curl --digest -L -D - http://localhost:9990/management --header "Content-Type: application/json" -d '{"operation":"read-attribute", "address" : [[{ "host" : "master" },{ "server-config" : "server-one" }]], "name" : "status","json.pretty":1}' -u admin:admin
> ...
> "WFLYCTL0201: Unknown attribute 'status'"
> {noformat}
> Issue can be seen in EAP 6, as well.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months