[JBoss JIRA] (JBTM-3302) New PR job text should include our policy on running checkstyle
by Ondrej Chaloupka (Jira)
[ https://issues.redhat.com/browse/JBTM-3302?page=com.atlassian.jira.plugin... ]
Ondrej Chaloupka updated JBTM-3302:
-----------------------------------
Git Pull Request: https://github.com/jbosstm/narayana/pull/1608
> New PR job text should include our policy on running checkstyle
> ---------------------------------------------------------------
>
> Key: JBTM-3302
> URL: https://issues.redhat.com/browse/JBTM-3302
> Project: JBoss Transaction Manager
> Issue Type: Enhancement
> Components: Build System
> Affects Versions: 5.10.4.Final
> Reporter: Michael Musgrove
> Assignee: Ondrej Chaloupka
> Priority: Major
> Fix For: 5.next
>
>
> The PR text should include the following:
> {quote}
> Our style rules for submitting code are as follows:
>
> * If you add a new file it MUST adhere to our checkstyle ruleset.
> * If you change a file (in a non trivial way) you are allowed (MAY) to reformat the code to conform to our checkstyle ruleset. If you choose not to reformat it then you SHOULD, where possible, try to follow the same style that's already in use for that file.
> Checkstyle is enabled via a boolean property "-Dcheckstyle" to the compilation.
> {quote}
> Note that we need our own property because you cannot override a plugin property that is already set in the plugin configuration section (ie -Dcheckstyle.skip=false does not work). The fix for this issue should include our new -Dcheckstyle property .
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 7 months
[JBoss JIRA] (JBTM-3302) New PR job text should include our policy on running checkstyle
by Ondrej Chaloupka (Jira)
[ https://issues.redhat.com/browse/JBTM-3302?page=com.atlassian.jira.plugin... ]
Ondrej Chaloupka updated JBTM-3302:
-----------------------------------
Status: Pull Request Sent (was: Open)
> New PR job text should include our policy on running checkstyle
> ---------------------------------------------------------------
>
> Key: JBTM-3302
> URL: https://issues.redhat.com/browse/JBTM-3302
> Project: JBoss Transaction Manager
> Issue Type: Enhancement
> Components: Build System
> Affects Versions: 5.10.4.Final
> Reporter: Michael Musgrove
> Assignee: Ondrej Chaloupka
> Priority: Major
> Fix For: 5.next
>
>
> The PR text should include the following:
> {quote}
> Our style rules for submitting code are as follows:
>
> * If you add a new file it MUST adhere to our checkstyle ruleset.
> * If you change a file (in a non trivial way) you are allowed (MAY) to reformat the code to conform to our checkstyle ruleset. If you choose not to reformat it then you SHOULD, where possible, try to follow the same style that's already in use for that file.
> Checkstyle is enabled via a boolean property "-Dcheckstyle" to the compilation.
> {quote}
> Note that we need our own property because you cannot override a plugin property that is already set in the plugin configuration section (ie -Dcheckstyle.skip=false does not work). The fix for this issue should include our new -Dcheckstyle property .
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 7 months
[JBoss JIRA] (JBTM-3302) New PR job text should include our policy on running checkstyle
by Ondrej Chaloupka (Jira)
[ https://issues.redhat.com/browse/JBTM-3302?page=com.atlassian.jira.plugin... ]
Ondrej Chaloupka reassigned JBTM-3302:
--------------------------------------
Assignee: Ondrej Chaloupka
> New PR job text should include our policy on running checkstyle
> ---------------------------------------------------------------
>
> Key: JBTM-3302
> URL: https://issues.redhat.com/browse/JBTM-3302
> Project: JBoss Transaction Manager
> Issue Type: Enhancement
> Components: Build System
> Affects Versions: 5.10.4.Final
> Reporter: Michael Musgrove
> Assignee: Ondrej Chaloupka
> Priority: Major
> Fix For: 5.next
>
>
> The PR text should include the following:
> {quote}
> Our style rules for submitting code are as follows:
>
> * If you add a new file it MUST adhere to our checkstyle ruleset.
> * If you change a file (in a non trivial way) you are allowed (MAY) to reformat the code to conform to our checkstyle ruleset. If you choose not to reformat it then you SHOULD, where possible, try to follow the same style that's already in use for that file.
> Checkstyle is enabled via a boolean property "-Dcheckstyle" to the compilation.
> {quote}
> Note that we need our own property because you cannot override a plugin property that is already set in the plugin configuration section (ie -Dcheckstyle.skip=false does not work). The fix for this issue should include our new -Dcheckstyle property .
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 7 months
[JBoss JIRA] (JBTM-3302) New PR job text should include our policy on running checkstyle
by Ondrej Chaloupka (Jira)
[ https://issues.redhat.com/browse/JBTM-3302?page=com.atlassian.jira.plugin... ]
Ondrej Chaloupka commented on JBTM-3302:
----------------------------------------
As this issue is not assigned I hope it's fine I'm assigning it to me.
> New PR job text should include our policy on running checkstyle
> ---------------------------------------------------------------
>
> Key: JBTM-3302
> URL: https://issues.redhat.com/browse/JBTM-3302
> Project: JBoss Transaction Manager
> Issue Type: Enhancement
> Components: Build System
> Affects Versions: 5.10.4.Final
> Reporter: Michael Musgrove
> Priority: Major
> Fix For: 5.next
>
>
> The PR text should include the following:
> {quote}
> Our style rules for submitting code are as follows:
>
> * If you add a new file it MUST adhere to our checkstyle ruleset.
> * If you change a file (in a non trivial way) you are allowed (MAY) to reformat the code to conform to our checkstyle ruleset. If you choose not to reformat it then you SHOULD, where possible, try to follow the same style that's already in use for that file.
> Checkstyle is enabled via a boolean property "-Dcheckstyle" to the compilation.
> {quote}
> Note that we need our own property because you cannot override a plugin property that is already set in the plugin configuration section (ie -Dcheckstyle.skip=false does not work). The fix for this issue should include our new -Dcheckstyle property .
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 7 months
[JBoss JIRA] (JBTM-3293) LRA coordinator jar cannot be deployed on WildFly
by Martin Stefanko (Jira)
[ https://issues.redhat.com/browse/JBTM-3293?page=com.atlassian.jira.plugin... ]
Martin Stefanko commented on JBTM-3293:
---------------------------------------
[~ochaloup] There is still an option to agree that we won't publish artifact that can be directly deployed to WFLY. If there is a way of how to document this maybe that would be even preferable. However, I will create PR now with the addition of new module to get a few more eyes on this issue.
> LRA coordinator jar cannot be deployed on WildFly
> -------------------------------------------------
>
> Key: JBTM-3293
> URL: https://issues.redhat.com/browse/JBTM-3293
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: LRA
> Affects Versions: 5.10.4.Final
> Reporter: Martin Stefanko
> Assignee: Martin Stefanko
> Priority: Major
> Fix For: 5.next
>
>
> I am not sure whether this should be possible but the lra-coordinator.jar from lra-coordinator-jar module can't be deployed on latest WildFly. The deployment fails with the following error:
> {noformat}
> Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type LRAService with qualifiers @Default
> at injection point [BackedAnnotatedField] @Inject io.narayana.lra.coordinator.api.RecoveryCoordinator.lraService
> at io.narayana.lra.coordinator.api.RecoveryCoordinator.lraService(RecoveryCoordinator.java:0)
> WELD-001474: Class io.narayana.lra.coordinator.domain.service.LRAService is on the classpath, but was ignored because a class it references was not found: com.arjuna.ats.arjuna.recovery.RecoveryModule from [Module "deployment.lra-coordinator.jar" from Service Module Loader].
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 7 months
[JBoss JIRA] (JBTM-3301) Adjust the Narayana Tomcat quickstarts to use the JWS integration and for working on JDK11
by Ondrej Chaloupka (Jira)
[ https://issues.redhat.com/browse/JBTM-3301?page=com.atlassian.jira.plugin... ]
Ondrej Chaloupka updated JBTM-3301:
-----------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 5.next
Resolution: Done
> Adjust the Narayana Tomcat quickstarts to use the JWS integration and for working on JDK11
> ------------------------------------------------------------------------------------------
>
> Key: JBTM-3301
> URL: https://issues.redhat.com/browse/JBTM-3301
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: Quickstarts
> Affects Versions: 5.10.4.Final
> Reporter: Ondrej Chaloupka
> Assignee: Ondrej Chaloupka
> Priority: Major
> Fix For: 5.next
>
>
> Current Tomcat related quickstarts in the Narayana quickstart repo https://github.com/jbosstm/quickstart/tree/5.10.4.Final
> First, use the old integration code of the Narayana-Tomcat from time the integration code was part of the Narayana repo (https://github.com/jbosstm/narayana/tree/5.9.0.Final/tomcat)
> But now it's separated under the standalone project here https://github.com/web-servers/narayana-tomcat
> There is a small trouble with this change as the code for JWS requires a newer version of the Tomcat than it's used in the quickstart now. The Tomcate version update from {{9.0.4}} to up-to-date version is needed as well.
> The Tomcat quickstart does not start on JDK9+ as the newer JDK misses the JAX-B classes directly in the JDK. The dependencies need to be provided as part of the {{war}} archive (or provided to Tomcat classpath in other way).
> A small trouble on the {{run.sh}} shell script used for quickstart execution is that if {{TOMCAT_HOME}} is placed on a path with space in name it fails as the path is not encapsulated with parentheses {{"}}.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 7 months
[JBoss JIRA] (JBTM-3247) Failed LRA records are reported but they not kept
by Michael Musgrove (Jira)
[ https://issues.redhat.com/browse/JBTM-3247?page=com.atlassian.jira.plugin... ]
Michael Musgrove reassigned JBTM-3247:
--------------------------------------
Assignee: Martin Stefanko (was: Michael Musgrove)
> Failed LRA records are reported but they not kept
> -------------------------------------------------
>
> Key: JBTM-3247
> URL: https://issues.redhat.com/browse/JBTM-3247
> Project: JBoss Transaction Manager
> Issue Type: Enhancement
> Components: LRA
> Affects Versions: 5.10.3.Final
> Reporter: Michael Musgrove
> Assignee: Martin Stefanko
> Priority: Blocker
> Fix For: 5.next
>
>
> When an LRA is closed/cancelled and some participants will never be able to complete/compensate then they are placed on the [BasicAction] failedList. The MP-LRA spec only requires that such failures are logged. The narayana implementation does indeed log the failure (using a log WARNING statement) but then removes the transaction record from the object store.
> It would be preferable to leave failed LRA's in the store and allow them to be queried and deleted using the REST coordinator (like we do for recovering LRA's).
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 7 months
[JBoss JIRA] (JBTM-3247) Failed LRA records are reported but they not kept
by Michael Musgrove (Jira)
[ https://issues.redhat.com/browse/JBTM-3247?page=com.atlassian.jira.plugin... ]
Michael Musgrove reassigned JBTM-3247:
--------------------------------------
Assignee: Michael Musgrove (was: Martin Stefanko)
> Failed LRA records are reported but they not kept
> -------------------------------------------------
>
> Key: JBTM-3247
> URL: https://issues.redhat.com/browse/JBTM-3247
> Project: JBoss Transaction Manager
> Issue Type: Enhancement
> Components: LRA
> Affects Versions: 5.10.3.Final
> Reporter: Michael Musgrove
> Assignee: Michael Musgrove
> Priority: Blocker
> Fix For: 5.next
>
>
> When an LRA is closed/cancelled and some participants will never be able to complete/compensate then they are placed on the [BasicAction] failedList. The MP-LRA spec only requires that such failures are logged. The narayana implementation does indeed log the failure (using a log WARNING statement) but then removes the transaction record from the object store.
> It would be preferable to leave failed LRA's in the store and allow them to be queried and deleted using the REST coordinator (like we do for recovering LRA's).
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 7 months