Dropwizard Could Not Resolve Type Id ‘http’ Error: Fix

The Dropwizard error “Failed to parse configuration … Could not resolve type id ‘http’ as a subtype of ConnectorFactory” means that Jackson cannot find any connector type when it reads config.yml, almost always because the fat JAR was built without the Maven Shade ServicesResourceTransformer. The fix is to add that transformer to the Shade plugin and rebuild the JAR.

<transformer implementation="org.apache.maven.plugins.shade.resource.ServicesResourceTransformer"/>

The error appears when we start the JAR, while the same code runs fine from the IDE or with mvn test. On Dropwizard 5.0.2 the message looks like this.

  * Failed to parse configuration at: server.applicationConnectors.[0]; Could not resolve type id 'http' as a subtype of `io.dropwizard.jetty.ConnectorFactory`: known type ids = [] (for POJO property 'applicationConnectors')

Below the fix, we look at why the transformer matters, how to check a JAR for the problem, and the two other causes of the same message, a missing module and a typo in type. More Dropwizard articles are on the Dropwizard tutorials page.

1. Reproducing the Error

Our example is a small notes service on Dropwizard 5.0.2 and Java 25. Its config.yml declares an HTTP application connector, which is the standard setup from the Dropwizard tutorial.

server:
  applicationConnectors:
    - type: http
      port: 8080
      bindHost: 127.0.0.1

We build the JAR with a Shade configuration that has only the ManifestResourceTransformer, which many old tutorials show, and start it with the server command.

$ java -jar target/dropwizard-config-parse-error-broken-1.0.0.jar server config.yml
io.dropwizard.configuration.ConfigurationParsingException: config.yml has an error:
  * Failed to parse configuration at: server.applicationConnectors.[0]; Could not resolve type id 'http' as a subtype of `io.dropwizard.jetty.ConnectorFactory`: known type ids = [] (for POJO property 'applicationConnectors')
 at [Source: UNKNOWN; byte offset: #UNKNOWN] (through reference chain: io.dropwizard.core.Configuration["server"]->io.dropwizard.core.server.DefaultServerFactory["applicationConnectors"]->java.util.ArrayList[0])

Notice the part known type ids = []. The list is empty, so Jackson knows no connector type at all, not even http. An empty list points to the JAR packaging, while a list with values points to the configuration file, as section 4 shows.

2. Why the Fat JAR Loses the Connector Types

Dropwizard does not hard-code the types that may appear under type in config.yml. Each module lists its polymorphic factories, such as connectors, appenders and server factories, in files under META-INF/services, and Jackson discovers the subtypes from those files at startup.

The problem starts when Maven Shade packs all libraries into one JAR. Several Dropwizard JARs contain a file with the same name, META-INF/services/io.dropwizard.jackson.Discoverable, and by default Shade keeps only one of them. The ServicesResourceTransformer merges the lines of all files with the same name instead, so every module stays visible.

We can see the difference by printing the file from both JARs. The broken JAR has one line, while the fixed JAR lists the factories of all modules, including io.dropwizard.jetty.ConnectorFactory.

$ unzip -p target/dropwizard-config-parse-error-broken-1.0.0.jar META-INF/services/io.dropwizard.jackson.Discoverable
io.dropwizard.core.server.ServerFactory

$ unzip -p target/dropwizard-config-parse-error-1.0.0.jar META-INF/services/io.dropwizard.jackson.Discoverable
io.dropwizard.core.server.ServerFactory
io.dropwizard.logging.common.AppenderFactory
io.dropwizard.logging.common.LoggingFactory
io.dropwizard.logging.common.filter.FilterFactory
io.dropwizard.logging.common.layout.DiscoverableLayoutFactory
io.dropwizard.metrics.common.ReporterFactory
io.dropwizard.jetty.ConnectorFactory
io.dropwizard.health.HealthFactory
io.dropwizard.health.response.HealthResponderFactory
io.dropwizard.health.response.HealthResponseProviderFactory
io.dropwizard.request.logging.RequestLogFactory

The IDE and mvn test run with the separate JARs on the classpath, so every services file is there and the error never shows up. That is why the problem appears only after packaging.

3. The Fix in pom.xml

Add the ServicesResourceTransformer next to the ManifestResourceTransformer in the Shade plugin and rebuild with mvn package.

<transformers>
  <transformer implementation="org.apache.maven.plugins.shade.resource.ServicesResourceTransformer"/>
  <transformer implementation="org.apache.maven.plugins.shade.resource.ManifestResourceTransformer">
    <mainClass>com.howtodoinjava.dropwizard.configerror.NotesApplication</mainClass>
  </transformer>
</transformers>

The check command confirms the fix without starting the server.

$ java -jar target/dropwizard-config-parse-error-1.0.0.jar check config.yml
INFO  [2026-10-11 16:15:48,287] io.dropwizard.core.cli.CheckCommand: Configuration is OK

The same rule applies to other fat JAR tools. With the Gradle Shadow plugin, call mergeServiceFiles() in the shadowJar task. With the Maven Assembly plugin, switch to Shade, because the assembly descriptor jar-with-dependencies does not merge services files.

4. Other Causes of the Same Error

When the list of known type ids is not empty, the JAR is fine and the value in config.yml is the problem. There are two common cases.

4.1. A Connector Type From a Module That Is Not on the Classpath

The types h2 and h2c for HTTP/2 come from the dropwizard-http2 module, which dropwizard-core does not include. A configuration with type: h2c fails until we add the module.

  * Failed to parse configuration at: server.applicationConnectors.[0]; Could not resolve type id 'h2c' as a subtype of `io.dropwizard.jetty.ConnectorFactory`: known type ids = [http, https] (for POJO property 'applicationConnectors')

<dependency>
  <groupId>io.dropwizard</groupId>
  <artifactId>dropwizard-http2</artifactId>
</dependency>

After the rebuild, the error message for an unknown type lists [h2, h2c, http, https], which proves that the module is registered.

4.2. A Typo in the type Value

A misspelled value such as htttp gives the same message with the valid values in the list. Compare the value with the list and correct the YAML.

    - type: htttp

5. Catch the Problem in a Test

A test that starts the packaged JAR would be slow, but we can at least verify the configuration file in the build. The example project runs DropwizardAppExtension with a test configuration, and the README shows a check call against the shaded JAR that fits a CI step.

mvn package
java -jar target/dropwizard-config-parse-error-1.0.0.jar check config.yml

6. Dropwizard Configuration Error FAQs

The parse error has a few close relatives, and the questions below cover the ones we meet after the fix.

6.1. Why Does the App Start in the IDE but Not From the JAR?

The IDE puts every dependency JAR on the classpath, so all META-INF/services files exist. The fat JAR contains only what Shade copied, and without the ServicesResourceTransformer most of those files are lost.

6.2. What Does known type ids = [] Mean?

An empty list means Jackson found no subtype at all for that factory, so the services files are missing from the JAR. A list with entries means the JAR is fine and the type value is wrong or comes from a missing module.

6.3. Does the Same Error Happen for Appenders and Other Types?

Yes. The same message appears for logging.appenders, metrics reporters and request logs, because all of them use the same discovery mechanism. The fix is the same transformer.

7. Conclusion

The “Could not resolve type id ‘http'” error is a packaging problem in most cases. Dropwizard modules publish their factory types in META-INF/services, and the fat JAR must merge those files with the Shade ServicesResourceTransformer.

When the list of known type ids has values, check the type value and the modules on the classpath instead. To learn the rest of the setup, start with the Dropwizard health check and Dropwizard client examples.

8. References

• Dropwizard Getting Started, Building Fat JARs
• Maven Shade Plugin Resource Transformers
• Dropwizard Configuration Reference

Happy Learning !!

Source Code on Github