Hi Jean-Baptiste, What Grzegorz is proposing looks to me like some magic behind-the-scenes automatic wrap for all kind of installed bundles.
I am not sure if this is really such a good idea. If it works, it can make things work that do not work without some significant effort like manually wrapping all bundles that reference the servlet API. If there are issues, you will have a situation, which is extremely hard to analyze with having bundles wiring to other bundles they are not supposed to be wiring according to their manifest. Even if that works with servlet API 4.0 for some reason, once that mechanism is there, it will likely be used for other packages, and once you have defined changes to several packages which cause the auto-wrap of dozens of bundles, I really think that it will be very difficult to understand the wiring afterwards. Therefore IMHO the least ugly workaround for this issue would be to create a fragment bundle for the servlet-api bundle that exports the packages with some lower version number (e.g. 3.2) that is only installed if it's really necessary. Over time the developers of the bundles referencing the servlet API hopefully asses whether their bundle also works with the servlet 4.0 API and adapt their import ranges accordingly (so the fragment can go away eventually). Best regards Stephan -----Original Message----- From: Jean-Baptiste Onofré <j...@nanthrax.net> Sent: Dienstag, 19. März 2019 10:24 To: dev@karaf.apache.org Subject: Re: Idea - how to override bundle headers without wrap: Hi Grzegorz I think what you are proposing is at different level than wrap. wrap is more for single jar (and works "outside" of Karaf) whereas your proposal is at feature level. It makes sense but we have to keep it simple and clear (in term of documentation). I think we should improve the feature processing documentation: in which case should I use it, and how to use it. But overall +1 to me. Regards JB On 19/03/2019 08:26, Grzegorz Grzybek wrote: > Hello > > I was thinking about one scenario. In my custom distro, I'm using pax-web > 7.3.3 (tech preview > <https://groups.google.com/d/msg/ops4j/JP5L63Qh4u8/nPG1LN4HAAAJ>) which > uses Undertow 2, Tomcat 9 and Servlet API 4. > > The "problem" is that maven-bundle-plugin, by default (and correctly) > generates import ranges according to pom dependencies. So if pom has > javax.servlet-api-3.1.0 dep, generated Import-Package header will have > (correctly) "[3.1,4.0)" range which is the most natural range according to > semantic versioning. > > The problem is that with some deps (and servlet-api used in > "@org.osgi.annotation.versioning.ConsumerType" mode is such dependency) > you're safe to use newer version of the API. > > There were different approaches to this problem, see for example: > https://bugs.eclipse.org/bugs/show_bug.cgi?id=385806 where bundles either > export packages in many versions or export lower version than one matching > directly JavaEE specification. For example, > geronimo-servlet_3.0_spec-1.0.jar exports javax.servlet package with > version 2.6 and 3.0. > > What I did (locally) is a little enhancement to new override&blacklisting > mechanism configured in etc/org.apache.karaf.features.xml. I added this > section for example: > > <bundleProcessing> > <bundle location="mvn:org.eclipse.jetty*/*"> > <add header="Processed-By" value="Karaf Bundle Processor" /> > <clause header="Import-Package" name="javax.servlet" > value='javax.servlet;version="[3.1.0,5)"' /> > <clause header="Import-Package" name="javax.servlet.annotation" > value='javax.servlet.annotation;version="[3.1.0,5)"' /> > <clause header="Import-Package" name="javax.servlet.descriptor" > value='javax.servlet.descriptor;version="[3.1.0,5)"' /> > <clause header="Import-Package" name="javax.servlet.http" > value='javax.servlet.http;version="[3.1.0,5)"' /> > </bundle> > </bundleProcessing> > > My goal was to be able to install for example "camel-websocket" feature > which uses jetty which (at version 9.4) requires servlet API 3.1. > > FeaturesProcessor (the one that currently can override URIs of bundles or > entire feature, blacklist features, bundle and repository URIs, has > (locally in my branch) ability to transform a bundle when matching some > criteria. > > In the above example, I can override all jetty bundles, so each *individual > clause* (unlike with wrap: where you work at header level) can be changed. > I can add full headers, remove headers, modify headers or modify individual > clauses. > > For example, to install jetty-util bundle, I had to wrap: it with: > > wrap:mvn:org.eclipse.jetty/jetty-util/9.4.12.v20180830$overwrite=merge&Import-Package=javax.imageio,javax.naming,javax.naming.ldap,javax.net.ssl,javax.security.auth.x500,javax.xml.parsers,org.slf4j.*;resolution:=optional;version="[1.7.25,2)",javax.servlet.*;version="[3.1,5)" > > remembering to preserve existing Import-Package clauses. > > With XML configuration I can focus only on fixing javax.servlet.* import > clauses. > > The transformed (repackaging + manifest change) bundles are stored in (by > default) ${karaf.data}/repository-bpr (bpr = bundle processing) directory, > which is also explicitly prepended to > org.ops4j.pax.url.mvn.defaultRepositories option used by maven resolver > used by features service. > > Fitting into existing features processor mechanism, this change is actually > not that big. I see nice potential in it, but I'd very like to get your > opinion on it - maybe additional ideas? Or problems with current idea? > > best regards > Grzegorz Grzybek > -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com
