Re: September 2023 board report
+1 Looks good Am So., 3. Sept. 2023 um 11:21 Uhr schrieb Jean-Baptiste Onofré < j...@nanthrax.net>: > Hi all, > > I prepared the board report for September: > https://cwiki.apache.org/confluence/display/KARAF/Board+Reports > > It's pretty short as the activity was pretty low during summer break. > We are now back to regular pace and fully committed to submit releases > to vote asap. > > Let me know if you want to add something on the board report, I would > like to submit the report asap. > > Thanks ! > Regards > JB > -- -- Christian Schneider http://www.liquid-reality.de Computer Scientist http://www.adobe.com
Re: [VOTE] Accept Apache Karaf Minho in Apache Karaf
+1 Christian Am Do., 13. Okt. 2022 um 08:47 Uhr schrieb Jean-Baptiste Onofré < j...@nanthrax.net>: > Hi guys, > > As discussed on the mailing list, I would like to start a formal vote > to accept Apache Karaf Minho in Apache Karaf. > > The proposal is: > - create karaf-minho repository on github > - use github issues/actions for Minho > - rework the website to have all projects at the same level, Karaf > runtime becoming Karaf OSGi. Each project will have its own > subwebsite, like https://jbonofre.github.io/karaf5/. > > In the meantime, I will change all resources to use > org.apache.karaf.minho namespace on my github before donation. > > Please vote to approve this donation/change: > > [ ] +1 Approve Minho donation and proposed plan > [ ] -1 Don't approve the donation/changes (please provide specific > comments) > > This vote will be open for at least 72 hours. > > Regards > JB > -- -- Christian Schneider http://www.liquid-reality.de Computer Scientist http://www.adobe.com
Re: [VOTE] Apache Karaf runtime 4.4.1 release
+1 Christian Am So., 10. Juli 2022 um 19:25 Uhr schrieb Jean-Baptiste Onofré < j...@nanthrax.net>: > Hi guys, > > I submit Apache Karaf runtime 4.4.1 release to your vote. > > This release is a maintenance release bringing a lot of dependency > updates and fixes. > Especially, this release includes: > - fix on the exported system packages > - fix on the config management in features service > - upgrade to Pax Web 8.0.6, Pax URL 2.6.11, Pax Logging 2.1.3 > - upgrade to OSGi frameworks (both Felix Framework 7.0.5 and Equinox > 3.18.0) > - upgrade to Spring 5.3.21 and 5.2.22.RELEASE > > You can take a look on the Release Notes for details: > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12351548 > > Maven Staging Repository: > https://repository.apache.org/content/repositories/orgapachekaraf-1176/ > > Dist Staging Repository: > https://dist.apache.org/repos/dist/dev/karaf/4.4.1/ > > Git tag: > karaf-4.4.1 > > 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. > > Regards > JB > -- -- Christian Schneider http://www.liquid-reality.de Computer Scientist http://www.adobe.com
Re: [PROPOSAL] Renaming terms
How about leader / follower instead of master / slave? Allowlist / denylist sounds good. Christian Am Mo., 27. Juli 2020 um 08:22 Uhr schrieb Jean-Baptiste Onofre < j...@nanthrax.net>: > Hi guys, > > I would like to propose new wording in some Karaf designs: > > - In Karaf runtime, I would like to rename master/slave to > primary/secondary > - in Cellar, I would like to rename blacklist/whitelist to allowlist and > deny list > > Thoughts ? > > Regards > JB -- -- Christian Schneider http://www.liquid-reality.de Computer Scientist http://www.adobe.com
Re: [VOTE] Apache Karaf Decanter 2.5.0 release
+1 (binding) Christian Am Do., 18. Juni 2020 um 08:56 Uhr schrieb Jean-Baptiste Onofre < j...@nanthrax.net>: > Hi all, > > I submit Apache Karaf Decanter 2.5.0 release to your vote. It’s a major > release on the Decanter 2.x series, containing bug fixes, improvements and > new features, especially: > > * extended REST support in REST collector and appender (REST verbs, basic > authentication, custom headers, ...) > * "connected" mode on the socket collector > * streaming mode on the socket appender > * new Pax Web Jetty handler collector > > Take a look on the Release Notes for details. > > Release Notes: > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12348163 > < > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12348163 > > > > Git Tag: > Decanter-2.5.0 > > Staging Repository: > https://repository.apache.org/content/repositories/orgapachekaraf-1144/ < > https://repository.apache.org/content/repositories/orgapachekaraf-1144/> > > Staging Dist: > https://dist.apache.org/repos/dist/dev/karaf/decanter/2.5.0/ < > https://dist.apache.org/repos/dist/dev/karaf/decanter/2.5.0/> > > 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. > > Regards > JB -- -- Christian Schneider http://www.liquid-reality.de Computer Scientist http://www.adobe.com
Re: [HEADS UP] Three new features proposal this week
e a even lighter Karaf runtime. About that, > I > > >>>> would like also to promote a bit the minimal distribution and do it > > even > > >>>> lighter. I propose to push minimal as official docker image, > allowing > > >>>> people to start from minimal to create their own docker image (we > will > > >>>> provide improved tools about that). > > >>>> > > >>>> 2. Features JSON > > >>>> As an alternative to features XML repo, I’ve working on features > JSON > > >>>> repo. It’s similar in term of content, but you will now have the > > choice > > >>>> between XML and JSON. > > >>>> > > >>>> 3. Simple resolver > > >>>> Several users complained about the features resolver: it might be > seen > > >> as > > >>>> complex (you have to understand req/caps, etc), it’s not always > > >> predictable > > >>>> (due to refresh with optional import, etc). I would like to propose > an > > >>>> alternative: the simple resolver. It’s pretty simple: it just takes > > what > > >>>> you have in features definition. It’s an optional resolver, meaning > > that > > >>>> the default will be still the regular resolver. The simple resolver > > can > > >> be > > >>>> enabled in etc/org.apache.karaf.features.cfg. > > >>>> > > >>>> 4. Spec features and cleanup > > >>>> As already discussed, I would like to remove the lib/jdk9plus folder > > and > > >>>> all spec packages from etc/jre.properties to use spec features > > instead. > > >>>> That will give us more control in the specs version and support of > > JDK. > > >>>> > > >>>> 5. ConfigAdmin persistence repository overwrite with env var > > >>>> It will be possible now to overwrite configuration with env var. For > > >>>> instance, if you have a property foo in my.config pid, you will be > > able > > >> to > > >>>> overwrite this property with -Dmy.config:foo=bar at bootstrap. > > >>>> > > >>>> If you agree, I would like to include those improvements in coming > > >> release > > >>>> (4.2.9 and 4.3.0.RC2). > > >>>> > > >>>> Regards > > >>>> JB > > >>>> > > >>>> > > >>>> > > >> > > > > > > > > > -- > > > > > > Apache Member > > > Apache Karaf <http://karaf.apache.org/> Committer & PMC > > > OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> > Committer > > & > > > Project Lead > > > blog <http://notizblog.nierbeck.de/> > > > Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS> > > > > > > -- > > Guillaume Nodet > -- -- Christian Schneider http://www.liquid-reality.de Computer Scientist http://www.adobe.com
Re: [HEADS UP] Three new features proposal this week
dk9plus folder > and > > >> all spec packages from etc/jre.properties to use spec features > instead. > > >> That will give us more control in the specs version and support of > JDK. > > >> > > >> 5. ConfigAdmin persistence repository overwrite with env var > > >> It will be possible now to overwrite configuration with env var. For > > >> instance, if you have a property foo in my.config pid, you will be > able > > to > > >> overwrite this property with -Dmy.config:foo=bar at bootstrap. > > >> > > >> If you agree, I would like to include those improvements in coming > > release > > >> (4.2.9 and 4.3.0.RC2). > > >> > > >> Regards > > >> JB > > >> > > >> > > >> > > > > > -- > > Apache Member > Apache Karaf <http://karaf.apache.org/> Committer & PMC > OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer & > Project Lead > blog <http://notizblog.nierbeck.de/> > Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS> > -- -- Christian Schneider http://www.liquid-reality.de Computer Scientist http://www.adobe.com
Re: [VOTE] Apache Karaf Decanter 2.4.0 release
+1 Christian Am Fr., 24. Apr. 2020 um 08:45 Uhr schrieb Jean-Baptiste Onofre < j...@nanthrax.net>: > Hi everyone, > > As discussed previously on the mailing list, I submit Apache Karaf > Decanter 2.4.0 to your vote. > > It’s a major release on the Decanter 2.x series, containing a bug fix on > the Prometheus appender feature, and new features, especially: > > - New processing layer with aggregator (see blog > http://blog.nanthrax.net/?p=1016 <http://blog.nanthrax.net/?p=1016>) > - New collectors (prometheus, Elasticsearch, configadmin, redis, oshi) > (see blog http://blog.nanthrax.net/?p=1019 < > http://blog.nanthrax.net/?p=1019>) > > Take a look on the Release Notes for details. > > Release Notes: > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12346613 > < > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12346613 > > > > Git Tag: > decanter-2.4.0 > > Staging Repository: > https://repository.apache.org/content/repositories/orgapachekaraf-1141/ < > https://repository.apache.org/content/repositories/orgapachekaraf-1141/> > > Staging Dist: > https://dist.apache.org/repos/dist/dev/karaf/decanter/2.4.0/ < > https://dist.apache.org/repos/dist/dev/karaf/decanter/2.4.0/> > > 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. > > Regards > JB -- -- Christian Schneider http://www.liquid-reality.de Computer Scientist http://www.adobe.com
Re: Apache Karaf twitter account
Hi JB, please also add me. @schneider_chris Christian Am Fr., 7. Feb. 2020 um 09:05 Uhr schrieb Jean-Baptiste Onofre < j...@nanthrax.net>: > Hi everyone, > > I’m happy to announce that ApacheKaraf twitter account has been created. > > I’m adding some content right now (logo, background, etc) and I’m linking > this account with the Karaf private mailing list. > > If you are PMC or committer and you want to post on behalf of ApacheKaraf, > please let me know I will link your twitter account on twitter desk. > > Regards > JB -- -- Christian Schneider http://www.liquid-reality.de Computer Scientist http://www.adobe.com
Re: [VOTE] Apache Karaf runtime 4.2.8 release
+1 binding Christian Am So., 12. Jan. 2020 um 12:34 Uhr schrieb Jean-Baptiste Onofré < j...@nanthrax.net>: > Hi all, > > I submit Apache Karaf runtime 4.2.8 to your vote. This is a > maintenance release on the 4.2.x series, bringing updates, improvements > and fixes. > > Release Notes: > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12346100 > > Staging Repository: > https://repository.apache.org/content/repositories/orgapachekaraf-1137 > > Staging Dist: > https://dist.apache.org/repos/dist/dev/karaf/4.2.8/ > > Git Tag: > karaf-4.2.8 > > 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 > -- > Jean-Baptiste Onofré > jbono...@apache.org > http://blog.nanthrax.net > Talend - http://www.talend.com > -- -- Christian Schneider http://www.liquid-reality.de Computer Scientist http://www.adobe.com
Re: [PR/DISCUSS] Interceptor module?
In that case I am fine with the ioc name. Christian Am Do., 14. Nov. 2019 um 13:17 Uhr schrieb Romain Manni-Bucau < rmannibu...@gmail.com>: > Im fine whatever works the most. > > Ioc proposal comes from the hope to fill the gap between spring/CDI and > OSGi ecosystem without going directly to osgi-cdi which has some pitfalls > for cdi guys. > Interceptors were just the first step but it can be more after so having > interceptor in the name sounded limited to me. > Hope it clarifies where Im coming from. > > Le jeu. 14 nov. 2019 à 13:05, Christian Schneider > > a écrit : > > > Sounds good .. for the name I propose karaf-interceptor. > > The name karaf-ioc ( I guess it should mean inversion of control) does > not > > seem to match well what it does. > > > > Christian > > > > Am Do., 14. Nov. 2019 um 12:51 Uhr schrieb Jean-Baptiste Onofré < > > j...@nanthrax.net>: > > > > > Agree, my point is that technically possible. > > > > > > And also agree to create a karaf-ioc repo (it takes me 2 minutes ;)). > > > > > > We can start a formal vote about that. Let's just wait Romain's > feedback. > > > > > > Regards > > > JB > > > > > > On 14/11/2019 12:44, Christian Schneider wrote: > > > > Of course it technically works but it would be the only case in the > > karaf > > > > main repo. It would confuse people a lot. I think we should not start > > > this. > > > > Creating a new karaf repo is no big issue. > > > > > > > > Christian > > > > > > > > Am Do., 14. Nov. 2019 um 11:54 Uhr schrieb Jean-Baptiste Onofré < > > > > j...@nanthrax.net>: > > > > > > > >> Hi, > > > >> > > > >> It can be released in its own cycle in the main repo. > > > >> > > > >> For instance, ServiceMix Bundles are on an unique git repo, but I do > > > >> release of each independently from the others. > > > >> > > > >> I think we can start like this. > > > >> > > > >> Regards > > > >> JB > > > >> > > > >> On 14/11/2019 11:09, Christian Schneider wrote: > > > >>> The fact that it evolves a lot at the start is even another > argument > > to > > > >>> keep it out of the karaf main repo as there you can only release > > > together > > > >>> with karaf. > > > >>> > > > >>> I think in the end it is your decision - either a new karaf repo (I > > can > > > >>> create it for you) or a new aries repo (again I can create it) or > the > > > >> aries > > > >>> main repo. So all options should be pretty quick to do. > > > >>> (Of course if you decide for aries we need an approval from the pmc > > of > > > >>> aries but I guess that is rather a formality as most are also in > this > > > >> list > > > >>> and would have objected if they did not want it at aries). > > > >>> > > > >>> Christian > > > >>> > > > >>> Am Mi., 13. Nov. 2019 um 09:39 Uhr schrieb Romain Manni-Bucau < > > > >>> rmannibu...@gmail.com>: > > > >>> > > > >>>> I kind of share the fact code will likely be stable - that said, > > > >> depending > > > >>>> the adoption it can evolve quite a lot for ~1 year I think (adding > > > >> method > > > >>>> binding support is the one I have in mind if the module works > great > > > >> without > > > >>>> this feature). > > > >>>> Where I'm a bit less "easy" is cause karaf has jms, jpa, jdbc etc > > > >> modules > > > >>>> so it sounds it is on the same plan to me, no? > > > >>>> That said, once again any home will be fine for me while it exists > > ;) > > > >>>> > > > >>>> Le mer. 13 nov. 2019 à 09:29, Christian Schneider < > > > >> ch...@die-schneider.net > > > >>>>> > > > >>>> a écrit : > > > >>>> > > > >>>>> I would not put the new code into an existing Aries subproject. > > > Instead > > > >>>> we > > > >>>>> could add a new one. > > > &g
Re: [PR/DISCUSS] Interceptor module?
Sounds good .. for the name I propose karaf-interceptor. The name karaf-ioc ( I guess it should mean inversion of control) does not seem to match well what it does. Christian Am Do., 14. Nov. 2019 um 12:51 Uhr schrieb Jean-Baptiste Onofré < j...@nanthrax.net>: > Agree, my point is that technically possible. > > And also agree to create a karaf-ioc repo (it takes me 2 minutes ;)). > > We can start a formal vote about that. Let's just wait Romain's feedback. > > Regards > JB > > On 14/11/2019 12:44, Christian Schneider wrote: > > Of course it technically works but it would be the only case in the karaf > > main repo. It would confuse people a lot. I think we should not start > this. > > Creating a new karaf repo is no big issue. > > > > Christian > > > > Am Do., 14. Nov. 2019 um 11:54 Uhr schrieb Jean-Baptiste Onofré < > > j...@nanthrax.net>: > > > >> Hi, > >> > >> It can be released in its own cycle in the main repo. > >> > >> For instance, ServiceMix Bundles are on an unique git repo, but I do > >> release of each independently from the others. > >> > >> I think we can start like this. > >> > >> Regards > >> JB > >> > >> On 14/11/2019 11:09, Christian Schneider wrote: > >>> The fact that it evolves a lot at the start is even another argument to > >>> keep it out of the karaf main repo as there you can only release > together > >>> with karaf. > >>> > >>> I think in the end it is your decision - either a new karaf repo (I can > >>> create it for you) or a new aries repo (again I can create it) or the > >> aries > >>> main repo. So all options should be pretty quick to do. > >>> (Of course if you decide for aries we need an approval from the pmc of > >>> aries but I guess that is rather a formality as most are also in this > >> list > >>> and would have objected if they did not want it at aries). > >>> > >>> Christian > >>> > >>> Am Mi., 13. Nov. 2019 um 09:39 Uhr schrieb Romain Manni-Bucau < > >>> rmannibu...@gmail.com>: > >>> > >>>> I kind of share the fact code will likely be stable - that said, > >> depending > >>>> the adoption it can evolve quite a lot for ~1 year I think (adding > >> method > >>>> binding support is the one I have in mind if the module works great > >> without > >>>> this feature). > >>>> Where I'm a bit less "easy" is cause karaf has jms, jpa, jdbc etc > >> modules > >>>> so it sounds it is on the same plan to me, no? > >>>> That said, once again any home will be fine for me while it exists ;) > >>>> > >>>> Le mer. 13 nov. 2019 à 09:29, Christian Schneider < > >> ch...@die-schneider.net > >>>>> > >>>> a écrit : > >>>> > >>>>> I would not put the new code into an existing Aries subproject. > Instead > >>>> we > >>>>> could add a new one. > >>>>> Either in its own git repo or in the shared one (depends on how we > want > >>>> to > >>>>> release). > >>>>> > >>>>> @Romain .. do you plan to version by bundle or the whole interceptor > >>>>> subproject? > >>>>> If you plan to release by bundle then the aries main git would be a > >> great > >>>>> fit as the modules there are released in the same fashion. > >>>>> If you plan to always release the whole interceptor tree then a new > git > >>>>> repo in aries or karaf would work great. > >>>>> > >>>>> The karaf main repo would be a bad choice as I think the interceptor > >> code > >>>>> will be quite stable after some time while karaf will always be > >> changing. > >>>>> > >>>>> Christian > >>>>> > >>>>> Am Di., 12. Nov. 2019 um 11:23 Uhr schrieb Romain Manni-Bucau < > >>>>> rmannibu...@gmail.com>: > >>>>> > >>>>>> Updated the code, last changes are mainly: > >>>>>> > >>>>>> 1. moving the module in the right parent (I put it in service > instead > >>>> of > >>>>>> service*s* originally) > >>>>>> 2. added an E2E test
Re: [PR/DISCUSS] Interceptor module?
Of course it technically works but it would be the only case in the karaf main repo. It would confuse people a lot. I think we should not start this. Creating a new karaf repo is no big issue. Christian Am Do., 14. Nov. 2019 um 11:54 Uhr schrieb Jean-Baptiste Onofré < j...@nanthrax.net>: > Hi, > > It can be released in its own cycle in the main repo. > > For instance, ServiceMix Bundles are on an unique git repo, but I do > release of each independently from the others. > > I think we can start like this. > > Regards > JB > > On 14/11/2019 11:09, Christian Schneider wrote: > > The fact that it evolves a lot at the start is even another argument to > > keep it out of the karaf main repo as there you can only release together > > with karaf. > > > > I think in the end it is your decision - either a new karaf repo (I can > > create it for you) or a new aries repo (again I can create it) or the > aries > > main repo. So all options should be pretty quick to do. > > (Of course if you decide for aries we need an approval from the pmc of > > aries but I guess that is rather a formality as most are also in this > list > > and would have objected if they did not want it at aries). > > > > Christian > > > > Am Mi., 13. Nov. 2019 um 09:39 Uhr schrieb Romain Manni-Bucau < > > rmannibu...@gmail.com>: > > > >> I kind of share the fact code will likely be stable - that said, > depending > >> the adoption it can evolve quite a lot for ~1 year I think (adding > method > >> binding support is the one I have in mind if the module works great > without > >> this feature). > >> Where I'm a bit less "easy" is cause karaf has jms, jpa, jdbc etc > modules > >> so it sounds it is on the same plan to me, no? > >> That said, once again any home will be fine for me while it exists ;) > >> > >> Le mer. 13 nov. 2019 à 09:29, Christian Schneider < > ch...@die-schneider.net > >>> > >> a écrit : > >> > >>> I would not put the new code into an existing Aries subproject. Instead > >> we > >>> could add a new one. > >>> Either in its own git repo or in the shared one (depends on how we want > >> to > >>> release). > >>> > >>> @Romain .. do you plan to version by bundle or the whole interceptor > >>> subproject? > >>> If you plan to release by bundle then the aries main git would be a > great > >>> fit as the modules there are released in the same fashion. > >>> If you plan to always release the whole interceptor tree then a new git > >>> repo in aries or karaf would work great. > >>> > >>> The karaf main repo would be a bad choice as I think the interceptor > code > >>> will be quite stable after some time while karaf will always be > changing. > >>> > >>> Christian > >>> > >>> Am Di., 12. Nov. 2019 um 11:23 Uhr schrieb Romain Manni-Bucau < > >>> rmannibu...@gmail.com>: > >>> > >>>> Updated the code, last changes are mainly: > >>>> > >>>> 1. moving the module in the right parent (I put it in service instead > >> of > >>>> service*s* originally) > >>>> 2. added an E2E test using pax-exam > >>>> 3. make it work :) > >>>> > >>>> I added a doc page ([1]) to try to share more what it tries to > achieve. > >>>> > >>>> About aries, the proxy module looks almost 100% bound to blueprint so > >>>> didn't see it as an option but I don't have a really strong blocker > >>> there, > >>>> I'll fully trust the OSGi@apache community on that. > >>>> > >>>> [1] > >>>> > >>>> > >>> > >> > https://github.com/apache/karaf/pull/993/files#diff-6aaf055d932f602b06135e6446ee6c2eR15 > >>>> > >>>> Romain Manni-Bucau > >>>> @rmannibucau <https://twitter.com/rmannibucau> | Blog > >>>> <https://rmannibucau.metawerx.net/> | Old Blog > >>>> <http://rmannibucau.wordpress.com> | Github < > >>>> https://github.com/rmannibucau> | > >>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book > >>>> < > >>>> > >>> > >> > https://www.packtpub.com/application-development/java-ee-8-high-performance > >>>>&g
Re: [PR/DISCUSS] Interceptor module?
The fact that it evolves a lot at the start is even another argument to keep it out of the karaf main repo as there you can only release together with karaf. I think in the end it is your decision - either a new karaf repo (I can create it for you) or a new aries repo (again I can create it) or the aries main repo. So all options should be pretty quick to do. (Of course if you decide for aries we need an approval from the pmc of aries but I guess that is rather a formality as most are also in this list and would have objected if they did not want it at aries). Christian Am Mi., 13. Nov. 2019 um 09:39 Uhr schrieb Romain Manni-Bucau < rmannibu...@gmail.com>: > I kind of share the fact code will likely be stable - that said, depending > the adoption it can evolve quite a lot for ~1 year I think (adding method > binding support is the one I have in mind if the module works great without > this feature). > Where I'm a bit less "easy" is cause karaf has jms, jpa, jdbc etc modules > so it sounds it is on the same plan to me, no? > That said, once again any home will be fine for me while it exists ;) > > Le mer. 13 nov. 2019 à 09:29, Christian Schneider > > a écrit : > > > I would not put the new code into an existing Aries subproject. Instead > we > > could add a new one. > > Either in its own git repo or in the shared one (depends on how we want > to > > release). > > > > @Romain .. do you plan to version by bundle or the whole interceptor > > subproject? > > If you plan to release by bundle then the aries main git would be a great > > fit as the modules there are released in the same fashion. > > If you plan to always release the whole interceptor tree then a new git > > repo in aries or karaf would work great. > > > > The karaf main repo would be a bad choice as I think the interceptor code > > will be quite stable after some time while karaf will always be changing. > > > > Christian > > > > Am Di., 12. Nov. 2019 um 11:23 Uhr schrieb Romain Manni-Bucau < > > rmannibu...@gmail.com>: > > > > > Updated the code, last changes are mainly: > > > > > > 1. moving the module in the right parent (I put it in service instead > of > > > service*s* originally) > > > 2. added an E2E test using pax-exam > > > 3. make it work :) > > > > > > I added a doc page ([1]) to try to share more what it tries to achieve. > > > > > > About aries, the proxy module looks almost 100% bound to blueprint so > > > didn't see it as an option but I don't have a really strong blocker > > there, > > > I'll fully trust the OSGi@apache community on that. > > > > > > [1] > > > > > > > > > https://github.com/apache/karaf/pull/993/files#diff-6aaf055d932f602b06135e6446ee6c2eR15 > > > > > > Romain Manni-Bucau > > > @rmannibucau <https://twitter.com/rmannibucau> | Blog > > > <https://rmannibucau.metawerx.net/> | Old Blog > > > <http://rmannibucau.wordpress.com> | Github < > > > https://github.com/rmannibucau> | > > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book > > > < > > > > > > https://www.packtpub.com/application-development/java-ee-8-high-performance > > > > > > > > > > > > > Le mar. 12 nov. 2019 à 08:15, Grzegorz Grzybek > a > > > écrit : > > > > > > > Hello > > > > > > > > pon., 11 lis 2019 o 20:45 Christian Schneider < > ch...@die-schneider.net > > > > > > > napisał(a): > > > > > > > > > Great to hear that you already considered aspecio. > > > > > If we want to put this into apache then I rather would suggest > Apache > > > > > Felix, Apache Aries or a Karaf submodule. > > > > > > > > > > > > > Yes, IMO it'd fit more into Apache Aries Proxy. > > > > > > > > regards > > > > Grzegorz Grzybek > > > > > > > > > > > > > The interceptor support is a small standalone module that should > have > > > its > > > > > own lifecycle. > > > > > Putting it in the main karaf tree would mean it is released for > every > > > > karaf > > > > > version. > > > > > > > > > > Christian > > > > > > > > > > Am Mo., 11. Nov. 2019 um 20:38 Uhr schrieb Romain Manni-Bucau < > > > > > rmannibu...@gmail.com>: > > > > > > > > &g
Re: [PR/DISCUSS] Interceptor module?
Yes.. mainly its own git repo so we can version it independently. Christian Am Mo., 11. Nov. 2019 um 20:49 Uhr schrieb Romain Manni-Bucau < rmannibu...@gmail.com>: > Guess it is true for all project and I assume "submodule" means > "subproject" right? > Not sure what it means in practise (new git?) but it is not shocking. Any > proposal karaf-ioc (we could add more feature later this way)? Is it what > you meant? > > Romain Manni-Bucau > @rmannibucau <https://twitter.com/rmannibucau> | Blog > <https://rmannibucau.metawerx.net/> | Old Blog > <http://rmannibucau.wordpress.com> | Github < > https://github.com/rmannibucau> | > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book > < > https://www.packtpub.com/application-development/java-ee-8-high-performance > > > > > Le lun. 11 nov. 2019 à 20:45, Christian Schneider > > a écrit : > > > Great to hear that you already considered aspecio. > > If we want to put this into apache then I rather would suggest Apache > > Felix, Apache Aries or a Karaf submodule. > > The interceptor support is a small standalone module that should have its > > own lifecycle. > > Putting it in the main karaf tree would mean it is released for every > karaf > > version. > > > > Christian > > > > Am Mo., 11. Nov. 2019 um 20:38 Uhr schrieb Romain Manni-Bucau < > > rmannibu...@gmail.com>: > > > > > @Christian yes and no. Ray pointed out aspecio to me but I had a few > > issues > > > with it: > > > > > > 1. it brings its own stack - and yes I care about each single dep my > app > > > brings cause, a) network usage the size can implies with modern > > > deployments, b) security vulnerabilities the stack can hide. > > > 2. it is not at asf or asf influenced (as part of codehaus projects had > > > been in early times for exapple) with all it implies in terms of > > governance > > > and legal quality. > > > 3. the API is reinvented compared to the final step of my proposal > which > > > would be aligned on the standard. Current version of code is almost > > aligned > > > on interceptor API (you just sed the package for the mainstream usage) > > but > > > the consumer side is a bit different, I must refine it to be closer to > > CDI > > > but it is just a matter of handling RUNTIME interceptor annotations and > > > just using @Interceptors as a component property type of type boolean > and > > > not a value holder which breaks interceptor simplicity. > > > 4. it is a one guy github project (even if code quality is not bad) so > > not > > > something you can reliably use in a professional project (we > don't > > > code in javascript ;)) > > > 5. no commit since > 1 year? > > > > > > Hope it clarifies a bit how I ended up on that proposal. > > > > > > Romain Manni-Bucau > > > @rmannibucau <https://twitter.com/rmannibucau> | Blog > > > <https://rmannibucau.metawerx.net/> | Old Blog > > > <http://rmannibucau.wordpress.com> | Github < > > > https://github.com/rmannibucau> | > > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book > > > < > > > > > > https://www.packtpub.com/application-development/java-ee-8-high-performance > > > > > > > > > > > > > Le lun. 11 nov. 2019 à 20:22, Jean-Baptiste Onofré a > > > écrit : > > > > > > > Hi Romain, > > > > > > > > that sounds great to me ! Thanks for that. > > > > > > > > First, you did well in terms of modules organization: it makes sense > to > > > > have interceptor in service (like staticcm). > > > > > > > > About the use case, it makes sense as well. I will take a deeper look > > > soon. > > > > > > > > Thanks again ! > > > > Regards > > > > JB > > > > > > > > > > > > On 11/11/2019 19:37, Romain Manni-Bucau wrote: > > > > > Hi all, > > > > > > > > > > I took some time this week-end to draft an interceptor module in > > Karaf. > > > > > I tried to describe it in the related PR ([1]) - in WIP mode so > don't > > > > jump > > > > > on me yet cause tests are not there please ;). > > > > > > > > > > High level, I missed a lot interceptors (from javax.) when starting > > to > > &g
Re: [PR/DISCUSS] Interceptor module?
Great to hear that you already considered aspecio. If we want to put this into apache then I rather would suggest Apache Felix, Apache Aries or a Karaf submodule. The interceptor support is a small standalone module that should have its own lifecycle. Putting it in the main karaf tree would mean it is released for every karaf version. Christian Am Mo., 11. Nov. 2019 um 20:38 Uhr schrieb Romain Manni-Bucau < rmannibu...@gmail.com>: > @Christian yes and no. Ray pointed out aspecio to me but I had a few issues > with it: > > 1. it brings its own stack - and yes I care about each single dep my app > brings cause, a) network usage the size can implies with modern > deployments, b) security vulnerabilities the stack can hide. > 2. it is not at asf or asf influenced (as part of codehaus projects had > been in early times for exapple) with all it implies in terms of governance > and legal quality. > 3. the API is reinvented compared to the final step of my proposal which > would be aligned on the standard. Current version of code is almost aligned > on interceptor API (you just sed the package for the mainstream usage) but > the consumer side is a bit different, I must refine it to be closer to CDI > but it is just a matter of handling RUNTIME interceptor annotations and > just using @Interceptors as a component property type of type boolean and > not a value holder which breaks interceptor simplicity. > 4. it is a one guy github project (even if code quality is not bad) so not > something you can reliably use in a professional project (we don't > code in javascript ;)) > 5. no commit since > 1 year? > > Hope it clarifies a bit how I ended up on that proposal. > > Romain Manni-Bucau > @rmannibucau <https://twitter.com/rmannibucau> | Blog > <https://rmannibucau.metawerx.net/> | Old Blog > <http://rmannibucau.wordpress.com> | Github < > https://github.com/rmannibucau> | > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book > < > https://www.packtpub.com/application-development/java-ee-8-high-performance > > > > > Le lun. 11 nov. 2019 à 20:22, Jean-Baptiste Onofré a > écrit : > > > Hi Romain, > > > > that sounds great to me ! Thanks for that. > > > > First, you did well in terms of modules organization: it makes sense to > > have interceptor in service (like staticcm). > > > > About the use case, it makes sense as well. I will take a deeper look > soon. > > > > Thanks again ! > > Regards > > JB > > > > > > On 11/11/2019 19:37, Romain Manni-Bucau wrote: > > > Hi all, > > > > > > I took some time this week-end to draft an interceptor module in Karaf. > > > I tried to describe it in the related PR ([1]) - in WIP mode so don't > > jump > > > on me yet cause tests are not there please ;). > > > > > > High level, I missed a lot interceptors (from javax.) when starting to > > use > > > SCR. > > > It mainly change the way to add transversal features (metrics, > security, > > > tracing, circuit-breaker, asynchronism to cite a few). > > > > > > I still have some API refinement to do but high level it would enable a > > > service to be marked as intercepted ([2]) and implement interceptors > "as > > > usual" ([3]) and link them with a marker (in the PoC it is an > > annotation). > > > > > > It is in very early stages but before investing way more time, I'd like > > to > > > know if it sounds like a module Karaf could host and would benefit more > > > than me or if it is an "EE guy" idea ;). > > > > > > Wdyt? > > > > > > [1] https://github.com/apache/karaf/pull/993 > > > [2] > > > > > > https://github.com/apache/karaf/pull/993/files#diff-5edc34da45232dc12a96cae52e620adcR22 > > > [3] > > > > > > https://github.com/apache/karaf/pull/993/files#diff-412d137df581cff1938e723692a1ec45R24 > > > > > > Romain Manni-Bucau > > > @rmannibucau <https://twitter.com/rmannibucau> | Blog > > > <https://rmannibucau.metawerx.net/> | Old Blog > > > <http://rmannibucau.wordpress.com> | Github < > > https://github.com/rmannibucau> | > > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book > > > < > > > https://www.packtpub.com/application-development/java-ee-8-high-performance > > > > > > > > > > -- > > Jean-Baptiste Onofré > > jbono...@apache.org > > http://blog.nanthrax.net > > Talend - http://www.talend.com > > > -- -- Christian Schneider http://www.liquid-reality.de Computer Scientist http://www.adobe.com
Re: [PR/DISCUSS] Interceptor module?
I think we do not have to invent this. There is already aspecio. https://github.com/primeval-io/aspecio Christian Am Mo., 11. Nov. 2019 um 19:37 Uhr schrieb Romain Manni-Bucau < rmannibu...@gmail.com>: > Hi all, > > I took some time this week-end to draft an interceptor module in Karaf. > I tried to describe it in the related PR ([1]) - in WIP mode so don't jump > on me yet cause tests are not there please ;). > > High level, I missed a lot interceptors (from javax.) when starting to use > SCR. > It mainly change the way to add transversal features (metrics, security, > tracing, circuit-breaker, asynchronism to cite a few). > > I still have some API refinement to do but high level it would enable a > service to be marked as intercepted ([2]) and implement interceptors "as > usual" ([3]) and link them with a marker (in the PoC it is an annotation). > > It is in very early stages but before investing way more time, I'd like to > know if it sounds like a module Karaf could host and would benefit more > than me or if it is an "EE guy" idea ;). > > Wdyt? > > [1] https://github.com/apache/karaf/pull/993 > [2] > > https://github.com/apache/karaf/pull/993/files#diff-5edc34da45232dc12a96cae52e620adcR22 > [3] > > https://github.com/apache/karaf/pull/993/files#diff-412d137df581cff1938e723692a1ec45R24 > > Romain Manni-Bucau > @rmannibucau <https://twitter.com/rmannibucau> | Blog > <https://rmannibucau.metawerx.net/> | Old Blog > <http://rmannibucau.wordpress.com> | Github < > https://github.com/rmannibucau> | > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book > < > https://www.packtpub.com/application-development/java-ee-8-high-performance > > > -- -- Christian Schneider http://www.liquid-reality.de Computer Scientist http://www.adobe.com
Re: [DISCUSS] Donate Winegrower as Karaf subproject, OSGi flavor with flat/single classloader runtime
I looked more into the documentation and it seems that Winegrower supports more than just running in a single classpath. It is also about assembling the application and custom annotations. Interesting concept. Christian Am Do., 31. Okt. 2019 um 13:05 Uhr schrieb Christian Schneider < ch...@die-schneider.net>: > Winegrower sounds similar to felix connect (aka pojo sr). > Can you elaborate how it is different? > > Christian > > Am Di., 29. Okt. 2019 um 10:16 Uhr schrieb Jean-Baptiste Onofré < > j...@nanthrax.net>: > >> Hi guys, >> >> For some months now, Romain and I worked on a PoC named Winegrower. >> >> Winegrower provides three modules: >> >> 1. a Java runtime with OSGi programming model with a flat/single >> classloader. >> >> 2. Winegrower "Cepages" are extensions (similar to spring-boot starter) >> that allows you to easily add flavors to your applications running with >> Winegrower. >> >> 3. Java agent to add winegrower at low level and get turnkey feature >> like monitoring, etc. >> >> We think Winegrower would be a great addition to Karaf for two reasons: >> >> 1. It's a first implementation about a flat/single classloader approach >> for OSGi. I know OSGi Alliance (and especially Ray) is thinking about >> that. >> >> 2. It's a great start to provide better tooling around OSGi and Karaf. >> The idea is to have >> >> Just to be clear, you can develop an application and test it with >> Winegrower. Then, you can run the application using a simple JVM with >> the Winegrower Ripener or deploy in Karaf, it's up to you, depending of >> the use case. >> >> The current Winegrower codebase is there: >> >> https://github.com/jbonofre/winegrower >> >> You can take a look on the README and the examples. >> >> We also deployed a quick website: https://jbonofre.github.io/winegrower/ >> >> Thoughts ? >> >> Regards >> JB & Romain >> >> > > -- > -- > Christian Schneider > http://www.liquid-reality.de > > Computer Scientist > http://www.adobe.com > > -- -- Christian Schneider http://www.liquid-reality.de Computer Scientist http://www.adobe.com
Re: Quarkus Integration https://quarkus.io/
gt; > >> > > >> regards > > >> Grzegorz Grzybek > > >> > > >> czw., 10 paź 2019 o 23:48 Patrique Legault > > > >> napisał(a): > > >> > > >>> Yes exactly what I meant. > > >>> > > >>> On Thu., Oct. 10, 2019, 11:39 p.m. Krzysztof Sobkowiak, < > > >>> krzys.sobkow...@gmail.com> wrote: > > >>> > > >>>> Hi > > >>>> > > >>>> Do you mean a Karaf feature prviding the Quarkus libraries (like the > > >>>> Spring or Hibernate feaures)? > > >>>> > > >>>> Best regards > > >>>> Krzysztof > > >>>> > > >>>> On Thu, 2019-09-26 at 15:25 -0400, Patrique Legault wrote: > > >>>>> Hello Romain, > > >>>>> > > >>>>> Let me just start by saying I probably should have done more > research > > >>> on > > >>>>> Quarkus before sending off this email. > > >>>>> > > >>>>> In my mind when I think of Karaf, I think of a service that allows > > >>>>> developers to simply install a feature into the service and gives > > >> them > > >>>>> access to a framework that they can then develop against. For > > >> instance, > > >>>>> installing a version of hibernate, spring, etc...into the Karaf > > >>> service. > > >>>>> > > >>>>> When I saw the Quarkus framework, I thought of a potential > > >> opportunity > > >>>> for > > >>>>> Karaf to provide another framework for developers to use. That > being > > >>> said > > >>>>> if this is something that Karaf already exposes through various > other > > >>>>> libraries then there is nothing to do. > > >>>>> > > >>>>> Next time though I will definitely do some more research prior to a > > >>>>> proposition. > > >>>>> > > >>>>> Cheers, > > >>>>> > > >>>>> On Thu, Sep 26, 2019 at 10:10 AM Jamie G. < > jamie.goody...@gmail.com> > > >>>> wrote: > > >>>>> > > >>>>>> I'm not sure the the ask entails here. > > >>>>>> > > >>>>>> Why does it need to be integrated into Karaf? Can Quarkus just > > >>> publish > > >>>>>> a feature which Karaf users could install in the usual manner? > > >>>>>> > > >>>>>> On Thu, Sep 26, 2019 at 11:34 AM Romain Manni-Bucau > > >>>>>> wrote: > > >>>>>>> Hi Patrique, > > >>>>>>> > > >>>>>>> I have to admit I'm not following, Quarkus is mainly a > > >> microprofile > > >>>> based > > >>>>>>> server integrated with GraalVM in the IBM/Redhat ecosystem to > > >> build > > >>>>>>> natively a HTTP app (for k8s). > > >>>>>>> It also supports a JVM mode but then it is like any CDI/JAXRS > > >>> server. > > >>>>>>> In this last mode Karaf is already very competitive so I guess it > > >>> is > > >>>> not > > >>>>>>> the target and in the first mode the current challenge of Graal > > >> for > > >>>> Karaf > > >>>>>>> (OSGi actually) is that it does not support classloading (and > > >>>> conflicting > > >>>>>>> API in the same application). > > >>>>>>> > > >>>>>>> Concretely my point is that Karaf already supports Tomcat and > > >> Jetty > > >>>> (and > > >>>>>>> undertow i think) through pax-web and jersey/cxf so it already > > >> has > > >>> a > > >>>>>> "lean > > >>>>>>> and efficient Java server". Add all the recent work about > > >>>>>> containerization > > >>>>>>> (static resolver, docker mojo etc) and you can couple it with > > >>>> "container > > >>>>>>> first framework". > > >>>>>>> >
Re: [VOTE] Apache Karaf (runtime) 4.2.7 release
+1 Christian Am Mo., 23. Sept. 2019 um 18:35 Uhr schrieb Jean-Baptiste Onofré < j...@nanthrax.net>: > Hi all, > > I submit Apache Karaf (runtime) 4.2.7 to your vote. This is a > maintenance release on the 4.2.x series, bringing updates, improvements > and fixes (client.bat on Windows, config fileinstall reuse, race > condition on config in some activator, ...). > > Release Notes: > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12345539 > > Staging Repository: > https://repository.apache.org/content/repositories/orgapachekaraf-1133/ > > Git Tag: > karaf-4.2.7 > > 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 > -- > Jean-Baptiste Onofré > jbono...@apache.org > http://blog.nanthrax.net > Talend - http://www.talend.com > -- -- Christian Schneider http://www.liquid-reality.de Computer Scientist http://www.adobe.com
Re: Hello World!
Don't get me wrong. The karaf examples are great and do a good job in showing all the features karaf has. The big issue though is that the examples show a lot of ways of doing the same thing. This is the right choice when it is about showing the features of karaf. It is not good as an introduction for how to create a streamlined application as it offers too many choices. What I have in mind is a very opinionated and structured documentation that concentrates on one solution for each of the parts of an application. It also has to show how it all fits together. This is very different from the goals of the karaf examples. I remember well the discussion we had about the karaf examples and about how opinionated they should be. I think you were right about being not very opinionated for karaf examples. It fits the idea of the platform. Christian Am Do., 19. Sept. 2019 um 15:43 Uhr schrieb Julian Feinauer < j.feina...@pragmaticminds.de>: > Thanks Christian, I will check out your stuff later on. Ideally I would > love to have a book about karaf and some osgi basics and ds... But I guess > that's a lot of work. > > So I think tutorials and examples are a good pragmatic compromise : ) > > From: Jean-Baptiste Onofré > Sent: Thursday, September 19, 2019 8:15:08 AM > To: dev@karaf.apache.org > Subject: Re: Hello World! > > Hi Christian, > > I think Karaf examples are good enough to start. They are maybe too > simple but provide "classic" use cases (rest, service, jpa, etc). > > I agree we can do more, and we are working on it. It's something I > discuss with some guys at ApacheCon last week. > I will come with concrete proposal soon ;) > > Regards > JB > > > On 19/09/2019 15:02, Christian Schneider wrote: > > The problem with OSGi docs is that most of the material is quite old. > > Much of it does not apply to modern OSGi development anymore. > > > > Another issue is that especially for dependency injection there are > quite a > > few alternatives. Every of these come with their own pros and cons. > > As a beginner it is difficult to understand and decide how to start. > > > > Karaf is a great way to start playing with OSGi as many things are > readily > > available and the shell and webconsole allow some nice insight into the > > system. What karaf does not provide though is a good introduction into > > OSGi. I tried to do so with my tutorials but they are more like explained > > examples. > > > > I planned to do a longer introduction around how to build a typical > > application based on best practices .. but it is a lot of work and I > never > > really took on the task. > > > > You might be interested in my recent talk about OSGi best practices. > > Unfortunately in 30 minutes I was not able to really explain how to build > > an application but maybe the example helps a bit. > > https://adapt.to/2019/en/schedule/osgi-best-practices.html > > The most interesting part there is maybe how to build bundles without xml > > config. > > The new annotations that combine requirements and configs are also very > > interesting. > > Both of these are not yet covered by much material on the web. > > In the example there is a small application with an angular front end > and a > > jax-rs backend that can be easily installed in karaf. > > > > Christian > > > > > > Am Mi., 18. Sept. 2019 um 06:45 Uhr schrieb Julian Feinauer < > > j.feina...@pragmaticminds.de>: > > > >> Hi, > >> > >> it was not so much karaf (I kind of liked it from the start) it was > rather > >> OSGi. > >> We come from spring and when I looked through all the osgi material lots > >> of it seemed strange and confusing like Aries, Blueprint, DS, enRoute, > ... . > >> Serge helped me a lot with sorting the things in my head and getting all > >> clear (also with bundle vs. feature vs. feature-repo) and DS stuff and > lots > >> more. > >> So I think Karaf is already doing an excellent job its rather the OSGi > >> world that is damn confusing and one thing that probably could help is a > >> small OSGi introduction or something. > >> > >> I hope that helps! > >> Julian > >> > >> Am 16.09.19, 11:47 schrieb "Jean-Baptiste Onofré" : > >> > >> By the way, Julian, I'm curious. Why did you consider Karaf "hard > for > >> you to adopt" ? It's to understand what we can improve (maybe > >> message/website, example, whatever) in the project to change that ! > >> &
Re: Hello World!
The problem with OSGi docs is that most of the material is quite old. Much of it does not apply to modern OSGi development anymore. Another issue is that especially for dependency injection there are quite a few alternatives. Every of these come with their own pros and cons. As a beginner it is difficult to understand and decide how to start. Karaf is a great way to start playing with OSGi as many things are readily available and the shell and webconsole allow some nice insight into the system. What karaf does not provide though is a good introduction into OSGi. I tried to do so with my tutorials but they are more like explained examples. I planned to do a longer introduction around how to build a typical application based on best practices .. but it is a lot of work and I never really took on the task. You might be interested in my recent talk about OSGi best practices. Unfortunately in 30 minutes I was not able to really explain how to build an application but maybe the example helps a bit. https://adapt.to/2019/en/schedule/osgi-best-practices.html The most interesting part there is maybe how to build bundles without xml config. The new annotations that combine requirements and configs are also very interesting. Both of these are not yet covered by much material on the web. In the example there is a small application with an angular front end and a jax-rs backend that can be easily installed in karaf. Christian Am Mi., 18. Sept. 2019 um 06:45 Uhr schrieb Julian Feinauer < j.feina...@pragmaticminds.de>: > Hi, > > it was not so much karaf (I kind of liked it from the start) it was rather > OSGi. > We come from spring and when I looked through all the osgi material lots > of it seemed strange and confusing like Aries, Blueprint, DS, enRoute, ... . > Serge helped me a lot with sorting the things in my head and getting all > clear (also with bundle vs. feature vs. feature-repo) and DS stuff and lots > more. > So I think Karaf is already doing an excellent job its rather the OSGi > world that is damn confusing and one thing that probably could help is a > small OSGi introduction or something. > > I hope that helps! > Julian > > Am 16.09.19, 11:47 schrieb "Jean-Baptiste Onofré" : > > By the way, Julian, I'm curious. Why did you consider Karaf "hard for > you to adopt" ? It's to understand what we can improve (maybe > message/website, example, whatever) in the project to change that ! > > Thanks ! > Regards > JB > > On 16/09/2019 18:21, Julian Feinauer wrote: > > Hi everybody, > > > > my name is Julian and as I’m new on this list, I just wanted to > shortly introduce myself. I’m a contributor to some Apache projects (PLC4X, > IoTDB, Calcite) and I met some karaf folks at the ApacheCon in Las Vegas (I > was the guy hanging around introducing JB and Serge). > > I have Karaf on my radar for quite some time but always considered > it to hard for us to adopt. > > > > But, as Serge gave me an awesome hands on introduction yesterday, I > feel like we should really start to work with it and see how it goes. So, > expect some mails from me here or on user@. > > > > Best > > Julian > > > > -- > Jean-Baptiste Onofré > jbono...@apache.org > http://blog.nanthrax.net > Talend - http://www.talend.com > > > -- -- Christian Schneider http://www.liquid-reality.de Computer Scientist http://www.adobe.com
Re: [VOTE] Move jclouds-karaf and jclouds-cli projects under Karaf project governance
+1 (binding) Christian Am Mi., 17. Apr. 2019 um 17:15 Uhr schrieb Jean-Baptiste Onofré < j...@nanthrax.net>: > Hi, > > Some days ago we discussed on the Apache jClouds dev mailing list about > moving the jclouds-karaf and jclouds-cli project under the Karaf project > governance, as it's hard for the jClouds community to maintain them. > > So, I'm proposing: > > 1. We keep the git repository where they are currently: > https://gitbox.apache.org/repos/asf?p=jclouds-karaf.git > https://gitbox.apache.org/repos/asf?p=jclouds-cli.git > We also keep the Maven coordinates as they are. > It would be completely transparent for our users. > > 2. The governance changes to Karaf PMC. I will ask to INFRA to change > the team (group) managing the repo and Jenkins jobs. > 3. I will update Jenkins to notify Karaf mailing list. > > I already have couple of PRs ready for upgrade jclouds-karaf for Karaf > 4.2.x/4.3.x and some other cleanups. > > Please vote to approve this change: > > [ ] +1 Approve the change > [ ] -1 Don't approve the change (please provide specific comments) > > Thanks, > Regards > JB > -- > Jean-Baptiste Onofré > jbono...@apache.org > http://blog.nanthrax.net > Talend - http://www.talend.com > -- -- Christian Schneider http://www.liquid-reality.de Computer Scientist http://www.adobe.com
Re: [VOTE] Apache Karaf (runtime) 4.2.4 release
+1 (binding) Christian Am Do., 14. März 2019 um 13:43 Uhr schrieb Jean-Baptiste Onofré < j...@nanthrax.net>: > Hi all, > > I submit Apache Karaf (runtime) 4.2.4 to your vote. This is a > maintenance release on the 4.2.x series, bringing some improvements and > bug fixes (child instances, blacklist, new configadmin, ASM, ... > versions, and much more). > > Release Notes: > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12344856 > > Staging Repository: > https://repository.apache.org/content/repositories/orgapachekaraf-1129/ > > Git Tag: > karaf-4.2.4 > > 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 > -- > Jean-Baptiste Onofré > jbono...@apache.org > http://blog.nanthrax.net > Talend - http://www.talend.com > -- -- Christian Schneider http://www.liquid-reality.de Computer Scientist http://www.adobe.com
Re: [PROPOSAL] Introduce "static" resolver
+1 Am Mo., 4. März 2019 um 15:29 Uhr schrieb Guillaume Nodet : > Right, and also, the demo is using profiles, and I think we should have a > demo using plain features instead. That does not really change anything, > as the assembly is all done by the plugin, but this lead to a simpler demo. > > Le lun. 4 mars 2019 à 15:18, Jean-Baptiste Onofré a > écrit : > > > That's a very good argument and actually I think you are right, that's > > even better. > > > > Maybe the "missing" part if the tooling and the documentation around > this. > > > > Let me prepare a PR for that ! > > > > Regards > > JB > > > > On 04/03/2019 15:15, Guillaume Nodet wrote: > > > I would argue that we should not use any resolver at all for such > > > containers, and that's already doable with the karaf plugin. > > > We have a demo of that in the > > > examples/karaf-profile-example/karaf-profile-example-static > > > The resolution is done at build time and the list of bundles is written > > in > > > the > > > etc/startup.properties > > > file, by virtue of having the features configured at startup phase > rather > > > than boot phase. > > > In this demo, we even avoid the fact that felix usually copy the > bundles > > in > > > its internal storage by using startup bundles referenced as: > > > > > > reference\:file\:org/ops4j/pax/logging/pax-logging-api/1.10.1/pax-logging-api-1.10.1.jar > > > = 8 > > > This leads to no resolution at all at runtime (the example assembly > does > > > not even contain the karaf features service), a much faster startup > time, > > > less disk space used. > > > > > > Unless I'm mistaken, I don't really see the need to build another > > different > > > thing, but maybe I missed something. > > > > > > Guillaume > > > > > > Le lun. 4 mars 2019 à 15:00, Jean-Baptiste Onofré a > > > écrit : > > > > > >> Hi guys, > > >> > > >> During the introduction thread about "kloud initiative", we quickly > > >> discussed about the resolver. > > >> > > >> Today, we can see concerns about the current features resolver, > > especially: > > >> - the resolution at runtime can be different than the one done during > > >> verify > > >> - the resolution at runtime can be impacted by the version range > > >> - the resolution can cause bunch of refresh, impacting startup and > > >> resolution time > > >> > > >> If the current resolver is great for a "container/dynamic" approach > > >> where karaf is running and we deploy things in it, it's not good for a > > >> "static" bootstrapping as expected for a runtime running on cloud or > > >> docker. > > >> > > >> I would like to propose to introduce a feature resolver named "karaf". > > >> The idea is to use a resolver that reads the features repositories as > > >> they are and install bundles/configuration/etc without checking all > > >> capabilities and requirements. It sounds a bit like a mix of the > simple > > >> resolver we use in the Karaf maven plugin in the verify goal, and what > > >> we had in the past (in Karaf 2.x for instance). It doesn't perform any > > >> refresh, it's up to the developer (and of course the tooling) to > provide > > >> a complete features definition. > > >> > > >> The resolver could be configured in etc/org.apache.karaf.features.cfg > > >> and we can have a "static" distribution with this resolver by default. > > >> > > >> I would propose to rename "standard" distribution as "container", and > we > > >> will provide the "static" distribution. > > >> > > >> Thoughts ? > > >> > > >> Another idea around this is Karaf Winegrower. Winegrower is kind of > > >> Karaf Boot, using a single/unique classloader instead of one > classloader > > >> per bundle. It's pretty convenient for cloud as well. > > >> Maybe we can have winegrower as Karaf subproject. > > >> Currently Winegrower is here: https://github.com/jbonofre/winegrower > > >> > > >> Thoughts ? > > >> > > >> Regards > > >> JB > > >> -- > > >> Jean-Baptiste Onofré > > >> jbono...@apache.org > > >> http://blog.nanthrax.net > > >> Talend - http://www.talend.com > > >> > > > > > > > > > > -- > > Jean-Baptiste Onofré > > jbono...@apache.org > > http://blog.nanthrax.net > > Talend - http://www.talend.com > > > > > -- > > Guillaume Nodet > -- -- Christian Schneider http://www.liquid-reality.de Computer Scientist http://www.adobe.com
Re: [PROPOSAL] Introduce "static" resolver
I agree. The static profile already works great by doing the resolution on build time. Actually it is the same model that bnd resolve also uses. They just do not have the feature concept and only rely on a set of repositories. Christian Am Mo., 4. März 2019 um 15:15 Uhr schrieb Guillaume Nodet : > I would argue that we should not use any resolver at all for such > containers, and that's already doable with the karaf plugin. > We have a demo of that in the > examples/karaf-profile-example/karaf-profile-example-static > The resolution is done at build time and the list of bundles is written in > the > etc/startup.properties > file, by virtue of having the features configured at startup phase rather > than boot phase. > In this demo, we even avoid the fact that felix usually copy the bundles in > its internal storage by using startup bundles referenced as: > > reference\:file\:org/ops4j/pax/logging/pax-logging-api/1.10.1/pax-logging-api-1.10.1.jar > = 8 > This leads to no resolution at all at runtime (the example assembly does > not even contain the karaf features service), a much faster startup time, > less disk space used. > > Unless I'm mistaken, I don't really see the need to build another different > thing, but maybe I missed something. > > Guillaume > > Le lun. 4 mars 2019 à 15:00, Jean-Baptiste Onofré a > écrit : > > > Hi guys, > > > > During the introduction thread about "kloud initiative", we quickly > > discussed about the resolver. > > > > Today, we can see concerns about the current features resolver, > especially: > > - the resolution at runtime can be different than the one done during > > verify > > - the resolution at runtime can be impacted by the version range > > - the resolution can cause bunch of refresh, impacting startup and > > resolution time > > > > If the current resolver is great for a "container/dynamic" approach > > where karaf is running and we deploy things in it, it's not good for a > > "static" bootstrapping as expected for a runtime running on cloud or > > docker. > > > > I would like to propose to introduce a feature resolver named "karaf". > > The idea is to use a resolver that reads the features repositories as > > they are and install bundles/configuration/etc without checking all > > capabilities and requirements. It sounds a bit like a mix of the simple > > resolver we use in the Karaf maven plugin in the verify goal, and what > > we had in the past (in Karaf 2.x for instance). It doesn't perform any > > refresh, it's up to the developer (and of course the tooling) to provide > > a complete features definition. > > > > The resolver could be configured in etc/org.apache.karaf.features.cfg > > and we can have a "static" distribution with this resolver by default. > > > > I would propose to rename "standard" distribution as "container", and we > > will provide the "static" distribution. > > > > Thoughts ? > > > > Another idea around this is Karaf Winegrower. Winegrower is kind of > > Karaf Boot, using a single/unique classloader instead of one classloader > > per bundle. It's pretty convenient for cloud as well. > > Maybe we can have winegrower as Karaf subproject. > > Currently Winegrower is here: https://github.com/jbonofre/winegrower > > > > Thoughts ? > > > > Regards > > JB > > -- > > Jean-Baptiste Onofré > > jbono...@apache.org > > http://blog.nanthrax.net > > Talend - http://www.talend.com > > > > > -- > > Guillaume Nodet > -- -- Christian Schneider http://www.liquid-reality.de Computer Scientist http://www.adobe.com
Re: [VOTE] Apache Karaf Cellar 4.1.3 release
+1 (binding) Christian Am Do., 21. Feb. 2019 um 16:52 Uhr schrieb Jean-Baptiste Onofré < j...@nanthrax.net>: > Hi all, > > I submit Karaf Cellar 4.1.3 release to your vote. This release is a > maintenance release of the Cellar 4.1.x serie. > > Release Notes: > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12344979 > > Staging Repository: > https://repository.apache.org/content/repositories/orgapachekaraf-1128/ > > Git Tag: > cellar-4.1.3 > > 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 > -- > Jean-Baptiste Onofré > jbono...@apache.org > http://blog.nanthrax.net > Talend - http://www.talend.com > -- -- Christian Schneider http://www.liquid-reality.de Computer Scientist http://www.adobe.com
Re: Problem with the newest blueprint in karaf 4.2.x
I think generally this can always happen. I usually use update-strategy="reload" to make sure the new config is applied. See https://github.com/cschneider/Karaf-Tutorial/blob/bf7c69efee2a49422106820a52e9a7ec24131bc3/configadmin/configapp-blueprint/src/main/resources/OSGI-INF/blueprint/context.xml#L9 Christian Am Mi., 13. Feb. 2019 um 14:11 Uhr schrieb Dominik Przybysz < alien11...@apache.org>: > Hi, > we have a problem with Blueprint in newest Karaf versions. We try to > upgrade Karaf from version 4.0.4 to 4.2.2/4.2.3. As we do that, we have a > strange situation during application startup. Bundles await for Config > Admin startup (opinion based on logs), but after that, sometimes our CM > Properties are injected empty. This is nondeterministic - sometimes > injection works fine, sometimes not. It looks like some kind of the race > between threads. On 4.0.4 everything seems to work fine. > > Steps to reproduce: > 1. Build Karaf 4.2.2/4.2.3 distribution using karaf-maven-plugin, including > a few apps using CM Properties. > 2. Start you distribution. > 3. Log injected properties. > 4. Observe that the properties are sometimes empty (after the bundle > restart everything is correct). > > Apache Karaf (4.0.4) > > karaf@root()> list -t 0 | grep -i blueprint > 11 | Active | 20 | 1.0.1| Apache Aries Blueprint API > 12 | Active | 20 | 1.0.7| Apache Aries Blueprint CM > 13 | Active | 20 | 1.5.0| Apache Aries Blueprint Core, Fragments: 14 > 14 | Resolved | 20 | 1.0.0| Apache Aries Blueprint Core Compatiblity > Fragment Bundle, Hosts: 13 > 16 | Active | 30 | 1.1.5| Apache Aries JMX Blueprint API > 17 | Active | 30 | 1.1.5| Apache Aries JMX Blueprint Core > 23 | Active | 30 | 4.0.4| Apache Karaf :: Bundle :: > BlueprintStateService > 26 | Active | 24 | 4.0.4| Apache Karaf :: Deployer :: Blueprint > 33 | Active | 30 | 4.0.4| Apache Karaf :: JAAS :: Blueprint :: > Config > > > Apache Karaf (4.2.2) > > karaf@root()> list -t 0 | grep -i blueprint > 76 ? Active ? 20 ? 1.0.1 ? Apache > Aries Blueprint API > 77 ? Active ? 20 ? 1.3.1 ? Apache > Aries Blueprint CM > 78 ? Active ? 20 ? 1.10.1? Apache > Aries Blueprint Core, Fragments: 79 > 79 ? Resolved ? 20 ? 1.0.0 ? Apache > Aries Blueprint Core Compatiblity Fragment Bundle, Hosts: 78 > 80 ? Active ? 30 ? 1.2.0 ? Apache > Aries JMX Blueprint API > 81 ? Active ? 30 ? 1.2.0 ? Apache > Aries JMX Blueprint Core > 84 ? Active ? 80 ? 1.0.2 ? Apache > Aries Transaction Blueprint > 132 ? Active ? 30 ? 4.2.2 ? Apache > Karaf :: Bundle :: BlueprintStateService > 133 ? Active ? 24 ? 4.2.2 ? Apache > Karaf :: Deployer :: Blueprint > 137 ? Active ? 30 ? 4.2.2 ? Apache > Karaf :: JAAS :: Blueprint :: Config > > What could be a source of problem? Is there any workaround for that? > -- -- Christian Schneider http://www.liquid-reality.de Computer Scientist http://www.adobe.com
Re: [DISCUSS] Launching the kloud initiative
923 > > > >> https://issues.apache.org/jira/browse/KARAF-6148 > > > >> https://issues.apache.org/jira/browse/KARAF-6149 > > > >> https://issues.apache.org/jira/browse/KARAF-6150 > > > >> > > > >> The idea is really to simplify the features generation and > distribution > > > >> packaging. > > > >> > > > >> For the features generation, I'm thinking on annotations directly > in the > > > >> code (in package-info.java for instance) describing the features > needed > > > >> by the application. The annotations scanner could then create the > > > >> features XML using the code itself and the annotations. That would > allow > > > >> us to not relay on Maven and be able to support CLI/Gradle/Maven. > In the > > > >> case where the user uses Maven, we could better leverage Maven to > get > > > >> some details. The idea is to especially easily create features XML > to > > > >> build "static" runtime (that make sense for the cloud). > > > >> > > > >> After the features XML generation, we should have a easier way to > build > > > >> a distribution. We also have to provide multiple "packaging output" > like > > > >> archives (zip/tar.gz), uber jar (embedding karaf and user > application), > > > >> docker image, openimage, kubernetes meta, ... > > > >> The idea is to have a ready to go packaging for the cloud. > > > >> > > > >> For the cloud perspective, the distribution should be > > > >> "immutable/static". Currently, the resolver we have is great for > > > >> "dynamic" deployment but could be painful for static one (dealing > with > > > >> refresh, multiple versions resolution, etc). > > > >> I'm proposing to create kind of "static" resolver > > > >> (https://issues.apache.org/jira/browse/KARAF-6147) directly taking > boot > > > >> features and installing straight forward what's defined in the > features. > > > >> It should result with a more "predictable" behavior, really helpful > from > > > >> a cloud perspective. > > > >> > > > >> Finally, I created some Jira about general improvements for the > cloud > > > >> and docker: > > > >> > > > >> https://issues.apache.org/jira/browse/KARAF-6111 > > > >> https://issues.apache.org/jira/browse/KARAF-4609 > > > >> > > > >> I think you got the overall idea: dramatically simplify creation of > > > >> distribution packaging karaf with user application (for developer), > > > >> simplify the packaging outputs and bootstrapping on cloud (for > devops). > > > >> > > > >> If you think it could be helpful to have a doc on confluence about > that, > > > >> please let me know I will create it. > > > >> > > > >> We all know that Karaf is an amazing runtime. To convince more and > more > > > >> users and give a new dimension to Karaf, I really think that the > "kloud > > > >> initiative" is a must have. We will have a runtime that can address > both > > > >> static and dynamic bootstrapping approach, one runtime for multiple > > > >> services or one runtime per service, etc. > > > >> > > > >> Thoughts ? > > > >> > > > >> Regards > > > >> JB > > > >> -- > > > >> Jean-Baptiste Onofré > > > >> jbono...@apache.org > > > >> http://blog.nanthrax.net > > > >> Talend - http://www.talend.com > > > >> > > > > > > > > > > -- > > > Jean-Baptiste Onofré > > > jbono...@apache.org > > > http://blog.nanthrax.net > > > Talend - http://www.talend.com > > > > -- -- Christian Schneider http://www.liquid-reality.de Computer Scientist http://www.adobe.com
Re: [VOTE] Apache Karaf (runtime) 4.2.3 release (take 2)
+1 (binding) Christian Am Fr., 8. Feb. 2019 um 05:31 Uhr schrieb Jean-Baptiste Onofré < j...@nanthrax.net>: > Hi all, > > I submit Apache Karaf (runtime) 4.2.3 to your vote. This is a > maintenance release on the 4.2.x series, bringing some improvements and > bug fixes. > NB: Once this release vote passed, I will create the karaf-4.2.x branch > and master will become 4.3.x. Obviously karaf-4.2.x will be an active > branch and I already plan to prepare 4.2.4 release. > > Release Notes: > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12344587 > > Staging Repository: > https://repository.apache.org/content/repositories/orgapachekaraf-1126/ > > Git Tag: > karaf-4.2.3 > > 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 > -- > Jean-Baptiste Onofré > jbono...@apache.org > http://blog.nanthrax.net > Talend - http://www.talend.com > -- -- Christian Schneider http://www.liquid-reality.de Computer Scientist http://www.adobe.com
Re: [VOTE] Apache Karaf (runtime) 4.2.3 release
I found the reason. The jdbc feature installs the pax-jdbc feature which installs the pax-jdbc bundle. This bundle creates one DataSourceFactory for all jdbc drivers it finds. This is the source of the duplicate DataSourceFactories. We should not install pax-jdbc feature in the karaf jdbc feature as this makes it harder to use proper drivers that already provide good DataSourceFactories. If we do this then of course this means we will have to re add the adapter bundle to pax-jdbc-derby. On the other hand whenever some installs the feature by hand we will also get into the situation of duplicate DSFs. WDYT? Christian Am Di., 5. Feb. 2019 um 15:36 Uhr schrieb Grzegorz Grzybek < gr.grzy...@gmail.com>: > Indeed ;) > > karaf@root()> bundle:services -p 45 > karaf@root()> feature:install jdbc > karaf@root()> bundle:services -p 45 > > Apache Derby 10.14 (45) provides: > - > objectClass = [org.osgi.service.jdbc.DataSourceFactory] > osgi.jdbc.driver.class = org.apache.derby.jdbc.AutoloadedDriver > osgi.jdbc.driver.name = derby > osgi.jdbc.driver.version = 10.14.200.1828579 > service.bundleid = 45 > service.id = 88 > service.scope = singleton > > regards > Grzegorz Grzybek > > wt., 5 lut 2019 o 15:34 Jean-Baptiste Onofré napisał(a): > > > Hi Christian, > > > > you have to install the jdbc feature, it will work. > > > > That has been found yesterday evening, already created the Jira at Pax > > JDBC. I have to check why Karaf jdbc feature makes the derby > > DataSourceFactory available. > > > > Regards > > JB > > > > On 05/02/2019 15:28, Christian Schneider wrote: > > > I just tried the derby data source: > > > > > > feature:install pax-jdbc-derby pax-jdbc-config pax-jdbc-pool-dbcp2 > > > service:list DataSourceFactory > > > > > > I see no services of this type. So it seems the derby bundle does not > > offer > > > a DataSourceFactory. > > > > > > Christian > > > > > > Am Di., 5. Feb. 2019 um 10:57 Uhr schrieb Jean-Baptiste Onofré < > > > j...@nanthrax.net>: > > > > > >> Hi all, > > >> > > >> I submit Apache Karaf (runtime) 4.2.3 to your vote. This is a > > >> maintenance release on the 4.2.x series, bringing some improvements > and > > >> bug fixes. > > >> NB: Once this release vote passed, I will create the karaf-4.2.x > branch > > >> and master will become 4.3.x. Obviously karaf-4.2.x will be an active > > >> branch and I already plan to prepare 4.2.4 release. > > >> > > >> Release Notes: > > >> > > >> > > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12344587 > > >> > > >> Staging Repository: > > >> > https://repository.apache.org/content/repositories/orgapachekaraf-1125/ > > >> > > >> Git Tag: > > >> karaf-4.2.3 > > >> > > >> 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 > > >> -- > > >> Jean-Baptiste Onofré > > >> jbono...@apache.org > > >> http://blog.nanthrax.net > > >> Talend - http://www.talend.com > > >> > > > > > > > > > > -- > > Jean-Baptiste Onofré > > jbono...@apache.org > > http://blog.nanthrax.net > > Talend - http://www.talend.com > > > -- -- Christian Schneider http://www.liquid-reality.de Computer Scientist http://www.adobe.com
Re: [VOTE] Apache Karaf (runtime) 4.2.3 release
I just tried the derby data source: feature:install pax-jdbc-derby pax-jdbc-config pax-jdbc-pool-dbcp2 service:list DataSourceFactory I see no services of this type. So it seems the derby bundle does not offer a DataSourceFactory. Christian Am Di., 5. Feb. 2019 um 10:57 Uhr schrieb Jean-Baptiste Onofré < j...@nanthrax.net>: > Hi all, > > I submit Apache Karaf (runtime) 4.2.3 to your vote. This is a > maintenance release on the 4.2.x series, bringing some improvements and > bug fixes. > NB: Once this release vote passed, I will create the karaf-4.2.x branch > and master will become 4.3.x. Obviously karaf-4.2.x will be an active > branch and I already plan to prepare 4.2.4 release. > > Release Notes: > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12344587 > > Staging Repository: > https://repository.apache.org/content/repositories/orgapachekaraf-1125/ > > Git Tag: > karaf-4.2.3 > > 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 > -- > Jean-Baptiste Onofré > jbono...@apache.org > http://blog.nanthrax.net > Talend - http://www.talend.com > -- -- Christian Schneider http://www.liquid-reality.de Computer Scientist http://www.adobe.com
Re: [VOTE] Apache Karaf (runtime) 4.2.2 release
+1 I tested the aries-jpa blueprint example with the karaf minimal distro on windows 10. Works perfectly now. Christian Am So., 16. Dez. 2018 um 11:18 Uhr schrieb Jean-Baptiste Onofré < j...@nanthrax.net>: > Hi all, > > Finally, after different new fixes and third party releases, I'm glad to > submit Karaf (runtime) 4.2.2 release to your vote. This is a major > maintenance release for 4.2.x series, bringing a lot of fixes & > improvements. > > Release Notes: > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12343458=12311140 > > Staging Repository: > https://repository.apache.org/content/repositories/orgapachekaraf-1123/ > > Git Tag: > karaf-4.2.2 > > 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 > -- > Jean-Baptiste Onofré > jbono...@apache.org > http://blog.nanthrax.net > Talend - http://www.talend.com > -- -- Christian Schneider http://www.liquid-reality.de Computer Scientist http://www.adobe.com
Re: [VOTE] Apache Karaf (runtime) 4.1.7 release
+1 Christian Am Mo., 26. Nov. 2018 um 19:38 Uhr schrieb Jean-Baptiste Onofré < j...@nanthrax.net>: > Hi all, > > I submit Karaf (runtime) 4.1.7 release to your vote. This is a > maintenance release on 4.1.x series. > > Release Notes: > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12343797 > > Staging Repository: > https://repository.apache.org/content/repositories/orgapachekaraf-1122/ > > Git Tag: > karaf-4.1.7 > > 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 > -- > Jean-Baptiste Onofré > jbono...@apache.org > http://blog.nanthrax.net > Talend - http://www.talend.com > -- -- Christian Schneider http://www.liquid-reality.de Computer Scientist http://www.adobe.com
Re: [DISCUSS] Apache Karaf 4.3.x and resource repositories
That might even be similar to what I have in mind. Can you elaborate a bit how it would work? Christian Am Fr., 23. Nov. 2018 um 11:35 Uhr schrieb Jean-Baptiste Onofré < j...@nanthrax.net>: > It's not a new concept. It's just better leverage bundle repositories in > feature and have light features. > > Regards > JB > > Le 23 nov. 2018 à 10:45, à 10:45, Christian Schneider < > ch...@die-schneider.net> a écrit: > >I do not really understand what this approach does different to > >features. > >Can you elaborate a bit more? > > > >I think it would be great to go more into the direction of repositories > >and > >features that do not have to list all bundles but only the required > >bundles > >to let the resolver find the rest. > >As far as I understand this does not require a completely new concept. > >It > >can be done based on the current features. > > > >Christian > > > >Am Fr., 23. Nov. 2018 um 05:16 Uhr schrieb Jean-Baptiste Onofré < > >j...@nanthrax.net>: > > > >> Hi guys, > >> > >> as discussed since some weeks, Karaf 4.2.2 should be in vote in > >couple > >> of weeks. > >> I started a Karaf 4.3.x branch locally and master will become 4.3.x > >once > >> 4.2.x branch will be created. > >> > >> Karaf 4.3.x will update to OSGi R7 and other major dependency > >updates. I > >> will include a new feature/improvement in 4.3.x: > >> > >> https://issues.apache.org/jira/browse/KARAF-6000 > >> > >> Today, Karaf supports resources repositories (yaml or xml) in > >> etc/org.apache.karaf.features.cfg. A resource repository looks a bit > >> like "old" OBR: it contains resources (bundles but also config, etc) > >> with associated requirements and capabilities. > >> The resolver uses those requirements and capabilities to find the > >> dependency resources he should install when installing a feature or a > >> bundle. That's convenient and close to the "core" OSGi approach. > >> > >> However, the resource repositories set defined in > >> etc/org.apache.karaf.features.cfg is static: it's loaded and > >evaluated > >> when the features service starts, then the resolver uses it. > >> > >> The proposal in KARAF-6000 is to be able to update the resource > >> repositories set on the fly (with dedicated commands for instance) > >and, > >> each time the resource repositories set is modified, perform a new > >whole > >> resolution. > >> Basically, it means that only the "standard" Karaf features would be > >> required at startup, the users will be able to use only resource > >> repositories (not features repositories) once Karaf is started. > >> I already started a PoC for KARAF-6000. > >> > >> Thoughts ? > >> > >> Regards > >> JB > >> -- > >> Jean-Baptiste Onofré > >> jbono...@apache.org > >> http://blog.nanthrax.net > >> Talend - http://www.talend.com > >> > > > > > >-- > >-- > >Christian Schneider > >http://www.liquid-reality.de > > > >Computer Scientist > >http://www.adobe.com > -- -- Christian Schneider http://www.liquid-reality.de Computer Scientist http://www.adobe.com
Re: [DISCUSS] Apache Karaf 4.3.x and resource repositories
I do not really understand what this approach does different to features. Can you elaborate a bit more? I think it would be great to go more into the direction of repositories and features that do not have to list all bundles but only the required bundles to let the resolver find the rest. As far as I understand this does not require a completely new concept. It can be done based on the current features. Christian Am Fr., 23. Nov. 2018 um 05:16 Uhr schrieb Jean-Baptiste Onofré < j...@nanthrax.net>: > Hi guys, > > as discussed since some weeks, Karaf 4.2.2 should be in vote in couple > of weeks. > I started a Karaf 4.3.x branch locally and master will become 4.3.x once > 4.2.x branch will be created. > > Karaf 4.3.x will update to OSGi R7 and other major dependency updates. I > will include a new feature/improvement in 4.3.x: > > https://issues.apache.org/jira/browse/KARAF-6000 > > Today, Karaf supports resources repositories (yaml or xml) in > etc/org.apache.karaf.features.cfg. A resource repository looks a bit > like "old" OBR: it contains resources (bundles but also config, etc) > with associated requirements and capabilities. > The resolver uses those requirements and capabilities to find the > dependency resources he should install when installing a feature or a > bundle. That's convenient and close to the "core" OSGi approach. > > However, the resource repositories set defined in > etc/org.apache.karaf.features.cfg is static: it's loaded and evaluated > when the features service starts, then the resolver uses it. > > The proposal in KARAF-6000 is to be able to update the resource > repositories set on the fly (with dedicated commands for instance) and, > each time the resource repositories set is modified, perform a new whole > resolution. > Basically, it means that only the "standard" Karaf features would be > required at startup, the users will be able to use only resource > repositories (not features repositories) once Karaf is started. > I already started a PoC for KARAF-6000. > > Thoughts ? > > Regards > JB > -- > Jean-Baptiste Onofré > jbono...@apache.org > http://blog.nanthrax.net > Talend - http://www.talend.com > -- -- Christian Schneider http://www.liquid-reality.de Computer Scientist http://www.adobe.com
Re: [VOTE] Apache Karaf Cave 4.1.1 release
+1 (binding) Christian Am Mi., 5. Sep. 2018 um 06:56 Uhr schrieb Jean-Baptiste Onofré < j...@nanthrax.net>: > Hi, > > I submit Apache Karaf Cave 4.1.1 release to your vote. > > This is a maintenance release on Cave 4.1.x series (working on Karaf > 4.0.x, 4.1.x and 4.2.x), before starting the upgrade to the next 4.2.x > series. > This release contains fixes on the Maven repository management, the > Feature gateway, the REST services (for both repository and deployer). > > For complete details, please take a look on the release notes: > > Release Notes: > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12342356 > > Git tag: > cave-4.1.1 > > Staging Repository: > https://repository.apache.org/content/repositories/orgapachekaraf-1115/ > > 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 > -- > Jean-Baptiste Onofré > jbono...@apache.org > http://blog.nanthrax.net > Talend - http://www.talend.com > -- -- Christian Schneider http://www.liquid-reality.de Computer Scientist http://www.adobe.com
Re: [VOTE] Apache Karaf "Container" 4.2.1 release
I am currently on holidays. Will take a while. Christian Francois Papon schrieb am Mi., 22. Aug. 2018, 18:48: > Hi Christian, > > I tried to unpack the zip on a Windows 7 and I don't get the path too > long issue. > > Can you share the full path of the example that is problematic ? > > I have created a Jira (KARAF-5876) and want to fix it. > > Thanks > > regards, > > François Papon > fpa...@apache.org > > Le 18/08/2018 à 21:30, Christian Schneider a écrit : > > +1 > > > > Found some issues on windows: > > When unpacking the zip on windows I get path too long for > > BookingServiceImpl.java. > > I think some of the examples are layered too deeply. > > > > Another issue on windows is with the shell. If I do feature:install > > then a long list of features appears. If I scroll thorugh the results > using > > tab the screen soon becomes totally garbled. > > > > So nothing very big but some things for 4.2.2 I guess. > > > > Christian > > > > Am Sa., 18. Aug. 2018 um 15:34 Uhr schrieb Jean-Baptiste Onofré < > > j...@nanthrax.net>: > > > >> Hi, > >> > >> I submit Apache Karaf 4.2.1 release to your vote. > >> > >> This release is a major update on the 4.2.x series. It includes bunch of > >> dependencies updates, fixes and new features, especially: > >> > >> - Better Java 9/10/11 support > >> - Assembly tooling to create Docker image, by the way, official Karaf > >> images will be available soon using these scripts > >> - Docker feature allowing you to manipulate Docker directly from Karaf > >> - Improved itest KarafTestSuport to create your own itests easily > >> - Updated dev guide with examples included in the Karaf standard > >> distribution (and using in the itests) > >> > >> For complete details, please take a look on the release notes: > >> > >> Release Notes: > >> > >> > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12342945 > >> > >> Git tag: > >> karaf-4.2.1 > >> > >> Staging Repository: > >> https://repository.apache.org/content/repositories/orgapachekaraf-1114/ > >> > >> 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 > >> -- > >> Jean-Baptiste Onofré > >> jbono...@apache.org > >> http://blog.nanthrax.net > >> Talend - http://www.talend.com > >> > > > >
Re: Karaf target audience and release granularity
Sounds interesting. Do you think you could write blog about your approach? Christian Am So., 19. Aug. 2018 um 01:42 Uhr schrieb Castor : > "by the way, what do you mean about remote admin ? Is it something like > the Deployer feature we have in Cave?" > > Yes! the deploy module is quite similar, but using JMS instead of JMX, i've > also created a suport to pre and post install hooks and plugins, blue-green > deployment, remote health checks and so on. > > > > -- > Sent from: http://karaf.922171.n3.nabble.com/Karaf-Dev-f930721.html > -- -- Christian Schneider http://www.liquid-reality.de Computer Scientist http://www.adobe.com
Re: [VOTE] Apache Karaf "Container" 4.2.1 release
+1 Found some issues on windows: When unpacking the zip on windows I get path too long for BookingServiceImpl.java. I think some of the examples are layered too deeply. Another issue on windows is with the shell. If I do feature:install then a long list of features appears. If I scroll thorugh the results using tab the screen soon becomes totally garbled. So nothing very big but some things for 4.2.2 I guess. Christian Am Sa., 18. Aug. 2018 um 15:34 Uhr schrieb Jean-Baptiste Onofré < j...@nanthrax.net>: > Hi, > > I submit Apache Karaf 4.2.1 release to your vote. > > This release is a major update on the 4.2.x series. It includes bunch of > dependencies updates, fixes and new features, especially: > > - Better Java 9/10/11 support > - Assembly tooling to create Docker image, by the way, official Karaf > images will be available soon using these scripts > - Docker feature allowing you to manipulate Docker directly from Karaf > - Improved itest KarafTestSuport to create your own itests easily > - Updated dev guide with examples included in the Karaf standard > distribution (and using in the itests) > > For complete details, please take a look on the release notes: > > Release Notes: > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12342945 > > Git tag: > karaf-4.2.1 > > Staging Repository: > https://repository.apache.org/content/repositories/orgapachekaraf-1114/ > > 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 > -- > Jean-Baptiste Onofré > jbono...@apache.org > http://blog.nanthrax.net > Talend - http://www.talend.com > -- -- Christian Schneider http://www.liquid-reality.de Computer Scientist http://www.adobe.com
Re: Karaf target audience and release granularity
rience. > > >> > > >> I don't say that it's your case, but most of the time, when people > > >> complains about refresh, it's because they don't know/understand the > > >> underlying mechanisms. > > >> Basically, I had the case with a customer that used a bunch of > optional > > >> import and complain of the refresh: the issue was basically a design > > >> error and an mistake in the bundles. > > >> > > >> For the update, I don't know which karaf version you are using, but > > >> Karaf 4.2.x has some improvements with feature:update. > > >> > > >> About spring-boot like, it's part of the karaf-boot scope. > > >> > > >> Anyway guys, I think you have very good ideas and it's really great > you > > >> share your experience/use cases. Feel free to create Jira > corresponding > > >> to your ideas, and feel free to contribute. Any help is welcome ! > > >> > > >> Thanks > > >> Regards > > >> JB > > >> > > >> On 17/08/2018 21:34, Castor wrote: > > >>> I can tell a little about my experience with karaf. > > >>> > > >>> Here we have an ERP writen in delphi (that was written in natural > > before > > >>> that) which we need to "upgrade" to a cloud capable software, using > the > > >>> same > > >>> database and mantaining the old software while we rewrite negotial > > rules > > >>> in > > >>> java. Great part of our clients are small-medium with on-premises, so > > we > > >>> had > > >>> to maintain a architecture easy enough for on-premises and able to > use > > a > > >>> cloud structure with clusters and so on. > > >>> > > >>> So, we are using karaf for that, OSGi services lets us to build > > >>> "microservices" and have a easier reuse of Negotial Rules, with > common > > >>> transactions and so on (icks for XA . > > >>> > > >>> Well, it works, but we have some headaches, we had to build or own > > >>> dependency mechanism, because every single feature refreshed the hell > > of > > >>> karaf, we also built an remote admin to update services on-the-fly in > > >>> every > > >>> single customer, it's working quite nicely, we still have some > trouble > > >>> with > > >>> failed bundles, but nothing irremediable. > > >>> > > >>> Two things that would help us a lot, a spring-boot like app and an > > easier > > >>> way to update karaf version, for the updates we had to create a > updater > > >>> which saves a list of negotial bundles, reinstall karaf and restores > > the > > >>> bundles, it works but it's quite meh. > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> -- > > >>> Sent from: http://karaf.922171.n3.nabble.com/Karaf-Dev-f930721.html > > >>> > > >> > > >> -- > > >> Jean-Baptiste Onofré > > > > > >> jbonofre@ > > > > > >> http://blog.nanthrax.net > > >> Talend - http://www.talend.com > > > > > > > > > > > > > > > > > > -- > > > Sent from: http://karaf.922171.n3.nabble.com/Karaf-Dev-f930721.html > > > > > > > -- > > Jean-Baptiste Onofré > > jbono...@apache.org > > http://blog.nanthrax.net > > Talend - http://www.talend.com > > > > > -- > Matt Sicker > -- -- Christian Schneider http://www.liquid-reality.de Computer Scientist http://www.adobe.com
Re: [VOTE] Apache Karaf (Container) 4.1.6 release - take #2
+1 (binding) Christian Am Fr., 10. Aug. 2018 um 06:58 Uhr schrieb Jean-Baptiste Onofré < j...@nanthrax.net>: > Hi all, > > I submit Karaf (Container) 4.1.6 release to your vote (take #2 after Pax > Web and Spring updates). This is a > maintenance release on 4.1.x series. > > Release Notes: > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12342748 > > Staging Repository: > https://repository.apache.org/content/repositories/orgapachekaraf-1113/ > > Git Tag: > karaf-4.1.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 > -- > Jean-Baptiste Onofré > jbono...@apache.org > http://blog.nanthrax.net > Talend - http://www.talend.com > -- -- Christian Schneider http://www.liquid-reality.de Computer Scientist http://www.adobe.com
Re: [VOTE] Apache Karaf (Container) 4.1.6 release
+1 (binding) Christian Am Fr., 3. Aug. 2018 um 19:20 Uhr schrieb Jean-Baptiste Onofré < j...@nanthrax.net>: > Hi all, > > I submit Karaf (Container) 4.1.6 release to your vote. This is a > maintenance release on 4.1.x series. > > Release Notes: > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12342748 > > Staging Repository: > https://repository.apache.org/content/repositories/orgapachekaraf-1112/ > > Git Tag: > karaf-4.1.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 > -- > Jean-Baptiste Onofré > jbono...@apache.org > http://blog.nanthrax.net > Talend - http://www.talend.com > -- -- Christian Schneider http://www.liquid-reality.de Computer Scientist http://www.adobe.com
Re: FYI, OSGi Features RFP
I think the RFP is based on the prototype of the sling feature model. See: https://github.com/apache/sling-whiteboard/tree/master/featuremodel As far as I know this is indeed inspired by karaf. I am not sure how compatible it is at the moment. I will try to participate in the standardisation effort and try to achieve some compatibility with karaf. Christian 2018-04-09 11:35 GMT+02:00 Guillaume Nodet <gno...@apache.org>: > I was not in any way aware of this RFP and I'm not part of the process, but > this looks really inspired from Karaf Features at least. > The author, David B. is a Karaf committer, so he may be able to comment on > what he has in mind. > > Having said that, I'm not so sure it's a good thing for Karaf, but we'll > see. Hopefully things will go well this time, but I've already seen several > things go wrong at the OSGi EEG... > > Guillaume > > 2018-04-09 11:07 GMT+02:00 Serge Huber <shu...@jahia.com>: > > > Interesting ! Is it planned to be based on Karaf Features model ? > > > > cheers, > > Serge... > > > > Serge Huber > > CTO & Co-Founder > > T +41 22 361 3424 > > 9 route des Jeunes | 1227 Acacias | Switzerland > > jahia.com <http://www.jahia.com/> > > SKYPE | LINKEDIN <https://www.linkedin.com/in/sergehuber> | TWITTER > > <https://twitter.com/sergehuber> | VCARD > > <http://www.jahia.com/vcard/HuberSerge.vcf> > > > > > > > JOIN OUR COMMUNITY <http://www.jahia.com/> to evaluate, get trained > and > > to discover why Jahia is a leading User Experience Platform (UXP) for > > Digital Transformation. > > > > On Mon, Apr 9, 2018 at 10:54 AM, Guillaume Nodet <gno...@apache.org> > > wrote: > > > > > See https://github.com/osgi/design/blob/master/rfps/rfp- > > 0188-Features.pdf > > > > > > -- > > > > > > Guillaume Nodet > > > > > > > > > -- > > Guillaume Nodet > -- -- Christian Schneider http://www.liquid-reality.de Computer Scientist http://www.adobe.com
Re: [VOTE] Apache Karaf (Container) 4.2.0 release (take 2)
That is fine. After all my -1 is not a veto. Christian 2018-04-06 7:41 GMT+02:00 Jean-Baptiste Onofré <j...@nanthrax.net>: > Just tried > > cxf-dosgi rest works, the problem is with cxf-dosgi soap: > > Caused by: java.lang.ClassNotFoundException: com.sun.xml.bind.v2. > ContextFactory > not found by org.apache.cxf.cxf-rt-transports-http [62] > > I'm testing a workaround. > > However, I'm proposing to move forward on 4.2.0 and fix that for 4.2.1 > (that I > will do earlier than expected). > > Regards > JB > > On 04/05/2018 12:17 PM, Christian Schneider wrote: > > I just tested with the CXF-DOSGi samples on karaf 4.2.0 and java 8. When > > there is an error during xml parsing. > > > > To reproduce install cxf-dosgi samples: > > > > feature:repo-add cxf-dosgi-samples 2.3.0 > > > > feature:install cxf-dosgi-sample-soap-impl > > > > and check the log. > > > > See this for the exception: > > https://paste.apache.org/FFNJ > > > > The code works fine in karaf 4.1.x. > > > > This could be the same thing that Dan reported about the xml parsing. As > it > > still seems to happen with the new build I am voting -1 for now. > > > > -1 > > > > Christian > > > > > > 2018-04-05 8:03 GMT+02:00 Jean-Baptiste Onofré <j...@nanthrax.net>: > > > >> Hi all, > >> > >> I submit Karaf (Container) 4.2.0 release to your vote. > >> > >> This is the first GA on the 4.2.x series, following M1 and M2. > >> > >> NB: I preferred to postpone the merge of the new examples as it needs a > >> little > >> polish. The PR is already available and it will be included in 4.2.1 > (that > >> we > >> can expect beginning of May depending of 4.2.0 feedbacks): > >> https://github.com/apache/karaf/pull/484 > >> > >> NB: This is take 2, including KARAF-5688 fix > >> > >> Release Notes: > >> https://issues.apache.org/jira/secure/ReleaseNote.jspa? > >> projectId=12311140=12342076 > >> > >> Staging Repository: > >> https://repository.apache.org/content/repositories/orgapachekaraf-/ > >> > >> Git Tag: > >> karaf-4.2.0 > >> > >> 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 > >> -- > >> Jean-Baptiste Onofré > >> jbono...@apache.org > >> http://blog.nanthrax.net > >> Talend - http://www.talend.com > >> > > > > > > > > -- > Jean-Baptiste Onofré > jbono...@apache.org > http://blog.nanthrax.net > Talend - http://www.talend.com > -- -- Christian Schneider http://www.liquid-reality.de Computer Scientist http://www.adobe.com
Re: [VOTE] Apache Karaf (Container) 4.2.0 release (take 2)
I just tested with the CXF-DOSGi samples on karaf 4.2.0 and java 8. When there is an error during xml parsing. To reproduce install cxf-dosgi samples: feature:repo-add cxf-dosgi-samples 2.3.0 feature:install cxf-dosgi-sample-soap-impl and check the log. See this for the exception: https://paste.apache.org/FFNJ The code works fine in karaf 4.1.x. This could be the same thing that Dan reported about the xml parsing. As it still seems to happen with the new build I am voting -1 for now. -1 Christian 2018-04-05 8:03 GMT+02:00 Jean-Baptiste Onofré <j...@nanthrax.net>: > Hi all, > > I submit Karaf (Container) 4.2.0 release to your vote. > > This is the first GA on the 4.2.x series, following M1 and M2. > > NB: I preferred to postpone the merge of the new examples as it needs a > little > polish. The PR is already available and it will be included in 4.2.1 (that > we > can expect beginning of May depending of 4.2.0 feedbacks): > https://github.com/apache/karaf/pull/484 > > NB: This is take 2, including KARAF-5688 fix > > Release Notes: > https://issues.apache.org/jira/secure/ReleaseNote.jspa? > projectId=12311140=12342076 > > Staging Repository: > https://repository.apache.org/content/repositories/orgapachekaraf-/ > > Git Tag: > karaf-4.2.0 > > 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 > -- > Jean-Baptiste Onofré > jbono...@apache.org > http://blog.nanthrax.net > Talend - http://www.talend.com > -- -- Christian Schneider http://www.liquid-reality.de Computer Scientist http://www.adobe.com
Re: Karaf 4.2.0 and endorsed libs
t; >>>> at java.util.ServiceLoader.access > >>>> $300(ServiceLoader.java:185) > >>>> at java.util.ServiceLoader$LazyIt > >>>> erator.nextService(ServiceLoader.java:372) > >>>> at java.util.ServiceLoader$LazyIt > >>>> erator.next(ServiceLoader.java:404) > >>>> at java.util.ServiceLoader$1.next > >>>> (ServiceLoader.java:480) > >>>> at javax.xml.stream.FactoryFinder > >>>> $1.run(FactoryFinder.java:353) > >>>> at java.security.AccessController.doPrivileged(Native > >>>> Method) > >>>> at javax.xml.stream.FactoryFinder > >>>> .findServiceProvider(FactoryFinder.java:341) > >>>> at javax.xml.stream.FactoryFinder > >>>> .find(FactoryFinder.java:313) > >>>> at javax.xml.stream.FactoryFinder > >>>> .find(FactoryFinder.java:227) > >>>> at javax.xml.stream.XMLInputFacto > >>>> ry.newFactory(XMLInputFactory.java:205) > >>>> > >>>> Is there any idea how this might work? I am aware that as long as I am > >>>> using Java 8 I might just re-introduce the stax-api bundle to > lib/endorsed, > >>>> but what are the ideas for this on Java 9? > >>>> > >>>> Best regards > >>>> Stephan > >>>> > >>> > >>> > >>> > >>> -- > >>> > >>> Guillaume Nodet > >>> > >>> > >> > >> > >> -- > >> > >> Guillaume Nodet > >> > >> > > > > > > -- > > > > Guillaume Nodet > > > > > > > -- > > Guillaume Nodet > -- -- Christian Schneider http://www.liquid-reality.de Computer Scientist http://www.adobe.com
Re: [VOTE] Apache Karaf (Container) 3.0.9 release
+1 Christian 2018-02-26 10:43 GMT+01:00 Jean-Baptiste Onofré <j...@nanthrax.net>: > Hi all, > > I submit Karaf (Container) 3.0.9 release to your vote. It's a maintenance > release, fixing several issues and bringing minor dependency updates. > > Release Notes: > https://issues.apache.org/jira/secure/ReleaseNote.jspa? > projectId=12311140=12338081 > > Staging Repository: > https://repository.apache.org/content/repositories/orgapachekaraf-1109 > > Git Tag: > karaf-3.0.9 > > 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 > -- > Jean-Baptiste Onofré > jbono...@apache.org > http://blog.nanthrax.net > Talend - http://www.talend.com > -- -- Christian Schneider http://www.liquid-reality.de Computer Scientist http://www.adobe.com
Re: [VOTE] Apache Karaf (Container) 4.1.5 release
+1 Christian 2018-02-12 19:52 GMT+01:00 Jean-Baptiste Onofré <j...@nanthrax.net>: > Hi all, > > I submit Karaf (Container) 4.1.5 release to your vote. > > Release Notes: > https://issues.apache.org/jira/secure/ReleaseNote.jspa? > projectId=12311140=12342294 > > Staging Repository: > https://repository.apache.org/content/repositories/orgapachekaraf-1108/ > > Git Tag: > karaf-4.1.5 > > 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 > -- > Jean-Baptiste Onofré > jbono...@apache.org > http://blog.nanthrax.net > Talend - http://www.talend.com > -- -- Christian Schneider http://www.liquid-reality.de Computer Scientist http://www.adobe.com
Re: [VOTE] Apache Karaf Decanter 2.0.0 release, take 2
+1 Christian 2018-02-02 15:20 GMT+01:00 Jean-Baptiste Onofré <j...@nanthrax.net>: > Hi all, > > I submit Karaf Decanter 2.0.0 release to your vote. > > This is the first release in the new Decanter 2.x series. It's designed to > work > with Karaf >= 4. > > It's an important release providing updated and new backends, a first > round of > shell commands (to manage the alerting feature) and much more. > > Release Notes: > https://issues.apache.org/jira/secure/ReleaseNote.jspa? > projectId=12311140=12341053 > > Staging Repository: > https://repository.apache.org/content/repositories/orgapachekaraf-1107/ > > Git Tag: > decanter-2.0.0 > > 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 > -- > Jean-Baptiste Onofré > jbono...@apache.org > http://blog.nanthrax.net > Talend - http://www.talend.com > -- -- Christian Schneider http://www.liquid-reality.de Computer Scientist http://www.adobe.com
Re: [VOTE] Apache Karaf Decanter 2.0.0 release
+1 Christian 2018-01-29 19:00 GMT+01:00 Jean-Baptiste Onofré <j...@nanthrax.net>: > Hi all, > > I submit Karaf Decanter 2.0.0 release to your vote. > > This is the first release in the new Decanter 2.x series. It's designed to > work > with Karaf >= 4. > > It's an important release providing updated and new backends, a first > round of > shell commands (to manage the alerting feature) and much more. > > Release Notes: > https://issues.apache.org/jira/secure/ReleaseNote.jspa? > projectId=12311140=12341053 > > Staging Repository: > https://repository.apache.org/content/repositories/orgapachekaraf-1106/ > > Git Tag: > decanter-2.0.0 > > 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 > -- > Jean-Baptiste Onofré > jbono...@apache.org > http://blog.nanthrax.net > Talend - http://www.talend.com > -- -- Christian Schneider http://www.liquid-reality.de Computer Scientist http://www.adobe.com
Re: [PROPOSAL] Docker feature in Karaf container
I agree that Aries JAXRS whiteboard currently might not be in good enough shape to already use it. I am pretty sure though that it can be fixed to fit nicely to what we need. I think the embedding is on purpose to make it easy to deploy jax-rs whiteboard to platforms outside of karaf. Maybe it can provide an embedded as well as a plugable bundle that coexists nicely with an installed cxf. Christian 2018-01-19 14:42 GMT+01:00 Jean-Baptiste Onofré <j...@nanthrax.net>: > Yeah, it's where I'm struggling, it requires some private package, and so. > > I'm not a big fan right now to be honest. > > Regards > JB > > > On 01/19/2018 02:33 PM, Daniel Kulp wrote: > >> JAX-RS whiteboard currently has a few other issues, mostly due to the >> implementation in Aries. Probably should find some time to work on that. >> >> The main issue is that, right now, it embeds parts of CXF but then >> exports a few packages. Thus, getting it and a “real” CXF application >> working together is nearly impossible. The Aries implementation really >> needs to be split so that there is a “whiteboard only” bundle that imports >> CXF (and other deps) instead of embedding them, and then maybe a separate >> uber bundle that embeds the stuff if that’s needed for the TCK. >> >> >> Dan >> >> >> >> On Jan 19, 2018, at 8:01 AM, Christian Schneider <ch...@die-schneider.net> >>> wrote: >>> >>> How about implementing jax-rs services using the OSGi jax-rs whiteboard >>> spec? So the implementation would be CXF but the code would ideally only >>> be >>> tied to the jax-rs spec and the jax-rs whiteboard spec. >>> >>> Cheers >>> Christian >>> >>> 2018-01-19 13:54 GMT+01:00 Guillaume Nodet <gno...@apache.org>: >>> >>> 2018-01-19 13:45 GMT+01:00 Daniel Kulp <dk...@apache.org>: >>>> >>>> >>>>> >>>>> On Jan 19, 2018, at 4:00 AM, Guillaume Nodet <gno...@apache.org> >>>>>> >>>>> wrote: >>>> >>>>> >>>>>> * investigate the use of JaxRS 2.0 api instead of the CXF dependency >>>>>> >>>>> (to >>>> >>>>> be more flexible and also because it would create yet another circular >>>>>> dependency) >>>>>> >>>>> >>>>> I’m not sure I get this….. Even if you use the JAX-RS 2.0 API, you >>>>> >>>> still >>>> >>>>> need an implementation in order for the API’s to work. I hope the >>>>> >>>> chosen. >>>> >>>>> Implementation would remain CXF. >>>>> >>>>> >>>> 1./ unless there's a compelling reason to tie the implementation to CXF, >>>> I'd rather use the standard API instead >>>> 2./ this does create a circular dependency, as karaf will depend on CXF >>>> and >>>> CXF on Karaf. I know this is not a problem when releasing because we >>>> always reference an older version of the other project, but still, if >>>> this >>>> can be avoided I think it would be better >>>> 3./ i'd like CXF to be the default and i don't have any reason to >>>> switch to >>>> a different provider, but that does not mean everyone should be forced >>>> to >>>> use it, as they may have reasons to use a different provider (which >>>> could >>>> also be a non technical reason) >>>> >>>> I don't see any difference between choosing a jaxrs provider and >>>> choosing a >>>> servlet provider or a transaction manager. We do usually leave room for >>>> choice, I'd like to keep it that way, if that's technically possible. >>>> >>>> >>>> >>>>> >>>>> Dan >>>>> >>>>> >>>>> >>>>> 2018-01-18 10:37 GMT+01:00 Jean-Baptiste Onofré <j...@nanthrax.net>: >>>>>> >>>>>> Hi, >>>>>>> >>>>>>> Some days ago, we discussed about Decanter 2.0.0 and using "external" >>>>>>> instances of used engines, like Elasticsearch or Kibana. >>>>>>> >>>>>>> Basically, the main reason is that some engines are not easy to embed >>>>>>> >>>>>> in >>>> >>>>> Karaf. It's the case of Kibana as it uses n
Re: [PROPOSAL] Docker feature in Karaf container
How about implementing jax-rs services using the OSGi jax-rs whiteboard spec? So the implementation would be CXF but the code would ideally only be tied to the jax-rs spec and the jax-rs whiteboard spec. Cheers Christian 2018-01-19 13:54 GMT+01:00 Guillaume Nodet <gno...@apache.org>: > 2018-01-19 13:45 GMT+01:00 Daniel Kulp <dk...@apache.org>: > > > > > > > > On Jan 19, 2018, at 4:00 AM, Guillaume Nodet <gno...@apache.org> > wrote: > > > > > > * investigate the use of JaxRS 2.0 api instead of the CXF dependency > (to > > > be more flexible and also because it would create yet another circular > > > dependency) > > > > I’m not sure I get this….. Even if you use the JAX-RS 2.0 API, you > still > > need an implementation in order for the API’s to work. I hope the > chosen. > > Implementation would remain CXF. > > > > 1./ unless there's a compelling reason to tie the implementation to CXF, > I'd rather use the standard API instead > 2./ this does create a circular dependency, as karaf will depend on CXF and > CXF on Karaf. I know this is not a problem when releasing because we > always reference an older version of the other project, but still, if this > can be avoided I think it would be better > 3./ i'd like CXF to be the default and i don't have any reason to switch to > a different provider, but that does not mean everyone should be forced to > use it, as they may have reasons to use a different provider (which could > also be a non technical reason) > > I don't see any difference between choosing a jaxrs provider and choosing a > servlet provider or a transaction manager. We do usually leave room for > choice, I'd like to keep it that way, if that's technically possible. > > > > > > > > Dan > > > > > > > > > 2018-01-18 10:37 GMT+01:00 Jean-Baptiste Onofré <j...@nanthrax.net>: > > > > > >> Hi, > > >> > > >> Some days ago, we discussed about Decanter 2.0.0 and using "external" > > >> instances of used engines, like Elasticsearch or Kibana. > > >> > > >> Basically, the main reason is that some engines are not easy to embed > in > > >> Karaf. It's the case of Kibana as it uses node.js. > > >> > > >> However, one of the big advantage of embedded instance of > Elasticsearch > > or > > >> Kibana is that it's very easy to install and use: it's just a > > >> feature:install command to perform. > > >> > > >> So, I would like to provide both advantages: easy to install and use > > with > > >> external instances ;) > > >> > > >> A first approach would be to create a "exec" bundle starting the > > instance. > > >> But we gonna face the "classic" issues depending of the environment. > > >> > > >> Maybe some of you remember the karaf-docker PoC I did month ago: > > >> > > >> https://github.com/jbonofre/karaf-docker > > >> > > >> This is a simple feature that allows you to manipulate docker images: > > >> bootstrapping, starting/running, ... > > >> > > >> I think it would help a lot in Decanter or Cellar: we can just provide > > >> Karaf Docker commands to bootstrap Elasticsearch, Kibana, OrientDB, > ... > > >> As a best effort, we will try to provide embedded instance as > possible, > > >> but it won't be the preferred approach. > > >> > > >> As karaf-docker is small project and just basically use docker, I > think > > it > > >> doesn't require to be a Karaf subproject. > > >> As we have the karaf scheduler (using Quartz internally), I would like > > to > > >> propose to add docker in Karaf container in a dedicated module. > > >> > > >> It means that users will be able to do feature:install docker to have > > the > > >> docker commands. > > >> I would like also to add a command and configuration to have "ready to > > go > > >> images". Something that will allow users to do: > > >> > > >> docker:run elasticsearch > > >> > > >> then, elasticsearch will use a ready to go dockerfile. > > >> > > >> It would be possible to do: > > >> > > >> docker:run mvn:org.apache.karaf.decanter.docker/elasticsearch/6.1.0/ > > docker > > >> > > >> Where we can host ready to use "official" dockerfile. > > >> > > >> Thoughts ? > > >> > > >> Regards > > >> JB > > >> -- > > >> Jean-Baptiste Onofré > > >> jbono...@apache.org > > >> http://blog.nanthrax.net > > >> Talend - http://www.talend.com > > >> > > > > > > > > > > > > -- > > > > > > Guillaume Nodet > > > > -- > > Daniel Kulp > > dk...@apache.org - http://dankulp.com/blog > > Talend Community Coder - http://coders.talend.com > > > > > > > -- > > Guillaume Nodet > -- -- Christian Schneider http://www.liquid-reality.de Computer Scientist http://www.adobe.com
Re: [VOTE] Apache Karaf (Container) 4.1.4 release
+1 Christian 2017-12-16 7:23 GMT+01:00 Jean-Baptiste Onofré <j...@nanthrax.net>: > Hi all, > > I submit Karaf (Container) 4.1.4 release to your vote. > > Release Notes: > https://issues.apache.org/jira/secure/ReleaseNote.jspa?proje > ctId=12311140=12341702 > > Staging Repository: > https://repository.apache.org/content/repositories/orgapachekaraf-1102/ > > Git Tag: > karaf-4.1.4 > > 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 > -- > Jean-Baptiste Onofré > jbono...@apache.org > http://blog.nanthrax.net > Talend - http://www.talend.com > -- -- Christian Schneider http://www.liquid-reality.de Computer Scientist http://www.adobe.com
Re: SAP JCO Factory
Hi Jean-Yves, do you know that there already is a pretty good SAP adapter called hibersap? http://hibersap.org/example/ It is apache licensed and works very well in OSGi. Christian 2017-11-18 17:27 GMT+01:00 Jean-Yves Terrien <jyterr...@yahoo.fr.invalid>: > This message to share with you my code on SAP JCO. > > I prepare a set of components to communicate with SAP via RFC. > the first is a factory connection for karaf. https://github.com/sekaijin/ > jco-factory > the next a camel component to send and receive idocs (xml) via RFC. > > This is a first SNAPSHOT. > > Bye JYT -- -- Christian Schneider http://www.liquid-reality.de <https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46=http%3a%2f%2fwww.liquid-reality.de> Computer Scientist http://www.adobe.com
Re: [VOTE] Apache Karaf 4.2.0.M1 release
+1 Christian 2017-10-28 8:31 GMT+02:00 Jean-Baptiste Onofré <j...@nanthrax.net>: > Hi all > > I submit Karaf 4.2.0.M1 release to your vote. It's not a GA release but a > technical preview. The purpose is to perform a test campaign before the > first GA Release. > Especially the Java9 support is not yet complete as we need new > dependencies releases. > > Release Notes: > https://issues.apache.org/jira/secure/ReleaseNote.jspa? > projectId=12311140=12338362 > > Staging Repository: > https://repository.apache.org/content/repositories/orgapachekaraf-1101/ > > Git tag: > karaf-4.2.0.M1 > > Please vote for this release: > > [ ] +1 (approve the release) > [ ] -1 (don't approve the release, provide reason) > > This vote is open for 72h. > > Thanks > Regards > JB > -- -- Christian Schneider http://www.liquid-reality.de <https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46=http%3a%2f%2fwww.liquid-reality.de> Computer Scientist http://www.adobe.com
Re: [VOTE] Apache Karaf (Container) 4.1.3 release
I looked through the solved jira issues .. at least one of these might be problematic for a bugfix release: https://issues.apache.org/jira/browse/KARAF-4932 Removing these bundles might cause issues for users. Shouldn`t we wait with the removal until 4.2.0? Christian 2017-10-27 6:08 GMT+02:00 Jean-Baptiste Onofré <j...@nanthrax.net>: > Hi all, > > I submit Karaf (Container) 4.1.3 release to your vote. > > Release Notes: > https://issues.apache.org/jira/secure/ReleaseNote.jspa?proje > ctId=12311140=12341130 > > Staging Repository: > https://repository.apache.org/content/repositories/orgapachekaraf-1100/ > > Git Tag: > karaf-4.1.3 > > 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 48 hours. > > Thanks, > Regards > JB > -- > Jean-Baptiste Onofré > jbono...@apache.org > http://blog.nanthrax.net > Talend - http://www.talend.com > -- -- Christian Schneider http://www.liquid-reality.de <https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46=http%3a%2f%2fwww.liquid-reality.de> Computer Scientist http://www.adobe.com
Re: [DISCUSS] Remove Karaf specific SCR commands
+1 Christian 2017-10-04 11:02 GMT+02:00 Guillaume Nodet <gno...@apache.org>: > I'm working on KARAF-4785 > <https://issues.apache.org/jira/browse/KARAF-4785> and > I've already fixed the completion of the native scr commands. This means > that we'll have some kind of duplication of all scr commands. Kind of, > because even though they are similar, the output is different. The native > commands provide a deeper view of the SCR components. > > So, should I go ahead and just remove the Karaf specific commands ? > > Below is the output of the native commands and then the karaf commands... > > Cheers, > Guillaume > > *karaf*@root()> scr:list > > BundleId Component Name Default State > > Component Id State PIDs (Factory PID) > > [ 38] ScrServiceMBean enabled > > [ 4] [active ] > > [ 145] org.ops4j.pax.web.deployer.internal.WarDeployer enabled > > [ 3] [active ] > > [ 151] org.ops4j.pax.web.service.internal.WhiteboardDtoService enabled > > [ 5] [active ] > > *karaf*@root()> scr:info org.ops4j.pax.web.deployer.internal.WarDeployer > > > > *** Bundle: org.ops4j.pax.web.pax-web-deployer (145) > > Component Description: > > Name: org.ops4j.pax.web.deployer.internal.WarDeployer > > Implementation Class: org.ops4j.pax.web.deployer.internal.WarDeployer > > Default State: enabled > > Activation: delayed > > Configuration Policy: optional > > Activate Method: activate > > Deactivate Method: deactivate > > Modified Method: - > > Configuration Pid: [org.ops4j.pax.web.deployer.internal.WarDeployer] > > Services: > > org.apache.felix.fileinstall.ArtifactUrlTransformer > > Service Scope: singleton > > Component Description Properties: > > Component Configuration: > > ComponentId: 3 > > State: active > > Component Configuration Properties: > > component.id = 3 > > component.name = org.ops4j.pax.web.deployer.internal.WarDeployer > > > *karaf*@root()> scr:components > > ID │ State │ Component Name > > ───┼┼ > > 3 │ ACTIVE │ org.ops4j.pax.web.deployer.internal.WarDeployer > > 5 │ ACTIVE │ org.ops4j.pax.web.service.internal.WhiteboardDtoService > > *karaf*@root()> scr:details org.ops4j.pax.web.deployer. > internal.WarDeployer > > *Component Details* > > * Name: *org.ops4j.pax.web.deployer.internal.WarDeployer > > * State : *ACTIVE > > *References* > > *karaf*@root()> > > > > > -- > > Guillaume Nodet > -- -- Christian Schneider http://www.liquid-reality.de <https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46=http%3a%2f%2fwww.liquid-reality.de> Computer Scientist http://www.adobe.com
Re: [VOTE] Migrate to gitbox
+1 Christian 2017-10-02 10:02 GMT+02:00 Guillaume Nodet <gno...@apache.org>: > Following a few discussions we had, I'm starting a vote. > The overall idea is to migrate our git repositories to gitbox, which allows > a deeper integration with github features. The first one we should > leverage is the ability to close, merge PRs directly from github. > > [ ] +1, migrate Karaf repositories to gitbox > [ ] -1, keep git-wip + github mirror > > > -- > ---- > Guillaume Nodet > -- -- Christian Schneider http://www.liquid-reality.de <https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46=http%3a%2f%2fwww.liquid-reality.de> Computer Scientist http://www.adobe.com
Re: [DISCUSS] Moving to gitbox
Very good question actually as this is not detailed in the proposal. CXF already switched to gitbox and what it allows me to do is work with github like I do with any of my own repositories. So I can push directly to the github repo and also use the github UI to close or merge PRs or for example directly edit a readme in the github UI. Christian On 12.09.2017 18:04, Achim Nierbeck wrote: fine with me, what are the benefits of it again? couldn't find what it is really good for compared to what we already got ... regards, Achim 2017-09-11 9:48 GMT+02:00 Jean-Baptiste Onofré <j...@nanthrax.net>: +1 I think I already sent an e-mail about this while ago (when gitbox has been proposed by infra). Regards JB On 09/11/2017 09:39 AM, Guillaume Nodet wrote: Infra now offers read/write access to github via a service called 'gitbox'[1]. PMCs have the option to join the service and then make use of whichever github features they want (like PRs). Thoughts ? [1]: https://gitbox.apache.org/ -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com -- Christian Schneider http://www.liquid-reality.de Open Source Architect http://www.talend.com
Re: [karaf] Git Push Summary [forced push!] [Forced Update!]
I quickly undid my commit as I just read JBs comment to check with guillaume first. Christian On 14.08.2017 10:43, cschnei...@apache.org wrote: Repository: karaf Updated Branches: refs/heads/master 2b6ca1865 -> e442a1b8a (forced update) -- Christian Schneider http://www.liquid-reality.de Open Source Architect http://www.talend.com
Re: [Proposal] New subproject rcomp - Reactive components framework
I now adapted the package names as well as the maven coordinates. All
files should now also have the apache headers.
I also made sure the build now works without any running mqtt or kafka
server.
I would be happy about a quick review of the current status. If there
are no objections then I will go ahead and ask for a git repository.
Christian
On 03.08.2017 08:02, Jean-Baptiste Onofré wrote:
Hi Christian,
the proposal is interesting, and I see a first potential use in
Decanter for sure.
The comment about Camel is fair as it looks very similar at first glance.
However, the scope is slightly different IMHO.
I checked about the legal. The code should be cleanup for donation
(ASF headers, package names, ...). About the dependency license, for
the reactive-streams, it' OK as it uses Creative Commons Zero into the
Public Domain. And Reactor is already under Apache license.
The DSL is a hot topic. I understand that leveraging Akka or Reactor
is easier, but I'm a bit concern that we could be too much "coupled".
Maybe our own simple DSL could help. Thoughts ?
Thanks anyway !
Regards
JB
On 07/19/2017 01:02 PM, Christian Schneider wrote:
Scope
I recently experimented with reactive streams and built a small
component framework on top of this spec.
See https://github.com/cschneider/reactive-components
The goal is to have a small API that can encapsulate a protocol and
transport. The code using such a reactive component should not
directly depend on the specifics of the transport or protocol.
Another goal is to have reactive features like back pressure.
Ultimately I am searching for something like Apache Camel Components
but with a lot less coupling. In camel the big problem is that
components depend on camel core which unfortunately is much more than
a component API. So any camel component is coupled quite tightly to
all of camel core.
Proposal
I propose to donate my code to Apache and establish this as a Apache
Karaf sub project. Some people like Jean-Baptiste and Hadrian have
already expressed that they support this and I hope for some more
feedback and help.
I chose the Karaf project at the moment but am also open to placing
this in another Apache project. Some matching projects would be
Apache Camel, Aries or Felix.
Component API
I was trying to find the simplest API that would allow similar
components to camel in one way mode.
public interface RComponent {
Publisher from(String destination, Class type);
Subscriber to(String destination, Class type);
}
A component is a factory for Publishers and Subscribers. From and to
have similar meaning as in camel. The component can be given a source
/ target type to produce / consume. So with the OSGi Converter spec
this would allow to have type safe messaging without coding the
conversion in every component. Each component is exposed as a service
which encapsulates most of the configuration. All endpoint specific
configuration can be done using the destination String.
Publisher and Subscriber are interfaces from the reactive streams api
(http://www.reactive-streams.org/). So they are well defined and have
zero additional dependencies.
I also considered to use OSGi push streams which is an OSGi spec and
would also be an interesting foundation. I decided against that
though as push streams have no API that is separate from the DSL and
will probably not be used a lot outside of OSGi.
See the examples for how to use this in practice.
https://github.com/cschneider/reactive-components
Possible use cases
Two big use cases are reactive microservices that need messaging as
well as plain camel like integrations.
Another case are the Apache Karaf decanter collectors and appenders.
Currently they use a decanter specific API but they could easily be
converted into the more general rcomp api.
We could also create a bridge to camel components to leverage the
many existing camel components using the rcomp API as well as
offering rcomp components to camel.
Components alone are of course not enough. One big strength of Apache
Camel is the DSL. In case of rcomp I propose to not create our own
DSL and instead use existing DSLs that work well in OSGi. Two examples:
Akka and reactive streams
https://de.slideshare.net/ktoso/reactive-integrations-with-akka-streams
Reactor and reactive streams
https://de.slideshare.net/StphaneMaldini/reactor-30-a-reactive-foundation-for-java-8-and-spring
Another integration is with REST. It is already possible to integrate
CXF Rest services with reactive streams using some adapters but we
could have native integration.
Risks and Opportunities
The main risk I see is not gathering a critical mass of components to
draw more people.
Another risk is that the RComponent API or the reactor streams have
some unexpected limitations.
The big opportunity I see is that the rcomp API is very simple so the
barrier of entry
Re: [VOTE] Apache Karaf (Container) 4.1.2 release
Anyone can vote. But only the votes from the PMC members are binding. This is why some people write (binding) or (non binding). We still look into every vote .. especially when you find a problem. Christian On 07.08.2017 16:46, Steinar Bang wrote: Who can vote on this? -- Christian Schneider http://www.liquid-reality.de Open Source Architect http://www.talend.com
Re: [VOTE] Apache Karaf (Container) 4.1.2 release
+1 Christian 2017-08-04 20:51 GMT+02:00 Jean-Baptiste Onofré <j...@nanthrax.net>: > Hi all, > > I submit Karaf (Container) 4.1.2 release to your vote. > > Release Notes: > https://issues.apache.org/jira/secure/ReleaseNote.jspa?proje > ctId=12311140=12340261 > > Staging Repository: > https://repository.apache.org/content/repositories/orgapachekaraf-1097/ > > Git Tag: > karaf-4.1.2 > > 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 48 hours. > > Thanks, > Regards > JB > -- > Jean-Baptiste Onofré > jbono...@apache.org > http://blog.nanthrax.net > Talend - http://www.talend.com > -- -- Christian Schneider http://www.liquid-reality.de <https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46=http%3a%2f%2fwww.liquid-reality.de> Open Source Architect http://www.talend.com <https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46=http%3a%2f%2fwww.talend.com>
[Proposal] New subproject rcomp - Reactive components framework
Scope
I recently experimented with reactive streams and built a small
component framework on top of this spec.
See https://github.com/cschneider/reactive-components
The goal is to have a small API that can encapsulate a protocol and
transport. The code using such a reactive component should not directly
depend on the specifics of the transport or protocol. Another goal is to
have reactive features like back pressure. Ultimately I am searching for
something like Apache Camel Components but with a lot less coupling. In
camel the big problem is that components depend on camel core which
unfortunately is much more than a component API. So any camel component
is coupled quite tightly to all of camel core.
Proposal
I propose to donate my code to Apache and establish this as a Apache
Karaf sub project. Some people like Jean-Baptiste and Hadrian have
already expressed that they support this and I hope for some more
feedback and help.
I chose the Karaf project at the moment but am also open to placing this
in another Apache project. Some matching projects would be Apache Camel,
Aries or Felix.
Component API
I was trying to find the simplest API that would allow similar
components to camel in one way mode.
public interface RComponent {
Publisher from(String destination, Class type);
Subscriber to(String destination, Class type);
}
A component is a factory for Publishers and Subscribers. From and to
have similar meaning as in camel. The component can be given a source /
target type to produce / consume. So with the OSGi Converter spec this
would allow to have type safe messaging without coding the conversion in
every component. Each component is exposed as a service which
encapsulates most of the configuration. All endpoint specific
configuration can be done using the destination String.
Publisher and Subscriber are interfaces from the reactive streams api
(http://www.reactive-streams.org/). So they are well defined and have
zero additional dependencies.
I also considered to use OSGi push streams which is an OSGi spec and
would also be an interesting foundation. I decided against that though
as push streams have no API that is separate from the DSL and will
probably not be used a lot outside of OSGi.
See the examples for how to use this in practice.
https://github.com/cschneider/reactive-components
Possible use cases
Two big use cases are reactive microservices that need messaging as well
as plain camel like integrations.
Another case are the Apache Karaf decanter collectors and appenders.
Currently they use a decanter specific API but they could easily be
converted into the more general rcomp api.
We could also create a bridge to camel components to leverage the many
existing camel components using the rcomp API as well as offering rcomp
components to camel.
Components alone are of course not enough. One big strength of Apache
Camel is the DSL. In case of rcomp I propose to not create our own DSL
and instead use existing DSLs that work well in OSGi. Two examples:
Akka and reactive streams
https://de.slideshare.net/ktoso/reactive-integrations-with-akka-streams
Reactor and reactive streams
https://de.slideshare.net/StphaneMaldini/reactor-30-a-reactive-foundation-for-java-8-and-spring
Another integration is with REST. It is already possible to integrate
CXF Rest services with reactive streams using some adapters but we could
have native integration.
Risks and Opportunities
The main risk I see is not gathering a critical mass of components to
draw more people.
Another risk is that the RComponent API or the reactor streams have some
unexpected limitations.
The big opportunity I see is that the rcomp API is very simple so the
barrier of entry is low.
I also hope that this might become a new foundation for a simpler and
more modern Apache Camel.
So this all depends on getting some support by you all.
Christian
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
Re: [VOTE] Apache Karaf Decanter 1.4.0 release
+1 Christian On 17.07.2017 15:02, Jean-Baptiste Onofré wrote: Hi all, I submit Karaf Decanter 1.4.0 release to your vote. Release Notes: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12338800 Git tag: decanter-1.4.0 Staging repository: https://repository.apache.org/content/repositories/orgapachekaraf-1096/ 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 -- Christian Schneider http://www.liquid-reality.de Open Source Architect http://www.talend.com
Re: AW: AW: [VOTE] Apache Karaf Decanter 1.4.0 release
I see .. so this is open for a while already. I propose we schedule a 1.5.0 soon and try to get in what you need. I did not work on the current issues as almost all are assigned to JB. I will check with him where I can help out. Christian On 05.07.2017 09:10, Oliver Wulff wrote: Hi Christian Of course, minor and of course it's late. Initially I thought the below issue should come into 1.4. I've raised the following issue where I mentioned this (besides the feature request): https://issues.apache.org/jira/browse/KARAF-5033 The same issue is with the camel headers. Thanks Oli -- Christian Schneider http://www.liquid-reality.de Open Source Architect http://www.talend.com
Re: AW: [VOTE] Apache Karaf Decanter 1.4.0 release
Hi Oli,
1.4.0 is just a minor release but of course we can have such
improvements or fixes in such a release.
On the other hand it is a bit late now. Is there already an issue for this?
Christian
On 05.07.2017 08:49, Oliver Wulff wrote:
Hi JB
Due to the fact that this is a major release wouldn't it make sense to fix the
Map serializations.
Here an example:
data.put("properties", exchange.getProperties().isEmpty() ? null :
exchange.getProperties().toString());
If it is serialized like that I can not filter for it if the data is stored in
elasticsearch because key/values are just one string.
WDYT?
Thanks
Oli
Von: Jean-Baptiste Onofré <j...@nanthrax.net>
Gesendet: Dienstag, 4. Juli 2017 08:40:32
An: Karaf Dev
Betreff: [VOTE] Apache Karaf Decanter 1.4.0 release
Hi all,
I submit Karaf Decanter 1.4.0 release to your vote.
Release Notes:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12338800
Git tag:
decanter-1.4.0
Staging repository:
https://repository.apache.org/content/repositories/orgapachekaraf-1094/
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
--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
Better documentation on how to contribute
Hi all, our current community page is not very detailed and leaves many questions open for contributors. I described now how to add issues, create pull requests and apply pull requests. Please review the changes and comment or improve the documentation. https://svn.apache.org/repos/asf/karaf/site/trunk/src/main/webapp/community.html Btw. We also need some documentation on how to edit the karaf site and manual. I do not know how to actually update the website. I would be happy about any pointers .. or ideally documentation on the community page. Christian -- Christian Schneider http://www.liquid-reality.de Open Source Architect http://www.talend.com
Re: [PROPOSAL] New pax project 'transx'
Aries transaction control has a lot of good parts. Unfortunately though it is an all or nothing solution. It works well if you directly depend on Aries transaction control in your user code. Unfortunately this makes the code OSGi only. So this is not an option for many projects like CXF or Camel. The benefit of pax-jdbc-config and pax-jdbc-pool* ist that it provides a XA ready DataSource that can be leveraged by code that is OSGi agnostic. So I think there is a need for the same in the JMS space. So why not focus on jms only and call the project pax-jms? In fact there already is such a project that we could build on and extend for XA features. Christian On 16.06.2017 11:29, Timothy Ward wrote: The Transaction Control project in Aries does have a pretty complete overlap with what’s being proposed here. There are already resource providers for JPA and JDBC which provide connection pooling, resource local transactions and XA transactions. It would be great to get some input into a JMS resource provider to extend the set of supported resource types. The Aries TX control code already includes a base resource project for adding Resource providers which should help to ensure correct lifecycle management - I’d be happy to talk through that code in more detail. Contributing JMS support should therefore be a (relatively) simple process of providing the necessary JMS customisation much like with JDBC. Happy to help, Tim On 16 Jun 2017, at 10:20, Grzegorz Grzybek <gr.grzy...@gmail.com> wrote: +1 Great about forking tranql - finally ;) regards Grzegorz 2017-06-16 11:16 GMT+02:00 Richard Nicholson <puppy_wants_a_...@me.com>: Doesn’t this directly clash with OSGi Alliance Transaction Control Specification work going on in Aries? If so, wouldn’t it make more sense for this community to input into that work rather than cause needless confusion / fragmentation? Just a thought. On 15 Jun 2017, at 13:55, Toni Menzel <toni.men...@rebaze.com> wrote: Sounds interesting! Two comments: - i find the whole space of "pooling resources" a not confusing and hard to find out what you actually really need. So, say once you know you want takaricp, which other bridges and matching configs do you need so that the DataSource proxy (for JDBC) appears in your Service Registry. Maybe it's just me not following bridge provider-projects like Aries too closely. Anything that makes setup simpler and offers a wider range of options is highly welcome. (particularly in the OPS4J community, or how Bndtools people say "P A X" ;) - Any reason why this is not Pax Tx (org.ops4j.pax.tx) ?Find the Transx a bit alien. just an idea. Thanks for your heads up, JB about karaf-boot. Was wondering what happened to it. Toni On Thu, Jun 15, 2017 at 1:58 PM, Achim Nierbeck <bcanh...@googlemail.com wrote: Hi Guillaume, sounds like a good idea to me, and the pax space like the perfect eco system :) regards, Achim 2017-06-15 10:20 GMT+02:00 Jean-Baptiste Onofré <j...@nanthrax.net>: +1 It sounds like a good idea and definitely a good candidate for PAX. By the way, on my side, I did good progress on: - karaf sample & new dev guide - some new updates on karaf-boot - ServiceMix APIMan for API/Service Discovery, Management, Gateway But I will send an update in separate threads. Regards JB On 06/15/2017 09:57 AM, Guillaume Nodet wrote: I began to work on a small project which aims at providing support for pooled XA-enabled connections for JDBC and JMS. For JDBC, the problem was already solved in pax-jdbc by using either pax-jdbc-pool-aries when deploying the Aries/Geronimo transaction manager, and by using pax-jdbc-pool-narayana when using the Narayana transaction manager. However, there's absolutely no support for JMS. So what I've been doing is to reuse the geronimo JCA connector, make it independent on Geronimo TM and add support for Narayana, use a clone of the old tranql adapter for JDBC and rewrite a new JMS 2.0 compatible adapter for JMS. It's not in a usable state yet, but I wanted to give an heads-up. My plan is to make the pooling almost transparent in OSGi, and reuse it instead of the connection pooling I added to Karaf a few weeks ago which does not support XA or recovery: https://github.com/apache/karaf/tree/master/jms/pool and maybe to plug it into pax-jdbc to replace pax-jdbc-pool-aries and pax-jdbc-pool-narayana. The source code is currently available at: https://github.com/gnodet/org.ops4j.pax.transx Cheers, -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com -- Apache Member Apache Karaf <http://karaf.apache.org/> Committer & PMC OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer & Project Lead blog <http://notizblog.nierbeck.de/> Co-Author of Apache Karaf Cookbook <http://bit.ly
Re: OSGi related PoC and Karaf
There is a big overlap between the jax-rs whiteboard and the jax-rs providers for RSA. We also discussed about this on the aries list. In practice you can use any of the alternatives with different drawbacks. Christian 2017-06-15 20:39 GMT+02:00 Milen Dyankov <milendyan...@gmail.com>: > Hmm ok I'm confused. I was thinking about the JAX-RS Services whiteboard > spec that is now being implemented in Apache Aries. I'm aware of the the > remote services spec but not sure how it relates to jax-rs connector . > > > > 15 cze 2017 20:11 "Scott Lewis" <sle...@composent.com> napisał(a): > > On 6/15/2017 1:24 AM, Milen Dyankov wrote: > > > Thanks Scott, > > > > I was looking into that some time ago but AFAIK it comes in R7. Not sure > if > > thete is anything released at this point that would work with R6. > > > > Were you saying 'there'? The OSGi remote services and RSA specs have been > quite stable since R5 (chap 100 and 122 in compendium). > > The Jax-RS distribution provider impls that I'm aware of are ECF's [1]. > It supports Jersey's or CXF's Jax-RS impls. > > I will attempt to work on a reworking of your POC remote service metadata > for a pull request, after the upcoming ECF release (June 28 I think). > > Scott > > [1] https://github.com/ECF/JaxRSProviders > > > So for > > now I just decided to go with what I know works. But if you have > practical > > experience with this spec, pull request would be more than welcome. > > > > Best, > > Milen > > > > > > > > > > 14 cze 2017 18:59 "Scott Lewis" <sle...@composent.com> napisał(a): > > > > On 6/14/2017 4:46 AM, Milen Dyankov wrote: > > > > Hi Karaf developers, > >> > >> I'd like to ask you to have a look at something I've been working on. > It's > >> a PoC called Eccentric Modularity (EM) and it's available here > >> https://github.com/azzazzel/EM > >> > >> FWIW:I think your example would be improved by using OSGi remote > > services specs for the remote service metadata (e.g. provide/require > > capability, standardized remote service properties, etc) rather than the > > jax-rs connector specifically. It would also then allow for supporting > > osgi remote service dynamics, service versioning, rs discovery, etc. > > > > Scott > > > > > -- -- Christian Schneider http://www.liquid-reality.de <https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46=http%3a%2f%2fwww.liquid-reality.de> Open Source Architect http://www.talend.com <https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46=http%3a%2f%2fwww.talend.com>
Re: OSGi related PoC and Karaf
2017-06-15 10:38 GMT+02:00 Milen Dyankov <milendyan...@gmail.com>: > I'm actually thinking of taking your chat demo and reimplementing it with > EM just to see if it will make it easier to understand for non-OSGi folks > and perhaps better demonstrate the purpose of EM. > That would be great. Looking forsward to see how it looks like. Christian > > The examples I have now are very simple and from the perspective of large > OSGI projects do not seem to add any value. That's why I was hoping to get > some ideas/help to move towards more "real life" examples. > > Best, > Milen > > 14 cze 2017 22:19 "Christian Schneider" <ch...@die-schneider.net> > napisał(a): > > > Actually I hope we can make OSGi so easy to use that you do not need to > be > > an expert to start using it. > > With a coarse grained modular approach where you just need to enumerate > > some technologies to combine I think we can achieve a lot in this regard. > > > > Still I have doubts that we can make it as simple as spring boot. Spring > > boot emphasizes easy setup at the cost of higher coupling. The problem is > > that people only realize this when they bought into the technology as the > > coupling only becomes a problem once your project grows. > > > > So I think we need to not try to be as simple as spring boot and instead > > sell the better modularity combined with reasonable simplicity. > > > > Christian > > > > 2017-06-14 21:52 GMT+02:00 Milen Dyankov <milendyan...@gmail.com>: > > > > > Thanks for your comments Christian, > > > > > > I understand this goes too far into making things simple to be useful > for > > > OSGi veterans. And that's OK. I don't aim to make OSGi or BND better > for > > > those who master them, but to lower the entry barrier. I think > > (especially > > > with JPMS promise for simple modularity around the corner) we need to > > show > > > to developers the benefits in the simplest possible way. I already > > > presented this concept to a couple of conferences. I haven't mentioned > > OSGi > > > not even once during the talks - just presented it as new concept for > > > dependency management. From my experience the moment you mention OSGi > to > > an > > > average 20+ years old java developer you'll see his ironic smile and > then > > > his back. After this talk some people who never thought of modular apps > > > before were quite interested. Some of them mentioned they never > > understand > > > the point of modularity this way (for them it was simply putting code > is > > > separate jar files). > > > > > > The reason I though of Karaf is because I know JB and other have been > > > discussing KarafBoot and I think it has a similar goal (but different > > > approach). I alway wanted a ModularityBoot kind of thing that will be > > > simple and at the same time flexible as far as choosing a runtime is > > > concerned. So I thought I'll share this with you here in case we can > > > somehow combine the ideas. > > > > > > As for the parent POM, I'm aware of that possibility but I didn't used > on > > > purpose. In fact you'll see the demo.* projects don't actually have a > > > parent, they are just aggregated in the demo project. The reason is, I > > use > > > this in my talk and I want to point out those are completely free to > use > > > any corporate parent pom they need to. > > > > > > Best, > > > Milen > > > > > > > > > On Wed, Jun 14, 2017 at 8:59 PM, Christian Schneider < > > > ch...@die-schneider.net> wrote: > > > > > > > Hi Milen, > > > > > > > > the concept is interesting when you are outside of OSGi but in that > > case > > > I > > > > doubt people will use OSGi requirements and tools even if it woud > make > > > > sense. > > > > > > > > When inside OSGi I do not see a big benefit compared to using plain > > > > bnd-maven-plugin, bnd-index-plugin and bnd-export-plugin like I use > in > > > > https://github.com/cschneider/osgi-chat . > > > > Merging all this functionality into one plugin is not a good idea > > imho. I > > > > prefer the unix like idea of small single purpose projects. > > > > > > > > As a general improvement for the bnd toolset I could imagine that the > > > > bnd-export-maven-plugin uses the current pom as a basis for an OBR &g
Re: OSGi related PoC and Karaf
Actually I hope we can make OSGi so easy to use that you do not need to be an expert to start using it. With a coarse grained modular approach where you just need to enumerate some technologies to combine I think we can achieve a lot in this regard. Still I have doubts that we can make it as simple as spring boot. Spring boot emphasizes easy setup at the cost of higher coupling. The problem is that people only realize this when they bought into the technology as the coupling only becomes a problem once your project grows. So I think we need to not try to be as simple as spring boot and instead sell the better modularity combined with reasonable simplicity. Christian 2017-06-14 21:52 GMT+02:00 Milen Dyankov <milendyan...@gmail.com>: > Thanks for your comments Christian, > > I understand this goes too far into making things simple to be useful for > OSGi veterans. And that's OK. I don't aim to make OSGi or BND better for > those who master them, but to lower the entry barrier. I think (especially > with JPMS promise for simple modularity around the corner) we need to show > to developers the benefits in the simplest possible way. I already > presented this concept to a couple of conferences. I haven't mentioned OSGi > not even once during the talks - just presented it as new concept for > dependency management. From my experience the moment you mention OSGi to an > average 20+ years old java developer you'll see his ironic smile and then > his back. After this talk some people who never thought of modular apps > before were quite interested. Some of them mentioned they never understand > the point of modularity this way (for them it was simply putting code is > separate jar files). > > The reason I though of Karaf is because I know JB and other have been > discussing KarafBoot and I think it has a similar goal (but different > approach). I alway wanted a ModularityBoot kind of thing that will be > simple and at the same time flexible as far as choosing a runtime is > concerned. So I thought I'll share this with you here in case we can > somehow combine the ideas. > > As for the parent POM, I'm aware of that possibility but I didn't used on > purpose. In fact you'll see the demo.* projects don't actually have a > parent, they are just aggregated in the demo project. The reason is, I use > this in my talk and I want to point out those are completely free to use > any corporate parent pom they need to. > > Best, > Milen > > > On Wed, Jun 14, 2017 at 8:59 PM, Christian Schneider < > ch...@die-schneider.net> wrote: > > > Hi Milen, > > > > the concept is interesting when you are outside of OSGi but in that case > I > > doubt people will use OSGi requirements and tools even if it woud make > > sense. > > > > When inside OSGi I do not see a big benefit compared to using plain > > bnd-maven-plugin, bnd-index-plugin and bnd-export-plugin like I use in > > https://github.com/cschneider/osgi-chat . > > Merging all this functionality into one plugin is not a good idea imho. I > > prefer the unix like idea of small single purpose projects. > > > > As a general improvement for the bnd toolset I could imagine that the > > bnd-export-maven-plugin uses the current pom as a basis for an OBR index > by > > default. So if you just need one packaging you could omit the separate > > index pom that I use right now. Another possible improvement would be > that > > it can be put in the parent and auto exports all bndrun files it finds. > > > > I agree that a bndrun file is a bit difficult to write from scratch. I > > wonder if we could provide parts of it from bundles that form kind of > > profiles. These could then contribute to the system package exports or > > other settings for specific technologies by using special Manifest > headers. > > Such information could then be used by bnd as well as karaf to setup the > > runtime correctly. > > > > One thing you could improve in your code is to define > > the em-maven-extension in the parent. So the individual projects do not > > need it. > > I did this for the bnd-maven-plugin so each project just needs a bnd.bnd > > file if it wants to override defaults. > > > > Christian > > > > 2017-06-14 13:46 GMT+02:00 Milen Dyankov <milendyan...@gmail.com>: > > > > > Hi Karaf developers, > > > > > > I'd like to ask you to have a look at something I've been working on. > > It's > > > a PoC called Eccentric Modularity (EM) and it's available here > > > https://github.com/azzazzel/EM > > > > > > The basic idea is to provide a jump start into modularity (particularly > > in >
Re: OSGi related PoC and Karaf
Hi Milen, the concept is interesting when you are outside of OSGi but in that case I doubt people will use OSGi requirements and tools even if it woud make sense. When inside OSGi I do not see a big benefit compared to using plain bnd-maven-plugin, bnd-index-plugin and bnd-export-plugin like I use in https://github.com/cschneider/osgi-chat . Merging all this functionality into one plugin is not a good idea imho. I prefer the unix like idea of small single purpose projects. As a general improvement for the bnd toolset I could imagine that the bnd-export-maven-plugin uses the current pom as a basis for an OBR index by default. So if you just need one packaging you could omit the separate index pom that I use right now. Another possible improvement would be that it can be put in the parent and auto exports all bndrun files it finds. I agree that a bndrun file is a bit difficult to write from scratch. I wonder if we could provide parts of it from bundles that form kind of profiles. These could then contribute to the system package exports or other settings for specific technologies by using special Manifest headers. Such information could then be used by bnd as well as karaf to setup the runtime correctly. One thing you could improve in your code is to define the em-maven-extension in the parent. So the individual projects do not need it. I did this for the bnd-maven-plugin so each project just needs a bnd.bnd file if it wants to override defaults. Christian 2017-06-14 13:46 GMT+02:00 Milen Dyankov <milendyan...@gmail.com>: > Hi Karaf developers, > > I'd like to ask you to have a look at something I've been working on. It's > a PoC called Eccentric Modularity (EM) and it's available here > https://github.com/azzazzel/EM > > The basic idea is to provide a jump start into modularity (particularly in > the scope of resolving dependencies and assembling applications from > modules) for people not familiar with OSGi. In fact it tries to hide OSGi > from the developer as much as possible. There is not much documentation but > hopefully the demo projects > <https://github.com/azzazzel/EM/tree/master/demo> (and the slides > <https://www.slideshare.net/MilenDyankov1/fantastic-java- > contracts-and-where-to-define-them> > from the relevant talk) would help you understand the intention. > > From code perspective it's just a (somewhat ugly) hack dynamically adding > bnd maven plugins to a Maven project based on properties. So please ignore > the actual implementation (it's just a PoC) and focus on the idea/concept. > > > Why I am sending this to karaf's dev mailing list? To see if Karaf and EM > can help each other in any way. For example > - adding Karaf as target runtime (next to liferay ) should be very easy > - perhaps EM can extended to also generate executable jar (spring-boot > like) powered by Karaf (it now uses BND's launcher) > - perhaps Karaf features can be special dependencies (like indexes > <https://github.com/azzazzel/EM/blob/master/demo/rest/pom.xml#L61>) that > the resolver can use > - perhaps EM can generate a feature based on the resolver results > > Those are just a few ideas I'd like to share with you and see what do you > think? If the concepts EM present turn out to be something developers are > interested in, it can evolve into real project. Perhaps one that Karaf can > also benefit from. > > > Regards, > Milen > > -- > http://about.me/milen > -- -- Christian Schneider http://www.liquid-reality.de <https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46=http%3a%2f%2fwww.liquid-reality.de> Open Source Architect http://www.talend.com <https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46=http%3a%2f%2fwww.talend.com>
Re: Multiple JPA features available
+1 for the removal of the jpa feature in karaf. I also agree that feature names are not unique enough. Probably we need repo id or url + feature name. Christian 2017-06-10 16:22 GMT+02:00 Achim Nierbeck <bcanh...@googlemail.com>: > Hi, > > just recently I stumbled over a strange effect while building a customized > Karaf with boot features. > In the end it turned out, the reason for that had been two features with > the same name but not the same content. > > Right now we do have a jpa feature in the enterprise repository > (feature.xml) in version 2.6.0 > While the same feature name exists from the aries repository (feature.xml) > also in version 2.6.0 > > I opened an issue for this: > https://issues.apache.org/jira/browse/KARAF-5185 > right now I'm in favor of dumping the jpa feature in the enterprise > repository in favor of the aries jpa feature. If there are no objections > I'd start to remove the enterprise feature. > > In general though we can't really expect to have unique feature names only > by the feature name itself. Maybe it's time to take the repository also > into account as coordinate for feature declarations? > > regards, Achim > > -- > > Apache Member > Apache Karaf <http://karaf.apache.org/> Committer & PMC > OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer & > Project Lead > blog <http://notizblog.nierbeck.de/> > Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS> > > Software Architect / Project Manager / Scrum Master > -- -- Christian Schneider http://www.liquid-reality.de <https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46=http%3a%2f%2fwww.liquid-reality.de> Open Source Architect http://www.talend.com <https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46=http%3a%2f%2fwww.talend.com>
Re: [VOTE] Apache Karaf Cellar 4.1.0 release
+1 Christian On 11.05.2017 08:12, Jean-Baptiste Onofré wrote: Hi all, I submit Karaf Cellar 4.1.0 release to your vote. This release is the first one in the Cellar 4.1.x serie, fully compatible with Karaf 4.1.x (and 4.2.x). Release Notes: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12340376 Staging Repository: https://repository.apache.org/content/repositories/orgapachekaraf-1092/ Git Tag: cellar-4.1.0 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 -- Christian Schneider http://www.liquid-reality.de Open Source Architect http://www.talend.com
Re: [VOTE] Apache Karaf (Container) 4.1.1 release
+1 I already did some basic tests with activemq. I will continue testing and report if I find anything. Christian On 28.03.2017 22:11, Jean-Baptiste Onofré wrote: Hi all, I submit Karaf (Container) 4.1.1 release to your vote. Release Notes: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12339244 Staging Repository: https://repository.apache.org/content/repositories/orgapachekaraf-1090/ Git Tag: karaf-4.1.1 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 48 hours. Thanks, Regards JB -- Christian Schneider http://www.liquid-reality.de Open Source Architect http://www.talend.com
Re: Karaf 4.1.0 whiteboard issues
That is great. Thanks, Christian On 17.03.2017 18:48, Achim Nierbeck wrote: I'll do that There are still some bugs that I need to verify Regards, Achim Christian Schneider <ch...@die-schneider.net> schrieb am Fr. 17. März 2017 um 18:46: Hi JB, we will need a pax web release for karaf 4.1.1. Should I take care of it? Christian 2017-03-17 15:41 GMT+01:00 Jean-Baptiste Onofré <j...@nanthrax.net>: Hi Lukas, Thanks for the report. Let me take a look on that and move forward (I was planning to release Karaf 4.1.1 this week end, so I have to move forward on pax web investigations). I keep you posted. Regards JB On 03/17/2017 04:52 PM, lrohner wrote: Hi all After upgrading to Karaf 4.1.0 I found two blocking issues for me, which are related to the pax-web-whiteboard implementation, so I created these tickets there and fixed them. https://ops4j1.jira.com/browse/PAXWEB-1073 https://ops4j1.jira.com/browse/PAXWEB-1074 I don't know when you are planning to release Karaf 4.1.1, but I would like to have them involved as soon pax-web 6.0.3 is out. Thanks Lukas -- View this message in context: http://karaf.922171.n3.nabble. com/Karaf-4-1-0-whiteboard-issues-tp4049868.html Sent from the Karaf - Dev mailing list archive at Nabble.com. -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com -- -- Christian Schneider http://www.liquid-reality.de < https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46=http%3a%2f%2fwww.liquid-reality.de Open Source Architect http://www.talend.com < https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46=http%3a%2f%2fwww.talend.com -- Christian Schneider http://www.liquid-reality.de Open Source Architect http://www.talend.com
Re: Karaf 4.1.0 whiteboard issues
Hi JB, we will need a pax web release for karaf 4.1.1. Should I take care of it? Christian 2017-03-17 15:41 GMT+01:00 Jean-Baptiste Onofré <j...@nanthrax.net>: > Hi Lukas, > > Thanks for the report. Let me take a look on that and move forward (I was > planning to release Karaf 4.1.1 this week end, so I have to move forward on > pax web investigations). > > I keep you posted. > > Regards > JB > > > On 03/17/2017 04:52 PM, lrohner wrote: > >> Hi all >> >> After upgrading to Karaf 4.1.0 I found two blocking issues for me, which >> are >> related to the pax-web-whiteboard implementation, so I created these >> tickets >> there and fixed them. >> >> https://ops4j1.jira.com/browse/PAXWEB-1073 >> https://ops4j1.jira.com/browse/PAXWEB-1074 >> >> I don't know when you are planning to release Karaf 4.1.1, but I would >> like >> to have them involved as soon pax-web 6.0.3 is out. >> >> Thanks >> Lukas >> >> >> >> -- >> View this message in context: http://karaf.922171.n3.nabble. >> com/Karaf-4-1-0-whiteboard-issues-tp4049868.html >> Sent from the Karaf - Dev mailing list archive at Nabble.com. >> >> > -- > Jean-Baptiste Onofré > jbono...@apache.org > http://blog.nanthrax.net > Talend - http://www.talend.com > -- -- Christian Schneider http://www.liquid-reality.de <https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46=http%3a%2f%2fwww.liquid-reality.de> Open Source Architect http://www.talend.com <https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46=http%3a%2f%2fwww.talend.com>
Re: [VOTE] Apache Karaf (Container) 4.1.0 release, RC#2
+1 I found quite a few issues. Mainly related to pax-web and activemq webconsole. * service:list does not work if a service has an empty list of ObjectClass properties. I guess that this is not too common and there are workarounds. https://issues.apache.org/jira/browse/KARAF-4974 * Servlets are not exported by the whiteboard if they have the pax web style as well as the new osgi whiteboard style https://ops4j1.jira.com/browse/PAXWEB-1060 * Activemq webconsole does start correctly as it misses an import for javax.servlet.annotation. I am not sure anymore if this is really an activemq error. It worked by adding the import but I can not find a place where the annotation is used. So maybe it is also an issue in pax web. https://issues.apache.org/jira/browse/AMQ-6591 * After the import is fixed for activemq webconsole I get another exception in the logs https://ops4j1.jira.com/browse/PAXWEB-1061 * The webconsole start up but it seems the tag libs are missing https://ops4j1.jira.com/browse/PAXWEB-1062 I still propose to push the release but we will soon need a bugfix release and we should warn about these issues. Another general note is that as the older spring versions have been removed now it might be necessary to add the spring-legacy repo. feature:repo-add spring-legacy 4.1.0 I hope we can soon provide each version of spring separately from servicemix then users can install exactly the spring features repo they need. Christian On 01.02.2017 20:32, Jean-Baptiste Onofré wrote: Hi all, I submit Karaf (Container) 4.1.0 release (second attempt) to your vote. Release Notes: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12332799 Staging Repository: https://repository.apache.org/content/repositories/orgapachekaraf-1089/ Git Tag: karaf-4.1.0 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 48 hours. Thanks, Regards JB -- Christian Schneider http://www.liquid-reality.de Open Source Architect http://www.talend.com
Re: [VOTE] Apache Karaf (Container) 4.1.0 release, RC#2
Features extension tracks the bundle wirings and stores them into the data directory. On a restart of karaf there wirings are then reloaded from disk. This makes the wiring more stable. As it is a fragment the resolved state is normal. Christian On 02.02.2017 12:15, Fabian Lange wrote: Hey, ok, so after a (surprisingly painful) migration of the log config we use i am having logging again. One more thing: 1 │ Resolved │ 1 │ 4.1.0 │ Apache Karaf :: Features :: Extension, Hosts: 0 is this new? what does it do? Why is it only resolved? Fabian -- Christian Schneider http://www.liquid-reality.de Open Source Architect http://www.talend.com
Re: [DISCUSS] Living on the edge... of version range
I also think we should better just change on the pax url level. Someone
else using the AetherBasedResolver might expect the default behaviour.
Christian
On 01.02.2017 14:28, Guillaume Nodet wrote:
Right. Not sure it's worth it, but why not.
I still think the best location for the osgi-compatible version resolver is
in pax-url-aether, as it's really the only place it will be used afaik, but
again, it's no big deal.
2017-02-01 14:14 GMT+01:00 Łukasz Dywicki <l...@code-house.org>:
What I was thinking about was something like that:
AetherBasedResolver.class.getResources("META-INF/pax-
customization.properties")
then just parsing it and pushing into ServiceLocator instance created
by MavenRepositorySystemUtil. We can do that because
DefaultServiceLocator implementation is mutable as Grzegorz pointed
out. Since we will be in internal package getResources should behave
properly in both cases.
Cheers,
Lukasz
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
Re: Problems with 3rd party commands in 4.1.0
I found a bit more now. The shell.console fragment itself also is in state installed while it should be resolved. If I manually refresh shell.core then the fragment shell.console goes to state resolved and the came command bundle can be started. Christian On 01.02.2017 10:46, Christian Schneider wrote: I can reproduce the issue. I think it might be a bug in the resolver. What I found: Camel commands import this package: (&(osgi.wiring.package=org.apache.karaf.shell.console)(version>=3.0.0)(!(version>=5.0.0))) The exported packages show this: org.apache.karaf.shell.console │ 2.3.0 │ 42 │ org.apache.karaf.shell.console org.apache.karaf.shell.console │ 4.1.0 │ 42 │ org.apache.karaf.shell.console So the package is exported in two versions. The version 2.3.0 would not match the range camel imports, the 4.1.0 version would match it. I suspect that the resolver behaves differently depending on which version it checks first. If it checks the 4.1.0 first it works, if it checks the 2.1.0 version first it fails. I guess it should check both versions and take the working one but apparently it does not. Unfortunately I do not know the implementation well enough to check or fix this but maybe it helps Guillaume to find the issue :-) Christian On 31.01.2017 21:42, Krzysztof Sobkowiak wrote: Hi While testing 4.1.0 I have observed following issue. karaf@root()> feature:repo-add camel 2.18.2 21:35:06 Adding feature url mvn:org.apache.camel.karaf/apache-camel/2.18.2/xml/features karaf@root()> feature:install camel 21:35:19 karaf@root()> camel 21:35:26 camel camel:context-list camel:eip-explain camel:rest-api-doc camel:route-profile camel:route-start camel camel:context-resume camel:eip-explain camel:rest-registry-list camel:route-profile camel:route-stop camel:component-listcamel:context-resume camel:endpoint-explain camel:rest-registry-list camel:route-reset-stats camel:route-stop camel:component-listcamel:context-start camel:endpoint-explain camel:rest-show camel:route-reset-stats camel:route-suspend camel:context-inflight camel:context-start camel:endpoint-list camel:rest-show camel:route-resume camel:route-suspend camel:context-inflight camel:context-stop camel:endpoint-list camel:route-info camel:route-resume camel:context-info camel:context-stop camel:endpoint-statscamel:route-info camel:route-show camel:context-info camel:context-suspend camel:endpoint-statscamel:route-list camel:route-show camel:context-list camel:context-suspend camel:rest-api-doc camel:route-list camel:route-start The commands are available and work. But after Karaf restart they are no more available and the log contains following error: 2017-01-31 21:37:25,415 | ERROR | FelixStartLevel | Felix| - - | Bundle org.apache.camel.karaf.camel-karaf-commands [57] Error starting mvn:org.apache.camel.karaf/camel-karaf-commands/2.18.2 (org.osgi.framework.BundleException: Unable to resolve org.apache.camel.karaf.camel-karaf-commands [57](R 57.0): missing requirement [org.apache.camel.karaf.camel-karaf-commands [57](R 57.0)] osgi.wiring.package; (&(osgi.wiring.package=org.apache.karaf.shell.console)(version>=3.0.0)(!(version>=5.0.0))) [caused by: Unable to resolve org.apache.karaf.shell.console [42](R 42.0): missing requirement [org.apache.karaf.shell.console [42](R 42.0)] osgi.wiring.host; (&(osgi.wiring.host=org.apache.karaf.shell.core)(bundle-version>=0.0.0))] Unresolved requirements: [[org.apache.camel.karaf.camel-karaf-commands [57](R 57.0)] osgi.wiring.package; (&(osgi.wiring.package=org.apache.karaf.shell.console)(version>=3.0.0)(!(version>=5.0.0)))]) org.osgi.framework.BundleException: Unable to resolve org.apache.camel.karaf.camel-karaf-commands [57](R 57.0): missing requirement [org.apache.camel.karaf.camel-karaf-commands [57](R 57.0)] osgi.wiring.package; (&(osgi.wiring.package=org.apache.karaf.shell.console)(version>=3.0.0)(!(version>=5.0.0))) [caused by: Unable to resolve org.apache.karaf.shell.console [42](R 42.0): missing requirement [org.apache.karaf.shell.console [42](R 42.0)] osgi.wiring.host; (&(osgi.wiring.host=org.apache.karaf.shell.core)(bundle-version>=0.0.0))] Unresolved requirements: [[org.apache.camel.karaf.camel-karaf-commands [57](R 57.0)] osgi.wiring.package; (&(osgi.wiring.package=org.apache.karaf.shell.console)(version>=3.0.0)(!(version>=5.0.0)))] at org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:4111) [?:?] at org.apache.felix.framework.Felix.startBundle(Felix.java:2117) [?:?]
Re: Problems with 3rd party commands in 4.1.0
=5.0.0)))] at org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:4111) [?:?] at org.apache.felix.framework.Felix.startBundle(Felix.java:2117) [?:?] at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1371) [?:?] at org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:308) [?:?] at java.lang.Thread.run(Thread.java:745) [?:?] 2017-01-31 21:37:25,417 | ERROR | lixDispatchQueue | camel-karaf-commands | 57 - org.apache.camel.karaf.camel-karaf-commands - 2.18.2 | FrameworkEvent ERROR - org.apache.camel.karaf.camel-karaf-commands org.osgi.framework.BundleException: Unable to resolve org.apache.camel.karaf.camel-karaf-commands [57](R 57.0): missing requirement [org.apache.camel.karaf.camel-karaf-commands [57](R 57.0)] osgi.wiring.package; (&(osgi.wiring.package=org.apache.karaf.shell.console)(version>=3.0.0)(!(version>=5.0.0))) [caused by: Unable to resolve org.apache.karaf.shell.console [42](R 42.0): missing requirement [org.apache.karaf.shell.console [42](R 42.0)] osgi.wiring.host; (&(osgi.wiring.host=org.apache.karaf.shell.core)(bundle-version>=0.0.0))] Unresolved requirements: [[org.apache.camel.karaf.camel-karaf-commands [57](R 57.0)] osgi.wiring.package; (&(osgi.wiring.package=org.apache.karaf.shell.console)(version>=3.0.0)(!(version>=5.0.0)))] at org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:4111) [?:?] at org.apache.felix.framework.Felix.startBundle(Felix.java:2117) [?:?] at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1371) [?:?] at org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:308) [?:?] at java.lang.Thread.run(Thread.java:745) [?:?] The same happens with other 3rd party commands, e.g: karaf@root()> feature:repo-add activemq 5.15.0-SNAPSHOT 21:39:14 Adding feature url mvn:org.apache.activemq/activemq-karaf/5.15.0-SNAPSHOT/xml/features karaf@root()> feature:install activemq-broker-noweb 21:39:26 karaf@root()> activemq 21:39:37 activemq activemq:bstat activemq:consumeractivemq:list activemq:produceractivemq:query activemq:browse activemq:bstat activemq:dstat activemq:list activemq:purge activemq:query activemq:browse activemq:consumeractivemq:dstat activemq:produceractivemq:purge Is this the same problem you have mentioned in this thread? Kindly regards Krzysztof On 29.01.2017 13:38, Jean-Baptiste Onofré wrote: 2. Shell command issue Several projects providing shell commands (like Camel, ActiveMQ, ...) directly use jline dependency. It's pretty bad (they should use the Karaf "wrapper), and, as Karaf 4.1.x now uses JLine 3.x, those commands don't work in Karaf 4.1.x. Here, we have two solutions: 2.1. We create the jline "2.x" compliant packages in Karaf (in a bundle as part of the shell-compat feature for instance). It's only a workaround but should fix the issue. 2.2. jline 3.x can provide a "compat" bundle with the jline 2.x packages name, wrapping the jline 3.x ones. It's probably the most elegant solution, but it's require a new jline 3.x release. -- Christian Schneider http://www.liquid-reality.de Open Source Architect http://www.talend.com
Re: Towards Karaf (Container) 4.1.0
+1 for releasing quickly. I think most people will take the examples from master anyway. Christian 2017-01-30 21:57 GMT+01:00 Jean-Baptiste Onofré <j...@nanthrax.net>: > Let me go back to the commit before removing OSGi examples. > > We can provide simple OSGi (with Config), Blueprint, DS, Branding and move > demos in examples pretty quickly, included in the distribution. > > As I would like to release 4.1.0 asap, I propose to start the merge on the > examples on master after the release. People can always take a look on the > examples and they will be shipped in 4.1.1 release. > As said, I don't want to hold 4.1.0 any longer (I'm already releasing Pax > Exam 4.10.0 as it's required for 4.1.0). > > Regards > JB > > > On 01/30/2017 09:40 PM, Achim Nierbeck wrote: > >> As I'm with Krzysztof it's sometimes hard to find good plain OSGi samples, >> I'd keep those. >> Still nowadays plain OSGi is actually rather advanced. Therefore a >> "starter" sample should start with DS, instead of plain OSGi. >> >> Besides this, why not start with some examples now and publish the full >> set >> with Karaf 4.1.1?? >> >> regards, Achim >> >> >> 2017-01-30 21:23 GMT+01:00 Jean-Baptiste Onofré <j...@nanthrax.net>: >> >> Thanks for your feedback Krzysztof. >>> >>> I share your thoughts. Christian comment was more to put the beginners on >>> the right track as soon as they start. >>> >>> I'm in favor of keeping OSGi samples (including config) as well. >>> >>> Let's see what the others will think. >>> >>> Regards >>> JB >>> >>> >>> On 01/30/2017 09:18 PM, Krzysztof Sobkowiak wrote: >>> >>> I like the new examples. They will be a good starter for people who want >>>> to start using Karaf. >>>> Personally I would keep the plain OSGi samples (maybe with a comment >>>> this >>>> is a more advanced stuff or moving them to a section with advanced >>>> examples). >>>> I was often looking for a good sample how to do something good in plain >>>> OSGI. It would be good to have them in Karaf examples >>>> >>>> Kindly regards >>>> Krzysztof >>>> >>>> On 30.01.2017 19:14, Jean-Baptiste Onofré wrote: >>>> >>>> I started to do the changes proposed by Christian, and Christian also >>>>> kindly offered his help to update the examples. >>>>> >>>>> As I don't want to hold the 4.1.0 longer, I'm postponing the examples >>>>> in >>>>> the distribution for 4.1.1 release. As examples can be the key part to >>>>> start with Karaf, it makes sense to take time to polish a bit and >>>>> provide a >>>>> complete overview. >>>>> >>>>> So, I moved KARAF-2511 (related to the examples in the distribution) to >>>>> Karaf 4.1.1 release and I'm starting 4.1.0 release. >>>>> >>>>> Sorry again for the noise (just wanted to keep you posted about the >>>>> last >>>>> progress). >>>>> >>>>> Stay tuned tonight for the release vote e-mail. >>>>> >>>>> Thanks ! >>>>> Regards >>>>> JB >>>>> >>>>> On 01/30/2017 03:12 PM, Christian Schneider wrote: >>>>> >>>>> Like discussed on IRC. >>>>>> >>>>>> The examples should be named sample or examples instead of starter. >>>>>> Starter would be confused with the spring boot meaning of starter. >>>>>> The blueprint and jpa examples are good. >>>>>> >>>>>> I would leave out the plain OSGi examples. For anything more complex >>>>>> the >>>>>> OSGi API is too difficult to use and leads beginners on the wrong >>>>>> track. >>>>>> Instead of the OSGi examples I propose to prepare DS examples and add >>>>>> them to the next karaf release. >>>>>> >>>>>> Christian >>>>>> >>>>>> On 30.01.2017 14:41, Jean-Baptiste Onofré wrote: >>>>>> >>>>>> Agree for the examples in the distribution as well ? >>>>>>> >>>>>>> Regards >>>>>>> JB >>>>>>> >>>>>>> On 01/30/2017 02:37 PM, Christian Schneider wrote: >>>>
Re: Towards Karaf (Container) 4.1.0
Like discussed on IRC. The examples should be named sample or examples instead of starter. Starter would be confused with the spring boot meaning of starter. The blueprint and jpa examples are good. I would leave out the plain OSGi examples. For anything more complex the OSGi API is too difficult to use and leads beginners on the wrong track. Instead of the OSGi examples I propose to prepare DS examples and add them to the next karaf release. Christian On 30.01.2017 14:41, Jean-Baptiste Onofré wrote: Agree for the examples in the distribution as well ? Regards JB On 01/30/2017 02:37 PM, Christian Schneider wrote: I also think a 4.1.0 should be ok with the current status. We just need to document that some features like activemq might need the spring or enterprise legacy repos. Christian On 30.01.2017 13:39, Jean-Baptiste Onofré wrote: Hi, I confirm the "jline" commands are now working fine. So, I will release 4.1.0. As part of the 4.1.0, I would like to include examples (I have some more in preparation that I gonna merge) in the standard distribution: https://github.com/jbonofre/karaf/tree/DEV_GUIDE/examples We will improve and extend the examples (and dev guide) for 4.1.1. WDYT ? Regards JB On 01/30/2017 11:05 AM, Jean-Baptiste Onofré wrote: Hi all, Guillaume fixed the shell backward compatibility this morning. I'm testing the fix now and if it's good, I will directly do a 4.1.0 release. Thanks ! Regards JB On 01/29/2017 01:38 PM, Jean-Baptiste Onofré wrote: A quick new update related to the first Karaf 4.1.x release. 1. Jenkins build I fixed the Jenkins jobs for both master and karaf-4.0.x: https://builds.apache.org/view/K/view/Karaf/ I also removed the job for karaf-3.0.x. The build are now fully OK, including itests. It's important to keep this build clean. I encourage you to check the result of the build after your commits. If you have any doubt before committing, we still have the PR validation job. So, you can create a pull request that will be validated by Jenkins. Then, you can merge your PR branch. 2. Shell command issue Several projects providing shell commands (like Camel, ActiveMQ, ...) directly use jline dependency. It's pretty bad (they should use the Karaf "wrapper), and, as Karaf 4.1.x now uses JLine 3.x, those commands don't work in Karaf 4.1.x. Here, we have two solutions: 2.1. We create the jline "2.x" compliant packages in Karaf (in a bundle as part of the shell-compat feature for instance). It's only a workaround but should fix the issue. 2.2. jline 3.x can provide a "compat" bundle with the jline 2.x packages name, wrapping the jline 3.x ones. It's probably the most elegant solution, but it's require a new jline 3.x release. 3. Version & Schedule Basically, I planned to release 4.1.0-M1 version today, as shell command "break" is pretty bad. I'm postponing the decision to tomorrow evening. I plan to discuss with Guillaume tomorrow about the jline 3 and shell commands issue. If we can find a good solution, and release jline 3.1.3 tomorrow, then, I will release Karaf 4.1.0 tomorrow evening. If it's more complex and requires more time, then, I will release 4.1.0-M1 tomorrow evening, the 4.1.0 (GA) will be released 3 weeks later, giving time for us to fix the jline/command issue. Thanks ! Regards JB On 01/29/2017 11:31 AM, Jean-Baptiste Onofré wrote: Hi all, the problem is clearly an incompatible version of jline (resulting of the update we did in Karaf 4.1.x). It breaks other projects which are using directly jline (for completer for instance). So, the other projects should be refactored (camel, activemq, ...) to not relay on jline but Karaf (for the completer for instance). Anyway, it means that Karaf 4.1.0 is not yet ready to support any other projects. So, I'm going to 4.1.0-M1 first and we will invite maximum of people to test on this milestone in order to clearly identify the breaking changes and provide max backward compatibility when possible. I already changed the version in Jira and I will cut 4.1.0-M1 later today. Regards JB On 01/28/2017 03:32 PM, Jean-Baptiste Onofré wrote: Hi guys, as you might know, I'm preparing the Karaf 4.1.0 release. We are mostly ok, but during my tests, I found that Camel (at least 2.18.1) commands are not available in the shell. I suspect because they use the "old" style. I also see lot of small annoying behaviors in the shell console (on completion especially). So, even we are mostly ready, I'm not sure it's fully ready for production. Instead of directly releasing Karaf 4.1.0, I propose to release 4.1.0-M1 as a tech preview. I would allow people to review and test 4.1.0-M1 but give a good message that's a tech preview. WDYT ? Regards JB On 01/05/2017 03:39 PM, Jean-Baptiste Onofré wrote: Hi guys, I started the updates and fixes for Karaf 4.1.0. As dependencies, we will need Pax Exam 4.10.0 and Pax Web 6.0.1. Achim
Re: [DISCUSS] & in feature (KARAF-4829)
You are right. This will be a problem. Maybe we can feed this into the development at felix. As fileinstall is also at felix they might be interested to solve this anyway. I will open an issue. Christian On 09.12.2016 11:32, Achim Nierbeck wrote: But this will only work, if the configuration passed through the file-installer is faster then the extender ... and this timing I really don't want to rely on. regards, Achim 2016-12-09 11:30 GMT+01:00 Christian Schneider <ch...@die-schneider.net>: As far as I understood the config from inside the bundle is only applied if config admin does not already have a config. So if there is a config in etc or in plain config admin it will always be prefered over the default. I think the configurator would currently work in karaf like the old config element which only created the config in config admin. I think though that we could enhance the behaviour so the config is also written to etc. I think then it should work exactly like the config Element works now. Christian On 09.12.2016 11:18, Achim Nierbeck wrote: I'm not really sure I like the bundle approach, it has some down-sides. Especially in the context of Karaf, the external configuration via the etc folder is well known and works reliable. I know it's a bit cumbersome if "NO" extra config is needed, but especially in a dev/ops separated environment (still the most-commonly-used) ops people just need to adapt the configurations. How is an Update handled? When will the bundle-based or the etc-based config be used? It's ok for environments like the enroute one, where the result is a self-contained all-in-one executable jar with no extras like what we have in a container with Karaf. regards, Achim -- Christian Schneider http://www.liquid-reality.de Open Source Architect http://www.talend.com -- Christian Schneider http://www.liquid-reality.de Open Source Architect http://www.talend.com
Re: [DISCUSS] & in feature (KARAF-4829)
As far as I understood the config from inside the bundle is only applied if config admin does not already have a config. So if there is a config in etc or in plain config admin it will always be prefered over the default. I think the configurator would currently work in karaf like the old config element which only created the config in config admin. I think though that we could enhance the behaviour so the config is also written to etc. I think then it should work exactly like the config Element works now. Christian On 09.12.2016 11:18, Achim Nierbeck wrote: I'm not really sure I like the bundle approach, it has some down-sides. Especially in the context of Karaf, the external configuration via the etc folder is well known and works reliable. I know it's a bit cumbersome if "NO" extra config is needed, but especially in a dev/ops separated environment (still the most-commonly-used) ops people just need to adapt the configurations. How is an Update handled? When will the bundle-based or the etc-based config be used? It's ok for environments like the enroute one, where the result is a self-contained all-in-one executable jar with no extras like what we have in a container with Karaf. regards, Achim -- Christian Schneider http://www.liquid-reality.de Open Source Architect http://www.talend.com
Re: [DISCUSS] & in feature (KARAF-4829)
The default config is in the bundle. Basically it simply uses an extender bundle that looks for the config in all bundles and writes the config to config admin if there is not already a config. So if the user wants to change a config he does it using config admin. I think the configurator might even work with karaf already. Christian On 09.12.2016 10:45, Jean-Baptiste Onofré wrote: Hi Christian, I like your idea ! However, definitely, it means it's for Karaf 4.1.x at least (not 4.0.x) as it's kind of breaking change. For the enroute configurer, does it mean that the config file is part of the bundle ? How the user is changing/updating the configuration ? Can you point where does it live at Felix (I didn't see it) ? Thanks ! Regards JB On 12/09/2016 10:25 AM, Christian Schneider wrote: I would ike to make a different proposal. We could add a url to config. So people could use this: In this case the config would be deployed to the etc dir and config admin would be updated immediately. would then be used exclusively to deploy files that are not related to config admin. I think we could then even rename the element to so the purpose is more clear. We could do this whenever we need a new feature xsd. Apart from this I really like the approach of the enroute configurer which seems to be a spec now with impl at felix. There default configs are deployed inside bundles in a special directory. I think this approach is even better than refering to config files in the feature. 1. It is easier to do in the build as you just put the config into src/main/resources. No need to change the pom. 2. The approach also works outside karaf as it does not rely on the karaf features. We could even enhance this by optionally copying the config files into etc to achieve the current karaf behaviour. So in the long run I could imagine to rely on configurer for config admin configs and only use an element to deploy arbitrary files. Christian// On 08.12.2016 15:42, Jean-Baptiste Onofré wrote: It means that we have to check on the final name (not the URL). And on the final name we have to check the target subfolder (cfg goes in etc but we can put something in bar folder using configfile for instance) and the extension of the final name (.cfg). Regards JB On Dec 8, 2016, 15:35, at 15:35, Guillaume Nodet <gno...@apache.org> wrote: Instead of trying to guess the format of the config file, we could simpy use the extension I think. The element has both the file name and the url. So if the file name ends with ".cfg", we assume we can write the content to configadmin directly. I'm not sure I see a real problem here. 2016-12-08 15:28 GMT+01:00 Guillaume Nodet <gno...@apache.org>: 2016-12-08 15:27 GMT+01:00 Jean-Baptiste Onofré <j...@nanthrax.net>: Yes, Achim already replied and I fully agree. So, I wonder if it makes sense to do ConfigAdmin configuration creation for as it would require to detect file format. Can we document that way: 1. for cfg file, we recommend to use in feature XML 2. for any other file format, we recommend to use in feature XML ? That sounds to me the exact reason why we create those two elements in the first place. ;-) Regards JB On 12/08/2016 03:24 PM, Guillaume Nodet wrote: The element supports any kind of configuration file, not only properties file. For example we use it for the xml configuration of jetty in pax-web. 2016-12-08 15:08 GMT+01:00 Jean-Baptiste Onofré <j...@nanthrax.net>: Hi guys, Some weeks ago we discussed on the mailing list about the fact that a feature using just creates the cfg file in the etc folder, and the corresponding configuration is created later by ConfigAdmin (thanks to FileInstall). This can produce unfortunate behavior as the bundles in the feature can be started before the creation of the configuration in ConfigAdmin. Christian proposes to create the configuration in ConfigAdmin as soon as the FeatureService deals with tag. On the other hand, in Karaf 4.0.5, we improved the tag: the FeatureService now creates the corresponding cfg file in etc based on the tag content. So, with KARAF-4829, we will have the same behavior using and : * will create the configuration in ConfigAdmin and the cfg file * will create the cfg file and the configuration in ConfigAdmin The difference is where the configuration comes from: - an existing file (mvn URL) in the case of - inner properties in the case of I wonder: 1. does it make sense to have both and in the future (Karaf 4.1.x) ? 2. should we do the change on in Karaf 4.0.x ? Thoughts ? Regards JB -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com -- Guillaume Nodet Red Hat, Open Source Integration
Re: [DISCUSS] & in feature (KARAF-4829)
I would ike to make a different proposal. We could add a url to config. So people could use this: In this case the config would be deployed to the etc dir and config admin would be updated immediately. would then be used exclusively to deploy files that are not related to config admin. I think we could then even rename the element to so the purpose is more clear. We could do this whenever we need a new feature xsd. Apart from this I really like the approach of the enroute configurer which seems to be a spec now with impl at felix. There default configs are deployed inside bundles in a special directory. I think this approach is even better than refering to config files in the feature. 1. It is easier to do in the build as you just put the config into src/main/resources. No need to change the pom. 2. The approach also works outside karaf as it does not rely on the karaf features. We could even enhance this by optionally copying the config files into etc to achieve the current karaf behaviour. So in the long run I could imagine to rely on configurer for config admin configs and only use an element to deploy arbitrary files. Christian// On 08.12.2016 15:42, Jean-Baptiste Onofré wrote: It means that we have to check on the final name (not the URL). And on the final name we have to check the target subfolder (cfg goes in etc but we can put something in bar folder using configfile for instance) and the extension of the final name (.cfg). Regards JB On Dec 8, 2016, 15:35, at 15:35, Guillaume Nodet <gno...@apache.org> wrote: Instead of trying to guess the format of the config file, we could simpy use the extension I think. The element has both the file name and the url. So if the file name ends with ".cfg", we assume we can write the content to configadmin directly. I'm not sure I see a real problem here. 2016-12-08 15:28 GMT+01:00 Guillaume Nodet <gno...@apache.org>: 2016-12-08 15:27 GMT+01:00 Jean-Baptiste Onofré <j...@nanthrax.net>: Yes, Achim already replied and I fully agree. So, I wonder if it makes sense to do ConfigAdmin configuration creation for as it would require to detect file format. Can we document that way: 1. for cfg file, we recommend to use in feature XML 2. for any other file format, we recommend to use in feature XML ? That sounds to me the exact reason why we create those two elements in the first place. ;-) Regards JB On 12/08/2016 03:24 PM, Guillaume Nodet wrote: The element supports any kind of configuration file, not only properties file. For example we use it for the xml configuration of jetty in pax-web. 2016-12-08 15:08 GMT+01:00 Jean-Baptiste Onofré <j...@nanthrax.net>: Hi guys, Some weeks ago we discussed on the mailing list about the fact that a feature using just creates the cfg file in the etc folder, and the corresponding configuration is created later by ConfigAdmin (thanks to FileInstall). This can produce unfortunate behavior as the bundles in the feature can be started before the creation of the configuration in ConfigAdmin. Christian proposes to create the configuration in ConfigAdmin as soon as the FeatureService deals with tag. On the other hand, in Karaf 4.0.5, we improved the tag: the FeatureService now creates the corresponding cfg file in etc based on the tag content. So, with KARAF-4829, we will have the same behavior using and : * will create the configuration in ConfigAdmin and the cfg file * will create the cfg file and the configuration in ConfigAdmin The difference is where the configuration comes from: - an existing file (mvn URL) in the case of - inner properties in the case of I wonder: 1. does it make sense to have both and in the future (Karaf 4.1.x) ? 2. should we do the change on in Karaf 4.0.x ? Thoughts ? Regards JB -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com -- Guillaume Nodet Red Hat, Open Source Integration Email: gno...@redhat.com Web: http://fusesource.com Blog: http://gnodet.blogspot.com/ -- Guillaume Nodet Red Hat, Open Source Integration Email: gno...@redhat.com Web: http://fusesource.com Blog: http://gnodet.blogspot.com/ -- Christian Schneider http://www.liquid-reality.de Open Source Architect http://www.talend.com
Re: Board Report for December 2016
Looks good Christian 2016-12-03 9:01 GMT+01:00 Andrea Cosentino <ancosen1...@yahoo.com.invalid>: > +1 for me. > > Thanks JB > -- > Andrea Cosentino > -- > Apache Camel PMC Member > Apache Karaf Committer > Apache Servicemix Committer > Email: ancosen1...@yahoo.com > Twitter: @oscerd2 > Github: oscerd > > > > On Saturday, December 3, 2016 8:19 AM, Jean-Baptiste Onofré < > j...@nanthrax.net> wrote: > Hi guys, > > I prepared the board report for December 2016: > > https://cwiki.apache.org/confluence/display/KARAF/Board+Reports > > Can you please take a look and update ? > > I would like to send asap. > > Thanks, > Regards > JB > -- > Jean-Baptiste Onofré > jbono...@apache.org > http://blog.nanthrax.net > Talend - http://www.talend.com > -- -- Christian Schneider http://www.liquid-reality.de <https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46=http%3a%2f%2fwww.liquid-reality.de> Open Source Architect http://www.talend.com <https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46=http%3a%2f%2fwww.talend.com>
Re: ActiveMQ and Camel 2.17.x on Karaf
My fixes were only touching activemq blueprint. I did not check the ActiveMQ spring support. This might be very relevant for TESB though. I will look into it tomorrow. Christian 2016-11-27 6:18 GMT+01:00 Jean-Baptiste Onofré <j...@nanthrax.net>: > Hi, > > Christian did some fixes recently. Did you check with a ActiveMQ SNAPSHOT ? > > Regards > JB > > > On 11/26/2016 09:44 PM, IODB wrote: > >> Issue still exists with ActiveMQ 5.14.1 - Camel 2.18.0 - Karaf 4.0.7 >> >> >> >> -- >> View this message in context: http://karaf.922171.n3.nabble. >> com/ActiveMQ-and-Camel-2-17-x-on-Karaf-tp4046427p4048826.html >> Sent from the Karaf - Dev mailing list archive at Nabble.com. >> >> > -- > Jean-Baptiste Onofré > jbono...@apache.org > http://blog.nanthrax.net > Talend - http://www.talend.com > -- -- Christian Schneider http://www.liquid-reality.de <https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46=http%3a%2f%2fwww.liquid-reality.de> Open Source Architect http://www.talend.com <https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46=http%3a%2f%2fwww.talend.com>
Re: [DISCUSS] Trim down the number of config files in etc/ in the distributions
+1 It is really important that we do such house keeping in karaf as without that the distro tends to grow over time. The only small issue I see is that it is more difficult for people to understand the defaults if a config file is not present but maybe we can find another way to solve this. Maybe using meta type more often. Christian On 25.11.2016 08:19, Guillaume Nodet wrote: I'd like to trim down a bit the number of files in the etc/ directory. The distribution contains a bunch of config files for the ACLs, but I'm not sure people usually modify those. I think this may be the same for various configuration. What I'm proposing is the following: * make sure all those configurations are moved into their respective feature * remove them from the assemblies/base maven module which is embedded by the framework and static kars * add a flag on the AssemblyMojo so that we can choose using glob patterns which config pids should be extracted as files at build time * the other ones are extracted automatically by the FeaturesService anyway during boot features installation The idea would be that distributions only contains configurations that are actually used. Also, I'm going to removing some additional files from the static framework (bin/contrib/, bin/instance(.sh|.bat), deploy/). Thoughts ? Guillaume -- Christian Schneider http://www.liquid-reality.de Open Source Architect http://www.talend.com
Re: java.transaction.xa not exported?
I recently had a similar problem when trying transactions on bndtools. The bndtools guys proposed a different solution by adding the jta 1.1 spec to the runpath. See https://github.com/cschneider/bndtools-tutorials/blob/master/tasklist-ds/tasklist.bndrun#L14 The nice thing with the above solution is that you do not have to exclude the javax.transaction.xa package from the system bundle exports. In karaf this is less of an issue as karaf completely redefines the system package exports anyway. Interestingly I was able to get jpa as well as CXF running on bndtools without redefining the system package exports. So without overriding the spec apis and impls from java. So I wonder what are the advantages / disadvantages of the two approaches. Christian On 22.11.2016 20:29, Guillaume Nodet wrote: Yes, the long answer is the following: * the javax.transaction.xa package provided by the JRE is incomplete * it contains a few classes used by the jdbc package * if the system bundle exports this package, users will hit NoClassDefFoundError because of the missing class * if the classes from the JRE are not used, there will be ClassCastException when using JDBC because the jdbc package uses the classes from the JRE while the driver deployed as an OSGi bundle will use the classes deployed as a bundle The only solution is the one used in karaf since years: - the system bundle exports javax.transaction; javax.transaction.xa; partial=true; mandatory:=partial This means that the package is exported but not really usable - the system bundle boot delegate javax.transaction and javax.transaction.xa - users should deploy a bundle such as mvn:org.apache.geronimo.specs/geronimo-jta_1.1_spec/1.1.1 to provide the full packages 2016-11-22 19:49 GMT+01:00 Achim Nierbeck <bcanh...@googlemail.com>: There is a Pax-JDBC Postgres feature, which also includes the Aries TX because of that. [1] regards, Achim [1] - https://github.com/ops4j/org.ops4j.pax.jdbc/blob/master/ pax-jdbc-features/src/main/resources/features.xml#L83-L90 2016-11-22 19:45 GMT+01:00 Guillaume Nodet <gno...@apache.org>: The package provided by the JRE is incomplete so you need to deploy the XA api separately. 2016-11-22 19:42 GMT+01:00 Fabian Lange <fabian.la...@codecentric.de>: Hi, i just tried to use the new postgres driver for java 8: Error executing command: Error executing command on bundles: Error starting bundle 101: Unable to resolve org.postgresql.jdbc42 [101](R 101.0): missing requirement [org.postgresql.jdbc42 [101](R 101.0)] osgi.wiring.package; (osgi.wiring.package=javax.transaction.xa) Unresolved requirements: [[org.postgresql.jdbc42 [101](R 101.0)] osgi.wiring.package; (osgi.wiring.package=javax.transaction.xa)] I see the .xa package is not exported in bootdelegation. I searched for this and could not find any reason it is not. is it just missing or is there a deeper reason? Fabian -- Fabian Lange | Performance Expert mobil: +49 (0) 160.3673393 codecentric AG | Merscheider Straße 1 | 42699 Solingen | Deutschland Sitz der Gesellschaft: Solingen | HRB 25917| Amtsgericht Wuppertal Vorstand: Michael Hochgürtel . Mirko Novakovic . Rainer Vehns Aufsichtsrat: Patric Fedlmeier (Vorsitzender) . Klaus Jäger . Jürgen Schütz -- Guillaume Nodet Red Hat, Open Source Integration Email: gno...@redhat.com Web: http://fusesource.com Blog: http://gnodet.blogspot.com/ -- Apache Member Apache Karaf <http://karaf.apache.org/> Committer & PMC OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer & Project Lead blog <http://notizblog.nierbeck.de/> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS> Software Architect / Project Manager / Scrum Master -- Christian Schneider http://www.liquid-reality.de Open Source Architect http://www.talend.com
Re: Default log color ( was discussion at aries)
For me the main problem is that the default color is not the terminal color. The user can easily tune the terminal color and background on his terminal client but he can not tune our special colors there. No color is good if you want to completely work without the colors but I think the more typical case is that you want colors for special highlights but not for the whole log. I just looked into my gnome terminal config. It seems to provide settings for a default color and a highlight color. So one possible solution might be that we limit ourselves to just use these two colors in most places. This would give the user a much better control on the client side. Of course it limits a bit what we do but I think that might be a case where such a self limitation makes sense. WDYT? Christian On 21.11.2016 10:19, Jean-Baptiste Onofré wrote: Hi Christian, I'm a bit surprised as the --no-color is always possible and you can also create an alias. So, if the issue is color or not color, I would recommend just a --no-color alias. If the colors themselves, then, no problem to use term colors and so create a Jira. Regards JB On 11/21/2016 10:15 AM, Christian Schneider wrote: I fully agree with Brad that the default color is not very readable. It also makes it difficult for users to change their terminal colors on their client. So I propose we change the default log color to the default terminal color and only use other colors to highlight special things like exceptions. If we agree on this I will open a jira issue (if Brad does not do it before) and change the color. Christian On 07.11.2016 17:34, Brad Johnson wrote: I realize that Aries isn't the keeper of Karaf but there is more than a little cross-pollination and I'm not on that mailing list. This is a small but persistent concern. It really is time for the default logging colors in Karaf to be changed. They've been atrocious to read for a very long time. Yes, they can be changed but I'm bouncing from client to client and version to version and it's a hassle and reading burgundy on black is tiring on the eyes and cyan on black isn't much of a step in the right direction. I'm sure most developers are like I and live in the log files and tail:log constantly. Something as simple as a modification of the color scheme would go a long way toward make the log files easier to work with. I'd be willing to say that a color change, any color change, would be better than the defaults. -- Christian Schneider http://www.liquid-reality.de Open Source Architect http://www.talend.com
Default log color ( was discussion at aries)
I fully agree with Brad that the default color is not very readable. It also makes it difficult for users to change their terminal colors on their client. So I propose we change the default log color to the default terminal color and only use other colors to highlight special things like exceptions. If we agree on this I will open a jira issue (if Brad does not do it before) and change the color. Christian On 07.11.2016 17:34, Brad Johnson wrote: I realize that Aries isn't the keeper of Karaf but there is more than a little cross-pollination and I'm not on that mailing list. This is a small but persistent concern. It really is time for the default logging colors in Karaf to be changed. They've been atrocious to read for a very long time. Yes, they can be changed but I'm bouncing from client to client and version to version and it's a hassle and reading burgundy on black is tiring on the eyes and cyan on black isn't much of a step in the right direction. I'm sure most developers are like I and live in the log files and tail:log constantly. Something as simple as a modification of the color scheme would go a long way toward make the log files easier to work with. I'd be willing to say that a color change, any color change, would be better than the defaults. -- Christian Schneider http://www.liquid-reality.de Open Source Architect http://www.talend.com
Re: [DISCUSS] Predictable Boot Feature Startup Order...
I think it is very important to resolve as many bundles in one go as possible. When installing them one by one it usually creates the need for bundle refreshs. From the numbering of the bundle ids I found a strange thing btw. When I create a feature with my own bundle and several dependent features it seems that my own bundle always has the lowest bundle id and the others follow in the reverse ordering. It looks a bit a like a depth first search. I wonder if that could be reversed. It at least would make finding the user bundles simpler at the end of the list. Not a big thing for me but I wonder if it could be changed. I am not sure how it works exactly in the feature resolver. If it spits out a list of bundles at some point then I think it might just work to install the bundles in the reverse order. Christian On 18.11.2016 17:03, James Carman wrote: Yes, I've tried using staged boot, but in 3.0.x it caused some classpath issues with CXF. It would be great if we could just set up our features so that they're just installed in the order they're defined. On Fri, Nov 18, 2016 at 10:56 AM Guillaume Nodet <gno...@apache.org> wrote: You mean installing the features one by one instead of all in one go ? Have you tried using (myfeature1,myfeature2),(myfeature3,myfeature4) so that you end up with 2 stages ? Ultimately, you can use (myfeature1),(myfeature2),(myfeature3),(myfeature4) 2016-11-18 16:44 GMT+01:00 James Carman <ja...@carmanconsulting.com>: Karaf 3.0.8+ now provides predictable boot feature startup order, but the 4.0.x line does not provide that guarantee. It apparently tries to be smart and figure out what you need, but sometimes it just works better if we can let the user control things explicitly. Is there, perhaps, a compromise here? Could we perhaps have a switch in the org.apache.karaf.features.cfg file that allows you to turn on manual control of the startup order? I'm not the only one who has encountered this issue. There have been emails recently where other folks have observed it. Thoughts? James -- Guillaume Nodet Red Hat, Open Source Integration Email: gno...@redhat.com Web: http://fusesource.com Blog: http://gnodet.blogspot.com/ -- Christian Schneider http://www.liquid-reality.de Open Source Architect http://www.talend.com
Re: Microservices governance for dependency management using Karaf
have been reading interesting things about *Apache Karaf and OSGi Bundle*OSGi Service / OSGi Bundles - containing services / OSGi Versioning and how OSGi Container enforces this / Implicit Interfaces / OSGi multiple version support.Apache Karaf Cellar can also manage the Control Center for managing the installation and lifecyle of a bundle- Node: a node which has the Host application installed. The control center tells the container which modules (or bundles) to install.- Chef: the initial installation of a processing node is managed by Chef. Upgrade to the Host are also managed by chef.- Services marketplace / registry: the marketplace where all bundles that can work with Ecp are exposed. A market can look at it to determine which bundle it wants to install based on its needs. Could you kindly validate this line of thinking?Could we achieve all of the above using this toolkit (OSGi, Karaf, Karaf Cellar and Apache Camel)?Is there anything you need clarification or I am missing?Any thoughts / elaborations / comments? -- View this message in context: http://karaf.922171.n3.nabble.com/Microservices-governance-for-dependency-management-using-Karaf-tp4048638.html Sent from the Karaf - Dev mailing list archive at Nabble.com. -- Christian Schneider http://www.liquid-reality.de Open Source Architect http://www.talend.com
Re: [VOTE] Apache Karaf Decanter 1.3.0 release
+1 Christian On 02.11.2016 08:12, Jean-Baptiste Onofré wrote: Hi all, I submit Karaf Decanter 1.3.0 release to your vote. Release Notes: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12338064 Git tag: decanter-1.3.0 Staging repository: https://repository.apache.org/content/repositories/orgapachekaraf-1077/ 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 -- Christian Schneider http://www.liquid-reality.de Open Source Architect http://www.talend.com
Re: [DISCUSS] Feature package, feature generation and validation
On 19.10.2016 16:57, Guillaume Nodet wrote: Something like: mvn:... mvn:... ... That sounds like a feature to me ;-) The advantage would be that you can use IDE tooling for poms like M2E. So you get search and completion for the artifacts. You get nice introspection for the transitive dependencies. I think one thing we are missing in karaf feature files is IDE support. Anyway, a custom osgi resource repository can be easily created for an external file by inheriting org.apache.karaf.features.internal.repository.BaseRepository. Just add your new repository into org.apache.karaf.features.internal.region. getRepository and it should work. Sounds interesting. I will play with that. Again, in the simple cases, if this list of bundles can be generated, it means that the feature itself can be generated, so I'm not sure where the benefit is... I have not used the generated features a lot. One thing that might be problematic is that a feature file can contain several features while a pom can only contain one list of bundles. That is why I would treat the list of bundles from the pom rather as a backing repository than as a feature. Again I think the main benefit would come from tooling. Bndtools allows to search in the index and just drag bundles into the requirements. Such a mechanism would also be great for features. Unfortunately we do not have a lot of good Eclipse RCP or Intellij plugin developers at Apache. So I guess the dream of having decent IDE tooling is quite far away :-( Christian -- Christian Schneider http://www.liquid-reality.de Open Source Architect http://www.talend.com
