Hello wt., 19 mar 2019 o 13:54 Jean-Baptiste Onofré <j...@nanthrax.net> napisał(a):
> Thanks, > > if we "stay" at build time, we can always find workaround (fragment, > wrap/uber bundle, ...). Not sure we have a lot of use cases for the > "runtime" approach though. > My PoC with "bundle processor" was just declarative configuration to process (without embedding - it's more like repackaging before passing the bundle's stream to felix) bundles matching some criteria. With fragment bundle for servlet-api, I needed another feature (or modified feature - in my case it was "undertow" feature from pax-web) to install this fragment. Fragment approach was very clean and simple - thus elegant. But I still see some potential with "bundle processor" - it could for example OSGify some jars that are not actually OSGi bundles (just like wrap). Or few other scenarios. I'll leave KARAF-6200 open without any version set. Thanks again for comments. regards Grzegorz Grzybek > > Regards > JB > > On 19/03/2019 13:51, Grzegorz Grzybek wrote: > > 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 > >> > > > > -- > Jean-Baptiste Onofré > jbono...@apache.org > http://blog.nanthrax.net > Talend - http://www.talend.com >
