Hi Stephan, that's what I meant by different between wrap and feature processing.
At least, it requires a good documentation and should be considered as "last chance action" ;) A fragment could work, but also a dedicated "wrapper" bundle (as we do for other spec), but that's at build time. Greg is proposing "runtime". Regards JB On 19/03/2019 11:30, Siano, Stephan wrote: > 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
