Memory exhaustion loop with Jersey, DeclarativeLinking and @NotNull with HTTP POST

For a POST method, with the following structure:

@Path("/auth")
@Produces(MediaType.APPLICATION_JSON)
@DenyAll
public class Auth {

    @POST
    @Path("/login")
    @Consumes(MediaType.APPLICATION_FORM_URLENCODED)
    @Produces(MediaType.TEXT_PLAIN)
    @PermitAll
    public Response createLogin(
            @NotNull @FormParam("username") final String username,
            @NotNull @FormParam("password") final String password,
            @Context final UriInfo uriInfo,
            @Context final HttpHeaders httpHeaders
    ) {
    }

}

I get the following errors (which repeat for ever till memory exhaustion).

INFO: [failed to localize] warning.linkfilter.processing(org.glassfish.jersey.internal.util.collection.KeyComparatorLinkedHashMap$Entry)
java.lang.NullPointerException
    at org.glassfish.jersey.internal.util.collection.KeyComparatorHashMap$Entry.hashCode(KeyComparatorHashMap.java:752)
    at org.glassfish.jersey.internal.util.collection.KeyComparatorLinkedHashMap$Entry.hashCode(KeyComparatorLinkedHashMap.java:295)
    at java.util.HashMap.hash(Unknown Source)
    at java.util.HashMap.containsKey(Unknown Source)
    at java.util.HashSet.contains(Unknown Source)
    at org.glassfish.jersey.linking.FieldProcessor.processLinks(FieldProcessor.java:99)
    at org.glassfish.jersey.linking.FieldProcessor.processMember(FieldProcessor.java:180)

The request is generated using the following:

Request.Post(BASE + "auth/login").bodyForm(Form.form().build())

Note the empty Form.

The Grizzly server is instantiated using the following:

final ResourceConfig rc = new ResourceConfig().packages("blah")
                .register(DeclarativeLinkingFeature.class)
                .register(ValidationFeature.class)
                .register(RolesAllowedDynamicFeature.class);
  • If I remove the @NotNull the error loop does not occur.
  • If I comment out the DeclarativeLinkingFeature.class the error loop does not occur, even with @NotNull
  • There are no other methods on this @Path.

My question is: is this a bug/defect within Jersey/Grizzly etc., or is this a misconfiguration/coding error on my part? (I don't accept errors on the part of the client, as this will be Internet facing any old crap can be sent)

A second question (not sure if that's bad form), should I be including @Valid or not?

The environment is running Grizzly 2.3.28, Jersey 2.25.1, MOXy 2.7.1 & the test client is using Apache HttpComponents Fluent 4.5.5