Thank you very much for constructive feedback. Fragment bundle for servlet-api fixes my problem with "[3.1,4)" import range perfectly. I'll keep the "bundle processor" mechanism in local branch - maybe there'll come some useful scenarios for it?
regards Grzegorz Grzybek wt., 19 mar 2019 o 13:42 Jean-Baptiste Onofré <j...@nanthrax.net> napisał(a): > 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 >
