[JBoss JIRA] (JBTM-3145) LRA TCK test failure on CI
by Michael Musgrove (Jira)
[ https://issues.jboss.org/browse/JBTM-3145?page=com.atlassian.jira.plugin.... ]
Work on JBTM-3145 started by Michael Musgrove.
----------------------------------------------
> LRA TCK test failure on CI
> --------------------------
>
> Key: JBTM-3145
> URL: https://issues.jboss.org/browse/JBTM-3145
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: LRA
> Affects Versions: 5.9.5.Final
> Reporter: Michael Musgrove
> Assignee: Michael Musgrove
> Priority: Major
> Fix For: 5.9.6.Final
>
>
> The test TckTests#timeLimit fails every time on the JDK 11 CI run (but not on JDK 8). For example
> http://narayanaci1.eng.hst.ams2.redhat.com/job/narayana/426/PROFILE=LRA,j...
> It is also failing consistently on JDK8 (after the the migration to thorntail) with:
> [INFO] [lra-coordinator-it-test] 2019-06-06 20:19:46,751 WARN [org.jboss.resteasy.resteasy_jaxrs.i18n] (ForkJoinPool.commonPool-worker-26) RESTEASY002120: ClassNotFoundException: Unable to load builtin provider org.jboss.resteasy.plugins.providers.jaxb.JAXBXmlSeeAlsoProvider from jar:file:/tmp/thorntailresteasy-jaxb-provider-3.6.2.Final3540226414131235050.jar!/META-INF/services/javax.ws.rs.ext.Providers: java.lang.ClassNotFoundException: org.jboss.resteasy.plugins.providers.jaxb.JAXBXmlSeeAlsoProvider
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
4 years, 7 months
[JBoss JIRA] (JBTM-3188) Location of the lock store is not configurable
by Michael Musgrove (Jira)
[ https://issues.jboss.org/browse/JBTM-3188?page=com.atlassian.jira.plugin.... ]
Michael Musgrove updated JBTM-3188:
-----------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> Location of the lock store is not configurable
> ----------------------------------------------
>
> Key: JBTM-3188
> URL: https://issues.jboss.org/browse/JBTM-3188
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: Transaction Core
> Affects Versions: 5.9.8.Final
> Reporter: Michael Musgrove
> Assignee: Michael Musgrove
> Priority: Major
> Fix For: 5.next
>
>
> During LockManager initialisation there is some code that instantiates an object store bean directly (using the new operator) but this bypasses the config properties. In particular the results in the creation of an object store relative to the current directory instead of the configured store location.
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
4 years, 7 months
[JBoss JIRA] (JBTM-3188) Location of the lock store is not configurable
by Michael Musgrove (Jira)
[ https://issues.jboss.org/browse/JBTM-3188?page=com.atlassian.jira.plugin.... ]
Issue was automatically transitioned when Michael Musgrove created pull request #1497 in GitHub
-----------------------------------------------------------------------------------------------
Status: Pull Request Sent (was: Open)
> Location of the lock store is not configurable
> ----------------------------------------------
>
> Key: JBTM-3188
> URL: https://issues.jboss.org/browse/JBTM-3188
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: Transaction Core
> Affects Versions: 5.9.8.Final
> Reporter: Michael Musgrove
> Assignee: Michael Musgrove
> Priority: Major
> Fix For: 5.next
>
>
> During LockManager initialisation there is some code that instantiates an object store bean directly (using the new operator) but this bypasses the config properties. In particular the results in the creation of an object store relative to the current directory instead of the configured store location.
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
4 years, 7 months
[JBoss JIRA] (JBTM-3188) Location of the lock store is not configurable
by Michael Musgrove (Jira)
Michael Musgrove created JBTM-3188:
--------------------------------------
Summary: Location of the lock store is not configurable
Key: JBTM-3188
URL: https://issues.jboss.org/browse/JBTM-3188
Project: JBoss Transaction Manager
Issue Type: Bug
Components: Transaction Core
Affects Versions: 5.9.8.Final
Reporter: Michael Musgrove
Assignee: Michael Musgrove
Fix For: 5.next
During LockManager initialisation there is some code that instantiates an object store bean directly (using the new operator) but this bypasses the config properties. In particular the results in the creation of an object store relative to the current directory instead of the configured store location.
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
4 years, 7 months
[JBoss JIRA] (JBTM-3182) Fix basic LRA tests
by Martin Stefanko (Jira)
[ https://issues.jboss.org/browse/JBTM-3182?page=com.atlassian.jira.plugin.... ]
Martin Stefanko edited comment on JBTM-3182 at 9/9/19 4:33 AM:
---------------------------------------------------------------
[~mmusgrov] I'm afraid this is not possible if we don't want to break the entire history of Narayana [0]. The renaming of file is not tracked by git. However, history is preserved in form of follow version of the git log command. Can you please try to run:
{code:java}
git log --follow lra-test/lra-test-tck/pom.xml
{code}
would that be sufficient for you? Unfortunately, there is no option to display this directly in GitHub yet [1] but it seems that it will be there in the future. In the meantime, git blame works even in GitHub UI.
[0] https://stackoverflow.com/questions/2314652/is-it-possible-to-move-rename...
[1] https://stackoverflow.com/questions/5646174/how-to-make-github-follow-dir...
was (Author: mstefank):
[~mmusgrov] I'm afraid this is not possible if we don't want to break the entire history of Narayana [0]. The renaming of file is not tracked by git. However, history is preserved in form of follow version of the git log command. Can you please try to run:
{code:java}
git log --follow lra-test/lra-test-tck/pom.xml
{code}
would that be sufficient for you? Unfortunately, there is no option to display this directly in GitHub yet [1] but there seems that it will be there in the future. In the meantime, git blame works even in GitHub UI.
[0] https://stackoverflow.com/questions/2314652/is-it-possible-to-move-rename...
[1] https://stackoverflow.com/questions/5646174/how-to-make-github-follow-dir...
> Fix basic LRA tests
> -------------------
>
> Key: JBTM-3182
> URL: https://issues.jboss.org/browse/JBTM-3182
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: LRA
> Affects Versions: 5.9.7.Final
> Reporter: Martin Stefanko
> Assignee: Martin Stefanko
> Priority: Major
> Fix For: 5.9.8.Final
>
>
> lra-test/basic is unable to run because of wrong CDI configuration after latest LRA upgrade:
> {code:java}
> ERROR [org.jboss.resteasy.resteasy_jaxrs.i18n] (default task-1) RESTEASY002025: Unknown exception while executing GET /root/participant/lra: java.lang.NullPointerException
> at io.narayana.lra.filter.ServerLRAFilter.filter(ServerLRAFilter.java:311)
> {code}
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
4 years, 7 months
[JBoss JIRA] (JBTM-3182) Fix basic LRA tests
by Martin Stefanko (Jira)
[ https://issues.jboss.org/browse/JBTM-3182?page=com.atlassian.jira.plugin.... ]
Martin Stefanko commented on JBTM-3182:
---------------------------------------
[~mmusgrov] I'm afraid this is not possible if we don't want to break the entire history of Narayana [0]. The renaming of file is not tracked by git. However, history is preserved in form of follow version of the git log command. Can you please try to run:
{code:java}
git log --follow lra-test/lra-test-tck/pom.xml
{code}
would that be sufficient for you? Unfortunately, there is no option to display this directly in GitHub yet [1] but there seems that it will be there in the future. In the meantime, git blame works even in GitHub UI.
[0] https://stackoverflow.com/questions/2314652/is-it-possible-to-move-rename...
[1] https://stackoverflow.com/questions/5646174/how-to-make-github-follow-dir...
> Fix basic LRA tests
> -------------------
>
> Key: JBTM-3182
> URL: https://issues.jboss.org/browse/JBTM-3182
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: LRA
> Affects Versions: 5.9.7.Final
> Reporter: Martin Stefanko
> Assignee: Martin Stefanko
> Priority: Major
> Fix For: 5.9.8.Final
>
>
> lra-test/basic is unable to run because of wrong CDI configuration after latest LRA upgrade:
> {code:java}
> ERROR [org.jboss.resteasy.resteasy_jaxrs.i18n] (default task-1) RESTEASY002025: Unknown exception while executing GET /root/participant/lra: java.lang.NullPointerException
> at io.narayana.lra.filter.ServerLRAFilter.filter(ServerLRAFilter.java:311)
> {code}
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
4 years, 7 months
[JBoss JIRA] (JBTM-3145) LRA TCK test failure on CI
by Michael Musgrove (Jira)
[ https://issues.jboss.org/browse/JBTM-3145?page=com.atlassian.jira.plugin.... ]
Michael Musgrove reopened JBTM-3145:
------------------------------------
TckTests#timeLimit is failing again
> LRA TCK test failure on CI
> --------------------------
>
> Key: JBTM-3145
> URL: https://issues.jboss.org/browse/JBTM-3145
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: LRA
> Affects Versions: 5.9.5.Final
> Reporter: Michael Musgrove
> Assignee: Michael Musgrove
> Priority: Major
> Fix For: 5.9.6.Final
>
>
> The test TckTests#timeLimit fails every time on the JDK 11 CI run (but not on JDK 8). For example
> http://narayanaci1.eng.hst.ams2.redhat.com/job/narayana/426/PROFILE=LRA,j...
> It is also failing consistently on JDK8 (after the the migration to thorntail) with:
> [INFO] [lra-coordinator-it-test] 2019-06-06 20:19:46,751 WARN [org.jboss.resteasy.resteasy_jaxrs.i18n] (ForkJoinPool.commonPool-worker-26) RESTEASY002120: ClassNotFoundException: Unable to load builtin provider org.jboss.resteasy.plugins.providers.jaxb.JAXBXmlSeeAlsoProvider from jar:file:/tmp/thorntailresteasy-jaxb-provider-3.6.2.Final3540226414131235050.jar!/META-INF/services/javax.ws.rs.ext.Providers: java.lang.ClassNotFoundException: org.jboss.resteasy.plugins.providers.jaxb.JAXBXmlSeeAlsoProvider
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
4 years, 7 months
[JBoss JIRA] (JBTM-3180) LRARecord http compliance: Entity null for PUT
by Michael Musgrove (Jira)
[ https://issues.jboss.org/browse/JBTM-3180?page=com.atlassian.jira.plugin.... ]
Michael Musgrove updated JBTM-3180:
-----------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> LRARecord http compliance: Entity null for PUT
> ----------------------------------------------
>
> Key: JBTM-3180
> URL: https://issues.jboss.org/browse/JBTM-3180
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: LRA
> Affects Versions: 5.9.7.Final
> Reporter: Paul Parkinson
> Assignee: Michael Musgrove
> Priority: Minor
>
> LRARecord has...
> case "javax.ws.rs.PUT":
> return asyncInvoker.put(Entity.text(null));
> whereas entity should never be null for PUT
> I see this comment has been there since the code was first added and so perhaps this is the desired...
> // return asyncInvoker.put(Entity.entity(compensatorData, mediaType));
> If not perhaps simply Entity.text("") should suffice (and has in my tests).
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
4 years, 7 months
[JBoss JIRA] (JBTM-3186) Safeguard LRA filters for situations when CDI is not available
by Michael Musgrove (Jira)
[ https://issues.jboss.org/browse/JBTM-3186?page=com.atlassian.jira.plugin.... ]
Michael Musgrove updated JBTM-3186:
-----------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> Safeguard LRA filters for situations when CDI is not available
> ---------------------------------------------------------------
>
> Key: JBTM-3186
> URL: https://issues.jboss.org/browse/JBTM-3186
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: LRA
> Reporter: Martin Stefanko
> Assignee: Martin Stefanko
> Priority: Major
>
> When CDI is not available in LRA microservice, following exception is thrown:
> {code:java}
> Caused by: java.lang.NullPointerException
> at io.narayana.lra.filter.ServerLRAFilter.filter(ServerLRAFilter.java:311)
> {code}
> This is thrown because CDI is not available in the container. The check for null injection can prohibit this behavior and LRA can still function for REST-based services in case CDI is not present.
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
4 years, 7 months