Lraid managed executor #206
Conversation
|
I can see the failure in the mp lra tests. |
It is a class from the regular Jakarta Concurrency API. On the WildFly instance I downloaded locally (or download automatically with the -Pdownload profile) that API is available. Maybe the test uses a specifically provisioned WildFly instance that excludes this API? EDIT: I noticed a couple of mistakes I made. I assumed that the /test/pom.xml would somewhere already patch whatever WildFly is being used with the last build Narayana LRA (as is common for e.g. GlassFish tests), but this doesn't happen. The Github action in combination with the ./scripts/hudson/narayana.sh script build WildFly on the uhh fly, with the version of Narayana to use via a -D property. And indeed, the JBoss Modules module for Narayana needs to declare its dependencies, and it now hasn't declared the Jakarta Concurrency dependency. I'll look again at the PR and will try to fix it. EDIT2: It gets a bit more confusing, as for the Arquillian tests Narayana LRA is added to the war itself when participants are added: public static WebArchive deploy(String appName, Class... participants) {
// manifest for WildFly deployment
final String ManifestMF = "Manifest-Version: 1.0\n"
+ "Dependencies: org.jboss.jandex, org.jboss.logging\n";
return ShrinkWrap.create(WebArchive.class, appName + ".war")
.addPackages(true,
"org.eclipse.microprofile.lra",
"io.narayana.lra.client.internal.proxy",
"io.smallrye.stork",
"io.smallrye.mutiny") // try to pull in everything under mutiny)
.addPackages(false,
"io.narayana.lra",
"io.narayana.lra.logging",
"io.narayana.lra.filter",
"io.narayana.lra.provider",
"io.narayana.lra.client",
"io.narayana.lra.client.internal",
"io.narayana.lra.arquillian.spi",
"io.smallrye.stork",
"io.smallrye.mutiny", // recursive addPacakges doesn't seem to resolve the missing classes, so:
"io.smallrye.mutiny.helpers",
"io.smallrye.mutiny.operators.multi",
"io.smallrye.mutiny.subscription",
"io.smallrye.mutiny.helpers.spies",
"io.smallrye.mutiny.helpers.test")
// adds the TestBase class, the test class itself seems to be uploaded during deployment by Arquillian
// then it requires the parent class as well, otherwise Weld NoClassDefFoundError is shown
.addClass(TestBase.class)
// adds the lra-participant wanted
.addClasses(participants)
// activates Wildfly modules
.addAsManifestResource(new StringAsset(ManifestMF), "MANIFEST.MF")
// activates the bean and explicitly specifies to work with annotated classes
.addAsWebInfResource(new StringAsset("<beans version=\"1.1\" bean-discovery-mode=\"all\"></beans>"),
"beans.xml")
.addAsResource(new StringAsset("org.jboss.resteasy.client.jaxrs.ResteasyClientBuilder"),
"META-INF/services/jakarta.ws.rs.client.ClientBuilder");
} |
|
@marcosgopen the tests now pass. I've also provided some additional comments that explain how the tests are structured. If this PR is merged and LRA 1.0.4.Final is added into WildFly, an update to the |
|
Thanks @arjantijms , tomorrow I will have a deeper look to the PR. Could you also create a PR for WildFly to update the module.xml? I can help with that if you want. |
|
@arjantijms Could you please review this PR : jbosstm/jboss-as#100 |
Includes a Jakarta EE provider and specifically for Quarkus a provider based on MicroProfile Context Propagation. Main code is in ClientLRAContextProviderEE Includes tests in a variation for WildFly, and an extra test (in an extra test folder) for Quarkus (using WildFly for the coordinator and for hosting the services being called from the initiating LRA on Quarkus) The async test (doing two requests right after each other to different services on the same WildFly instance) triggered a race condition in Current. This is fixed as well.
Fixed test classes also sending backup LRA header in REST request (the tests should rely fully on the context propagation) Updated downloaded WildFly with LRA client jars (but not used yet, as LRA classes are added to the test wars now) Fixed setting debugging mode for participant wildfly instance.
arjantijms
force-pushed
the
lraid_managed_executor
branch
from
7095f90 to
34f73ad
Compare
I did the review of the PR for jboss-as, and have done an initial rebase to solve the conflicts. I can further rebase (squash commits) after we removed that last commit in this PR. |
| <artifactId>maven-antrun-plugin</artifactId> | ||
| <executions> | ||
| <execution> | ||
| <id>replace-lra-jars</id> |
There was a problem hiding this comment.
@arjantijms I understand your reasoning for this change but we historically use narayana.sh to build WildFly with the current version of LRA: see https://github.com/jbosstm/lra/blob/main/scripts/hudson/narayana.sh#L280
Usually we need to run the test with narayana.sh script as we do in our GitHub actions: see https://github.com/jbosstm/lra/blob/main/.github/workflows/lra-profile.yml#L65
OTOH when we use the download profile this might be needed so I am not against this change but my concern is that we are going to configure the WildFly AS in two different places which can add complexity when debugging and for maintenance. As I said I am ok with this change but I will probably work on simplifying the configuration in the future to have a single place responsible for the AS configuration.
There was a problem hiding this comment.
That's okay, thanks!
I was thinking that for the future we could also provide an option to not include the LRA classes in the test war, and rely on those classes as present in the modules folder in WildFly. That's another code path. It should work with either the downloaded WildFly then and the WildFly build by the script.
2 participants
Propagate the LRA ID when using a managed executor service
Includes a Jakarta EE provider and specifically for Quarkus a provider
based on MicroProfile Context Propagation. See #126
Main code is in ClientLRAContextProviderEE
Includes tests in a variation for WildFly, and an extra test (in an
extra test folder) for Quarkus (using WildFly for the coordinator and
for hosting the services being called from the initiating LRA on
Quarkus)
The async test (doing two requests right after each other to different
services on the same WildFly instance) triggered a race condition in
Current. This is fixed as well.
Needs rebasing after #203 is merged.