[http] extract Multipart code into new ServletRequestMultipartWrapper

[stbischof]

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.

[paulrutter]

I haven't checked the whole PR yet, but i would expect commons-fileupload to be marked optional in the pom.xml of the base bundle.
Otherwise the bundle wouldn't even start if those classes are not on the classpath, right?

[stbischof]

yes the imports are is marked as optional. this way it could resolve and start without commons-fileupload.
And this is what i do,o i do not used the dependency on runtime.

But the class ServletRequestWrapper imports classes from commons-fileupload
https://github.com/apache/felix-dev/pull/367/files#diff-b1cfaf93f83551a9004116c63a435ac8e64b198c1e8ee68f4178d3b59073568dL51-L56

But in any case the ServletRequestWrapper must be instantiated. But this will fails because the classes are`t there

[paulrutter]

I see, but wouldn't it make sense to mark the dependencies as optional as well, in

felix-dev/http/jetty/pom.xml

Line 504 in f572bd8

<dependency>

?

[laeubi]

but i would expect commons-fileupload to be marked optional in the pom.xml

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. slf4-api will be compile and slf4-simple will be optional runtime because one might choose a different implementation of the API but it wont work without any provided!

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 ClassNotFound Exceptions should be catched somewhere and output a meaningful message so the user understands how to resolve the issue.

[paulrutter]

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

<optional>true</optional>

[stbischof]

@cziegeler I now throw an ServletException on the 2 Messages. see my last commit.

[cziegeler]

Thanks, looks good

[stbischof]

also tested in my application.
Now works proper without file-upload and commons.io

@paulrutter okay with a merge?

[paulrutter]

@stbischof Yes 👍🏻
The only thing i was wondering now is if the optional stated here (jetty12 bundle only)

felix-dev/http/jetty12/pom.xml

Line 738 in f572bd8

<optional>true</optional>

is then correct.
From what i understood from @laeubi, that optional should not be there, right?

[laeubi]

@paulrutter I think "optional" is sued semantically wrong here from maven point of view, but as the artifact is most likely never used as a maven dependency (but only as OSGi artifact it might not really matter, I would just remove all <optional> and let them be simple compile scope.

[paulrutter]

I will make that change to the jetty12 bundle then.

[paulrutter]

@laeubi See #368