You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@karaf.apache.org by Grzegorz Grzybek <gr...@gmail.com> on 2019/03/19 07:26:26 UTC
Idea - how to override bundle headers without wrap:
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
Re: Idea - how to override bundle headers without wrap:
Posted by Grzegorz Grzybek <gr...@gmail.com>.
Thanks
I still have documentation issue related to features processor unresolved:
https://issues.apache.org/jira/browse/KARAF-5540
But I agree. I really have to describe it.
regards
Grzegorz Grzybek
wt., 19 mar 2019 o 10:24 Jean-Baptiste Onofré <jb...@nanthrax.net> napisał(a):
> 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é
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
Re: Idea - how to override bundle headers without wrap:
Posted by Grzegorz Grzybek <gr...@gmail.com>.
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&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é
> >> 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
>
Re: Idea - how to override bundle headers without wrap:
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
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&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é
>> 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
Re: Idea - how to override bundle headers without wrap:
Posted by Grzegorz Grzybek <gr...@gmail.com>.
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&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é
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
Re: Idea - how to override bundle headers without wrap:
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
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&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é
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Idea - how to override bundle headers without wrap:
Posted by Grzegorz Grzybek <gr...@gmail.com>.
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...@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 <st...@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&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é
>> jbonofre@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
>
Re: Idea - how to override bundle headers without wrap:
Posted by Grzegorz Grzybek <gr...@gmail.com>.
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 <st...@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&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é
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
RE: Idea - how to override bundle headers without wrap:
Posted by "Siano, Stephan" <st...@sap.com>.
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&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é
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Idea - how to override bundle headers without wrap:
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
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é
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com