Add Spring Boot service name guesser / ResourceProvider

[breedx-splk]

This may not be the final home for ResourceProvider implementations, but it's a start. I know that the core project is likely going to migrate at least some of the existing ResourceProviders out of core....maybe some go to the instrumentation repo and some go to contrib? I'm open to reorganization suggestions.

This adds a new module that contains a single ResourceProvider called SpringBootServiceNameGuesser that does what it says. There are some additional, more complicated strategies that have not yet been included (such as the inline JSON doc as environment variable).

This new module will publish a new contrib artifact that distros can include to do spring app name detection.

This class could have been built as a composition of each of the strategies with a Resource.merge() step at the end, but that felt a little overengineered.

[mateuszrzeszutek]

I'm in favor of including this in the base javaagent distro -- it looks like it'll be very useful for spring boot users, and the accuracy of guessing the service name is rather high I think.

[laurit]

I would check that the file exists before attempting to open it

[breedx-splk]

Why, just to avoid the FileNotFound exception? I'm pretty "meh" on this.

I mean, if we're going to do that we might as well check to ensure that the file exists AND that it's a regular file AND that I have permission to read it also, right?

[laurit]

This can be super annoying if you need to debug some exception during agent startup and use an exception breakpoint and you get a million random exceptions before the one where you want to stop. Imo it is best not to cause exceptions if you can easily avoid it. I'd add regular file check, but I wouldn't bother with checking permissions.

[breedx-splk]

Is it more annoying that code that's just littered with checked exception handlers and guarded code all over the place? 😁

In this case, if I add check, what should I do in the event that the file doesn't exist?

Apparently I shouldn't throw a different exception, so I guess I slap @Nullable on the method and return a null InputStream? That will cause an NPE in the caller unless guarded, and the callers are currently using try-with-resources. So I'll have to unwrap those into separate assignments. Yuck. Alternatively, I could return a ByteArrayInputStream with nothing in it and hope that the parsers can grok an empty stream without exploding -- but returning an empty stream also suggests to any caller that the file was actually read but contains nothing. That's not great either. I dunno. Situations like this always feel like a language shortcoming to me.

Coincidentally, I was reading the nodejs docs on fs.exists() yesterday and they explicitly discourage checking before attempting because it's not multi-thread/process safe. That doesn't really apply here, but I thought it was interesting nonetheless.

[laurit]

As far as I know try with resource works nicely with null, it won't NPE.

[trask]

I'm in favor of including this in the base javaagent distro -- it looks like it'll be very useful for spring boot users, and the accuracy of guessing the service name is rather high I think.

+1

[breedx-splk]

Closing and will reopen in the main instrumentation repo.