How does the Java Agent handle application naming

Question

How does the Java agent handle application naming?

Answer

In order of precedence - the following factors will determine the resulting application name as seen in the Contrast UI.

Use of -Dcontrast.agent.java.standalone_app_name

Used only as a last resort - although similar to -Dcontrast.application.name below, this setting is only needed to force the onboarding of an application that runs in a Java framework that the Contrast Java Agent does not yet support (see here for a list of currently supported frameworks).  When used, the agent will, on startup, immediately create an application in the Contrast UI with this name regardless of whether traffic or vulnerabilities have been discovered.

If several applications are running in the JVM, all will be bundled under a single onboarded application in the Contrast UI with the name specified by this setting.

Use this setting only if both:

• It is desired that any and all applications running on the JVM should be bundled under the same application name.
• The application(s) are not running a supported framework. 

Use of -Dcontrast.application.name

Similarly to -Dcontrast.agent.java.standalone_app.nameabove, If several applications are running in the JVM, all will be bundled under a single onboarded application in the Contrast UI with the name specified by this setting.

The noticeable difference here is that an application with this name will not be onboarded until either traffic is seen by the agent or inventory (library discovery) occurs.

This option should only be used if both:

• It is desired that any and all applications running on the JVM should be bundled under the same application name.
• The application(s) are running a supported framework. 

For more information on these and other agent configuration properties see the Contrast Documentation.

In all other cases, if no override options are specified, the following discovery logic comes into play: 

Direct Framework Support

Several frameworks provide a hook point that allows an application name to be explicitly specified.  If this is the case, the application name will be set using that value.

The following frameworks are currently supported in this regard:

• MuleSoft
  
  
• Servlet WebServers:
  • Jetty
  • Resin
  • Tomcat
  • Undertow
  • WebLogic
  • WebSphere

Inferred Framework Support

For frameworks other than the above, the following logic is used:

• Akka
  • ClassPath Derived name
  • Fallback to akka-application
• Grizzly
  • Result of getServerConfiguration if it is not empty
  • Backup to ClassPath Derived name
  • Fallback to Grizzly Application
• Http4k
  • ClassPath Derived name
  • Fallback to http4k-application
• Netty
  • ClassPath Derived name
  • Fallback to Netty Application
• Quarkus
  • ClassPath Derived name
  • Fallback to Quarkus Application
• Scala / Play
  • ClassPath Derived name
  • Fallback to play-application
• Spring Boot
  • Environment variable of spring.application.name
  • ClassPath Derived name or the 'temp app name' from getId on the application context
  • The context path
• Undertow
  • ClassPath Derived name
  • Fallback to Undertow Application
• Vert.X
  • ClassPath Derived name
  • Fallback to Vert.x Application

Context Path

If the above framework-related logic returns nothing, the context path is used as a fallback.

ClassPath Derived Name

The ClassPath Derived Name is determined by looking at the JAR file entry Implementation-Title or the name of the file minus the value of Implementation_Version.

• If the application is packaged as an Uber jar, only the Uber jar file will be examined.
• If not an Uber jar, all the classpath entries are walked until something matching the above description is discovered that does not result in an empty value.

If all else fails - the default of ROOT is used