Service name discovery based on webapp manifest

[felixbarny]

What does this PR do?

Discovers the service name based on servletContext.getResource("/META-INF/MANIFEST.MF")

• Servlet::service
• Servlet::init
• Filter::doFilter
• Filter::init

Open questions

• What happens if the web application archive doesn't have a /META-INF/MANIFEST.MF? Does servletContext.getResource("/META-INF/MANIFEST.MF") return the manifest of a jar in the lib directory?

Checklist

• This is an enhancement of existing features, or a new feature in existing plugins
  • I have updated CHANGELOG.asciidoc
  • I have added tests that prove my fix is effective or that my feature works
  • Added an API method or config option? Document in which version this will be introduced
  • I have made corresponding changes to the documentation
• This is a bugfix
  • I have updated CHANGELOG.asciidoc
  • I have added tests that would fail without this fix
• This is a new plugin
  • I have updated CHANGELOG.asciidoc
  • My code follows the style guidelines of this project
  • I have made corresponding changes to the documentation
  • I have added tests that prove my fix is effective or that my feature works
  • New and existing unit tests pass locally with my changes
  • I have updated supported-technologies.asciidoc
  • Added an API method or config option? Document in which version this will be introduced
  • Added an instrumentation plugin? Describe how you made sure that old, non-supported versions are not instrumented by accident.
• This is something else
  • I have updated CHANGELOG.asciidoc

cc @tobiasstadler

[ghost]

💚 Build Succeeded

the below badges are clickable and redirect to their specific view in the CI or DOCS

Expand to view the summary

Build stats

• Reason: null

• Start Time: 2022-02-02T08:10:22.591+0000

• Duration: 51 min 24 sec

• Commit: a6249cc

Test stats 🧪

Test	Results
Failed	0
Passed	2478
Skipped	16
Total	2494

💚 Flaky test report

Tests succeeded.

🤖 GitHub comments

To re-run your PR in the CI, just comment with:

• /test : Re-trigger the build.

• run benchmark tests : Run the benchmark tests.

• run jdk compatibility tests : Run the JDK Compatibility tests.

• run integration tests : Run the Agent Integration tests.

• run end-to-end tests : Run the APM-ITs.

• run windows tests : Build & tests on windows.

• run elasticsearch-ci/docs : Re-trigger the docs validation. (use unformatted text in the comment!)

[felixbarny]

@tobiasstadler would you be able to try this out?

[tobiasstadler]

Sure, should I test anything specific?

[felixbarny]

I'd appreciate feedback on these scenarios in particular:

• Test whether the detection for multiple Webapps on the same container works as expected
• Is the Filter::init and Servlet::init instrumentation a good enough alternative to the approach you proposed earlier that involved container-specific hooks?
• What happens if the web application archive doesn't have a /META-INF/MANIFEST.MF? Does servletContext.getResource("/META-INF/MANIFEST.MF") return the manifest of a jar in the lib directory?
• General feedback on the code, if you have any

[felixbarny]

I've added integration tests and they're passing now 🎉

What happens if the web application archive doesn't have a /META-INF/MANIFEST.MF? Does servletContext.getResource("/META-INF/MANIFEST.MF") return the manifest of a jar in the lib directory?

The /META-INF/MANIFEST.MF file gets created even if users don't add the Implementation-Title and Implementation-Version manifest entries. When you purposefully delete the manifest file, servletContext.getResource("/META-INF/MANIFEST.MF") returns null, not a random manifest file from a jar in the WEB-INF/lib dir.

[github-actions]

/test

[felixbarny]

This is how to properly set the manifest entries so that the agent can discover the service.name and service.version:

    <build>
        <plugins>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <!-- uncomment if you're building a jar
                <artifactId>maven-jar-plugin</artifactId>
                <version>3.2.2</version>
                -->
                <!-- uncomment if you're building a war
                <artifactId>maven-war-plugin</artifactId>
                <version>3.3.2</version>
                -->
                <configuration>
                    <archive>
                        <!-- Adds
                        Implementation-Title based on ${project.name} and
                        Implementation-Version based on ${project.version}
                        -->
                        <manifest>
                            <addDefaultImplementationEntries>true</addDefaultImplementationEntries>
                        </manifest>
                        <!-- To customize the Implementation-* entries, remove addDefaultImplementationEntries and add them manually
                        <manifestEntries>
                            <Implementation-Title>foo</Implementation-Title>
                            <Implementation-Version>4.2.0</Implementation-Version>
                        </manifestEntries>
                        -->
                    </archive>
                </configuration>
            </plugin>
        </plugins>
    </build>

[felixbarny]

@SylvainJuge review hints: Start with ServletServiceNameHelper, ServiceInfo, and InitServiceNameInstrumentation. The rest is really just moving things around.

[SylvainJuge]

LGTM, changed a few bits for proper coverage of ServiceInfo

[tobiasstadler]

@tobiasstadler would you be able to try this out?

It will look at it it on the weekend

[tobiasstadler]

Here are my results on JBoss EAP:

• My JAX-RS applications mostly work. org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher#init is called during deployment and uses the Manifest (if available and the Servlet Context Name otherwise) to set the service name. However sometimes javax.ejb.Schedule transactions have the "wrong" service name as they are started before the init method of any servlet is called (but subsequent invocations will have the correct service name)
• My Struts applications do not really work because no init method is called before any request is received. But during the first request the service name is configured correctly. Maybe instrumenting javax.servlet.ServletContextListener#contextInitialized (and the JakartaEE equivalent) can help determining the "correct" service name earlier.
• My JMS applications also do not work as no init method is ever called.

I have one application that uses Spark Java which (ab)uses Servlet Filters. Fortunately FilterConfig is null when javax.servlet.Filter#init is called, so the service name is not falsely overwritten.

Overall I think it is an improvement, but not the way I would like it to be. So I will stay with my customer WildFly/JBoss instrumentation at the moment.

[tobiasstadler]

@felixbarny I implemented ServletContextListener#contextInitialized instrumentation in #2443

[tobiasstadler]

@felixbarny I implemented ServletContainerInitializer#onStartup instrumentation in #2449