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

Use of standalone_app_name has been deprecated as it's functionality has been incorporated into java agents(≥4.x) by default.

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.

Use this setting only if the following apply:

• The Java agent is ≤ 3.x
• The application(s) are not running a supported framework. 

Use of -Dcontrast.application.name

The contrast.application.name property allows for the customization of the onboarded application name. 

Applications will be onboarded into the Contrast UI once activity occurs on the application itself. 

This option should be used if:

• If you desire to customize the name of the application instead of taking the default behavior found below.
• Only one application is loaded into the JVM
• For situations where multiple applications are loaded in one JVM please refer to: 
  • Multi-Application configuration with Contrast Profiles
  • Onboarding and management of multiple web applications running in a single JVM (will link once published)

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

Related Articles:

• Multi-Application configuration with Contrast Profiles
• Onboarding and management of multiple web applications running in a single JVM