karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Nodet <gno...@apache.org>
Subject Re: [DISCUSS] Service capabilities (was: [VOTE] Apache Karaf (Container) 4.0.6 release)
Date Thu, 25 Aug 2016 16:48:19 GMT
And btw, given the code to remove service requirements is already present,
we could go a bit more fine grained and add a flag on the feature xml
element to disable/enforce service requirements :

<feature name="foo" serviceRequirements="disable|default|enforce" ...>

That should be fairly easy to do in a 1.5 schema for Karaf 4.1 imho.

2016-08-25 18:44 GMT+02:00 Guillaume Nodet <gnodet@apache.org>:

> You don't use any extender like DS or blueprint ?
> The capabilities can be easily auto-generated for those.
>
> You can always disable service requirements globally by setting
>   serviceRequirements = disable
> in the etc/org.apache.karaf.features.cfg config file.
>
> Guillaume
>
> 2016-08-25 16:17 GMT+02:00 Markus Rathgeb <maggu2810@gmail.com>:
>
>> So, is there a way to use 1.3.0 (IIRC prerequisite and dependency has
>> been added there) or newer without adding the capability instruction
>> to every feature using a bundle without that information in the
>> manifest?
>> I see there is a configuration for the runtime, but is there one for
>> the plugin to control the verification?
>>
>> I have to use a dozen of third party bundles that miss that
>> information and that change frequently, adding the capability to the
>> feature is a too time consuming effort.
>>
>> 2016-08-25 16:12 GMT+02:00 Guillaume Nodet <gnodet@apache.org>:
>> > Agreed, so the problem was caused by a custom feature ?
>> > I thought it was directly the pax-web feature.
>> >
>> > In that case, I agree, that's exactly the behavior we wanted I think.
>> >
>> > On a side note, if pax-web does not expose the service capability, it
>> > should also be fixed ;-)
>> >
>> > Guillaume
>> >
>> > 2016-08-25 15:55 GMT+02:00 Jean-Baptiste Onofré <jb@nanthrax.net>:
>> >
>> >> After digging a bit, I don't think it's actually a bug.
>> >>
>> >> Let me explain and see we all agree ;)
>> >>
>> >> Previously to the commit, the service enforcement was "enabled" only
>> for
>> >> features XML using xmlns 1.3.0 (not 1.4.0). The commit fixed service
>> >> enforcement also for xmlns 1.4.0 (which makes sense).
>> >>
>> >> In Markus' use case, he said he tried xmlns 1.2.0 and it failed.
>> However,
>> >> as he's using Karaf Maven plugin to generate the descriptor, by
>> default,
>> >> even if the "source" features XML contains xmlns 1.2.0, the generated
>> one
>> >> is using xmlns 1.4.0.
>> >>
>> >> That's why it worked before and not after the commit.
>> >>
>> >> Due to that, I don't think we have to consider it as a bug:
>> >> 1. If we don't want service enforcement, than, we have to use a feature
>> >> with xmlns 1.2.0
>> >> 2. Actually using features xmlns 1.3.0 or 1.4.0 means we want resolver
>> >> features including services enforcement.
>> >>
>> >> WDYT ?
>> >>
>> >> Regards
>> >> JB
>> >>
>> >>
>> >> On 08/25/2016 03:41 PM, Jean-Baptiste Onofré wrote:
>> >>
>> >>> It looks like the commit in cause is the following:
>> >>>
>> >>> ---------------------
>> >>> 5c5828322ad898e80e66923edeb29e1a25b774cb is the first bad commit
>> >>> commit 5c5828322ad898e80e66923edeb29e1a25b774cb
>> >>> Author: Guillaume Nodet <gnodet@apache.org>
>> >>> Date:   Fri Jul 22 12:33:17 2016 +0200
>> >>>
>> >>>     [KARAF-4632] Default serviceRequirements should handle 1.4.0
>> schema
>> >>>
>> >>> :040000 040000 d038cf82d490d3cd0c7df97376575e323ef2382f
>> >>> 2e6efa64dfd142e722970949b05dcc1e152a3cd8 M      features
>> >>> ----------------------
>> >>>
>> >>> I'm testing a revert.
>> >>>
>> >>> Regards
>> >>> JB
>> >>>
>> >>> On 08/25/2016 11:03 AM, Jean-Baptiste Onofré wrote:
>> >>>
>> >>>> No, I don't think it's related as it's not a change in 4.0.6.
>> >>>>
>> >>>> I think it's a combination between the features resolver and the
>> >>>> karaf-maven-plugin.
>> >>>>
>> >>>> I'm pretty close in the bisect now ;)
>> >>>>
>> >>>> Regards
>> >>>> JB
>> >>>>
>> >>>> On 08/25/2016 10:46 AM, Markus Rathgeb wrote:
>> >>>>
>> >>>>> I found this one:
>> >>>>>
>> >>>>> # By default, the feature resolver checks the service
>> >>>>> requirements/capabilities of
>> >>>>> # bundles for new features (xml schema >= 1.3.0) in order
to
>> >>>>> automatically installs
>> >>>>> # the required bundles.
>> >>>>> # The following flag can have those values:
>> >>>>> #   - disable: service requirements are completely ignored
>> >>>>> #   - default: service requirements are ignored for old features
>> >>>>> #   - enforce: service requirements are always verified
>> >>>>> #
>> >>>>> #serviceRequirements=default
>> >>>>>
>> >>>>> Do you think this one could be related?
>> >>>>>
>> >>>>> Changing the xmlns from v1.4.0 to v1.2.0 does not result in
a
>> >>>>> successful verification.
>> >>>>>
>> >>>>> -<features xmlns="http://karaf.apache.org/xmlns/features/v1.4.0"
>> >>>>> name="${project.artifactId}-${project.version}">
>> >>>>> +<features xmlns="http://karaf.apache.org/xmlns/features/v1.2.0"
>> >>>>> name="${project.artifactId}-${project.version}">
>> >>>>>
>> >>>>> 2016-08-25 10:40 GMT+02:00 Jean-Baptiste Onofré <jb@nanthrax.net>:
>> >>>>>
>> >>>>>> Hi Guillaume,
>> >>>>>>
>> >>>>>> I'm on git biset to identify the guilty ;)
>> >>>>>>
>> >>>>>> And yes, I will recut a release.
>> >>>>>>
>> >>>>>> Regards
>> >>>>>> JB
>> >>>>>>
>> >>>>>>
>> >>>>>> On 08/25/2016 10:25 AM, Guillaume Nodet wrote:
>> >>>>>>
>> >>>>>>>
>> >>>>>>> Yeah, if it breaks compatibility, we should recut a
release ?
>> >>>>>>> Has anyone identified the culprit commit yet ?
>> >>>>>>>
>> >>>>>>> 2016-08-25 9:39 GMT+02:00 Jean-Baptiste Onofré <jb@nanthrax.net>:
>> >>>>>>>
>> >>>>>>> I think it's a change in the karaf-maven-plugin.
>> >>>>>>>>
>> >>>>>>>> And yes, I reproduce Markus' issue as well.
>> >>>>>>>>
>> >>>>>>>> Do we consider as release blocker ?
>> >>>>>>>>
>> >>>>>>>> If so, I will fix it today and submit a new vote.
>> >>>>>>>>
>> >>>>>>>> Regards
>> >>>>>>>> JB
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>> On 08/25/2016 09:34 AM, Achim Nierbeck wrote:
>> >>>>>>>>
>> >>>>>>>> Hi,
>> >>>>>>>>>
>> >>>>>>>>> I was able to reproduce the issue Markus described
with his
>> test.
>> >>>>>>>>> One thing that crosses my mind, did we change
something with the
>> >>>>>>>>> feature
>> >>>>>>>>> resolver? Cause I can't remember that the pax-web-api
did
>> actually
>> >>>>>>>>> contain
>> >>>>>>>>> a provide-capability for the WebContainer Service.
>> >>>>>>>>>
>> >>>>>>>>> regards, Achim
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>> 2016-08-25 0:44 GMT+02:00 Krzysztof Sobkowiak
>> >>>>>>>>> <krzys.sobkowiak@gmail.com
>> >>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>> :
>> >>>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>> +1 (non-binding)
>> >>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>> ServiceMix 7.x tests ok. Thanks!!!
>> >>>>>>>>>>
>> >>>>>>>>>> Regards
>> >>>>>>>>>> Krzysztof
>> >>>>>>>>>>
>> >>>>>>>>>> On 24.08.2016 06:47, Jean-Baptiste Onofré
wrote:
>> >>>>>>>>>>
>> >>>>>>>>>> Hi all,
>> >>>>>>>>>>>
>> >>>>>>>>>>> I submit Karaf (Container) 4.0.6 release
to your vote.
>> >>>>>>>>>>>
>> >>>>>>>>>>> Release Notes:
>> >>>>>>>>>>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?
>> >>>>>>>>>>>
>> >>>>>>>>>>> projectId=12311140&version=12335477
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>> Staging Repository:
>> >>>>>>>>>>>
>> >>>>>>>>>>> https://repository.apache.org/content/repositories/orgapache
>> >>>>>>>>>>> karaf-1071/
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>> Git Tag:
>> >>>>>>>>>>> karaf-4.0.6
>> >>>>>>>>>>>
>> >>>>>>>>>>> Please vote to approve this release:
>> >>>>>>>>>>>
>> >>>>>>>>>>> [ ] +1 Approve the release
>> >>>>>>>>>>> [ ] -1 Don't approve the release (please
provide specific
>> >>>>>>>>>>> comments)
>> >>>>>>>>>>>
>> >>>>>>>>>>> This vote will be open for at least
72 hours.
>> >>>>>>>>>>>
>> >>>>>>>>>>> Thanks,
>> >>>>>>>>>>> Regards
>> >>>>>>>>>>> JB
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>> --
>> >>>>>>>>>> Krzysztof Sobkowiak (@ksobkowiak)
>> >>>>>>>>>>
>> >>>>>>>>>> JEE & OSS Architect, Integration Architect
>> >>>>>>>>>> Apache Software Foundation Member (http://apache.org/)
>> >>>>>>>>>> Apache ServiceMix Committer & PMC Member
>> >>>>>>>>>> (http://servicemix.apache.org/)
>> >>>>>>>>>> Senior Solution Architect @ Capgemini SSC
>> >>>>>>>>>> (http://www.capgeminisoftware.
>> >>>>>>>>>> pl/)
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>> --
>> >>>>>>>> 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
>> >>>>>>
>> >>>>>
>> >>>>
>> >>>
>> >> --
>> >> Jean-Baptiste Onofré
>> >> jbonofre@apache.org
>> >> http://blog.nanthrax.net
>> >> Talend - http://www.talend.com
>> >>
>> >
>> >
>> >
>> > --
>> > ------------------------
>> > Guillaume Nodet
>> > ------------------------
>> > Red Hat, Open Source Integration
>> >
>> > Email: gnodet@redhat.com
>> > Web: http://fusesource.com
>> > Blog: http://gnodet.blogspot.com/
>>
>
>
>
> --
> ------------------------
> Guillaume Nodet
> ------------------------
> Red Hat, Open Source Integration
>
> Email: gnodet@redhat.com
> Web: http://fusesource.com
> Blog: http://gnodet.blogspot.com/
>
>


-- 
------------------------
Guillaume Nodet
------------------------
Red Hat, Open Source Integration

Email: gnodet@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/

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