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 14:01:12 GMT
Hello

wt., 19 mar 2019 o 13:54 Jean-Baptiste Onofré <jb@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é <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
> >>
> >
>
> --
> 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