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

fix and/or ignore spotbugs errors #1325

Merged
merged 10 commits into from
Oct 7, 2020

Conversation

imavroukakis
Copy link
Contributor

@imavroukakis imavroukakis commented Oct 5, 2020

There are a couple of spotbugs complaints that I'd like some feedback on

H C NP: Null passed for non-null parameter of io.opentelemetry.trace.Span.setAttribute(AttributeKey, Object) in io.opentelemetry.instrumentation.auto.grpc.common.GrpcHelper.prepareSpan(Span, String, InetSocketAddress, boolean)  Method invoked at GrpcHelper.java:[line 62]

API for setAttribute strongly advises against null. If it's still ok to pass null here we can add a spotbugs exclusion otherwise, is an empty string an acceptable value?


H B Nm: The class name io.opentelemetry.javaagent.tooling.config.ConfigBuilder shadows the simple name of the superclass io.opentelemetry.sdk.common.export.ConfigBuilder  At ConfigBuilder.java:[lines 26-61]

I think this can be safely ignored


H D UC: Method io.opentelemetry.instrumentation.api.tracer.utils.NetPeerUtils.setNetPeer(Span, String, String, int) seems to be useless  At NetPeerUtils.java:[line 86]

This is probably a false positive as it is used in HttpClientTracer, do you agree?

gradle/spotbugs-exclude.xml Outdated Show resolved Hide resolved
@@ -46,7 +46,7 @@ abstract class SmokeTest extends Specification {

private static final ObjectMapper OBJECT_MAPPER = new ObjectMapper()

protected static OkHttpClient client = OkHttpUtils.client()
protected static final OkHttpClient CLIENT = OkHttpUtils.client()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we instead ignore this rule? I think @trask will object, but why static final variable MUST be in uppercase?

Copy link
Contributor Author

@imavroukakis imavroukakis Oct 5, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

spotBugs actually doesn't complain about the uppercase, just the missing final declaration. As for the uppercase, I believe it's a JLS convention for constants, but given the naming exception done for loggers, I don't see why it cannot be the same here - just possibly, have to look out for other static analysis checkers complaining about it ;)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think JLS has any naming conventions. Has it?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

https://docs.oracle.com/javase/specs/jls/se11/html/jls-6.html look for "Constant Names" section.
Emphasis, mine.

The names of constants in interface types should be, and final variables of class types may conventionally be, a sequence of one or more words, acronyms, or abbreviations, all uppercase

The capitalisation could have been a misrepresentation though, and the intent may have been to use them for primitives, but it somehow stuck for everything

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we instead ignore this rule? I think @trask will object, but why static final variable MUST be in uppercase?

I do not object 😂

static final variables should only be uppercase if they are constants, see https://google.github.io/styleguide/javaguide.html#s5.2.4-constant-names for "what is a constant"

@iNikem
Copy link
Contributor

iNikem commented Oct 5, 2020

There are a couple of spotbugs complaints that I'd like some feedback on

H C NP: Null passed for non-null parameter of io.opentelemetry.trace.Span.setAttribute(AttributeKey, Object) in io.opentelemetry.instrumentation.auto.grpc.common.GrpcHelper.prepareSpan(Span, String, InetSocketAddress, boolean)  Method invoked at GrpcHelper.java:[line 62]

Should be fixed: set attribute only if it is not null.

H B Nm: The class name io.opentelemetry.javaagent.tooling.config.ConfigBuilder shadows the simple name of the superclass io.opentelemetry.sdk.common.export.ConfigBuilder  At ConfigBuilder.java:[lines 26-61]

@mateuszrzeszutek please remind me, why do we need this class which largely duplicates superclass?

H D UC: Method io.opentelemetry.instrumentation.api.tracer.utils.NetPeerUtils.setNetPeer(Span, String, String, int) seems to be useless  At NetPeerUtils.java:[line 86]

Main branch does not 86 lines in NetPeerUtils :) Can you rebase your branch and try again?

@mateuszrzeszutek
Copy link
Member

H B Nm: The class name io.opentelemetry.javaagent.tooling.config.ConfigBuilder shadows the simple name of the superclass io.opentelemetry.sdk.common.export.ConfigBuilder At ConfigBuilder.java:[lines 26-61]

@mateuszrzeszutek please remind me, why do we need this class which largely duplicates superclass?

It doesn't really duplicate its superclass, it only extends those methods that it absolutely needs to. Though I agree that its name is somewhere between "uncreative" and "terrible", but I didn't have any better idea when I wrote it 😛

@imavroukakis
Copy link
Contributor Author

export.ConfigBuilder

how about ExportConfigBuilder ?

* GrpcHelper: methodName should not be set in the span if null
* GrpcHelper: fix warnings instead of hiding by using Callable
@imavroukakis
Copy link
Contributor Author

Main branch does not 86 lines in NetPeerUtils :) Can you rebase your branch and try again?
Now it complains about line 75 😆

H D UC: Method io.opentelemetry.instrumentation.api.tracer.utils.NetPeerUtils.setNetPeer(Span, String, String, int) seems to be useless  At NetPeerUtils.java:[line 75]

@mateuszrzeszutek
Copy link
Member

how about ExportConfigBuilder ?

I believe that io.opentelemetry.sdk.common.export.ConfigBuilder is the full name of the super class in the OTel SDK. Hmm, how about AgentConfigBuilder?

@imavroukakis
Copy link
Contributor Author

Odd failures for :instrumentation:servlet:glassfish-testing:test and :instrumentation:jms-1.1:test I can't replicate them locally.

@iNikem
Copy link
Contributor

iNikem commented Oct 5, 2020

jms is a known flaky test

@imavroukakis
Copy link
Contributor Author

jms is a known flaky test

ah thanks, @iNikem , is there any way to manually kick the build again?

@iNikem
Copy link
Contributor

iNikem commented Oct 5, 2020

I will wait, maybe #1327 will fix this

@anuraaga
Copy link
Contributor

anuraaga commented Oct 5, 2020

CircleCI is flaky lately (maybe running out of money with all the free alternatives? :P) Sorry if it looks a little weird @imavroukakis but we may close/open PRs to retrigger the build :)

@anuraaga anuraaga closed this Oct 5, 2020
@anuraaga anuraaga reopened this Oct 5, 2020
@imavroukakis imavroukakis reopened this Oct 5, 2020
@imavroukakis
Copy link
Contributor Author

Finally, I know how it happens but not why

This works

new Callable<Object>() {
   public Object call() throws Exception {
      resp.sendRedirect(endpoint.getBody());
         return null;
      }
});

This doesn't:

() -> {
  resp.sendRedirect(endpoint.getBody());
  return null;
})

I don't quite know why the test chokes with the lambda, maybe this has to do something with how it's called from Groovy?

@mateuszrzeszutek
Copy link
Member

I don't quite know why the test chokes with the lambda, maybe this has to do something with how it's called from Groovy?

That might be caused by the fact that Callables are instrumented by the java-concurrent instrumentation and Groovy Closures are not.

@imavroukakis
Copy link
Contributor Author

imavroukakis commented Oct 6, 2020

I don't quite know why the test chokes with the lambda, maybe this has to do something with how it's called from Groovy?

That might be caused by the fact that Callables are instrumented by the java-concurrent instrumentation and Groovy Closures are not.

Hmm, I don't understand your point, can you explain? The issue here is that, whilst the Groovy Closure and Java Callable work fine, when the Callable is expressed as a lambda, it's as if the Glassfish endpoint is not registered (this is a guess as I'm seeing 404s)

@imavroukakis imavroukakis reopened this Oct 6, 2020
@mateuszrzeszutek
Copy link
Member

whilst the Groovy Closure and Java Callable work fine

Wait, Groovy Closure works fine? Then please disregard my previous theory 😄
(Callable is instrumented to carry the context/scope with a current span that started it; I thought that groovy Closures were losing this piece of data and that was causing those tests to fail)

@iNikem
Copy link
Contributor

iNikem commented Oct 6, 2020

Beats me why CircleCI does not kick in...

@imavroukakis
Copy link
Contributor Author

whilst the Groovy Closure and Java Callable work fine

Wait, Groovy Closure works fine? Then please disregard my previous theory 😄
(Callable is instrumented to carry the context/scope with a current span that started it; I thought that groovy Closures were losing this piece of data and that was causing those tests to fail)

😄 it's just the Callable when expressed as a lambda that chokes

@imavroukakis imavroukakis reopened this Oct 6, 2020
@iNikem
Copy link
Contributor

iNikem commented Oct 6, 2020

@imavroukakis I am still looking into why it fails to kick in, but please run ./gradlew codenarcTest task and fix failures.

@imavroukakis
Copy link
Contributor Author

./gradlew codenarcTest

image

Guess we have to go full uppercase for this @iNikem after all.

@iNikem iNikem closed this Oct 6, 2020
@iNikem iNikem reopened this Oct 6, 2020
@iNikem
Copy link
Contributor

iNikem commented Oct 6, 2020

@imavroukakis I don't know if this is important, but you may want to fix this:

Screenshot 2020-10-06 at 14 38 31

@imavroukakis
Copy link
Contributor Author

@imavroukakis I don't know if this is important, but you may want to fix this:

Screenshot 2020-10-06 at 14 38 31

Ah thanks, it seems to be picking up the wrong key in GH.

@imavroukakis
Copy link
Contributor Author

circleCI exploded

* Exception is:
java.lang.OutOfMemoryError: Java heap space
	at org.gradle.api.internal.file.archive.impl.FileZipInput.<init>(FileZipInput.java:71)
	at org.gradle.api.internal.file.archive.impl.FileZipInput.create(FileZipInput.java:43)
	at org.gradle.api.internal.changedetection.state.Zip

@imavroukakis imavroukakis reopened this Oct 6, 2020
@imavroukakis
Copy link
Contributor Author

And now it's run out of space.apparently.

> Task :smoke-tests:test
java.io.IOException: No space left on device
com.esotericsoftware.kryo.KryoException: java.io.IOException: No space left on device
	at com.esotericsoftware.kryo.io.Output.flush(Output.java:165)
	at com.esotericsoftware.kryo.io.Output.require(Output.java:142)

@iNikem
Copy link
Contributor

iNikem commented Oct 6, 2020

Yea, I am trying to understand that disk space issue

Copy link
Member

@trask trask left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @imavroukakis 👍

I'll submit a separate PR to update the codenarc configuration to avoid having to use uppercase for (non-constant) static final fields (in groovy)

@trask trask merged commit 9523f9f into open-telemetry:master Oct 7, 2020
@imavroukakis imavroukakis deleted the fix-spotbugs-violations branch October 7, 2020 08:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants