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 11:52:14 GMT
Stephan - many many thanks! Fragment trick works like a charm.
Looks like I was not thinking enough in OSGi concepts (or maybe I was
trying to be too clever? :)

regards
Grzegorz Grzybek

wt., 19 mar 2019 o 12:34 Grzegorz Grzybek <gr.grzybek@gmail.com> napisał(a):

> Thanks Stephan for valuable comment.
>
> I agree that it'd be possible to simply remove all Import-Package headers
> from all bundles. But that's not done by default. You have to be very
> explicit when creating custom distribution. I'm not doing this change
> upstream and also I created this
> https://issues.apache.org/jira/browse/KARAF-6200 as "proposal" with minor
> priority.
>
> Using fragment bundle sounds like great alternative - was it the same case
> with org.apache.aries.blueprint.core.compatibility-1.0.0.jar ?
>
> regards
> Grzegorz Grzybek
>
> wt., 19 mar 2019 o 11:30 Siano, Stephan <stephan.siano@sap.com>
> napisał(a):
>
>> 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