karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grzegorz Grzybek <gr.grzy...@gmail.com>
Subject Re: Idea - how to override bundle headers without wrap:
Date Tue, 19 Mar 2019 12:51:12 GMT
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é <jb@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é <jb@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&amp;Import-Package=javax.imageio,javax.naming,javax.naming.ldap,javax.net.ssl,javax.security.auth.x500,javax.xml.parsers,org.slf4j.*;resolution:=optional;version=&quot;[1.7.25,2)&quot;,javax.servlet.*;version=&quot;[3.1,5)&quot;
> >>
> >> 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é
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message