Not sure why you are not just using ResourceConfig instead of the Application class. The only reason I can think of is portability, but using a specific multi-part Jersey function already violates this mobility.
But in any case, I will try to answer this in the "most portable" way. What you can do is set the property as in web.xml. To set custom properties, you can override
@Override public Map<String, Object> getProperties() {}
in the Application subclass and set the properties there.
@Override public Map<String, Object> getProperties() { Map<String, Object> props = new HashMap<>(); props.put("jersey.config.server.provider.classnames", "org.glassfish.jersey.media.multipart.MultiPartFeature"); return props; }
This will support class scans for your resources and providers. Scanning is disabled only if you override getClasses() or getSingletons() (and return non-empty sets), but getProperties() is fine.
Another variant:
Create Feature to wrap this function, and let the function be detected, as here.
Personally, I would ...
Just use ResourceConfig as you are already violating portability (which is a bit more of a breakdown :-)
@ApplicationPath("/") public class AppConfig extends ResourceConfig { public AppConfig() { packages("packages.to.scan"); register(MultiPartFeature.class); } }
source share