karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Baptiste Onofré ...@nanthrax.net>
Subject Re: Idea - how to override bundle headers without wrap:
Date Tue, 19 Mar 2019 12:54:19 GMT
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.

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
View raw message