Not sure why you don't just use a ResourceConfig
instead of an Application
class. The only reason I can think of is portability, but the use of the Jersey specific multipart feature already breaks that portability.
But anyway, I'll try to answer this in the "most portable" way. What you can do is set a property, as you would in a web.xml. To set arbitrary 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 maintain the classpath scanning for your resources and providers. The scanning is only disabled if you override getClasses()
or getSingletons()
(and return non-empty sets), but getProperties()
is fine.
Another Option:
Create a Feature
to wrap that feature, and let the feature be discovered, as seen here
Personally, I would...
Just use a ResourceConfig
, as you're already breaking portability (what's a little more breakage :-)
@ApplicationPath("/")
public class AppConfig extends ResourceConfig {
public AppConfig() {
packages("packages.to.scan");
register(MultiPartFeature.class);
}
}
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…