Arquillian + jacoco IT coverage - maven-3

I configured 2 projects to use last jacoco version 0.7.8 and last Arquillian jacoco extension (1.0.09Alpha) it works like a charm (for jenkins and sonar 6.2)! but i have a bigger project, when i launch only Arquillian IT test my war archive is created and have all classes and so tests OK, when i run the same tests with IT code coverage, no class are included in the arquillian archive and have this error :
org.jboss.shrinkwrap.api.exporter.ArchiveExportException: Failed to write asset to output: /WEB-INF/...
Caused by: java.lang.RuntimeException: Could not instrument Asset org.jboss.shrinkwrap.api.asset.ClassLoaderAsset
Same configuration as other project BOM Arquillian 1.1.12Final arquillian suite 1.1.2 container 2.0.2 testng.....
any help ?

finally it was lib error indeed library asm-debug-all version was omitted because other library (apache-tika-parsers) already imported an older version (in pom.xml)... make an exclude in pom.xml fix the issue, we can check dependencies hierarchy in eclipse for example.
jacoco-arquillian extension use asm to instrument code...
<dependency>
<groupId>org.apache.tika</groupId>
<artifactId>tika-parsers</artifactId>
<version>1.9</version>
<scope>${defaultScope}</scope>
<exclusions>
<exclusion>
<groupId>org.bouncycastle</groupId>
<artifactId>bcprov-jdk15</artifactId>
</exclusion>
<exclusion>
<groupId>org.bouncycastle</groupId>
<artifactId>bcmail-jdk15</artifactId>
</exclusion>
<exclusion>
<groupId>org.ow2.asm</groupId>
<artifactId>asm-debug-all</artifactId>
</exclusion>
</exclusions>
</dependency>

Related

Log4j does not seem to be using my configuration file

I created a simple log4j2.properties file:
status = warn
appender.console.type = Console
appender.console.name = LogToConsole
appender.console.layout.type = PatternLayout
appender.console.layout.pattern = %level: %msg%n
rootLogger.level = warn
rootLogger.appenderRef.stdout.ref = LogToConsole
I added a VM argument to the run configuration in eclipse to point to the file.
Here is the resulting command line:
C:\Program Files\Java\jdk-17.0.1\bin\javaw.exe "-Dlog4j2.configurationFile=G:\My Drive\Dev\CrossFigureSolver\target\classes\log4j2.properties"
-Dfile.encoding=UTF-8
-classpath "[...]"
-XX:+ShowCodeDetailsInExceptionMessages com.propfinancing.crossFigure.Solver
But, when my program runs, it seems like log4j2 is not using my config file.
I am getting a lot of logs, including ones at the debug level. Also, they are not the same format as the pattern I specified. Here is an example:
13:16:37.505 [main] DEBUG org.apache.poi.openxml4j.opc.ZipPackage - Save core properties part
I can't find anything except instructions on setting log4j2.configurationFile which I did.
Any ideas?
I was able to use -Dlog4j2.debug and mvn dependency:tree to figure out that spring-boot-starter-web was bringing in slf4j which was interfering with log4j2.
I was able to add these exclusions to the pom.xml file to avoid loading it and now my logging works as expected:
<exclusions>
<exclusion>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-to-slf4j</artifactId>
</exclusion>
<exclusion>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
</exclusion>
<exclusion>
<groupId>org.slf4j</groupId>
<artifactId>jul-to-slf4j</artifactId>
</exclusion>
</exclusions>
I am surprised Spring was causing the problem, but at least now it is solved.

Getting ClassNotFoundException in Grails 2.5.6

Migrating from 1.3.7 to 2.5.6
java.lang.ClassNotFoundException: org.codehaus.groovy.grails.project.compiler.GrailsProjectCompiler how can we fix this?
Trying to build project using goal grails:clean grails:war -Dmaven.skip.test=true
Grails Version : 2.5.6
Java version 1.7
As stated by the comments, you're in for quite a ride to get this up and running.
This particular error is probably because you are missing the new dependencies needed for Grails. This is what you need if you have a maven project which I assume you have while getting this problem:
<dependency>
<groupId>org.grails</groupId>
<artifactId>grails-dependencies</artifactId>
<version>${grails.version}</version>
<type>pom</type>
</dependency>
<dependency>
<groupId>org.grails</groupId>
<artifactId>grails-test</artifactId>
<version>${grails.version}</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.grails</groupId>
<artifactId>grails-plugin-testing</artifactId>
<version>${grails.version}</version>
<scope>test</scope>
</dependency>
You also have to remove all of the old dependencies to the 1.3 grails core. In 1.3 it was a series of dependencies if I don't remember incorrectly.
If it is not a maven project you should get this for free by specifying the inerits("global") in your BuildConfig.groovy:
grails.project.dependency.resolution = {
// inherit Grails' default dependencies
inherits("global") {
// specify dependency exclusions here; for example, uncomment this to
}
...
That said, this will not be the last of your problems while upgrading. I have successfully managed to upgrade some small projects but it has taken quite an effort. For larger projects, I would seriously consider if it is worth it.
My best advice if you decide to go through with it is to generate a new empty 2.5.6 project and compare settings and dependencies to your legacy project.

Apache Beam running Pipeline from DoFn throws NoSuchMethodError

I am running an Application on Google AppEngine which generates Dataflow-Templates and starts them. In one of those pipelines, inside a DoFn, the process generates another pipeline and waits for it to finish, before it continues its work. Until a few days ago, that was not a problem. But now, I get a NoSuchMethodError when pipeline.run() is called.
The stacktrace:
java.lang.NoSuchMethodError: org.apache.beam.sdk.common.runner.v1.RunnerApi$FunctionSpec$Builder.setPayload(Lcom/google/protobuf/ByteString;)Lorg/apache/beam/sdk/common/runner/v1/RunnerApi$FunctionSpec$Builder;
at org.apache.beam.runners.dataflow.repackaged.org.apache.beam.runners.core.construction.WindowingStrategyTranslation.toProto(WindowingStrategyTranslation.java:224)
at org.apache.beam.runners.dataflow.repackaged.org.apache.beam.runners.core.construction.WindowingStrategyTranslation.toProto(WindowingStrategyTranslation.java:299)
at org.apache.beam.runners.dataflow.repackaged.org.apache.beam.runners.core.construction.WindowingStrategyTranslation.toProto(WindowingStrategyTranslation.java:285)
at org.apache.beam.runners.dataflow.DataflowPipelineTranslator.serializeWindowingStrategy(DataflowPipelineTranslator.java:129)
at org.apache.beam.runners.dataflow.DataflowPipelineTranslator.access$1500(DataflowPipelineTranslator.java:114)
at org.apache.beam.runners.dataflow.DataflowPipelineTranslator$5.groupByKeyHelper(DataflowPipelineTranslator.java:806)
at org.apache.beam.runners.dataflow.DataflowPipelineTranslator$5.translate(DataflowPipelineTranslator.java:784)
at org.apache.beam.runners.dataflow.DataflowPipelineTranslator$5.translate(DataflowPipelineTranslator.java:781)
at org.apache.beam.runners.dataflow.DataflowPipelineTranslator$Translator.visitPrimitiveTransform(DataflowPipelineTranslator.java:442)
at org.apache.beam.sdk.runners.TransformHierarchy$Node.visit(TransformHierarchy.java:663)
at org.apache.beam.sdk.runners.TransformHierarchy$Node.visit(TransformHierarchy.java:655)
at org.apache.beam.sdk.runners.TransformHierarchy$Node.visit(TransformHierarchy.java:655)
at org.apache.beam.sdk.runners.TransformHierarchy$Node.visit(TransformHierarchy.java:655)
at org.apache.beam.sdk.runners.TransformHierarchy$Node.visit(TransformHierarchy.java:655)
at org.apache.beam.sdk.runners.TransformHierarchy$Node.visit(TransformHierarchy.java:655)
at org.apache.beam.sdk.runners.TransformHierarchy$Node.access$600(TransformHierarchy.java:311)
at org.apache.beam.sdk.runners.TransformHierarchy.visit(TransformHierarchy.java:245)
at org.apache.beam.sdk.Pipeline.traverseTopologically(Pipeline.java:446)
at org.apache.beam.runners.dataflow.DataflowPipelineTranslator$Translator.translate(DataflowPipelineTranslator.java:386)
at org.apache.beam.runners.dataflow.DataflowPipelineTranslator.translate(DataflowPipelineTranslator.java:173)
at org.apache.beam.runners.dataflow.DataflowRunner.run(DataflowRunner.java:537)
at org.apache.beam.runners.dataflow.DataflowRunner.run(DataflowRunner.java:170)
at org.apache.beam.sdk.Pipeline.run(Pipeline.java:303)
at org.apache.beam.sdk.Pipeline.run(Pipeline.java:289)
at com.mycompany.projectsign.dataflow.dofn.downloads.something.RunDownloadPipeline.processElement(RunDownloadPipeline.java:150)
The referenced line of my code is the pipeline.run()
When I look at the maven-dependencies in Eclipse, the right dependencies (and versions) are added in the project and the RunnerApi.FunctionSpec.Builder.setPayload(com.google.protobuf.ByteString) method exists, too. I continued enforcing the versions with dependencyManagement:
<dependencyManagement>
<dependencies>
....
<dependency>
<groupId>com.google.protobuf</groupId>
<artifactId>protobuf-java</artifactId>
<version>3.2.0</version>
</dependency>
<dependency>
<groupId>io.grpc</groupId>
<artifactId>grpc-core</artifactId>
<version>1.2.0</version>
</dependency>
<dependency>
<groupId>io.grpc</groupId>
<artifactId>grpc-protobuf</artifactId>
<version>1.2.0</version>
</dependency>
<dependency>
<groupId>io.grpc</groupId>
<artifactId>grpc-stub</artifactId>
<version>1.2.0</version>
</dependency>
<dependency>
<groupId>org.apache.beam</groupId>
<artifactId>beam-sdks-common-runner-api</artifactId>
<version>2.2.0</version>
</dependency>
.....
</dependencies>
</dependencyManagement>
When running in AppEngine or creating the pipeline from localhost (running directly on Google Dataflow) the templates can be created and started without a problem, but running the created Pipeline inside the DoFn throws the same error.
However, when I run the Pipeline as a local pipeline directly on my computer (with DirectRunner), the pipeline runs without a problem and creates the other pipelines on GoogleDataflow.
I updated the beam-version to 2.2.0.
If some Googler is reading this, this is one of the failing JobIds: 2017-12-11_07_01_17-3122752092943950314
What might be the reason for the NoSuchMethodError? Could it be a conflicting dependency or something else?
Any help is highly appreciated :-)

Dataflow fails with java.lang.NoSuchMethodError: io.grpc.protobuf.ProtoUtils.marshaller(Lcom/google/protobuf/Message;)

I'm trying to get a Dataflow job to run on Google Cloud. It always fails with:
java.lang.NoSuchMethodError: io.grpc.protobuf.ProtoUtils.marshaller(Lcom/google/protobuf/Message;)Lio/grpc/MethodDescriptor$Marshaller
It's a maven project, here are my dependencies:
<dependencies>
<dependency>
<groupId>com.google.cloud.dataflow</groupId>
<artifactId>google-cloud-dataflow-java-sdk-all</artifactId>
<version>1.8.0</version>
</dependency>
<dependency>
<groupId>com.google.cloud</groupId>
<artifactId>google-cloud-pubsub</artifactId>
<version>0.4.0</version>
</dependency>
<dependency>
<groupId>com.google.protobuf</groupId>
<artifactId>protobuf-java</artifactId>
<version>3.0.0</version>
</dependency>
</dependencies>
I've tried a bunch of different dependency versions. What am I missing?
It has the same result whether I run via exec:java or via a shade jar.
Full stack trace:
(e8dbd0c1b8b8a22): java.lang.NoSuchMethodError:
io.grpc.protobuf.ProtoUtils.marshaller(Lcom/google/protobuf/Message;)Lio/grpc/MethodDescriptor$Marshaller;
at com.google.iam.v1.IAMPolicyGrpc.(IAMPolicyGrpc.java:56) at
com.google.cloud.pubsub.spi.v1.PublisherSettings$Builder.(PublisherSettings.java:487)
at
com.google.cloud.pubsub.spi.v1.PublisherSettings$Builder.createDefault(PublisherSettings.java:508)
at
com.google.cloud.pubsub.spi.v1.PublisherSettings$Builder.access$000(PublisherSettings.java:402)
at
com.google.cloud.pubsub.spi.v1.PublisherSettings.defaultBuilder(PublisherSettings.java:224)
at
com.google.cloud.pubsub.spi.DefaultPubSubRpc.(DefaultPubSubRpc.java:138)
at
com.google.cloud.pubsub.PubSubOptions$DefaultPubSubRpcFactory.create(PubSubOptions.java:60)
at
com.google.cloud.pubsub.PubSubOptions$DefaultPubSubRpcFactory.create(PubSubOptions.java:54)
at com.google.cloud.ServiceOptions.rpc(ServiceOptions.java:399) at
com.google.cloud.pubsub.PubSubImpl.(PubSubImpl.java:115) at
com.google.cloud.pubsub.PubSubOptions$DefaultPubSubFactory.create(PubSubOptions.java:43)
at
com.google.cloud.pubsub.PubSubOptions$DefaultPubSubFactory.create(PubSubOptions.java:38)
at com.google.cloud.ServiceOptions.service(ServiceOptions.java:391) at
com.google.lindsaysmith.titan.DataflowBulkLoadNodes$SendPubSub.sendPubsubMessage(DataflowBulkLoadNodes.java:41)
at
com.google.lindsaysmith.titan.DataflowBulkLoadNodes$SendPubSub.processElement(DataflowBulkLoadNodes.java:32)
at
com.google.cloud.dataflow.sdk.util.SimpleDoFnRunner.invokeProcessElement(SimpleDoFnRunner.java:49)
at
com.google.cloud.dataflow.sdk.util.DoFnRunnerBase.processElement(DoFnRunnerBase.java:139)
at
com.google.cloud.dataflow.sdk.runners.worker.SimpleParDoFn.processElement(SimpleParDoFn.java:190)
at
com.google.cloud.dataflow.sdk.runners.worker.ForwardingParDoFn.processElement(ForwardingParDoFn.java:42)
at
com.google.cloud.dataflow.sdk.runners.worker.DataflowWorkerLoggingParDoFn.processElement(DataflowWorkerLoggingParDoFn.java:47)
at
com.google.cloud.dataflow.sdk.util.common.worker.ParDoOperation.process(ParDoOperation.java:55)
at
The usual answer in this situation is that you really must use exactly the version of gRPC and Protocol Buffers declared in the dependencies of the Dataflow SDK. This includes all transitive dependencies, so you may have to suppress gRPC or protobuf dependencies of other libraries so they do not intefere.
You can see the versions here (gRPC) and here (protobuf). I'm leaving them out of this answer so it does not get out of date.

why axis-1.4.jar is dependent upon wsdl4j-1.5.1 jar file in maven

Container is already having wsdl4j-1.5.1.jar. I have observed that when I have written only
axis1.4 dependency code in my pom.xml, it automatically downloading axis-wsdl4j-1.5.1.jar file which is also
creating problem to my existing application. could you please let me know,
why axis jar is internally downloading wsdl file and how to remove this
internal dependency
Like we declare needed artifacts as maven dependencies in pom for our java project, artifacts(declared as dependencies) are also projects and need other artifacts(dependencies).
According to this url, artifact-axis-1.4.jar is using artifact-axis-wsdl4j-1.5.1.
That is why when you are trying to download the axis-1.4.jar, maven is automatically downloading its corresponding dependency - axis-wsdl4j-1.5.1.
If your container is providing wsdl jar then you can tell maven to not to download axis-wsdl4j-1.5.1.jar, by using the exclude tag in your pom file, like below -
<dependency>
<groupId>axis</groupId>
<artifactId>axis</artifactId>
<version>1.4</version>
<exclusions>
<exclusion>
<groupId>axis</groupId>
<artifactId>axis-wsdl4j</artifactId>
</exclusion>
</exclusions>
</dependency>
Above declaration should solve your jar clashing problem.
You can refer to this url suggested by Timo, to get the detailed explanation of exclude tag. *

Resources