We're using WebLogic 220.127.116.11 (12c), and are working on a REST application with JSON for requests and responses. If the requests are valid everything works just fine. However, when a request is not correctly formatted, we expect an exception (which we can map to the right responses, if necessary). Instead, the value remains null instead. (Of course we can then validate that the value is not null, but what if null is allowed for some fields? We won't be able to see the difference between absent fields and incorrectly formatted fields, so instead of rejecting the request we would accept it as if no value was sent.)
We have created a subclass of org.eclipse.persistence.jaxb.rs.MOXyJsonProvider annotated with @Provider which sets some custom properties, but even without this (so with the default JSON handling) no exceptions are thrown.
We have already traced this internally to org.eclipse.persistence.oxm.record.UnmarshalRecord which treats each org.eclipse.persistence.exceptions.EclipseLinkException as warnings, meaning that (by default) they are ignored. The actual EclipseLinkException thrown is a org.eclipse.persistence.exceptions.ConversionException wrapped around the actual exception thrown by the XmlAdapter. This ConversionException is thrown from org.eclipse.persistence.internal.jaxb.XMLJavaTypeConverter's convertDataValueToObjectValue.
We can already work around this ConversionException being ignored, but we still get a ConversionException instead of a JAXBException. This means we cannot show to the caller which field is invalid; all we have is "The object [XXX], of class [class java.lang.String], could not be converted to [class YYY]". Since class YYY may be used in more than 1 request we cannot assume the same mapping. The exception stack trace can also not be used since it doesn't even enter the REST method.