[JBoss JIRA] (JBTM-1905) Use authentication when connecting to GitHub from narayana.sh
by Gytis Trikleris (JIRA)
[ https://issues.jboss.org/browse/JBTM-1905?page=com.atlassian.jira.plugin.... ]
Gytis Trikleris updated JBTM-1905:
----------------------------------
Description: GitHub allows only 60 requests from the same host per hour. Authentication usage increases this number to 5000. (was: GitHub allows only 60 requests from the same host per hour. OAuth usage increases this number to 5000.)
> Use authentication when connecting to GitHub from narayana.sh
> -------------------------------------------------------------
>
> Key: JBTM-1905
> URL: https://issues.jboss.org/browse/JBTM-1905
> Project: JBoss Transaction Manager
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: Build System
> Reporter: Gytis Trikleris
> Assignee: Gytis Trikleris
> Fix For: 5.0.0.M5
>
>
> GitHub allows only 60 requests from the same host per hour. Authentication usage increases this number to 5000.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 8 months
[JBoss JIRA] (JBTM-1905) Use OAuth when connecting to GitHub from narayana.sh
by Gytis Trikleris (JIRA)
Gytis Trikleris created JBTM-1905:
-------------------------------------
Summary: Use OAuth when connecting to GitHub from narayana.sh
Key: JBTM-1905
URL: https://issues.jboss.org/browse/JBTM-1905
Project: JBoss Transaction Manager
Issue Type: Enhancement
Security Level: Public (Everyone can see)
Components: Build System
Reporter: Gytis Trikleris
Assignee: Gytis Trikleris
Fix For: 5.0.0.M5
GitHub allows only 60 requests from the same host per hour. OAuth usage increases this number to 5000.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 8 months
[JBoss JIRA] (JBTM-1893) Update TXProfiler to support Wildfly 8.0.0.Beta1-SNAPSHOT
by Paul Robinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1893?page=com.atlassian.jira.plugin.... ]
Paul Robinson commented on JBTM-1893:
-------------------------------------
Amos,
You can make a start with the current docs. Currently it only deploys to a specific commit of WildFly (see docs). Can you figure out why it doesn't deploy to WildFly master and fix the issue?
When I update the docs to show how to run the tool, you can check that that works on WildFly master.
> Update TXProfiler to support Wildfly 8.0.0.Beta1-SNAPSHOT
> ---------------------------------------------------------
>
> Key: JBTM-1893
> URL: https://issues.jboss.org/browse/JBTM-1893
> Project: JBoss Transaction Manager
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: TxProf
> Reporter: Paul Robinson
> Assignee: Amos Feng
> Priority: Critical
> Fix For: 5.0.0.M5
>
>
> Wait for the docs first, so that you can easily get it up and running.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 8 months
[JBoss JIRA] (JBTM-1898) UndeclaredThrowableException in CompensatableTest.testNeverExistingTX
by Paul Robinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1898?page=com.atlassian.jira.plugin.... ]
Paul Robinson commented on JBTM-1898:
-------------------------------------
Ok, so maybe that's the problem, as the test will hang until it sees the expected number of completes.
> UndeclaredThrowableException in CompensatableTest.testNeverExistingTX
> ---------------------------------------------------------------------
>
> Key: JBTM-1898
> URL: https://issues.jboss.org/browse/JBTM-1898
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: TXFramework
> Reporter: Gytis Trikleris
> Assignee: Amos Feng
> Priority: Minor
> Fix For: 5.0.0.M5
>
>
> http://172.17.131.2/view/Narayana+BlackTie/job/narayana-codeCoverage/68/c...
> {code}
> [0mAug 23, 2013 8:06:55 PM org.jboss.arquillian.protocol.jmx.JMXMethodExecutor invoke
> SEVERE: Failed: org.jboss.narayana.compensations.functional.compensatable.CompensatableTest.testNeverExistingTX
> java.lang.reflect.UndeclaredThrowableException
> at $Proxy21.runTestMethod(Unknown Source)
> at org.jboss.arquillian.protocol.jmx.JMXMethodExecutor.invoke(JMXMethodExecutor.java:71)
> at org.jboss.arquillian.container.test.impl.execution.RemoteTestExecuter.execute(RemoteTestExecuter.java:120)
> at sun.reflect.GeneratedMethodAccessor10.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115)
> at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
> at org.jboss.arquillian.container.test.impl.execution.ClientTestExecuter.execute(ClientTestExecuter.java:57)
> at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createContext(ContainerEventController.java:142)
> at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createTestContext(ContainerEventController.java:129)
> at sun.reflect.GeneratedMethodAccessor8.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:89)
> at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:75)
> at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:60)
> at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135)
> at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:111)
> at org.jboss.arquillian.junit.Arquillian$6.evaluate(Arquillian.java:263)
> at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:226)
> at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314)
> at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46)
> at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:240)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
> at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:185)
> at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314)
> at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46)
> at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:199)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
> at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:147)
> at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
> at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
> at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
> Caused by: java.io.IOException: Unable to invoke invoke(), status=WAITING
> at org.jboss.remotingjmx.protocol.v2.ClientConnection$TheConnection.invoke(ClientConnection.java:1058)
> at org.jboss.as.arquillian.container.ManagementClient$MBeanConnectionProxy.invoke(ManagementClient.java:540)
> at javax.management.MBeanServerInvocationHandler.invoke(MBeanServerInvocationHandler.java:305)
> ... 77 more
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 8 months
[JBoss JIRA] (JBTM-1561) Cannot create a user defined XATMI service
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1561?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson commented on JBTM-1561:
-------------------------------------
Hi Cris,
1. I agree that the blacktie-admin-services ear needs all the servers and services defining in it, this is by design. However, as you say the problem is that those are not embedded within a domain element (servers is a top level element) so it would not work at the moment. It would be possible to modify the code to embed the servers element under domain so we can advertise queues with a specific domain prefix/suffix.
2. I agree, the domain concept has not been fully designed yet. The question is how to approach domain. We could:
i. back out the concept of domain entirely, as you say this has the negative that you can't define different servers which have the same service id in them
ii. allow multiple domains to communicate within a single blacktie stompconnect. Client code would have to send to queues with a domain qualified name if not sending to the default domain.
iii. Modify our approach so that the domain is the set of separate servers that connect via a single blacktie stompconnect service. We probably would not need the <DOMAIN>fooapp</DOMAIN> config in each _servers_ btconfig.xml as the domain is implicity by the connection to the stomp admin service server socket (<MQ HOST="${JBOSSAS_IP_ADDR}" PORT="61613" USER="guest" PASSWORD="password1@" RECEIVE_TIMEOUT="10" TIME_TO_LIVE="40"/>). Different servers should connect to different domains via <MQ> configuration. It would be useful for each blacktie stompconnect _service_ to have access to <DOMAIN> config in order to add a message header identifying the domain it was created within on the JMS messages it creates and then the blacktie stompconnect receiver to apply this as a filter on the queue when receiving messages. As you say there would be no way to call cross domain at the moment and as such btadmin would at least need changing so that it can talk to multiple <MQ> elements for the different domains.
iv. Remove domain support altogether. This is like option 3 but without even embeding the domain identifier as a message property in the stompconnect service.
What do you prefer? I am erring on the side of stripping out domains altogether.
Tom
> Cannot create a user defined XATMI service
> ------------------------------------------
>
> Key: JBTM-1561
> URL: https://issues.jboss.org/browse/JBTM-1561
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: BlackTie, Documentation
> Affects Versions: 5.0.0.M1
> Reporter: Michael Musgrove
> Assignee: Amos Feng
> Fix For: 6.0.0.Final
>
>
> The administrative interface, btadmin, does not support the definition of user defined services. Perhaps this functionality was present in the old RHQ interface and was not ported to btadmin when RHQ support was dropped.
> The documentation set does not describe how to configure user defined services.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 8 months
[JBoss JIRA] (JBTM-1364) Migrate "REST-AT to JTA" bridge into RTS component
by Gytis Trikleris (JIRA)
[ https://issues.jboss.org/browse/JBTM-1364?page=com.atlassian.jira.plugin.... ]
Gytis Trikleris updated JBTM-1364:
----------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> Migrate "REST-AT to JTA" bridge into RTS component
> --------------------------------------------------
>
> Key: JBTM-1364
> URL: https://issues.jboss.org/browse/JBTM-1364
> Project: JBoss Transaction Manager
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Demonstrator, REST, TxBridge
> Reporter: Paul Robinson
> Assignee: Gytis Trikleris
> Priority: Critical
> Labels: assign
> Fix For: 5.0.0.M4
>
> Original Estimate: 1 week
> Time Spent: 1 week, 2 days, 4 hours, 45 minutes
> Remaining Estimate: 0 minutes
>
> The task is to the work Gytis did on his internship and migrate it into the REST-TX project.
> Tasks:
> 1. Review the current solution looking for:
> 1.1 Major issues that prevent an initial release
> 1.2 Test coverage
> 2. Make any required changes
> 3. Merge into the REST-TX project
> 4. Migrate the quickstarts accross
> 5. Create a blog post
> 5.1 Consider what the end user will need to do to use this technology. We may want to wait until REST-AT and this Bridge are shipped with a Narayana build of AS7. Otherwise the steps to get this working could be rather lengthy.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 8 months
[JBoss JIRA] (JBTM-1645) Allow pull requests to configure some parameters in scripts/hudson/narayana.sh
by Gytis Trikleris (JIRA)
[ https://issues.jboss.org/browse/JBTM-1645?page=com.atlassian.jira.plugin.... ]
Gytis Trikleris updated JBTM-1645:
----------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> Allow pull requests to configure some parameters in scripts/hudson/narayana.sh
> ------------------------------------------------------------------------------
>
> Key: JBTM-1645
> URL: https://issues.jboss.org/browse/JBTM-1645
> Project: JBoss Transaction Manager
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Build System
> Reporter: Tom Jenkinson
> Assignee: Gytis Trikleris
> Fix For: 5.0.0.M5
>
> Original Estimate: 4 hours
> Time Spent: 1 hour, 40 minutes
> Remaining Estimate: 0 minutes
>
> If the pull description has something like this:
> export NARAYANA_BUILD=1 AS_BUILD=1 NARAYANA_TESTS=1 TXF_TESTS=1 XTS_TESTS=1 XTS_AS_TESTS=1 txbridge=1 QA_TESTS=1 [SUN_ORB=0] [JAC_ORB=1] [QA_TARGET=ci-jts-tests]
> We could use it in scripts/hudson/narayana.sh if we detect it is a pull build. We might need to white list users we apply this to.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 8 months