[http] extract Multipart code into new ServletRequestMultipartWrapper #367
Conversation
Mostly in the usage of felix-jetty-light there is the cases where you do not need the multipart support and can remove the dependencies of common-fileupload and common-io. To be able to do this we could not load a instantiate a class that imports common-fileupload classes. So we have to free the old class ServletRequestWrapper of this imports and add a ServletRequestMultipartWrapper that still have the multipart support. Signed-off-by: Stefan Bischof <[email protected]>
|
I haven't checked the whole PR yet, but i would expect |
|
yes the imports are is marked as optional. this way it could resolve and start without But the class But in any case the |
|
I see, but wouldn't it make sense to mark the dependencies as optional as well, in Line 504 in f572bd8 |
Please note that "optional" means something totally different to maven, see https://maven.apache.org/guides/introduction/introduction-to-optional-and-excludes-dependencies.html Optional is similar to "provided" but should not be included into runtime collections e.g. Optional in OSGi mean it could work with or without this dependency, is really hard to get correct and almost never useful if not carefully crafted and tested. Especially in this case it might lead to hard to track runtime errors, so |
|
Thanks for clarifying @laeubi, that makes sense 👍 It's already optional in the jetty12 bundle, is that considered a bug then? felix-dev/http/jetty12/pom.xml Line 738 in f572bd8 |
Mostly in the usage of felix-jetty-light there is the cases where you do not need the multipart support and can remove the dependencies of common-fileupload and common-io. To be able to do this we could not load a instantiate a class that imports common-fileupload classes. So we have to free the old class ServletRequestWrapper of this imports and add a ServletRequestMultipartWrapper that still have the multipart support.