[JBoss JIRA] (IPROTO-161) Maven compiler plugin 3.8.1 and Protostream seem broken
by Dan Berindei (Jira)
[ https://issues.redhat.com/browse/IPROTO-161?page=com.atlassian.jira.plugi... ]
Dan Berindei commented on IPROTO-161:
-------------------------------------
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.
# 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.
{noformat}
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}"
{noformat}
# 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|https://issues.apache.org/jira/browse/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:
{noformat}
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"
{noformat}
{noformat}
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"
{noformat}
# 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.
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.
> Maven compiler plugin 3.8.1 and Protostream seem broken
> -------------------------------------------------------
>
> Key: IPROTO-161
> URL: https://issues.redhat.com/browse/IPROTO-161
> Project: Infinispan ProtoStream
> Issue Type: Bug
> Affects Versions: 4.3.3.Final
> Reporter: Katia Aresti
> Assignee: Nistor Adrian
> Priority: Blocker
> Fix For: 4.3.4.Final
>
>
> Coming from a Quarkus issue, the maven compiler plugin in version 3.8.1 seems not working properly with classes compilation and generation
>
> Check the Quarkus issue.
>
> [https://github.com/quarkusio/quarkus/issues/9980]
>
> This might be a library problem or a maven problem
>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
3 years, 8 months
[JBoss JIRA] (ISPN-12307) Improve media type parsing
by Tristan Tarrant (Jira)
[ https://issues.redhat.com/browse/ISPN-12307?page=com.atlassian.jira.plugi... ]
Tristan Tarrant reassigned ISPN-12307:
--------------------------------------
Assignee: Dan Berindei
> Improve media type parsing
> --------------------------
>
> Key: ISPN-12307
> URL: https://issues.redhat.com/browse/ISPN-12307
> Project: Infinispan
> Issue Type: Enhancement
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Major
>
> Media type parsing has some problems with double-quoted parameters:
> * {{;}} and {{,}} are interpreted as parameter/media type separator even when they occur in a quoted parameter value
> * {{'}} is interpreted as a quoting character, the spec says only {{"}} must be used for quoting
> * Only spaces are allowed, not {{\t}}.
> * Spaces are allowed in too many places, e.g. {{type / subtype}} or {{parameter = value}}
> * Start and end quotes are removed from quoted parameter values, but the escaped characters inside are not unescaped.
> * Quotes are not added back in {{toString()}}, which makes deserialization fail if one of the parameters included an escaped double-quote (e.g. {{type/subtype; param="\""}}).
> Performance can also be improved, as we create many {{String}} instances via {{trim()}}, {{substring()}}, or {{split()}}.
> The clearest explanation of the media type grammar seems to be in
> https://tools.ietf.org/html/rfc7231#section-3.1.1.1
> https://tools.ietf.org/html/rfc7230#section-3.2.6
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
3 years, 8 months
[JBoss JIRA] (ISPN-12356) ScatteredStreamIteratorTest random failure
by Tristan Tarrant (Jira)
[ https://issues.redhat.com/browse/ISPN-12356?page=com.atlassian.jira.plugi... ]
Tristan Tarrant reassigned ISPN-12356:
--------------------------------------
Assignee: Will Burns
> ScatteredStreamIteratorTest random failure
> ------------------------------------------
>
> Key: ISPN-12356
> URL: https://issues.redhat.com/browse/ISPN-12356
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 12.0.0.Dev03
> Reporter: Will Burns
> Assignee: Will Burns
> Priority: Major
> Fix For: 12.0.0.Dev04
>
>
> The test can fail randomly https://ci.infinispan.org/job/Infinispan/job/PR-8699/4/testReport/junit/o... with
> {code}
> java.lang.NullPointerException
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.invokeCommand(JGroupsTransport.java:877)
> at org.infinispan.remoting.rpc.RpcManagerImpl.invokeCommand(RpcManagerImpl.java:146)
> at org.infinispan.reactive.publisher.impl.ClusterPublisherManagerImpl$SubscriberHandler.sendCancelCommand(ClusterPublisherManagerImpl.java:1077)
> at org.infinispan.reactive.publisher.impl.InnerPublisherSubscription.run(InnerPublisherSubscription.java:93)
> at io.reactivex.rxjava3.internal.operators.flowable.FlowableDoOnLifecycle$SubscriptionLambdaSubscriber.cancel(FlowableDoOnLifecycle.java:115)
> at io.reactivex.rxjava3.internal.subscriptions.SubscriptionArbiter.drainLoop(SubscriptionArbiter.java:221)
> at io.reactivex.rxjava3.internal.subscriptions.SubscriptionArbiter.drain(SubscriptionArbiter.java:190)
> at io.reactivex.rxjava3.internal.subscriptions.SubscriptionArbiter.cancel(SubscriptionArbiter.java:182)
> at io.reactivex.rxjava3.internal.subscriptions.SubscriptionArbiter.drainLoop(SubscriptionArbiter.java:221)
> at io.reactivex.rxjava3.internal.subscriptions.SubscriptionArbiter.drain(SubscriptionArbiter.java:190)
> at io.reactivex.rxjava3.internal.subscriptions.SubscriptionArbiter.cancel(SubscriptionArbiter.java:182)
> at io.reactivex.rxjava3.internal.subscriptions.SubscriptionHelper.cancel(SubscriptionHelper.java:181)
> at io.reactivex.rxjava3.internal.operators.flowable.BlockingFlowableIterable$BlockingFlowableIterator.run(BlockingFlowableIterable.java:173)
> at io.reactivex.rxjava3.internal.operators.flowable.BlockingFlowableIterable$BlockingFlowableIterator.hasNext(BlockingFlowableIterable.java:104)
> at org.infinispan.commons.util.Closeables$1.hasNext(Closeables.java:247)
> at org.infinispan.stream.DistributedStreamIteratorTest.lambda$verifyNodeLeavesBeforeGettingData$0(DistributedStreamIteratorTest.java:136)
> at org.infinispan.test.AbstractInfinispanTest$CallableWrapper.call(AbstractInfinispanTest.java:527)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.base/java.lang.Thread.run(Thread.java:834)
> {code}
> The assumption is that it is due to having no owner for a given segment, but further investigation is required.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
3 years, 8 months
[JBoss JIRA] (ISPN-12356) ScatteredStreamIteratorTest random failure
by Tristan Tarrant (Jira)
[ https://issues.redhat.com/browse/ISPN-12356?page=com.atlassian.jira.plugi... ]
Tristan Tarrant updated ISPN-12356:
-----------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> ScatteredStreamIteratorTest random failure
> ------------------------------------------
>
> Key: ISPN-12356
> URL: https://issues.redhat.com/browse/ISPN-12356
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 12.0.0.Dev03
> Reporter: Will Burns
> Priority: Major
> Fix For: 12.0.0.Dev04
>
>
> The test can fail randomly https://ci.infinispan.org/job/Infinispan/job/PR-8699/4/testReport/junit/o... with
> {code}
> java.lang.NullPointerException
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.invokeCommand(JGroupsTransport.java:877)
> at org.infinispan.remoting.rpc.RpcManagerImpl.invokeCommand(RpcManagerImpl.java:146)
> at org.infinispan.reactive.publisher.impl.ClusterPublisherManagerImpl$SubscriberHandler.sendCancelCommand(ClusterPublisherManagerImpl.java:1077)
> at org.infinispan.reactive.publisher.impl.InnerPublisherSubscription.run(InnerPublisherSubscription.java:93)
> at io.reactivex.rxjava3.internal.operators.flowable.FlowableDoOnLifecycle$SubscriptionLambdaSubscriber.cancel(FlowableDoOnLifecycle.java:115)
> at io.reactivex.rxjava3.internal.subscriptions.SubscriptionArbiter.drainLoop(SubscriptionArbiter.java:221)
> at io.reactivex.rxjava3.internal.subscriptions.SubscriptionArbiter.drain(SubscriptionArbiter.java:190)
> at io.reactivex.rxjava3.internal.subscriptions.SubscriptionArbiter.cancel(SubscriptionArbiter.java:182)
> at io.reactivex.rxjava3.internal.subscriptions.SubscriptionArbiter.drainLoop(SubscriptionArbiter.java:221)
> at io.reactivex.rxjava3.internal.subscriptions.SubscriptionArbiter.drain(SubscriptionArbiter.java:190)
> at io.reactivex.rxjava3.internal.subscriptions.SubscriptionArbiter.cancel(SubscriptionArbiter.java:182)
> at io.reactivex.rxjava3.internal.subscriptions.SubscriptionHelper.cancel(SubscriptionHelper.java:181)
> at io.reactivex.rxjava3.internal.operators.flowable.BlockingFlowableIterable$BlockingFlowableIterator.run(BlockingFlowableIterable.java:173)
> at io.reactivex.rxjava3.internal.operators.flowable.BlockingFlowableIterable$BlockingFlowableIterator.hasNext(BlockingFlowableIterable.java:104)
> at org.infinispan.commons.util.Closeables$1.hasNext(Closeables.java:247)
> at org.infinispan.stream.DistributedStreamIteratorTest.lambda$verifyNodeLeavesBeforeGettingData$0(DistributedStreamIteratorTest.java:136)
> at org.infinispan.test.AbstractInfinispanTest$CallableWrapper.call(AbstractInfinispanTest.java:527)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.base/java.lang.Thread.run(Thread.java:834)
> {code}
> The assumption is that it is due to having no owner for a given segment, but further investigation is required.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
3 years, 8 months