Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Quarkus 1.8.1.Final + infinispan-client and deletion of Marshaller.class files #9980

Closed
jeffhubLR opened this issue Jun 12, 2020 · 33 comments
Closed
Labels
area/infinispan Infinispan kind/bug Something isn't working
Milestone

Comments

@jeffhubLR
Copy link

jeffhubLR commented Jun 12, 2020

Describe the bug
With a clean project generated from https://code.quarkus.io/ and following the Infinispan guide (https://quarkus.io/guides/infinispan-client), namely the Annotation based serialization (https://quarkus.io/guides/infinispan-client#annotation-based-serialization), there are scenarios where the generated Marshaller java files are not compiled into class files (or they are, but then removed), resulting in the following error:

2020-06-12 14:27:20,998 ERROR [io.qua.ver.htt.run.QuarkusErrorHandler] (executor-thread-1) HTTP Request to /hello failed, error id: 097bb367-f3e4-4dc1-9888-640b5238f00f-1: org.jboss.resteasy.spi.UnhandledException: java.lang.IllegalArgumentException: No marshaller registered for Java type org.acme.Book
	at org.jboss.resteasy.core.ExceptionHandler.handleApplicationException(ExceptionHandler.java:106)
	at org.jboss.resteasy.core.ExceptionHandler.handleException(ExceptionHandler.java:372)
	at org.jboss.resteasy.core.SynchronousDispatcher.writeException(SynchronousDispatcher.java:216)
	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:515)
	at org.jboss.resteasy.core.SynchronousDispatcher.lambda$invoke$4(SynchronousDispatcher.java:259)
	at org.jboss.resteasy.core.SynchronousDispatcher.lambda$preprocess$0(SynchronousDispatcher.java:160)
	at org.jboss.resteasy.core.interception.jaxrs.PreMatchContainerRequestContext.filter(PreMatchContainerRequestContext.java:362)
	at org.jboss.resteasy.core.SynchronousDispatcher.preprocess(SynchronousDispatcher.java:163)
	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:245)
	at io.quarkus.resteasy.runtime.standalone.RequestDispatcher.service(RequestDispatcher.java:73)
	at io.quarkus.resteasy.runtime.standalone.VertxRequestHandler.dispatch(VertxRequestHandler.java:132)
	at io.quarkus.resteasy.runtime.standalone.VertxRequestHandler.access$000(VertxRequestHandler.java:37)
	at io.quarkus.resteasy.runtime.standalone.VertxRequestHandler$1.run(VertxRequestHandler.java:94)
	at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
	at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:2046)
	at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1578)
	at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1452)
	at org.jboss.threads.DelegatingRunnable.run(DelegatingRunnable.java:29)
	at org.jboss.threads.ThreadLocalResettingRunnable.run(ThreadLocalResettingRunnable.java:29)
	at java.base/java.lang.Thread.run(Thread.java:834)
	at org.jboss.threads.JBossThread.run(JBossThread.java:479)
Caused by: java.lang.IllegalArgumentException: No marshaller registered for Java type org.acme.Book
	at org.infinispan.protostream.impl.SerializationContextImpl.getMarshallerDelegate(SerializationContextImpl.java:279)
	at org.infinispan.protostream.WrappedMessage.writeMessage(WrappedMessage.java:240)
	at org.infinispan.protostream.ProtobufUtil.toWrappedByteArray(ProtobufUtil.java:181)
	at org.infinispan.protostream.ProtobufUtil.toWrappedByteArray(ProtobufUtil.java:176)
	at org.infinispan.commons.marshall.ProtoStreamMarshaller.objectToBuffer(ProtoStreamMarshaller.java:69)
	at org.infinispan.commons.marshall.AbstractMarshaller.objectToByteBuffer(AbstractMarshaller.java:70)
	at org.infinispan.client.hotrod.marshall.MarshallerUtil.obj2bytes(MarshallerUtil.java:99)
	at org.infinispan.client.hotrod.DataFormat.valueToBytes(DataFormat.java:98)
	at org.infinispan.client.hotrod.impl.RemoteCacheImpl.valueToBytes(RemoteCacheImpl.java:560)
	at org.infinispan.client.hotrod.impl.RemoteCacheImpl.putAsync(RemoteCacheImpl.java:375)
	at org.infinispan.client.hotrod.impl.InvalidatedNearRemoteCache.putAsync(InvalidatedNearRemoteCache.java:60)
	at org.infinispan.client.hotrod.impl.RemoteCacheImpl.put(RemoteCacheImpl.java:344)
	at org.infinispan.client.hotrod.impl.RemoteCacheSupport.put(RemoteCacheSupport.java:89)
	at org.acme.ExampleResource.hello(ExampleResource.java:22)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:566)
	at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:167)
	at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:130)
	at org.jboss.resteasy.core.ResourceMethodInvoker.internalInvokeOnTarget(ResourceMethodInvoker.java:621)
	at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTargetAfterFilter(ResourceMethodInvoker.java:487)
	at org.jboss.resteasy.core.ResourceMethodInvoker.lambda$invokeOnTarget$2(ResourceMethodInvoker.java:437)
	at org.jboss.resteasy.core.interception.jaxrs.PreMatchContainerRequestContext.filter(PreMatchContainerRequestContext.java:362)
	at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:439)
	at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:400)
	at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:374)
	at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:67)
	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:488)
	... 17 more

Expected behavior
Regardless of mvn command used, the class files should be reliably generated which would prevent the above error.

Actual behavior
If ./mvnw clean compile test is executed, no class file is compiled for the generated Marshaller sources, resulting in the above error. **NOTE THAT THIS IS JUST A SIMPLE REPRODUCTION, IN PRACTICE THIS BEHAVIOR IS WITNESSED WITH A SIMPLE mvn compile quarkus:dev...

To Reproduce
Steps to reproduce the behavior:

  1. Clone this repo: https://github.com/jeffhubLR/quarkus-infinispan-issue
  2. Follow the README step to create the infinispan docker container
  3. Execute ./mvnw clean compile test and observe the error
  4. Execute find target -name '*Marshaller*' and see that the java files exist, but no class files

Now to see it work, do the following:

  1. Execute ./mvnw clean
  2. Execute ./mvnw compile
  3. Execute find target -name '*Marshaller*' and see that the java files and class files exist
  4. Execute ./mvnw test and see the test pass

Configuration

# Add your application.properties here, if applicable.
quarkus.infinispan-client.near-cache-max-entries=1000
quarkus.infinispan-client.server-list=localhost:11222
quarkus.infinispan-client.client-intelligence=BASIC

Environment (please complete the following information):

  • Output of uname -a or ver: Darwin USMACEA094JHUBB 19.4.0 Darwin Kernel Version 19.4.0: Wed Mar 4 22:28:40 PST 2020; root:xnu-6153.101.6~15/RELEASE_X86_64 x86_64
  • Output of java -version:
    openjdk version "11.0.6" 2020-01-14
    OpenJDK Runtime Environment AdoptOpenJDK (build 11.0.6+10)
    OpenJDK 64-Bit Server VM AdoptOpenJDK (build 11.0.6+10, mixed mode)
  • GraalVM version (if different from Java): Not needed for this issue
  • Quarkus version or git rev: 1.8.1.Final
  • Build tool (ie. output of mvnw --version or gradlew --version): ./mvnw --version
    Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)
    Maven home: /Users/jeff.hubbach/.m2/wrapper/dists/apache-maven-3.6.3-bin/1iopthnavndlasol9gbrbg6bf2/apache-maven-3.6.3
    Java version: 11.0.6, vendor: AdoptOpenJDK, runtime: /Library/Java/JavaVirtualMachines/adoptopenjdk-11.jdk/Contents/Home
    Default locale: en_US, platform encoding: UTF-8
    OS name: "mac os x", version: "10.15.4", arch: "x86_64", family: "mac"
@jeffhubLR jeffhubLR added the kind/bug Something isn't working label Jun 12, 2020
@jeffhubLR
Copy link
Author

Update: I added maven profiles to facilitate testing in Quarkus 1.4.2.Final and Quarkus 1.3.4.Final as well. They all exhibit this behavior, so this isn't a regression.

./mvnw clean test works
./mvnw clean && ./mvnw compile && ./mvnw test works
./mvnw clean compile test fails

@gsmet
Copy link
Member

gsmet commented Jun 15, 2020

/cc @wburns @karesti

@gsmet gsmet added the area/infinispan Infinispan label Jun 15, 2020
@sean-scott-lr
Copy link

FYI, our only way to work around this is with the Deprecated MessageMarshaller<>

@gsmet
Copy link
Member

gsmet commented Jun 18, 2020

/ping @wburns @karesti

@wburns
Copy link
Member

wburns commented Jun 18, 2020

It sounds like the annotation processor is not being ran for some reason when compile test arguments are provided, which seems odd to me. I am not that familiar with the processor we implemented, so I would have to discuss with someone else on the team.

@wburns
Copy link
Member

wburns commented Jun 18, 2020

Using inotifywait I can see the AP is properly invoked initially and generates the classes, but then they are all removed and recompiled again but the second time the AP is not invoked it seems

The file 'Author.class' appeared in directory 'target/classes/org/acme/' via 'CREATE'
The file 'ExampleResource.class' appeared in directory 'target/classes/org/acme/' via 'CREATE'
The file 'Book.class' appeared in directory 'target/classes/org/acme/' via 'CREATE'
The file 'BookContextInitializer.class' appeared in directory 'target/classes/org/acme/' via 'CREATE'
The file 'Author$___Marshaller_58f9cfc92d6df0e524374380ae551ca945f9755247b3ced4618717b9b7152c47.class' appeared in directory 'target/classes/org/acme/' via 'CREATE'
The file 'Book$___Marshaller_f3251d80b7f97c5316431ab6fd7b3cce42c9d8c8189856dba3e3f2c585f19c79.class' appeared in directory 'target/classes/org/acme/' via 'CREATE'
The file 'BookContextInitializerImpl.class' appeared in directory 'target/classes/org/acme/' via 'CREATE'

The file 'BookContextInitializerImpl.class' removed from directory 'target/classes/org/acme/' via 'DELETE'
The file 'Author.class' removed from directory 'target/classes/org/acme/' via 'DELETE'
The file 'Author$___Marshaller_58f9cfc92d6df0e524374380ae551ca945f9755247b3ced4618717b9b7152c47.class' removed from directory 'target/classes/org/acme/' via 'DELETE'
The file 'Book.class' removed from directory 'target/classes/org/acme/' via 'DELETE'
The file 'Book$___Marshaller_f3251d80b7f97c5316431ab6fd7b3cce42c9d8c8189856dba3e3f2c585f19c79.class' removed from directory 'target/classes/org/acme/' via 'DELETE'
The file 'BookContextInitializer.class' removed from directory 'target/classes/org/acme/' via 'DELETE'
The file 'ExampleResource.class' removed from directory 'target/classes/org/acme/' via 'DELETE'

The file 'Author.class' appeared in directory 'target/classes/org/acme/' via 'CREATE'
The file 'ExampleResource.class' appeared in directory 'target/classes/org/acme/' via 'CREATE'
The file 'Book.class' appeared in directory 'target/classes/org/acme/' via 'CREATE'
The file 'BookContextInitializer.class' appeared in directory 'target/classes/org/acme/' via 'CREATE'

I removed

      <plugin>
        <artifactId>maven-compiler-plugin</artifactId>
        <version>${compiler-plugin.version}</version>
      </plugin>

from the pom.xml and now it works for me.

@jeffhubLR
Copy link
Author

Thanks for looking into this @wburns

The reproducer is a project generated from code.quarkus.io, which includes the maven-compiler-plugin block.

Is investigation still ongoing or is the recommended fix to remove the maven-compiler-plugin block to resolve? If the recommended fix is to remove the maven-compiler-plugin block, is the generator at code.quarkus.io going to be updated appropriately?

@wburns
Copy link
Member

wburns commented Jun 18, 2020

Unfortunately, I am not a maven wiz and Quarkus does their own pom magic in their plugin. So my guess is the example should probably be changed. WDYT @gsmet ?

@jeffhubLR
Copy link
Author

The maven-compiler-plugin configuration is where compiler arguments are currently specified for maven projects.
It appears that quarkus-maven-plugin supports some of the configuration that maven-compiler-plugin does. Is it expected that quarkus-maven-plugin reach parity with the configuration that can be passed to maven-compiler-plugin? If not, how is it proposed that the gaps be handled?

I guess what I'm trying to say, poorly, is that maven-compiler-plugin is the idiomatic way to configure any compiler arguments within maven projects. I would personally recommend figuring out what is causing this problem and resolving it, rather than requiring removal of a pretty standard Maven configuration. It will affect multi-module setups where quarkus is but one component, or where companies have a master parent pom that configures all their best practices.

@jeffhubLR
Copy link
Author

I just discovered that this problem does NOT exhibit itself when maven-compiler-plugin 3.8.0 is used.

Nothing in the release notes to go on, though: https://blogs.apache.org/maven/entry/apache-maven-compiler-plugin-version1

@geoand
Copy link
Contributor

geoand commented Jul 23, 2020

So it breaks with maven-compiler-plugin 3.8.1 and works with 3.8.0?

@jeffhubLR
Copy link
Author

Correct.

@geoand
Copy link
Contributor

geoand commented Jul 23, 2020

That sounds like a maven compiler plugin

@jeffhubLR
Copy link
Author

If it is a bug in maven-compiler-plugin, regardless, the reproducer project was generated from code.quarkus.io, which sets maven-compiler-plugin version to 3.8.1. Thus this should affect anyone using Infinispan who have recently generated a project and followed the Infinispan guide. It's also possible that the maven-compiler-plugin version upgrade surfaced some race condition in the quarkus plugin that is otherwise hidden. I don't know anything about the internals of the quarkus-plugin, the quarkus annotation processor that was mentioned in a comment in this issue, and how they tie into the maven lifecycle methods to know where to start looking.

With Maven-compiler-plugin 3.8.1 (the version that code.quarkus.io uses in its generated projects):

  • mvn clean
  • mvn compile
  • mvn test
    works

while

  • mvn clean compile test
    fails.

Is it reasonable to expect that a project generated from code.quarkus.io, and modified following a quarkus guide, would function without error? If so, then this issue should be addressed in some manner within the quarkus ecosystem, as currently that expectation is not met based on this reproducer.

From @wburns investigation and suggestion, there does appear to be a behavior change based on whether maven-compiler-plugin is included in the pom or not.

@sean-scott-lr
Copy link

@gsmet @wburns Been a while since this was opened. Will anyone be looking at this or assume that we need to find another caching solution?

@karesti
Copy link
Member

karesti commented Sep 23, 2020

@sean-scott-lr do you reproduce these issues with the latest stable Quarkus that is built with the latest Infinispan?

@sean-scott-lr
Copy link

Yes

@sean-scott-lr
Copy link

Also, I Looked into just not using the auto generated protostream method since it doesn't work in quarkus, and directly writing a Marshaller however this method has been deprecated for quite a while by protostream and will be removed soon. ( protostream 4.4 ).

@karesti
Copy link
Member

karesti commented Sep 23, 2020

@sean-scott-lr I will work on your reproducer now but it seems very odd. I could not reproduce this issue in my demo

@karesti
Copy link
Member

karesti commented Sep 23, 2020

@sean-scott-lr Just to clarify, the auto generated protostream method does work in Quarkus. What it is failing here is something else.

I've tested your example and indeed I can reproduce the problem when we specifically run 'mvn clean compile test' on a row.
However, it does work when I run simply 'mvn clean test' and the maven test goal compiles the code before running the tests.
'mvn clean package' and 'mvn clean install' do work as well for me.

Could you please tell me if 'mvn clean test', 'mvn clean package' and 'mvn clean install' do also work for you?

In any case this error is odd and I will report it to our protostream main maintainer in the team in case there is something missing from our side when we specifically call 'mvn clean compile test'.

@sean-scott-lr
Copy link

No running the maven goals one at a time does not work for us. I believe that this issue is just being surfaced a particular way in the reproducer on this ticket ( by running more than a single goal at the same time ). I believe that since we have a multi-module maven project, the same problem is being surfaced even when running a single goal.

In our multi-module project, here are the adapted steps from above:

Execute ./mvnw clean

mvnw clean -pl :child-module -am

Execute ./mvnw compile

mvnw compile -pl :child-module -am

Execute find target -name 'Marshaller' and see that the java files and class files exist

find child-module/target -name 'Marshaller'
Yes, the java files and class files exist

Execute ./mvnw test and see the test pass

mvnw test -pl :child-module -am
Nope, Witness "java.lang.IllegalArgumentException: No marshaller registered for Java type XXX"

Interestingly running this again:

find child-module/target -name 'Marshaller'
Shows that the *.class files for the marshallers have been deleted.

@jeffhubLR jeffhubLR changed the title Quarkus 1.5.1.Final + infinispan-client + mvn compile test failure Quarkus 1.8.1.Final + infinispan-client and deletion of Marshaller.class files Sep 23, 2020
@jeffhubLR
Copy link
Author

Title, description and reproducer repo updated.

Problem still exists in Quarkus 1.8.1.Final.

In the project that drove the creation of this issue and reproducer, a simple mvn compile quarkus:dev... will exhibit
the same behavior. The purpose of this reproducer is not to show that running commands in this order causes a failure,
the purpose of this reproducer is to demonstrate the issue in as simple a reproduction as possible, so that the code
paths that are deleting the Marshaller .class files are exercised so it can be investigated and resolved.

@karesti
Copy link
Member

karesti commented Sep 23, 2020

@jeffhubLR thanks for the clarifications! As I mentioned before, the team will check if this is a protostream issue and if something was missing or if it's a maven bug we need to report.

https://issues.redhat.com/browse/IPROTO-161

@danberindei
Copy link

danberindei commented Sep 28, 2020

I have reproduced the problem in a simpler project that doesn't use Quarkus. After debugging it I'd say it's an aggregate of a maven-core problem (or tradition?), a maven-compiler-plugin problem introduced in 3.8.1, and a protostream problem.

  1. When you invoke mvn clean compile test, the default-compile execution runs twice.
    This is because org.apache.maven.lifecycle.internal.DefaultLifecycleExecutionPlanCalculator#calculateMojoExecutions() (which hasn't changed in 6 years) collects the list of mojo executions in a list, and for each phase on the command-line it adds the mojo executions for that phase and its dependencies, even if some executions already exist in the list. E.g.
mojoExecutions = {java.util.ArrayList}  size = 8
 0 = {org.apache.maven.plugin.MojoExecution} "org.apache.maven.plugins:maven-clean-plugin:2.5:clean {execution: default-clean}"
 1 = {org.apache.maven.plugin.MojoExecution} "org.apache.maven.plugins:maven-resources-plugin:2.6:resources {execution: default-resources}"
 2 = {org.apache.maven.plugin.MojoExecution} "org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile {execution: default-compile}"
 3 = {org.apache.maven.plugin.MojoExecution} "org.apache.maven.plugins:maven-resources-plugin:2.6:resources {execution: default-resources}"
 4 = {org.apache.maven.plugin.MojoExecution} "org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile {execution: default-compile}"
 5 = {org.apache.maven.plugin.MojoExecution} "org.apache.maven.plugins:maven-resources-plugin:2.6:testResources {execution: default-testResources}"
 6 = {org.apache.maven.plugin.MojoExecution} "org.apache.maven.plugins:maven-compiler-plugin:3.8.1:testCompile {execution: default-testCompile}"
 7 = {org.apache.maven.plugin.MojoExecution} "org.apache.maven.plugins:maven-surefire-plugin:2.12.4:test {execution: default-test}"
  1. The second execution of maven-compiler-plugin version 3.8.0 used to check that the sources haven't changed and do nothing. But that check was wrong, because it didn't check any class files, and MCOMPILER-349 replaced it with another check that is also wrong, because it (org.apache.maven.plugin.compiler.AbstractCompilerMojo#isDependencyChanged()) checks for changes since the start of the build in all the classes on the module's classpath, including target/classes.
    This means the second execution of maven-compiler-plugin verison 3.8.1 deletes all the .class files from target/classes. It does not delete the files generated by annotation processors in target/generated-sources/annotations, but it also doesn't add them to the Javac sources parameter because org.apache.maven.plugin.compiler.AbstractCompilerMojo#getCompileSources() ignores the generated sources directory:
compileSourceRoots = {java.util.ArrayList}  size = 3
 0 = "/home/dan/Work/maven-compiler-test/src/main/java"
 1 = "/home/dan/Work/maven-compiler-test/target/generated-sources/annotations"
 2 = "/home/dan/Work/maven-compiler-test/target/generated-sources/annotations"
sources = {java.util.HashSet}  size = 2
 0 = {java.io.File} "/home/dan/Work/maven-compiler-test/src/main/java/ProtoStreamContextInitializer.java"
 1 = {java.io.File} "/home/dan/Work/maven-compiler-test/src/main/java/A.java"
  1. The protostream annotation processor sees that the generated Java source file exists with the correct checksum and doesn't overwrite it (org.infinispan.protostream.annotations.impl.processor.GeneratedFilesWriter.SourceFile#write()). But this means the generated source file is not added to Javac's sources, and Javac does not compile it to a .class file.

IMO issue # 1 is just the way Maven works, and it's not going to change any time soon. Because of this, I not suggest using more than one phase from each lifecycle on the Maven command line.
Issue # 2 should be fixed, and I'll create an issue in the maven-compiler-plugin JIRA.
Issue # 3 could also be fixed by removing the checksum check in org.infinispan.protostream.annotations.impl.processor.GeneratedFilesWriter.SourceFile#write() and always writing the generated Java source file. TBH I'm not sure what's the purpose of the check is, so I'm not 100% it can be removed, but I hope it can be removed.

@jeffhubLR
Copy link
Author

Thank you very much for the thorough analysis, explanation and writeup, @danberindei . When you create the issue in the maven-compiler-plugin JIRA, would you mind posting that here so I can watch its progress?

@anistor
Copy link

anistor commented Sep 29, 2020

#3 is fixed (worked around) by https://issues.redhat.com/browse/IPROTO-161 "Enhance generated source file up-to-date check by also ensuring the class file exists and is newer than the java file"

This is released in protostream 4.3.4.Final and @danberindei 's simple reproducer without Quarkus (https://github.com/danberindei/maven-compiler-test/tree/master) confirms the fix. It would be great to have confirmation of how it behaves in quarkus.

@danberindei
Copy link

@jeffhubLR the maven-compiler-plugin issue is https://issues.apache.org/jira/browse/MCOMPILER-433

@jeffhubLR
Copy link
Author

jeffhubLR commented Oct 1, 2020

@anistor @danberindei
Thank you both for your work on this. I've confirmed that upgrading to protostream 4.3.4.Final corrects the problem in my minimal Quarkus reproducer.
https://github.com/jeffhubLR/quarkus-infinispan-issue

I've also verified that updating to protostream 4.3.4.Final (and going back to the current default of maven-compiler-plugin: 3.8.1) corrects the problem in our multi-module monorepo with multiple quarkus services and a shared library.

Once that, or another fix, is incorporated into Quarkus, this can be closed.

@karesti
Copy link
Member

karesti commented Oct 2, 2020

@jeffhubLR We are about to release 11.0.4.Final that includes this fix, we will upgrade Quarkus to that version after. Thanks!

@gsmet gsmet added this to the 1.9.0 - master milestone Oct 6, 2020
@gsmet
Copy link
Member

gsmet commented Oct 6, 2020

@karesti when do you plan to update Quarkus? I'm releasing 1.9.0.CR1 tomorrow morning.

@wburns
Copy link
Member

wburns commented Oct 6, 2020

@gsmet I will get a PR ready today.

@wburns
Copy link
Member

wburns commented Oct 6, 2020

#12552

@karesti
Copy link
Member

karesti commented Oct 7, 2020

@gsmet thanks for the heads up and for the pr @wburns !

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/infinispan Infinispan kind/bug Something isn't working
Projects
None yet
Development

No branches or pull requests

8 participants