Re: [PROPOSAL] Renaming terms
+1 as a user of karaf 4.2 building our own distribution, we would be okay with this being even in 4.2.x Even when not backwards compatible Fabian On Mon, Jul 27, 2020 at 8:22 AM Jean-Baptiste Onofre wrote: > 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
Re: [VOTE] Apache Karaf Runtime 4.2.8 release (take #2)
Just to clarify: this is not a showstopper for me (therefore my +1) Our distribution process runs a license checker and that noticed the extra jar. We excluded it from being packaged and everything is fine. I also expect that other users due the same due diligence. The file does have the CDDL 1.0+GPL2 license. This is however not mentioned in https://github.com/apache/karaf/blob/master/NOTICE or https://github.com/apache/karaf/blob/master/LICENSE This fact may be a showstopper for some people. Fabian On Mon, Jan 20, 2020 at 2:07 PM Jean-Baptiste Onofré wrote: > > Hi Fabian, > > About KARAF-2925, let me check about an alternative dep. > > Regards > JB > > On 20/01/2020 13:26, Fabian Lange wrote: > > +1 (non-binding) > > > > findings: > > * pax-logging + knoplerfish issue resolved > > * wrap + logging dependency/ordering issue resolved > > * https://issues.apache.org/jira/browse/KARAF-2925 - IMHO this should > > be fixed. Karaf now ships a 10 year old unmaintained early access jar > > with no source or licensing info on the boot classpath > > (https://github.com/apache/karaf/commit/364a98078cb007500af9718a9a443eb4745b) > > > > tested with java 8 on mac only. > > > > Fabian > > > > On Mon, Jan 20, 2020 at 8:19 AM Francois Papon > > wrote: > >> > >> +1 (binding) > >> > >> regards, > >> > >> François > >> fpa...@apache.org > >> > >> Le 19/01/2020 à 22:49, Jean-Baptiste Onofré a écrit : > >>> 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&version=12346100 > >>> > >>> Staging Repository: > >>> https://repository.apache.org/content/repositories/orgapachekaraf-1138 > >>> > >>> 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
Re: [VOTE] Apache Karaf Runtime 4.2.8 release (take #2)
+1 (non-binding) findings: * pax-logging + knoplerfish issue resolved * wrap + logging dependency/ordering issue resolved * https://issues.apache.org/jira/browse/KARAF-2925 - IMHO this should be fixed. Karaf now ships a 10 year old unmaintained early access jar with no source or licensing info on the boot classpath (https://github.com/apache/karaf/commit/364a98078cb007500af9718a9a443eb4745b) tested with java 8 on mac only. Fabian On Mon, Jan 20, 2020 at 8:19 AM Francois Papon wrote: > > +1 (binding) > > regards, > > François > fpa...@apache.org > > Le 19/01/2020 à 22:49, Jean-Baptiste Onofré a écrit : > > 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&version=12346100 > > > > Staging Repository: > > https://repository.apache.org/content/repositories/orgapachekaraf-1138 > > > > 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
Re: Proguard is not working in karaf 4.2.6
Thats a proguard bug. This is a correct multi release jar file https://openjdk.java.net/jeps/238 https://www.baeldung.com/java-multi-release-jar Fabian On Thu, Jun 20, 2019 at 3:16 PM Ravi wrote: > > Hi Team > After we are upgraded our application from karaf 4.2.2 to 4.2.6 when > proguarding the compilation is failing below warning followed by exception. > > [proguard] Warning: class > [META-INF/versions/9/javax/xml/bind/ModuleUtil.class] unexpectedly contains > class [javax.xml.bind.ModuleUtil] > > [proguard] Warning: there were 1 classes in incorrectly named files. > [proguard] You should make sure all file names correspond to their class > names. > [proguard] The directory hierarchies must correspond to the package > hierarchies. > [proguard] > (proguard.sourceforge.net/manual/troubleshooting.html#unexpectedclass) > [proguard] If you don't mind the mentioned classes not being written out, > [proguard] you could try your luck using the '-ignorewarnings' option. > [proguard] java.io.IOException: Please correct the above warnings first. > [proguard] at proguard.InputReader.execute(InputReader.java:149) > [proguard] at proguard.ProGuard.readInput(ProGuard.java:255) > [proguard] at proguard.ProGuard.execute(ProGuard.java:96) > [proguard] at proguard.ProGuard.main(ProGuard.java:572) > [proguard] Reading library jar [C:\Program > Files\Java\jdk1.8.0_192\jre\lib\jsse.jar] > [proguard] Reading library jar [C:\Program > Files\Java\jdk1.8.0_192\jre\lib\jce.jar] > > Any suggestions or help please. > > Thanks, > Ravi > > > > -- > Sent from: http://karaf.922171.n3.nabble.com/Karaf-Dev-f930721.html
Re: Problem deploying 4.2.3 custom distribution
Not required from my side. Now that this has been documented here and can be found with your favourite search engine, I am fine with keeping it like it is. Fabian On Tue, Feb 26, 2019 at 6:44 AM Jean-Baptiste Onofré wrote: > > As other plugins (especially deploy) didn't yet update, and in order to > keep aligned, I'm proposing to downgrade to wagon 3.2.0 (as before) and > quickly cut Karaf 4.2.4 to avoid to impact the users. > We will upgrade wagon sync with other Maven plugins to avoid "API > change" in Wagon. > > Thoughts ? > > Regards > JB > > On 24/02/2019 11:20, Fabian Lange wrote: > > Hi, > > > > did anyone come across this problem when deploying a 4.2.3 custom > > distribution? > > > > [ERROR] Failed to execute goal > > org.apache.maven.plugins:maven-deploy-plugin:2.8.2:deploy > > (default-deploy) on project karaf-assembly: Execution default-deploy > > of goal org.apache.maven.plugins:maven-deploy-plugin:2.8.2:deploy > > failed: An API incompatibility was encountered while executing > > org.apache.maven.plugins:maven-deploy-plugin:2.8.2:deploy: > > java.lang.NoSuchMethodError: > > org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.getBufferCapacityForTransfer(J)I > > > > > > I have the feeling that there is a new dependency from pax-url / karaf > > maven plugin interfering with mvn-deploy? > > > > I will dig into this and report findings, if somebody has seen and > > solved this let me know. Thx > > > > Fabian > > > > -- > Jean-Baptiste Onofré > jbono...@apache.org > http://blog.nanthrax.net > Talend - http://www.talend.com
Re: Problem deploying 4.2.3 custom distribution
Hi JB, happened on 3.3 - 3.6 On deploy 2.8.2 and 3.0.0.M1 In typical rubber ducking style, I managed to get it working just 2 minutes ago, by overriding wagon for deploy org.apache.maven.plugins maven-deploy-plugin 2.8.2 org.apache.maven.wagon wagon-http 2.12 So I guess somehow the new karaf maven plugin messes with the wagon dependency for deploy Fabian On Sun, Feb 24, 2019 at 11:31 AM Jean-Baptiste Onofré wrote: > > Hi Fabian, > > What Maven version are you using ? And do you have wagon defined in your > pom.xml ? > > Karaf itself is a custom distribution, so, it works fine. I think it's > dependency version issue on wagon. > > Regards > JB > > On 24/02/2019 11:20, Fabian Lange wrote: > > Hi, > > > > did anyone come across this problem when deploying a 4.2.3 custom > > distribution? > > > > [ERROR] Failed to execute goal > > org.apache.maven.plugins:maven-deploy-plugin:2.8.2:deploy > > (default-deploy) on project karaf-assembly: Execution default-deploy > > of goal org.apache.maven.plugins:maven-deploy-plugin:2.8.2:deploy > > failed: An API incompatibility was encountered while executing > > org.apache.maven.plugins:maven-deploy-plugin:2.8.2:deploy: > > java.lang.NoSuchMethodError: > > org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.getBufferCapacityForTransfer(J)I > > > > > > I have the feeling that there is a new dependency from pax-url / karaf > > maven plugin interfering with mvn-deploy? > > > > I will dig into this and report findings, if somebody has seen and > > solved this let me know. Thx > > > > Fabian > > > > -- > Jean-Baptiste Onofré > jbono...@apache.org > http://blog.nanthrax.net > Talend - http://www.talend.com
Problem deploying 4.2.3 custom distribution
Hi, did anyone come across this problem when deploying a 4.2.3 custom distribution? [ERROR] Failed to execute goal org.apache.maven.plugins:maven-deploy-plugin:2.8.2:deploy (default-deploy) on project karaf-assembly: Execution default-deploy of goal org.apache.maven.plugins:maven-deploy-plugin:2.8.2:deploy failed: An API incompatibility was encountered while executing org.apache.maven.plugins:maven-deploy-plugin:2.8.2:deploy: java.lang.NoSuchMethodError: org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.getBufferCapacityForTransfer(J)I I have the feeling that there is a new dependency from pax-url / karaf maven plugin interfering with mvn-deploy? I will dig into this and report findings, if somebody has seen and solved this let me know. Thx Fabian
Re: SCR Bundle refreshes Pax Logging?
Thats a pit, because it is the no longer under the control of a feature, and then version updates cause a new bundle rather than replace the old. Tricky. I will experiment some more, looking forward to a cleanup in pax logging! Thanks for all the interesting tips and tricks Fabian On Fri, Jan 18, 2019 at 1:49 PM Jean-Baptiste Onofré wrote: > > No in the case of pax-logging as it starts before the feature service > (iself in startup.properties). Featuresboot works fine for ActiveMQ for > instance. However, for the early staged bundles, you need to add in > etc/startup.properties (as said in my previous email: > > "In your case, just install commons-csv (via startup.properties for > instance)." > > Regards > JB > > On 18/01/2019 13:46, Fabian Lange wrote: > > It's not working as bootFeature, you mentioned that this should be possible > > JB. > > It looks like the bundle in startup.properties is started before > > bootFeatures is processed, and when thats done it refreshes the bundle > > nonetheless > > > > Fabian > > > > On Fri, Jan 18, 2019 at 1:23 PM Jean-Baptiste Onofré > > wrote: > >> > >> Yes, that's the purpose of custom distribution: install your > >> applications, and dependencies to avoid refresh. > >> > >> It's what I'm doing in my custom distro as well. > >> > >> Regards > >> JB > >> > >> On 18/01/2019 11:31, Fabian Lange wrote: > >>> featuresBoot doesnt seem to work, > >>> listing in etc/startup.properties does > >>> > >>> hooray, this saves me about 10% of native memory eaten up by the > >>> duplicate classloading. > >>> > >>> On Fri, Jan 18, 2019 at 10:33 AM Grzegorz Grzybek > >>> wrote: > >>>> > >>>> Hello > >>>> > >>>> having commons-csv in etc/startup.properties is the best (for now) way to > >>>> resolve this unnecessary refresh problem (I did it many times with JBoss > >>>> Fuse). > >>>> > >>>> For pax-logging fix, I've created > >>>> https://ops4j1.jira.com/browse/PAXLOGGING-248 to track it. > >>>> > >>>> regards > >>>> Grzegorz Grzybek > >>>> > >>>> pt., 18 sty 2019 o 06:19 Jean-Baptiste Onofré > >>>> napisał(a): > >>>> > >>>>> A simple hack is to actually install the bundle causing the refresh as > >>>>> boot feature or startup.properties. If the optional imports are already > >>>>> resolved/provided, the refresh won't happen. > >>>>> > >>>>> In your case, just install commons-csv (via startup.properties for > >>>>> instance). > >>>>> > >>>>> Regards > >>>>> JB > >>>>> > >>>>> On 17/01/2019 21:12, Fabian Lange wrote: > >>>>>> Is there a hack with which I can prevent the bundle from refreshing? I > >>>>>> can of course monkeypatch the manifest :) > >>>>>> > >>>>>> Fabian > >>>>>> > >>>>>> On Thu, Jan 17, 2019 at 9:06 PM Jean-Baptiste Onofré > >>>>>> > >>>>> wrote: > >>>>>>> > >>>>>>> Yes, the purpose was to support extra appenders easily. > >>>>>>> > >>>>>>> An alternative to optional import would be to use fragment but it's > >>>>>>> less > >>>>>>> flexible. A discover/locator service would be easier indeed. > >>>>>>> > >>>>>>> Regards > >>>>>>> JB > >>>>>>> > >>>>>>> On 17/01/2019 19:46, Grzegorz Grzybek wrote: > >>>>>>>> I understand. I don't remember (wasn't there when pax-logging was > >>>>> founded), > >>>>>>>> but it's about those exotic appenders you can use. > >>>>>>>> But in OSGi, it'd be probably better to rewrite/adjust the > >>>>>>>> discover/extensibility part in pax-logging-log4j2, to use our beloved > >>>>> TCCL > >>>>>>>> instead or kind of service discovery / locator. > >>>>>>>> > >>>>>>>> regards > >>>>>>>> Gr
Re: SCR Bundle refreshes Pax Logging?
It's not working as bootFeature, you mentioned that this should be possible JB. It looks like the bundle in startup.properties is started before bootFeatures is processed, and when thats done it refreshes the bundle nonetheless Fabian On Fri, Jan 18, 2019 at 1:23 PM Jean-Baptiste Onofré wrote: > > Yes, that's the purpose of custom distribution: install your > applications, and dependencies to avoid refresh. > > It's what I'm doing in my custom distro as well. > > Regards > JB > > On 18/01/2019 11:31, Fabian Lange wrote: > > featuresBoot doesnt seem to work, > > listing in etc/startup.properties does > > > > hooray, this saves me about 10% of native memory eaten up by the > > duplicate classloading. > > > > On Fri, Jan 18, 2019 at 10:33 AM Grzegorz Grzybek > > wrote: > >> > >> Hello > >> > >> having commons-csv in etc/startup.properties is the best (for now) way to > >> resolve this unnecessary refresh problem (I did it many times with JBoss > >> Fuse). > >> > >> For pax-logging fix, I've created > >> https://ops4j1.jira.com/browse/PAXLOGGING-248 to track it. > >> > >> regards > >> Grzegorz Grzybek > >> > >> pt., 18 sty 2019 o 06:19 Jean-Baptiste Onofré > >> napisał(a): > >> > >>> A simple hack is to actually install the bundle causing the refresh as > >>> boot feature or startup.properties. If the optional imports are already > >>> resolved/provided, the refresh won't happen. > >>> > >>> In your case, just install commons-csv (via startup.properties for > >>> instance). > >>> > >>> Regards > >>> JB > >>> > >>> On 17/01/2019 21:12, Fabian Lange wrote: > >>>> Is there a hack with which I can prevent the bundle from refreshing? I > >>>> can of course monkeypatch the manifest :) > >>>> > >>>> Fabian > >>>> > >>>> On Thu, Jan 17, 2019 at 9:06 PM Jean-Baptiste Onofré > >>> wrote: > >>>>> > >>>>> Yes, the purpose was to support extra appenders easily. > >>>>> > >>>>> An alternative to optional import would be to use fragment but it's less > >>>>> flexible. A discover/locator service would be easier indeed. > >>>>> > >>>>> Regards > >>>>> JB > >>>>> > >>>>> On 17/01/2019 19:46, Grzegorz Grzybek wrote: > >>>>>> I understand. I don't remember (wasn't there when pax-logging was > >>> founded), > >>>>>> but it's about those exotic appenders you can use. > >>>>>> But in OSGi, it'd be probably better to rewrite/adjust the > >>>>>> discover/extensibility part in pax-logging-log4j2, to use our beloved > >>> TCCL > >>>>>> instead or kind of service discovery / locator. > >>>>>> > >>>>>> regards > >>>>>> Grzegorz Grzybek > >>>>>> > >>>>>> czw., 17 sty 2019 o 19:37 Fabian Lange > >>> napisał(a): > >>>>>> > >>>>>>> I will have the same problem with jackson as well ;) > >>>>>>> > >>>>>>> pax-logging-log4j2 has really broad optional imports. probably for the > >>>>>>> other formatters that can be plugged. > >>>>>>> > >>>>>>> thats really inconvenient in my case :( > >>>>>>> > >>>>>>> Fabian > >>>>>>> > >>>>>>> On Thu, Jan 17, 2019 at 7:08 PM Jean-Baptiste Onofré > >>>>>>> >>>> > >>>>>>> wrote: > >>>>>>>> > >>>>>>>> Yeah, I don't remember why pax-logging-log4j2 has this import. > >>>>>>>> > >>>>>>>> Let me check where the package could be used. > >>>>>>>> > >>>>>>>> Regards > >>>>>>>> JB > >>>>>>>> > >>>>>>>> On 17/01/2019 18:42, Fabian Lange wrote: > >>>>>>>>> Well, that does look like a wrong dependency in pax-logging-log4j2, > >>>>>>> doesnt it? > >>>>>>>>&
Re: SCR Bundle refreshes Pax Logging?
featuresBoot doesnt seem to work, listing in etc/startup.properties does hooray, this saves me about 10% of native memory eaten up by the duplicate classloading. On Fri, Jan 18, 2019 at 10:33 AM Grzegorz Grzybek wrote: > > Hello > > having commons-csv in etc/startup.properties is the best (for now) way to > resolve this unnecessary refresh problem (I did it many times with JBoss > Fuse). > > For pax-logging fix, I've created > https://ops4j1.jira.com/browse/PAXLOGGING-248 to track it. > > regards > Grzegorz Grzybek > > pt., 18 sty 2019 o 06:19 Jean-Baptiste Onofré napisał(a): > > > A simple hack is to actually install the bundle causing the refresh as > > boot feature or startup.properties. If the optional imports are already > > resolved/provided, the refresh won't happen. > > > > In your case, just install commons-csv (via startup.properties for > > instance). > > > > Regards > > JB > > > > On 17/01/2019 21:12, Fabian Lange wrote: > > > Is there a hack with which I can prevent the bundle from refreshing? I > > > can of course monkeypatch the manifest :) > > > > > > Fabian > > > > > > On Thu, Jan 17, 2019 at 9:06 PM Jean-Baptiste Onofré > > wrote: > > >> > > >> Yes, the purpose was to support extra appenders easily. > > >> > > >> An alternative to optional import would be to use fragment but it's less > > >> flexible. A discover/locator service would be easier indeed. > > >> > > >> Regards > > >> JB > > >> > > >> On 17/01/2019 19:46, Grzegorz Grzybek wrote: > > >>> I understand. I don't remember (wasn't there when pax-logging was > > founded), > > >>> but it's about those exotic appenders you can use. > > >>> But in OSGi, it'd be probably better to rewrite/adjust the > > >>> discover/extensibility part in pax-logging-log4j2, to use our beloved > > TCCL > > >>> instead or kind of service discovery / locator. > > >>> > > >>> regards > > >>> Grzegorz Grzybek > > >>> > > >>> czw., 17 sty 2019 o 19:37 Fabian Lange > > napisał(a): > > >>> > > >>>> I will have the same problem with jackson as well ;) > > >>>> > > >>>> pax-logging-log4j2 has really broad optional imports. probably for the > > >>>> other formatters that can be plugged. > > >>>> > > >>>> thats really inconvenient in my case :( > > >>>> > > >>>> Fabian > > >>>> > > >>>> On Thu, Jan 17, 2019 at 7:08 PM Jean-Baptiste Onofré > > > > >>>> wrote: > > >>>>> > > >>>>> Yeah, I don't remember why pax-logging-log4j2 has this import. > > >>>>> > > >>>>> Let me check where the package could be used. > > >>>>> > > >>>>> Regards > > >>>>> JB > > >>>>> > > >>>>> On 17/01/2019 18:42, Fabian Lange wrote: > > >>>>>> Well, that does look like a wrong dependency in pax-logging-log4j2, > > >>>> doesnt it? > > >>>>>> or can a logic for that be found ;) > > >>>>>> > > >>>>>> Fabian > > >>>>>> > > >>>>>> On Thu, Jan 17, 2019 at 6:34 PM Grzegorz Grzybek < > > gr.grzy...@gmail.com> > > >>>> wrote: > > >>>>>>> > > >>>>>>> You don't have to find the source of WTF :) > > >>>>>>> > > >>>>>>> pax-logging-log4j2 has: Import-Package: > > >>>>>>> org.apache.commons.csv;resolution:=optional > > >>>>>>> > > >>>>>>> regards > > >>>>>>> Grzegorz Grzybek > > >>>>>>> > > >>>>>>> czw., 17 sty 2019 o 17:07 Fabian Lange > > >>>> napisał(a): > > >>>>>>> > > >>>>>>>> Hi, > > >>>>>>>> see its not a karaf problem. > > >>>>>>>> Grzegorz gave me really good hints off-list, and it turns out I do > > >>>>>>>> load a feature which contains this apache commons bundle: > > &
Re: SCR Bundle refreshes Pax Logging?
Is there a hack with which I can prevent the bundle from refreshing? I can of course monkeypatch the manifest :) Fabian On Thu, Jan 17, 2019 at 9:06 PM Jean-Baptiste Onofré wrote: > > Yes, the purpose was to support extra appenders easily. > > An alternative to optional import would be to use fragment but it's less > flexible. A discover/locator service would be easier indeed. > > Regards > JB > > On 17/01/2019 19:46, Grzegorz Grzybek wrote: > > I understand. I don't remember (wasn't there when pax-logging was founded), > > but it's about those exotic appenders you can use. > > But in OSGi, it'd be probably better to rewrite/adjust the > > discover/extensibility part in pax-logging-log4j2, to use our beloved TCCL > > instead or kind of service discovery / locator. > > > > regards > > Grzegorz Grzybek > > > > czw., 17 sty 2019 o 19:37 Fabian Lange napisał(a): > > > >> I will have the same problem with jackson as well ;) > >> > >> pax-logging-log4j2 has really broad optional imports. probably for the > >> other formatters that can be plugged. > >> > >> thats really inconvenient in my case :( > >> > >> Fabian > >> > >> On Thu, Jan 17, 2019 at 7:08 PM Jean-Baptiste Onofré > >> wrote: > >>> > >>> Yeah, I don't remember why pax-logging-log4j2 has this import. > >>> > >>> Let me check where the package could be used. > >>> > >>> Regards > >>> JB > >>> > >>> On 17/01/2019 18:42, Fabian Lange wrote: > >>>> Well, that does look like a wrong dependency in pax-logging-log4j2, > >> doesnt it? > >>>> or can a logic for that be found ;) > >>>> > >>>> Fabian > >>>> > >>>> On Thu, Jan 17, 2019 at 6:34 PM Grzegorz Grzybek > >> wrote: > >>>>> > >>>>> You don't have to find the source of WTF :) > >>>>> > >>>>> pax-logging-log4j2 has: Import-Package: > >>>>> org.apache.commons.csv;resolution:=optional > >>>>> > >>>>> regards > >>>>> Grzegorz Grzybek > >>>>> > >>>>> czw., 17 sty 2019 o 17:07 Fabian Lange > >> napisał(a): > >>>>> > >>>>>> Hi, > >>>>>> see its not a karaf problem. > >>>>>> Grzegorz gave me really good hints off-list, and it turns out I do > >>>>>> load a feature which contains this apache commons bundle: > >>>>>> > >>>>>> mvn:org.apache.commons/commons-csv/1.5 > >>>>>> > >>>>>> after I remove this bundle, the logging classes are no longer loaded > >> twice. > >>>>>> Now the next step is to find out WTF, but I leave that for another > >> day > >>>>>> > >>>>>> Fabian > >>>>>> > >>>>>> On Thu, Jan 17, 2019 at 3:49 PM Grzegorz Grzybek < > >> gr.grzy...@gmail.com> > >>>>>> wrote: > >>>>>>> > >>>>>>> Hello > >>>>>>> > >>>>>>> I suggest checking jansi - you have SL=8 for jansi bundle and SL=7 > >> for > >>>>>>> pax-logging-log4j2. > >>>>>>> > >>>>>>> pax-logging-log4j has optional import for org.fusesource.jansi - > >> and this > >>>>>>> may be the cause of refresh. > >>>>>>> > >>>>>>> In my custom distro, my etc/startup.properties has: > >>>>>>> > >>>>>>> mvn\:org.fusesource.jansi/jansi/1.17 = 8 > >>>>>>> mvn\:org.ops4j.pax.logging/pax-logging-api/1.10.1 = 8 > >>>>>>> mvn\:org.ops4j.pax.logging/pax-logging-log4j2/1.10.1 = 8 > >>>>>>> > >>>>>>> So I've already ensured that jansi starts/resolves before > >>>>>>> pax-logging-log4j2. > >>>>>>> > >>>>>>> I hope this helps. > >>>>>>> > >>>>>>> regards > >>>>>>> Grzegorz Grzybek > >>>>>>> > >>>>>>> czw., 17 sty 2019 o 15:15 Jean-Baptiste Onofré > >>>>>> napisał(a): > >>>>>&
Re: SCR Bundle refreshes Pax Logging?
I will have the same problem with jackson as well ;) pax-logging-log4j2 has really broad optional imports. probably for the other formatters that can be plugged. thats really inconvenient in my case :( Fabian On Thu, Jan 17, 2019 at 7:08 PM Jean-Baptiste Onofré wrote: > > Yeah, I don't remember why pax-logging-log4j2 has this import. > > Let me check where the package could be used. > > Regards > JB > > On 17/01/2019 18:42, Fabian Lange wrote: > > Well, that does look like a wrong dependency in pax-logging-log4j2, doesnt > > it? > > or can a logic for that be found ;) > > > > Fabian > > > > On Thu, Jan 17, 2019 at 6:34 PM Grzegorz Grzybek > > wrote: > >> > >> You don't have to find the source of WTF :) > >> > >> pax-logging-log4j2 has: Import-Package: > >> org.apache.commons.csv;resolution:=optional > >> > >> regards > >> Grzegorz Grzybek > >> > >> czw., 17 sty 2019 o 17:07 Fabian Lange napisał(a): > >> > >>> Hi, > >>> see its not a karaf problem. > >>> Grzegorz gave me really good hints off-list, and it turns out I do > >>> load a feature which contains this apache commons bundle: > >>> > >>> mvn:org.apache.commons/commons-csv/1.5 > >>> > >>> after I remove this bundle, the logging classes are no longer loaded > >>> twice. > >>> Now the next step is to find out WTF, but I leave that for another day > >>> > >>> Fabian > >>> > >>> On Thu, Jan 17, 2019 at 3:49 PM Grzegorz Grzybek > >>> wrote: > >>>> > >>>> Hello > >>>> > >>>> I suggest checking jansi - you have SL=8 for jansi bundle and SL=7 for > >>>> pax-logging-log4j2. > >>>> > >>>> pax-logging-log4j has optional import for org.fusesource.jansi - and this > >>>> may be the cause of refresh. > >>>> > >>>> In my custom distro, my etc/startup.properties has: > >>>> > >>>> mvn\:org.fusesource.jansi/jansi/1.17 = 8 > >>>> mvn\:org.ops4j.pax.logging/pax-logging-api/1.10.1 = 8 > >>>> mvn\:org.ops4j.pax.logging/pax-logging-log4j2/1.10.1 = 8 > >>>> > >>>> So I've already ensured that jansi starts/resolves before > >>>> pax-logging-log4j2. > >>>> > >>>> I hope this helps. > >>>> > >>>> regards > >>>> Grzegorz Grzybek > >>>> > >>>> czw., 17 sty 2019 o 15:15 Jean-Baptiste Onofré > >>> napisał(a): > >>>> > >>>>> Not a problem, Jira should be used when we "suspect" something. I think > >>>>> it's good for the tracking and also for the history of faced problems. > >>>>> > >>>>> Just my €0.01 ;) > >>>>> > >>>>> Regards > >>>>> JB > >>>>> > >>>>> On 17/01/2019 15:12, Fabian Lange wrote: > >>>>>> I already feel bad for asking such wide questions here. I usually > >>> only > >>>>>> file tickets once I kind-of know whats going on. > >>>>>> Could be a Felix or SCR issue as well ;) > >>>>>> > >>>>>> Fabian > >>>>>> > >>>>>> On Thu, Jan 17, 2019 at 3:10 PM Jean-Baptiste Onofré < > >>> j...@nanthrax.net> > >>>>> wrote: > >>>>>>> > >>>>>>> Hi Fabian, > >>>>>>> > >>>>>>> did you create a Jira about that ? It's for the tracking as I'm > >>>>>>> preparing Karaf 4.2.3 ;) > >>>>>>> > >>>>>>> Thanks ! > >>>>>>> Regards > >>>>>>> JB > >>>>>>> > >>>>>>> On 17/01/2019 15:08, Fabian Lange wrote: > >>>>>>>> Quick update, this apparently is still the case with Karaf 4.2.2 > >>>>>>>> > >>>>>>>> Would appreciate if somebody knows a workaround. I am able to play > >>>>>>>> around with startlevels, but I cant seem to avoid this. > >>>>>>>> > >>>>>>>> Fabian > >>>>>>>> > >>>>>>>> On Mon, Nov 2
Re: SCR Bundle refreshes Pax Logging?
Well, that does look like a wrong dependency in pax-logging-log4j2, doesnt it? or can a logic for that be found ;) Fabian On Thu, Jan 17, 2019 at 6:34 PM Grzegorz Grzybek wrote: > > You don't have to find the source of WTF :) > > pax-logging-log4j2 has: Import-Package: > org.apache.commons.csv;resolution:=optional > > regards > Grzegorz Grzybek > > czw., 17 sty 2019 o 17:07 Fabian Lange napisał(a): > > > Hi, > > see its not a karaf problem. > > Grzegorz gave me really good hints off-list, and it turns out I do > > load a feature which contains this apache commons bundle: > > > > mvn:org.apache.commons/commons-csv/1.5 > > > > after I remove this bundle, the logging classes are no longer loaded twice. > > Now the next step is to find out WTF, but I leave that for another day > > > > Fabian > > > > On Thu, Jan 17, 2019 at 3:49 PM Grzegorz Grzybek > > wrote: > > > > > > Hello > > > > > > I suggest checking jansi - you have SL=8 for jansi bundle and SL=7 for > > > pax-logging-log4j2. > > > > > > pax-logging-log4j has optional import for org.fusesource.jansi - and this > > > may be the cause of refresh. > > > > > > In my custom distro, my etc/startup.properties has: > > > > > > mvn\:org.fusesource.jansi/jansi/1.17 = 8 > > > mvn\:org.ops4j.pax.logging/pax-logging-api/1.10.1 = 8 > > > mvn\:org.ops4j.pax.logging/pax-logging-log4j2/1.10.1 = 8 > > > > > > So I've already ensured that jansi starts/resolves before > > > pax-logging-log4j2. > > > > > > I hope this helps. > > > > > > regards > > > Grzegorz Grzybek > > > > > > czw., 17 sty 2019 o 15:15 Jean-Baptiste Onofré > > napisał(a): > > > > > > > Not a problem, Jira should be used when we "suspect" something. I think > > > > it's good for the tracking and also for the history of faced problems. > > > > > > > > Just my €0.01 ;) > > > > > > > > Regards > > > > JB > > > > > > > > On 17/01/2019 15:12, Fabian Lange wrote: > > > > > I already feel bad for asking such wide questions here. I usually > > only > > > > > file tickets once I kind-of know whats going on. > > > > > Could be a Felix or SCR issue as well ;) > > > > > > > > > > Fabian > > > > > > > > > > On Thu, Jan 17, 2019 at 3:10 PM Jean-Baptiste Onofré < > > j...@nanthrax.net> > > > > wrote: > > > > >> > > > > >> Hi Fabian, > > > > >> > > > > >> did you create a Jira about that ? It's for the tracking as I'm > > > > >> preparing Karaf 4.2.3 ;) > > > > >> > > > > >> Thanks ! > > > > >> Regards > > > > >> JB > > > > >> > > > > >> On 17/01/2019 15:08, Fabian Lange wrote: > > > > >>> Quick update, this apparently is still the case with Karaf 4.2.2 > > > > >>> > > > > >>> Would appreciate if somebody knows a workaround. I am able to play > > > > >>> around with startlevels, but I cant seem to avoid this. > > > > >>> > > > > >>> Fabian > > > > >>> > > > > >>> On Mon, Nov 26, 2018 at 1:21 AM Fabian Lange < > > lange.fab...@gmail.com> > > > > wrote: > > > > >>>> > > > > >>>> Hi, > > > > >>>> currently debugging an issue. Maybe the bits I came up so far are > > > > >>>> already sufficient for you guys to fix it, or you help me how to > > debug > > > > >>>> this better. > > > > >>>> In our distribution, we have these features > > > > >>>> > > > > >>>> 0 │ Active │ 0 │ 5.6.10 │ System Bundle, Fragments: 1 > > > > >>>> 1 │ Resolved │ 1 │ 4.2.1│ Apache Karaf :: Features :: > > > > >>>> Extension, Hosts: 0 > > > > >>>> 2 │ Active │ 5 │ 2.5.4│ OPS4J Pax Url - aether: > > > > >>>> 3 │ Active │ 7 │ 1.10.1 │ OPS4J Pax Logging - Log4j v2 > > > > >>>> 4 │ Active │ 7 │ 1.10.1 │ OPS4J Pax Logging - API > > > > >>>> 5 │ Act
Re: SCR Bundle refreshes Pax Logging?
Hi, see its not a karaf problem. Grzegorz gave me really good hints off-list, and it turns out I do load a feature which contains this apache commons bundle: mvn:org.apache.commons/commons-csv/1.5 after I remove this bundle, the logging classes are no longer loaded twice. Now the next step is to find out WTF, but I leave that for another day Fabian On Thu, Jan 17, 2019 at 3:49 PM Grzegorz Grzybek wrote: > > Hello > > I suggest checking jansi - you have SL=8 for jansi bundle and SL=7 for > pax-logging-log4j2. > > pax-logging-log4j has optional import for org.fusesource.jansi - and this > may be the cause of refresh. > > In my custom distro, my etc/startup.properties has: > > mvn\:org.fusesource.jansi/jansi/1.17 = 8 > mvn\:org.ops4j.pax.logging/pax-logging-api/1.10.1 = 8 > mvn\:org.ops4j.pax.logging/pax-logging-log4j2/1.10.1 = 8 > > So I've already ensured that jansi starts/resolves before > pax-logging-log4j2. > > I hope this helps. > > regards > Grzegorz Grzybek > > czw., 17 sty 2019 o 15:15 Jean-Baptiste Onofré napisał(a): > > > Not a problem, Jira should be used when we "suspect" something. I think > > it's good for the tracking and also for the history of faced problems. > > > > Just my €0.01 ;) > > > > Regards > > JB > > > > On 17/01/2019 15:12, Fabian Lange wrote: > > > I already feel bad for asking such wide questions here. I usually only > > > file tickets once I kind-of know whats going on. > > > Could be a Felix or SCR issue as well ;) > > > > > > Fabian > > > > > > On Thu, Jan 17, 2019 at 3:10 PM Jean-Baptiste Onofré > > wrote: > > >> > > >> Hi Fabian, > > >> > > >> did you create a Jira about that ? It's for the tracking as I'm > > >> preparing Karaf 4.2.3 ;) > > >> > > >> Thanks ! > > >> Regards > > >> JB > > >> > > >> On 17/01/2019 15:08, Fabian Lange wrote: > > >>> Quick update, this apparently is still the case with Karaf 4.2.2 > > >>> > > >>> Would appreciate if somebody knows a workaround. I am able to play > > >>> around with startlevels, but I cant seem to avoid this. > > >>> > > >>> Fabian > > >>> > > >>> On Mon, Nov 26, 2018 at 1:21 AM Fabian Lange > > wrote: > > >>>> > > >>>> Hi, > > >>>> currently debugging an issue. Maybe the bits I came up so far are > > >>>> already sufficient for you guys to fix it, or you help me how to debug > > >>>> this better. > > >>>> In our distribution, we have these features > > >>>> > > >>>> 0 │ Active │ 0 │ 5.6.10 │ System Bundle, Fragments: 1 > > >>>> 1 │ Resolved │ 1 │ 4.2.1│ Apache Karaf :: Features :: > > >>>> Extension, Hosts: 0 > > >>>> 2 │ Active │ 5 │ 2.5.4│ OPS4J Pax Url - aether: > > >>>> 3 │ Active │ 7 │ 1.10.1 │ OPS4J Pax Logging - Log4j v2 > > >>>> 4 │ Active │ 7 │ 1.10.1 │ OPS4J Pax Logging - API > > >>>> 5 │ Active │ 8 │ 1.17.1 │ jansi > > >>>> 6 │ Active │ 9 │ 1.0.2│ Apache Felix Coordinator Service > > >>>> 7 │ Active │ 10 │ 1.9.4│ Apache Felix Configuration > > Admin Service > > >>>> 8 │ Active │ 11 │ 3.6.4│ Apache Felix File Install > > >>>> 9 │ Active │ 15 │ 4.2.1│ Apache Karaf :: Features :: Core > > >>>> 10 │ Active │ 20 │ 2.2.11.1 │ Apache ServiceMix :: Bundles :: > > jaxb-impl > > >>>> 11 │ Active │ 30 │ 1.2.0│ Apache Felix Metatype Service > > >>>> 12 │ Active │ 30 │ 2.1.2│ Apache Felix Declarative > > Services > > >>>> 13 │ Active │ 30 │ 4.2.1│ Apache Karaf :: Bundle :: Core > > >>>> 14 │ Active │ 30 │ 4.2.1│ Apache Karaf :: ConfigAdmin :: > > Core > > >>>> 15 │ Active │ 30 │ 4.2.1│ Apache Karaf :: Features :: > > Command > > >>>> 16 │ Active │ 30 │ 4.2.1│ Apache Karaf :: Log :: Core > > >>>> 17 │ Active │ 30 │ 4.2.1│ Apache Karaf :: SCR :: Bundle > > State > > >>>> 18 │ Active │ 30 │ 4.2.1│ Apache Karaf :: Service :: Core > > >>>> 19 │ Active │ 30 │ 4.2.1│ Apa
Re: SCR Bundle refreshes Pax Logging?
I already feel bad for asking such wide questions here. I usually only file tickets once I kind-of know whats going on. Could be a Felix or SCR issue as well ;) Fabian On Thu, Jan 17, 2019 at 3:10 PM Jean-Baptiste Onofré wrote: > > Hi Fabian, > > did you create a Jira about that ? It's for the tracking as I'm > preparing Karaf 4.2.3 ;) > > Thanks ! > Regards > JB > > On 17/01/2019 15:08, Fabian Lange wrote: > > Quick update, this apparently is still the case with Karaf 4.2.2 > > > > Would appreciate if somebody knows a workaround. I am able to play > > around with startlevels, but I cant seem to avoid this. > > > > Fabian > > > > On Mon, Nov 26, 2018 at 1:21 AM Fabian Lange wrote: > >> > >> Hi, > >> currently debugging an issue. Maybe the bits I came up so far are > >> already sufficient for you guys to fix it, or you help me how to debug > >> this better. > >> In our distribution, we have these features > >> > >> 0 │ Active │ 0 │ 5.6.10 │ System Bundle, Fragments: 1 > >> 1 │ Resolved │ 1 │ 4.2.1│ Apache Karaf :: Features :: > >> Extension, Hosts: 0 > >> 2 │ Active │ 5 │ 2.5.4│ OPS4J Pax Url - aether: > >> 3 │ Active │ 7 │ 1.10.1 │ OPS4J Pax Logging - Log4j v2 > >> 4 │ Active │ 7 │ 1.10.1 │ OPS4J Pax Logging - API > >> 5 │ Active │ 8 │ 1.17.1 │ jansi > >> 6 │ Active │ 9 │ 1.0.2│ Apache Felix Coordinator Service > >> 7 │ Active │ 10 │ 1.9.4│ Apache Felix Configuration Admin > >> Service > >> 8 │ Active │ 11 │ 3.6.4│ Apache Felix File Install > >> 9 │ Active │ 15 │ 4.2.1│ Apache Karaf :: Features :: Core > >> 10 │ Active │ 20 │ 2.2.11.1 │ Apache ServiceMix :: Bundles :: > >> jaxb-impl > >> 11 │ Active │ 30 │ 1.2.0│ Apache Felix Metatype Service > >> 12 │ Active │ 30 │ 2.1.2│ Apache Felix Declarative Services > >> 13 │ Active │ 30 │ 4.2.1│ Apache Karaf :: Bundle :: Core > >> 14 │ Active │ 30 │ 4.2.1│ Apache Karaf :: ConfigAdmin :: Core > >> 15 │ Active │ 30 │ 4.2.1│ Apache Karaf :: Features :: Command > >> 16 │ Active │ 30 │ 4.2.1│ Apache Karaf :: Log :: Core > >> 17 │ Active │ 30 │ 4.2.1│ Apache Karaf :: SCR :: Bundle State > >> 18 │ Active │ 30 │ 4.2.1│ Apache Karaf :: Service :: Core > >> 19 │ Active │ 30 │ 4.2.1│ Apache Karaf :: Shell :: Various > >> Commands > >> 20 │ Active │ 30 │ 4.2.1│ Apache Karaf :: Shell :: Core > >> 21 │ Active │ 30 │ 4.2.1│ Apache Karaf :: System :: Core > >> 22 │ Active │ 30 │ 3.9.0│ JLine Builtins > >> 23 │ Active │ 30 │ 3.9.0│ JLine Reader > >> 24 │ Active │ 30 │ 3.9.0│ JLine Terminal, Fragments: 25 > >> 25 │ Resolved │ 30 │ 3.9.0│ JLine JANSI Terminal, Hosts: 24 > >> > >> What I noticed is that A LOT of apache LOG4J classes are loaded twice > >> in the JVM. > >> I turned on -verbose:class and saw this snippet: > >> > >> [5.580s][info][class,load] > >> org.apache.felix.scr.impl.logger.StdOutLogger source: > >> jar:bundle://12.0:0/!/ > >> [5.626s][info][class,load] > >> org.apache.felix.framework.util.ImmutableMap$1 source: > >> file:/Users/fabian/work/karaf-dist/system/org/apache/felix/org.apache.felix.framework/5.6.10/org.apache.felix.framework-5.6.10.jar > >> [5.834s][info][class,load] > >> org.apache.karaf.features.internal.service.BundleInstallSupportImpl$$Lambda$412/0x0007fecd0c40 > >> source: org.apache.karaf.features.internal.service.BundleInstallSupportImpl > >> [5.834s][info][class,load] > >> org.apache.felix.framework.Felix$RefreshHelper source: > >> file:/Users/fabian/work/karaf-dist/system/org/apache/felix/org.apache.felix.framework/5.6.10/org.apache.felix.framework-5.6.10.jar > >> [5.970s][info][class,load] > >> org.ops4j.pax.logging.log4j2.internal.Activator source: > >> jar:bundle://3.0:0/!/ > >> > >> So here is my suspicion: Whatever SCR does, it causes the Log4j2 > >> bundle to reload all classes and activate again. This leads to all > >> bundles before the SCR to reference the first loaded log4j classes, > >> and all afterwards the refreshed bundle. > >> > >> Can we prevent this somehow? Also curiously SCR uses its StdOutLogger, > >> which it shouldnt do. > >> Is this reload caused by the Service Tracker > >> org.apache.felix.scr.impl.logger.LogServiceEnabledLogger uses? > >> > >> Ideas, suggestions how to prevent this refresh? I played with the load > >> order but it does not seem possible to get it right > >> > >> Fabian > > -- > Jean-Baptiste Onofré > jbono...@apache.org > http://blog.nanthrax.net > Talend - http://www.talend.com
Re: SCR Bundle refreshes Pax Logging?
Quick update, this apparently is still the case with Karaf 4.2.2 Would appreciate if somebody knows a workaround. I am able to play around with startlevels, but I cant seem to avoid this. Fabian On Mon, Nov 26, 2018 at 1:21 AM Fabian Lange wrote: > > Hi, > currently debugging an issue. Maybe the bits I came up so far are > already sufficient for you guys to fix it, or you help me how to debug > this better. > In our distribution, we have these features > > 0 │ Active │ 0 │ 5.6.10 │ System Bundle, Fragments: 1 > 1 │ Resolved │ 1 │ 4.2.1│ Apache Karaf :: Features :: > Extension, Hosts: 0 > 2 │ Active │ 5 │ 2.5.4│ OPS4J Pax Url - aether: > 3 │ Active │ 7 │ 1.10.1 │ OPS4J Pax Logging - Log4j v2 > 4 │ Active │ 7 │ 1.10.1 │ OPS4J Pax Logging - API > 5 │ Active │ 8 │ 1.17.1 │ jansi > 6 │ Active │ 9 │ 1.0.2│ Apache Felix Coordinator Service > 7 │ Active │ 10 │ 1.9.4│ Apache Felix Configuration Admin Service > 8 │ Active │ 11 │ 3.6.4│ Apache Felix File Install > 9 │ Active │ 15 │ 4.2.1│ Apache Karaf :: Features :: Core > 10 │ Active │ 20 │ 2.2.11.1 │ Apache ServiceMix :: Bundles :: > jaxb-impl > 11 │ Active │ 30 │ 1.2.0│ Apache Felix Metatype Service > 12 │ Active │ 30 │ 2.1.2│ Apache Felix Declarative Services > 13 │ Active │ 30 │ 4.2.1│ Apache Karaf :: Bundle :: Core > 14 │ Active │ 30 │ 4.2.1│ Apache Karaf :: ConfigAdmin :: Core > 15 │ Active │ 30 │ 4.2.1│ Apache Karaf :: Features :: Command > 16 │ Active │ 30 │ 4.2.1│ Apache Karaf :: Log :: Core > 17 │ Active │ 30 │ 4.2.1│ Apache Karaf :: SCR :: Bundle State > 18 │ Active │ 30 │ 4.2.1│ Apache Karaf :: Service :: Core > 19 │ Active │ 30 │ 4.2.1│ Apache Karaf :: Shell :: Various > Commands > 20 │ Active │ 30 │ 4.2.1│ Apache Karaf :: Shell :: Core > 21 │ Active │ 30 │ 4.2.1│ Apache Karaf :: System :: Core > 22 │ Active │ 30 │ 3.9.0│ JLine Builtins > 23 │ Active │ 30 │ 3.9.0│ JLine Reader > 24 │ Active │ 30 │ 3.9.0│ JLine Terminal, Fragments: 25 > 25 │ Resolved │ 30 │ 3.9.0│ JLine JANSI Terminal, Hosts: 24 > > What I noticed is that A LOT of apache LOG4J classes are loaded twice > in the JVM. > I turned on -verbose:class and saw this snippet: > > [5.580s][info][class,load] > org.apache.felix.scr.impl.logger.StdOutLogger source: > jar:bundle://12.0:0/!/ > [5.626s][info][class,load] > org.apache.felix.framework.util.ImmutableMap$1 source: > file:/Users/fabian/work/karaf-dist/system/org/apache/felix/org.apache.felix.framework/5.6.10/org.apache.felix.framework-5.6.10.jar > [5.834s][info][class,load] > org.apache.karaf.features.internal.service.BundleInstallSupportImpl$$Lambda$412/0x0007fecd0c40 > source: org.apache.karaf.features.internal.service.BundleInstallSupportImpl > [5.834s][info][class,load] > org.apache.felix.framework.Felix$RefreshHelper source: > file:/Users/fabian/work/karaf-dist/system/org/apache/felix/org.apache.felix.framework/5.6.10/org.apache.felix.framework-5.6.10.jar > [5.970s][info][class,load] > org.ops4j.pax.logging.log4j2.internal.Activator source: > jar:bundle://3.0:0/!/ > > So here is my suspicion: Whatever SCR does, it causes the Log4j2 > bundle to reload all classes and activate again. This leads to all > bundles before the SCR to reference the first loaded log4j classes, > and all afterwards the refreshed bundle. > > Can we prevent this somehow? Also curiously SCR uses its StdOutLogger, > which it shouldnt do. > Is this reload caused by the Service Tracker > org.apache.felix.scr.impl.logger.LogServiceEnabledLogger uses? > > Ideas, suggestions how to prevent this refresh? I played with the load > order but it does not seem possible to get it right > > Fabian
Re: [VOTE] Apache Karaf (runtime) 4.2.2 release
The inc script defaults it now. Maybe the java code should do that for BC Fabian On Mon, Dec 17, 2018 at 2:50 PM Jean-Baptiste Onofré wrote: > > That's because KARAF_LOG env variable is not set. > > I don't think it's a blocker, I will do a full pass. > > Regards > JB > > > On 17/12/2018 13:54, Freeman Fang wrote: > > Yep, I also see this > > java.io.FileNotFoundException: /karaf.log (Permission denied) > > > > when I test Karaf 4.2.2 candidate in CXF. > > － > > Freeman(Yue) Fang > > > > Red Hat, Inc. > > > > > > > > > > > >> On Dec 17, 2018, at 8:38 PM, Oliver Lietz wrote: > >> > >> On Sunday 16 December 2018 11:11:06 Jean-Baptiste Onofré wrote: > >>> Hi all, > >> > >> Hi, > >> > >>> 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&proj > >>> ectId=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. > >> > >> I see several issues in Karaf build and Sling/Karaf ITs. > >> > >> Karaf build: > >> > >> [INFO] Results: > >> [INFO] > >> [ERROR] Errors: > >> [ERROR] JmsTest.testCommands » NotBound > >> ef29bfce-4ace-4ea4-8529-9b0255ab485c > >> [ERROR] JmsTest.testMBean » NotBound 94e3f2b8-8ba2-45c1-92d3-9ec1f7933258 > >> [ERROR] ServletExampleTest.testWithAnnotation:76->verify:49 » Connect > >> Connection refus... > >> [INFO] > >> [ERROR] Tests run: 265, Failures: 0, Errors: 3, Skipped: 5 > >> [INFO] > >> [INFO] > >> > >> [INFO] Reactor Summary for Apache Karaf 4.2.2: > >> > >> Sling/Karaf ITs: > >> > >> java.lang.RuntimeException: /karaf.log (Permission denied) > >>at > >> org.apache.karaf.main.util.BootstrapLogManager.getDefaultHandlerInternal(BootstrapLogManager.java:102) > >>at > >> org.apache.karaf.main.util.BootstrapLogManager.getDefaultHandlersInternal(BootstrapLogManager.java:137) > >>at > >> org.apache.karaf.main.util.BootstrapLogManager.getDefaultHandlers(BootstrapLogManager.java:70) > >>at > >> org.apache.karaf.main.util.BootstrapLogManager.configureLogger(BootstrapLogManager.java:75) > >>at org.apache.karaf.main.Main.launch(Main.java:244) > >>at org.apache.karaf.main.Main.main(Main.java:178) > >> Caused by: java.io.FileNotFoundException: /karaf.log (Permission denied) > >>at java.io.FileOutputStream.open0(Native Method) > >>at java.io.FileOutputStream.open(FileOutputStream.java:270) > >>at java.io.FileOutputStream.(FileOutputStream.java:213) > >>at > >> org.apache.karaf.main.util.BootstrapLogManager$SimpleFileHandler.open(BootstrapLogManager.java:193) > >>at > >> org.apache.karaf.main.util.BootstrapLogManager$SimpleFileHandler.(BootstrapLogManager.java:182) > >>at > >> org.apache.karaf.main.util.BootstrapLogManager.getDefaultHandlerInternal(BootstrapLogManager.java:100) > >>... 5 more > >> java.lang.RuntimeException: /karaf.log (Permission denied) > >>at > >> org.apache.karaf.main.util.BootstrapLogManager.getDefaultHandlerInternal(BootstrapLogManager.java:102) > >>at > >> org.apache.karaf.main.util.BootstrapLogManager.getDefaultHandlersInternal(BootstrapLogManager.java:137) > >>at > >> org.apache.karaf.main.util.BootstrapLogManager.getDefaultHandlers(BootstrapLogManager.java:70) > >>at > >> org.apache.karaf.main.util.BootstrapLogManager.configureLogger(BootstrapLogManager.java:75) > >>at > >> org.apache.karaf.main.KarafActivatorManager.(KarafActivatorManager.java:48) > >>at org.apache.karaf.main.Main.launch(Main.java:280) > >>at org.apache.karaf.main.Main.main(Main.java:178) > >> Caused by: java.io.FileNotFoundException: /karaf.log (Permission denied) > >>at java.io.FileOutputStream.open0(Native Method) > >>at java.io.FileOutputStream.open(FileOutputStream.java:270) > >>at java.io.FileOutputStream.(FileOutputStream.java:213) > >>at > >> org.apache.karaf.main.util.BootstrapLogManager$SimpleFileHandler.open(BootstrapLogManager.java:193) > >>at > >> org.apache.karaf.main.util.BootstrapLogManager$SimpleFileHandler.(BootstrapLogManager.java:182) > >>at > >> org.apache.karaf.main.util.BootstrapLogManager.getDefaultHandlerInternal(BootstrapLogManager.java:100) > >>... 6 more > >> java.lang.RuntimeException: /karaf.log (Permission denied) > >>at > >> org.apache.karaf.main.util.BootstrapLogManager.getDefaultHandlerInternal(BootstrapLogManager.java:102) > >>at > >> org.apache.karaf.main.util.Boots
Re: [VOTE] Apache Karaf (runtime) 4.2.2 release
My dist upgrade tests passed too +1 (non-binding) Fabian On Mon, Dec 17, 2018 at 10:51 AM Roedl Lukas wrote: > > +1 (non-binding) > > regards, > Lukas > > -Ursprüngliche Nachricht- > Von: Jean-Baptiste Onofré > Gesendet: Sonntag, 16. Dezember 2018 11:11 > An: Karaf Dev > Betreff: [VOTE] Apache Karaf (runtime) 4.2.2 release > > 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&projectId=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
SCR Bundle refreshes Pax Logging?
Hi, currently debugging an issue. Maybe the bits I came up so far are already sufficient for you guys to fix it, or you help me how to debug this better. In our distribution, we have these features 0 │ Active │ 0 │ 5.6.10 │ System Bundle, Fragments: 1 1 │ Resolved │ 1 │ 4.2.1│ Apache Karaf :: Features :: Extension, Hosts: 0 2 │ Active │ 5 │ 2.5.4│ OPS4J Pax Url - aether: 3 │ Active │ 7 │ 1.10.1 │ OPS4J Pax Logging - Log4j v2 4 │ Active │ 7 │ 1.10.1 │ OPS4J Pax Logging - API 5 │ Active │ 8 │ 1.17.1 │ jansi 6 │ Active │ 9 │ 1.0.2│ Apache Felix Coordinator Service 7 │ Active │ 10 │ 1.9.4│ Apache Felix Configuration Admin Service 8 │ Active │ 11 │ 3.6.4│ Apache Felix File Install 9 │ Active │ 15 │ 4.2.1│ Apache Karaf :: Features :: Core 10 │ Active │ 20 │ 2.2.11.1 │ Apache ServiceMix :: Bundles :: jaxb-impl 11 │ Active │ 30 │ 1.2.0│ Apache Felix Metatype Service 12 │ Active │ 30 │ 2.1.2│ Apache Felix Declarative Services 13 │ Active │ 30 │ 4.2.1│ Apache Karaf :: Bundle :: Core 14 │ Active │ 30 │ 4.2.1│ Apache Karaf :: ConfigAdmin :: Core 15 │ Active │ 30 │ 4.2.1│ Apache Karaf :: Features :: Command 16 │ Active │ 30 │ 4.2.1│ Apache Karaf :: Log :: Core 17 │ Active │ 30 │ 4.2.1│ Apache Karaf :: SCR :: Bundle State 18 │ Active │ 30 │ 4.2.1│ Apache Karaf :: Service :: Core 19 │ Active │ 30 │ 4.2.1│ Apache Karaf :: Shell :: Various Commands 20 │ Active │ 30 │ 4.2.1│ Apache Karaf :: Shell :: Core 21 │ Active │ 30 │ 4.2.1│ Apache Karaf :: System :: Core 22 │ Active │ 30 │ 3.9.0│ JLine Builtins 23 │ Active │ 30 │ 3.9.0│ JLine Reader 24 │ Active │ 30 │ 3.9.0│ JLine Terminal, Fragments: 25 25 │ Resolved │ 30 │ 3.9.0│ JLine JANSI Terminal, Hosts: 24 What I noticed is that A LOT of apache LOG4J classes are loaded twice in the JVM. I turned on -verbose:class and saw this snippet: [5.580s][info][class,load] org.apache.felix.scr.impl.logger.StdOutLogger source: jar:bundle://12.0:0/!/ [5.626s][info][class,load] org.apache.felix.framework.util.ImmutableMap$1 source: file:/Users/fabian/work/karaf-dist/system/org/apache/felix/org.apache.felix.framework/5.6.10/org.apache.felix.framework-5.6.10.jar [5.834s][info][class,load] org.apache.karaf.features.internal.service.BundleInstallSupportImpl$$Lambda$412/0x0007fecd0c40 source: org.apache.karaf.features.internal.service.BundleInstallSupportImpl [5.834s][info][class,load] org.apache.felix.framework.Felix$RefreshHelper source: file:/Users/fabian/work/karaf-dist/system/org/apache/felix/org.apache.felix.framework/5.6.10/org.apache.felix.framework-5.6.10.jar [5.970s][info][class,load] org.ops4j.pax.logging.log4j2.internal.Activator source: jar:bundle://3.0:0/!/ So here is my suspicion: Whatever SCR does, it causes the Log4j2 bundle to reload all classes and activate again. This leads to all bundles before the SCR to reference the first loaded log4j classes, and all afterwards the refreshed bundle. Can we prevent this somehow? Also curiously SCR uses its StdOutLogger, which it shouldnt do. Is this reload caused by the Service Tracker org.apache.felix.scr.impl.logger.LogServiceEnabledLogger uses? Ideas, suggestions how to prevent this refresh? I played with the load order but it does not seem possible to get it right Fabian
Re: [VOTE] Apache Karaf "Container" 4.2.1 release
(Sorry for this mail not being threaded. I messed up my dev subscription and now gmail wont make it threaded) I hereby vote on the 4.2.1 Karaf Container release: +1 (non-binding) We built our custom distribution and tested it on linux and windows. start script fixes for solaris had been backported by us earlier and are working fine. The only thing I am not too excited about is an additional 4MB in download size. That is due to the need of jaxb for features parsing. And for improved Java 9 / 10 compatibility we added servicemix jaxb implementation and api. Fabian
Re: Java 9 work
http://central.maven.org/maven2/org/ow2/asm/asm/6.0/asm-6.0.jar Sent from my iPhone > On 3. Oct 2017, at 23:12, Jean-Baptiste Onofré wrote: > > That's not central, right ? > > Regards > JB > >> On Oct 4, 2017, 08:08, at 08:08, Fabian Lange >> wrote: >> https://mvnrepository.com/artifact/org.ow2.asm/asm/6.0 >> >> Sent from my iPhone >> >>> On 3. Oct 2017, at 22:08, Jean-Baptiste Onofré >> wrote: >>> >>> Hi, >>> >>> there's no GA on Central, only 6.0 ALPHA and 6.0 BETA. >>> >>> Regards >>> JB >>> >>>> On 10/03/2017 05:51 PM, Fabian Lange wrote: >>>> Its actually on central >>>> Fabian >>>> Sent from my iPhone >>>>> On 3. Oct 2017, at 08:47, Guillaume Nodet >> wrote: >>>>> >>>>> Good catch, I only looked on maven central... >>>>> I guess we need to ask for an upload there... Wanna take care of it >> ? >>>>> >>>>> Guillaume >>>>> >>>>> 2017-10-03 17:13 GMT+02:00 Fabian Lange >> : >>>>> >>>>>> Asm 6 is GA now >>>>>> Fabiann >>>>>> >>>>>> Sent from my iPhone >>>>>> >>>>>>> On 3. Oct 2017, at 08:06, Guillaume Nodet >> wrote: >>>>>>> >>>>>>> 2017-10-03 16:23 GMT+02:00 Fabian Lange >> : >>>>>>> >>>>>>>> Hi Guys, >>>>>>>> whats our plan to support Java 9? >>>>>>>> >>>>>>>> Will that be karaf 4.2 >>>>>>>> 5.0 >>>>>>>> or even 4.1/4.0 backports? >>>>>>>> >>>>>>> >>>>>>> I'd say 4.3 >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> The only real task is writing proper module-info files which >> should be >>>>>> easy >>>>>>>> for anything osgi. >>>>>>>> I would like to look into this. >>>>>>>> >>>>>>> >>>>>>> Those are definitely not needed afaik. What do you have in mind ? >>>>>>> >>>>>>> What is needed is: >>>>>>> * need a GA version of asm 6 >>>>>>> * support from downstream projects like xbean, jetty, undertow, >> pax-web, >>>>>>> aries-proxy, etc... >>>>>>> * KARAF-3518 which I think requires a fair amount of work on >>>>>>> servicemix-specs and provide jigsaw modules for some >> implementations such >>>>>>> as xerces, xalan... >>>>>>> * If you run master with java9, you should see a warning when the >>>>>> console >>>>>>> is started. That would require some work in gogo/jline. >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Fabian >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> Guillaume Nodet >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> Guillaume Nodet >>> >>> -- >>> Jean-Baptiste Onofré >>> jbono...@apache.org >>> http://blog.nanthrax.net >>> Talend - http://www.talend.com
Re: Java 9 work
https://mvnrepository.com/artifact/org.ow2.asm/asm/6.0 Sent from my iPhone > On 3. Oct 2017, at 22:08, Jean-Baptiste Onofré wrote: > > Hi, > > there's no GA on Central, only 6.0 ALPHA and 6.0 BETA. > > Regards > JB > >> On 10/03/2017 05:51 PM, Fabian Lange wrote: >> Its actually on central >> Fabian >> Sent from my iPhone >>> On 3. Oct 2017, at 08:47, Guillaume Nodet wrote: >>> >>> Good catch, I only looked on maven central... >>> I guess we need to ask for an upload there... Wanna take care of it ? >>> >>> Guillaume >>> >>> 2017-10-03 17:13 GMT+02:00 Fabian Lange : >>> >>>> Asm 6 is GA now >>>> Fabiann >>>> >>>> Sent from my iPhone >>>> >>>>> On 3. Oct 2017, at 08:06, Guillaume Nodet wrote: >>>>> >>>>> 2017-10-03 16:23 GMT+02:00 Fabian Lange : >>>>> >>>>>> Hi Guys, >>>>>> whats our plan to support Java 9? >>>>>> >>>>>> Will that be karaf 4.2 >>>>>> 5.0 >>>>>> or even 4.1/4.0 backports? >>>>>> >>>>> >>>>> I'd say 4.3 >>>>> >>>>> >>>>>> >>>>>> The only real task is writing proper module-info files which should be >>>> easy >>>>>> for anything osgi. >>>>>> I would like to look into this. >>>>>> >>>>> >>>>> Those are definitely not needed afaik. What do you have in mind ? >>>>> >>>>> What is needed is: >>>>> * need a GA version of asm 6 >>>>> * support from downstream projects like xbean, jetty, undertow, pax-web, >>>>> aries-proxy, etc... >>>>> * KARAF-3518 which I think requires a fair amount of work on >>>>> servicemix-specs and provide jigsaw modules for some implementations such >>>>> as xerces, xalan... >>>>> * If you run master with java9, you should see a warning when the >>>> console >>>>> is started. That would require some work in gogo/jline. >>>>> >>>>> >>>>>> >>>>>> >>>>>> Fabian >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> Guillaume Nodet >>>> >>> >>> >>> >>> -- >>> >>> Guillaume Nodet > > -- > Jean-Baptiste Onofré > jbono...@apache.org > http://blog.nanthrax.net > Talend - http://www.talend.com
Re: Java 9 work
Its actually on central Fabian Sent from my iPhone > On 3. Oct 2017, at 08:47, Guillaume Nodet wrote: > > Good catch, I only looked on maven central... > I guess we need to ask for an upload there... Wanna take care of it ? > > Guillaume > > 2017-10-03 17:13 GMT+02:00 Fabian Lange : > >> Asm 6 is GA now >> Fabiann >> >> Sent from my iPhone >> >>> On 3. Oct 2017, at 08:06, Guillaume Nodet wrote: >>> >>> 2017-10-03 16:23 GMT+02:00 Fabian Lange : >>> >>>> Hi Guys, >>>> whats our plan to support Java 9? >>>> >>>> Will that be karaf 4.2 >>>> 5.0 >>>> or even 4.1/4.0 backports? >>>> >>> >>> I'd say 4.3 >>> >>> >>>> >>>> The only real task is writing proper module-info files which should be >> easy >>>> for anything osgi. >>>> I would like to look into this. >>>> >>> >>> Those are definitely not needed afaik. What do you have in mind ? >>> >>> What is needed is: >>> * need a GA version of asm 6 >>> * support from downstream projects like xbean, jetty, undertow, pax-web, >>> aries-proxy, etc... >>> * KARAF-3518 which I think requires a fair amount of work on >>> servicemix-specs and provide jigsaw modules for some implementations such >>> as xerces, xalan... >>> * If you run master with java9, you should see a warning when the >> console >>> is started. That would require some work in gogo/jline. >>> >>> >>>> >>>> >>>> Fabian >>>> >>> >>> >>> >>> -- >>> >>> Guillaume Nodet >> > > > > -- > > Guillaume Nodet
Re: Java 9 work
Asm 6 is GA now Fabiann Sent from my iPhone > On 3. Oct 2017, at 08:06, Guillaume Nodet wrote: > > 2017-10-03 16:23 GMT+02:00 Fabian Lange : > >> Hi Guys, >> whats our plan to support Java 9? >> >> Will that be karaf 4.2 >> 5.0 >> or even 4.1/4.0 backports? >> > > I'd say 4.3 > > >> >> The only real task is writing proper module-info files which should be easy >> for anything osgi. >> I would like to look into this. >> > > Those are definitely not needed afaik. What do you have in mind ? > > What is needed is: > * need a GA version of asm 6 > * support from downstream projects like xbean, jetty, undertow, pax-web, > aries-proxy, etc... > * KARAF-3518 which I think requires a fair amount of work on > servicemix-specs and provide jigsaw modules for some implementations such > as xerces, xalan... > * If you run master with java9, you should see a warning when the console > is started. That would require some work in gogo/jline. > > >> >> >> Fabian >> > > > > -- > > Guillaume Nodet
Java 9 work
Hi Guys, whats our plan to support Java 9? Will that be karaf 4.2 5.0 or even 4.1/4.0 backports? The only real task is writing proper module-info files which should be easy for anything osgi. I would like to look into this. Fabian
Re: Removal of JaxBUtil ?
I cannot really tell. Whatever XML stream or Document parser we would use, it also would load new classes and require some time to initialize. JAXB is however known to be the most inefficient in that regard. On the other hand it offers the most convenience because you get these nice mapped POJOs. Felix SCR does it manually as far as I can see: https://github.com/apache/felix/blob/trunk/osgi-r7/scr/src/main/java/org/apache/felix/scr/impl/xml/XmlHandler.java Felix IPojo uses sax: https://github.com/apache/felix/blob/a4755e768329a29252b1d7d8e52537941768606d/ipojo/manipulator/manipulator/src/main/java/org/apache/felix/ipojo/xml/parser/XMLMetadataParser.java Felix metatype uses xmlpullparser: https://github.com/apache/felix/blob/a4755e768329a29252b1d7d8e52537941768606d/metatype/src/main/java/org/apache/felix/metatype/MetaDataReader.java None of Felix uses jaxb. Maybe its worth giving xmlpullparser a shot. The code of metatype looks straigtforward, and the embedded classes are minimal. Fabian On Wed, Aug 9, 2017 at 10:53 AM, Jean-Baptiste Onofré wrote: > Hi Fabian, > > interesting fact indeed. What alternate do you propose ? > > Regards > JB > > On 08/09/2017 10:46 AM, Fabian Lange wrote: > >> Hey, >> I have new intel on this. A colleague generated a flame graph. >> I cannot share the raw svg unfortunately, but I cropped the Feature JAXB >> parsing. >> >> It is about 25% of the overall startup time just to boot up the jaxb >> infrastructure. >> >> Fabian >> >> >> On Fri, Jul 22, 2016 at 10:06 AM, Fabian Lange < >> fabian.la...@codecentric.de <mailto:fabian.la...@codecentric.de>> wrote: >> >> Thanks, good hint. >> For those inclined to understand my request, attached is the output of >> -XX:+TraceClassLoading >> >> Using the xml binding feature approximately loads 800 classes (which >> represent about 5MB memory) >> >> I haven't checked alternatives to the jaxb. And I am aware that this >> is a >> more esoteric requirement to reduce footprint. >> >> However, I am sure if this would not be from the JDK, nobody would >> pull in a >> 5MB dependency to parse a single xml file. >> >> Fabian >> >> >> On Fri, Jul 22, 2016 at 9:25 AM, Guillaume Nodet > <mailto:gno...@apache.org>> wrote: >> >> Note that on older branches, the feature repositories are still >> parsed >> using DOM >> https://github.com/apache/karaf/blob/karaf-2.x/features/core >> /src/main/java/org/apache/karaf/features/internal/RepositoryImpl.java >> <https://github.com/apache/karaf/blob/karaf-2.x/features/cor >> e/src/main/java/org/apache/karaf/features/internal/RepositoryImpl.java> >> >> The xml is now also written, that may be the reason why we >> switched. >> >> 2016-07-14 23:11 GMT+02:00 Fabian Lange < >> fabian.la...@codecentric.de >> <mailto:fabian.la...@codecentric.de>>: >> >> > Hi, >> > >> > i am looking into ways to trim down Karaf. I notices that >> Karaf uses JaxB >> > to parse features.xml - However this is the only application >> of JaxB. >> > >> > Could somebody more involved help me to figure out if it is >> worth to >> > replace it with manual marshalling? I assume other xmls are >> parsed >> > differently? >> > Advantage would be that the whole jaxb infrastructure could be >> avoided, >> > including the contexts. >> > >> > I know manual parsing is a pain, but anyway, just wanted to >> throw >> this out, >> > maybe somebody has a good suggestion. >> > >> > 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 <mailto:gno...@redhat.com> >> Web: http://fusesource.com >> Blog: http://gnodet.blogspot.com/ >> >> >> >> > -- > Jean-Baptiste Onofré > jbono...@apache.org > http://blog.nanthrax.net > Talend - http://www.talend.com >
Re: Removal of JaxBUtil ?
Hey, I have new intel on this. A colleague generated a flame graph. I cannot share the raw svg unfortunately, but I cropped the Feature JAXB parsing. It is about 25% of the overall startup time just to boot up the jaxb infrastructure. Fabian On Fri, Jul 22, 2016 at 10:06 AM, Fabian Lange wrote: > Thanks, good hint. > For those inclined to understand my request, attached is the output of > -XX:+TraceClassLoading > > Using the xml binding feature approximately loads 800 classes (which > represent about 5MB memory) > > I haven't checked alternatives to the jaxb. And I am aware that this is a > more esoteric requirement to reduce footprint. > > However, I am sure if this would not be from the JDK, nobody would pull in > a 5MB dependency to parse a single xml file. > > Fabian > > > On Fri, Jul 22, 2016 at 9:25 AM, Guillaume Nodet > wrote: > >> Note that on older branches, the feature repositories are still parsed >> using DOM >> https://github.com/apache/karaf/blob/karaf-2.x/features/ >> core/src/main/java/org/apache/karaf/features/internal/RepositoryImpl.java >> >> The xml is now also written, that may be the reason why we switched. >> >> 2016-07-14 23:11 GMT+02:00 Fabian Lange : >> >> > Hi, >> > >> > i am looking into ways to trim down Karaf. I notices that Karaf uses >> JaxB >> > to parse features.xml - However this is the only application of JaxB. >> > >> > Could somebody more involved help me to figure out if it is worth to >> > replace it with manual marshalling? I assume other xmls are parsed >> > differently? >> > Advantage would be that the whole jaxb infrastructure could be avoided, >> > including the contexts. >> > >> > I know manual parsing is a pain, but anyway, just wanted to throw this >> out, >> > maybe somebody has a good suggestion. >> > >> > 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/ >> > >
Re: [VOTE] Apache Karaf (Container) 4.1.2 release
+1 (non-binding) Our dist builds without problems. The changes I checked were from the correct revisions of dependencies. No regressions in the stuff we use. Thanks! Fabian On Fri, Aug 4, 2017 at 8:51 PM, Jean-Baptiste Onofré wrote: > 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&version=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 >
Re: Building custom dist, including all features of a repository
Sure, done in https://issues.apache.org/jira/browse/KARAF-5273 No prio from my side though, its more a convenience thing Fabian On Thu, Jul 27, 2017 at 9:51 AM, Jean-Baptiste Onofré wrote: > Ah yeah, that's it: the wildcard is for verify. Actually, we could do the > same for assembly as well. > > @Fabian: can you create the Jira about that ? > > Thanks > Regards > JB > > > On 07/27/2017 09:03 AM, Guillaume Nodet wrote: > >> The verify goal accepts a matching pattern, but I don't think the assembly >> goal ever supported it. >> >> 2017-07-27 8:33 GMT+02:00 Jean-Baptiste Onofré : >> >> Hi, >>> >>> AFAIR it was supported, so it looks like a regression. Let me take a >>> look. >>> >>> And it doesn't work just defining the repo and using >>> installAllFeaturesByDefault true ? >>> >>> Can you create a Jira about that, I will investigate ? Thanks ! >>> >>> Regards >>> JB >>> >>> >>> On 07/27/2017 07:52 AM, Fabian Lange wrote: >>> >>> Sure, JB, :-) >>>> >>>> >>>>myfeature-* >>>> >>>> >>>> Unable to build assembly: Could not find matching feature for >>>> myfeature-* >>>> >>>> That is probably because >>>> >>>> https://github.com/apache/karaf/blob/master/profile/src/main >>>> /java/org/apache/karaf/profile/assembly/Builder.java#L1284 >>>> >>>> Checks for f.getName().equals(name) >>>> >>>> >>>> If that should be supported, then this is also probably the place where >>>> I >>>> would add some wildcarding >>>> >>>> Fabian >>>> >>>> -- >>>> Fabian Lange | Performance Expert >>>> mobil: +49 (0) 160.3673393 >>>> >>>> codecentric AG | Hochstraße 11 | 42697 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 >>>> >>>> On Thu, Jul 27, 2017 at 7:38 AM, Jean-Baptiste Onofré >>>> wrote: >>>> >>>> Hi Fabian, >>>> >>>>> >>>>> did you try with wildcard ? >>>>> >>>>> Regards >>>>> JB >>>>> >>>>> >>>>> On 07/26/2017 06:49 PM, Fabian Lange wrote: >>>>> >>>>> Hi, >>>>> >>>>>> >>>>>> I have a features.xml aka repository, and I want to include all >>>>>> features >>>>>> defined in that repository when building a dist with >>>>>> karaf-maven-plugin. >>>>>> >>>>>> As far as I can tell this doesnt work, and I need to list all features >>>>>> manually as boot/installed feature >>>>>> >>>>>> Is this something we should have? >>>>>> >>>>>> Fabian >>>>>> >>>>>> -- >>>>>> Fabian Lange | Performance Expert >>>>>> mobil: +49 (0) 160.3673393 >>>>>> >>>>>> codecentric AG | Hochstraße 11 | 42697 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 >>>>>> >>>>>> >>>>>>
Re: Building custom dist, including all features of a repository
Hi, will check, but I do not really want to install all standard and framework features as side effect ;) Fabian On Thu, Jul 27, 2017 at 8:33 AM, Jean-Baptiste Onofré wrote: > Hi, > > AFAIR it was supported, so it looks like a regression. Let me take a look. > > And it doesn't work just defining the repo and using > installAllFeaturesByDefault true ? > > Can you create a Jira about that, I will investigate ? Thanks ! > > Regards > JB > > > On 07/27/2017 07:52 AM, Fabian Lange wrote: > >> Sure, JB, :-) >> >> >> myfeature-* >> >> >> Unable to build assembly: Could not find matching feature for myfeature-* >> >> That is probably because >> >> https://github.com/apache/karaf/blob/master/profile/src/main >> /java/org/apache/karaf/profile/assembly/Builder.java#L1284 >> >> Checks for f.getName().equals(name) >> >> >> If that should be supported, then this is also probably the place where I >> would add some wildcarding >> >> Fabian >> >> -- >> Fabian Lange | Performance Expert >> mobil: +49 (0) 160.3673393 >> >> codecentric AG | Hochstraße 11 | 42697 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 >> >> On Thu, Jul 27, 2017 at 7:38 AM, Jean-Baptiste Onofré >> wrote: >> >> Hi Fabian, >>> >>> did you try with wildcard ? >>> >>> Regards >>> JB >>> >>> >>> On 07/26/2017 06:49 PM, Fabian Lange wrote: >>> >>> Hi, >>>> >>>> I have a features.xml aka repository, and I want to include all features >>>> defined in that repository when building a dist with karaf-maven-plugin. >>>> >>>> As far as I can tell this doesnt work, and I need to list all features >>>> manually as boot/installed feature >>>> >>>> Is this something we should have? >>>> >>>> Fabian >>>> >>>> -- >>>> Fabian Lange | Performance Expert >>>> mobil: +49 (0) 160.3673393 >>>> >>>> codecentric AG | Hochstraße 11 | 42697 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 >>>> >>>> >>>> -- >>> 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 >
Re: Building custom dist, including all features of a repository
Sure, JB, :-) myfeature-* Unable to build assembly: Could not find matching feature for myfeature-* That is probably because https://github.com/apache/karaf/blob/master/profile/src/main/java/org/apache/karaf/profile/assembly/Builder.java#L1284 Checks for f.getName().equals(name) If that should be supported, then this is also probably the place where I would add some wildcarding Fabian -- Fabian Lange | Performance Expert mobil: +49 (0) 160.3673393 codecentric AG | Hochstraße 11 | 42697 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 On Thu, Jul 27, 2017 at 7:38 AM, Jean-Baptiste Onofré wrote: > Hi Fabian, > > did you try with wildcard ? > > Regards > JB > > > On 07/26/2017 06:49 PM, Fabian Lange wrote: > >> Hi, >> >> I have a features.xml aka repository, and I want to include all features >> defined in that repository when building a dist with karaf-maven-plugin. >> >> As far as I can tell this doesnt work, and I need to list all features >> manually as boot/installed feature >> >> Is this something we should have? >> >> Fabian >> >> -- >> Fabian Lange | Performance Expert >> mobil: +49 (0) 160.3673393 >> >> codecentric AG | Hochstraße 11 | 42697 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 >> >> > -- > Jean-Baptiste Onofré > jbono...@apache.org > http://blog.nanthrax.net > Talend - http://www.talend.com >
Building custom dist, including all features of a repository
Hi, I have a features.xml aka repository, and I want to include all features defined in that repository when building a dist with karaf-maven-plugin. As far as I can tell this doesnt work, and I need to list all features manually as boot/installed feature Is this something we should have? Fabian -- Fabian Lange | Performance Expert mobil: +49 (0) 160.3673393 codecentric AG | Hochstraße 11 | 42697 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
Features Service lost its provision task
Hi, I have a karaf instance which is starved for CPU, which might be helpful to figure out how it could come to this: A threaddump shows the following: at sun.misc.Unsafe.park(boolean, long) at java.util.concurrent.locks.LockSupport.park(java.lang.Object) (line: 175) at java.util.concurrent.FutureTask.awaitDone(boolean, long) (line: 429) at java.util.concurrent.FutureTask.get() (line: 191) at org.apache.karaf.features.internal.service.FeaturesServiceImpl.doProvisionInThread(java.util.Map, java.util.Map, org.apache.karaf.features.internal.service.State, java.util.EnumSet) (line: 1071) at org.apache.karaf.features.internal.service.FeaturesServiceImpl.addRequirements(java.util.Map, java.util.EnumSet) (line: 1014) I checked the executor that is used here, and its thread is: at sun.misc.Unsafe.park(boolean, long)at java.util.concurrent.locks.LockSupport.parkNanos(java.lang.Object, long) (line: 215) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(long) (line: 2078) at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take() (line: 1093) at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take() (line: 809) at java.util.concurrent.ThreadPoolExecutor.getTask() (line: 1067) at java.util.concurrent.ThreadPoolExecutor.runWorker(java.util.concurrent.ThreadPoolExecutor$Worker) (line: 1127) at java.util.concurrent.ThreadPoolExecutor$Worker.run() (line: 617) at java.lang.Thread.run() (line: 745) So the thread is ready for work, the FeaturesService is waiting for the work to complete. Now it gets interesting. Looking at the heap dump, I can see the lambda instance, and it is claimed to be on the stack of the executor thread [image: Inline image 1] But the thread dump disagrees. The reason is, that this pool-3-thread-1 exists twice! So the get() is waiting forever, because the thread that is supposed to run the callable is not running. I am actually quite puzzled how this could happen. Any ideas, suggestions what I could look for? What I think should happen in any case is that the doProvisionInThread sets a timeout on the get() method, then potentially retires or other actions could fix this situation. Maybe the Features service was restarted? with bad timing? The stop() method of the features service potentially should cancel/interrupt pending tasks? Fabian -- Fabian Lange | Performance Expert mobil: +49 (0) 160.3673393 codecentric AG | Hochstraße 11 | 42697 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
Property Escaping of Whitspace
Hi, i was investigating a problem why sometimes our maven settings.xml is not found. The reason is it is configured like this: org.ops4j.pax.url.mvn.settings=/Users/fabian/karaf test/etc/mvn-settings.xml It then cannot be used, because when I look via a heap dump, the org.ops4j.pax.url.mvn.internal.AetherBasedResolver.AetherBasedResolver(MavenConfiguration, MirrorInfo) has a MavenConfiguration which extends org.ops4j.util.property.PropertyStore. This has the following value: settings=/Users/fabian/karaf%20test/etc/mvn-settings.xml now that file does not exist, therefor it doesn't work. Now i wonder: is this a regression or did it never work. Is it a problem in pax-url / util or is the property escaped already by somebody else. I did not notice this problem with Karaf 4.0 but i might have not realized that it also was broken there. Fabian -- Fabian Lange | Performance Expert mobil: +49 (0) 160.3673393 codecentric AG | Hochstraße 11 | 42697 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
Re: [VOTE] Apache Karaf (Container) 4.1.1 release
+1 (non-binding) Fabian On Tue, Mar 28, 2017 at 10:11 PM, 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?proje > ctId=12311140&version=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 > -- > Jean-Baptiste Onofré > jbono...@apache.org > http://blog.nanthrax.net > Talend - http://www.talend.com >
Karaf no longer logs when log line has trailing whitespace
Hi, when you download the karaf distribution, then change this log line: log4j2.rootLogger.level = INFO so that it ends with a trailing whitespace then karaf will not log when you start it. Is that a pax-logging or a karaf bug? With 4.0.x trailing whitspace was trimmed. Fabian -- Fabian Lange | Performance Expert mobil: +49 (0) 160.3673393 codecentric AG | Hochstraße 11 | 42697 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
Re: [VOTE] Apache Karaf (Container) 4.1.0 release, RC#2
Hey, just wanted to point out that I today found and fixed KARAF-4978, a native memory leak in the Features Subsystem caused by not closing a ZipInputStream. Christian also fixed KARAF-4974 an ArrayIndexOutOfBounds Exception when listing services. I have the feeling that these two fixes might justify another attempt, but I will of course leave this up to you :) Fabian On Sat, Feb 4, 2017 at 12:08 PM, Jamie G. wrote: > +1 (binding) > > On Sat, Feb 4, 2017 at 7:25 AM, Markus Rathgeb > wrote: > > +1 (non-binding) >
Re: [VOTE] Apache Karaf (Container) 4.1.0 release, RC#2
Thanks Christian for clarification. Reverting to a +1 non-binding now. migration was successful on my side. Fabian On Thu, Feb 2, 2017 at 3:11 PM, Christian Schneider wrote: > 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: [VOTE] Apache Karaf (Container) 4.1.0 release, RC#2
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 On Thu, Feb 2, 2017 at 11:26 AM, Guillaume Nodet wrote: > Karaf 4.1.0 now uses log4j v2 so the config has changed. > > 2017-02-02 11:14 GMT+01:00 Jean-Baptiste Onofré : > > > OK, thanks. Yes, I think you have to "update" your log config. > > > > Regards > > JB > > > > > > On 02/02/2017 11:12 AM, Fabian Lange wrote: > > > >> No, I am using my current log config, which is probably the cause of > that. > >> Will check and come back > >> > >> Fabian > >> > >> On Thu, Feb 2, 2017 at 11:11 AM, Jean-Baptiste Onofré > >> wrote: > >> > >> Hi Fabian, > >>> > >>> what do you mean by "logging doesn't work" ? > >>> > >>> On a fresh Karaf 4.1.0: > >>> 1. log:* commands work for me > >>> 2. I see data/log/karaf.log populated by default > >>> > >>> Do you use the etc/org.ops4j.pax.logging.cfg provided by Karaf 4.1.0 > >>> (using log4j2) ? > >>> > >>> Regards > >>> JB > >>> > >>> On 02/02/2017 11:09 AM, Fabian Lange wrote: > >>> > >>> Hi, > >>>> > >>>> currently -1 (non-binding) > >>>> I just started our container with 4.1.0 instead of 4.0.8 and logging > no > >>>> longer works. > >>>> is there a migration of logging config necessary? > >>>> > >>>> Fabian > >>>> > >>>> On Wed, Feb 1, 2017 at 8:32 PM, 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?proje > >>>>> ctId=12311140&version=12332799 > >>>>> > >>>>> Staging Repository: > >>>>> https://repository.apache.org/content/repositories/orgapache > >>>>> karaf-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 > >>>>> -- > >>>>> 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 > >>> > >>> > >> > > -- > > Jean-Baptiste Onofré > > jbono...@apache.org > > http://blog.nanthrax.net > > Talend - http://www.talend.com > > > > > > -- > > Guillaume Nodet >
Re: [VOTE] Apache Karaf (Container) 4.1.0 release, RC#2
No, I am using my current log config, which is probably the cause of that. Will check and come back Fabian On Thu, Feb 2, 2017 at 11:11 AM, Jean-Baptiste Onofré wrote: > Hi Fabian, > > what do you mean by "logging doesn't work" ? > > On a fresh Karaf 4.1.0: > 1. log:* commands work for me > 2. I see data/log/karaf.log populated by default > > Do you use the etc/org.ops4j.pax.logging.cfg provided by Karaf 4.1.0 > (using log4j2) ? > > Regards > JB > > On 02/02/2017 11:09 AM, Fabian Lange wrote: > >> Hi, >> >> currently -1 (non-binding) >> I just started our container with 4.1.0 instead of 4.0.8 and logging no >> longer works. >> is there a migration of logging config necessary? >> >> Fabian >> >> On Wed, Feb 1, 2017 at 8:32 PM, 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?proje >>> ctId=12311140&version=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 >>> -- >>> 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 >
Re: [VOTE] Apache Karaf (Container) 4.1.0 release, RC#2
Hi, currently -1 (non-binding) I just started our container with 4.1.0 instead of 4.0.8 and logging no longer works. is there a migration of logging config necessary? Fabian On Wed, Feb 1, 2017 at 8:32 PM, 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?proje > ctId=12311140&version=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 > -- > Jean-Baptiste Onofré > jbono...@apache.org > http://blog.nanthrax.net > Talend - http://www.talend.com >
Re: Towards Karaf (Container) 4.1.0
Hey, I would still vote for a preview release. Other people might find other compatibility issues ( and I would love to have configadmin 1.8.14 in, for which a vote was started today) Fabian On Mon, Jan 30, 2017 at 1:39 PM, 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 >> and I will tackle this as it's pre-requisite for 4.1.0. >> >> I plan to create karaf-4.1.x branch next week for a release the >> fol
Re: [RESULT][VOTE] Apache Karaf (Container) 4.0.8 release
Hi, Late to the party, but just wanted to let you know that I successfully upgraded our stuff to 4.0.8 as well. No issues. +1 (non-binding, too-late) Fabian On Sun, Dec 18, 2016 at 6:11 PM, Jean-Baptiste Onofré wrote: > Hi all, > > this vote passed with the following result: > > +1 (binding): Christian Schneider, Achim Nierbeck, Jamie Goodyear, > Jean-Baptiste Onofré, Freeman Fang > +1 (non binding): Luca Burgazzoli, Andrea Cosentino, Grzegorz Grzybek, > Markus Rathgeb > > I'm promoting the artifacts on Central, update Jira and I will announce > the release. > > Thanks all for your vote ! > > Regards > JB > > On 12/14/2016 09:48 AM, Jean-Baptiste Onofré wrote: > >> Hi all, >> >> I submit Karaf (Container) 4.0.8 release to your vote. >> >> Release Notes: >> https://issues.apache.org/jira/secure/ReleaseNote.jspa?proje >> ctId=12311140&version=12338273 >> >> Staging Repository: >> https://repository.apache.org/content/repositories/orgapachekaraf-1085/ >> >> Git Tag: >> karaf-4.0.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 >
Re: [DISCUSS] Trim down the number of config files in etc/ in the distributions
Hi Guillaume, We are building a distribution, and we modify these files: -rw-r--r-- 1 fabian staff 0 Sep 6 16:13 blacklisted.properties -rw-r--r-- 1 fabian staff 977 Dec 11 2015 branding.properties -rw-r--r-- 1 fabian staff 2414 Oct 28 17:35 custom.properties -rw-r--r-- 1 fabian staff 2867 Nov 11 14:10 org.apache.karaf.features.cfg -rw-r--r--@ 1 fabian staff 1935 Dec 21 2015 org.apache.karaf.log.cfg -rw-r--r-- 1 fabian staff 3317 Dec 11 2015 org.apache.karaf.shell.cfg -rw-r--r-- 1 fabian staff 2818 Nov 21 08:08 org.ops4j.pax.logging.cfg -rw-r--r--@ 1 fabian staff 3889 Oct 6 09:07 org.ops4j.pax.url.mvn.cfg -rw-r--r-- 1 fabian staff 0 Sep 6 16:13 overrides.properties -rw-r--r--@ 1 fabian staff 5430 Oct 5 10:02 system.properties -rw-r--r-- 1 fabian staff 1701 Apr 2 2016 users.properties the 0 byte properties are just to avoid the file not found exception And we have the following excludes bin/** deploy/README system/README lib/**/README etc/org.apache.karaf.jaas.cfg etc/org.apache.karaf.management.cfg etc/org.apache.karaf.features.repos.cfg etc/org.apache.karaf.command.acl* etc/jmx.acl* I am very much in favor of removing the files. The only issue i see is that I was able to modify above files, because I saw them being present. 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 On Fri, Nov 25, 2016 at 8:19 AM, 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 > > > -- > > Guillaume Nodet > > Red Hat, Open Source Integration > > Email: gno...@redhat.com > Web: http://fusesource.com > Blog: http://gnodet.blogspot.com/ >
java.transaction.xa not exported?
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
Re: [Proposal] Karaf with embedded JVM
Hi Achim, Karaf does not need to ship this and can leave those questions up to the distributors using the feature. Fabian On Mon, Oct 31, 2016 at 1:43 PM, Achim Nierbeck wrote: > hmm ... even though I like the idea ... what Implications does it have for > > a) is it compliant with the ASF license? > b) how about different JVMs and different processors ... don't we need to > provide it for intel, arm, ppc? > > regards, Achim > > > 2016-10-31 13:39 GMT+01:00 Fabian Lange : > > > Hi Sascha, > > > > i very much like the idea. It can be a very lightweight enhancement to > the > > start scripts, because what it basically does is that it defines a > "search > > list" for "JAVA_HOME". Maybe it is sufficient to add that feature to the > > scripts and every distributor can customize the directory they prefer. > > > > 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 > > > > On Mon, Oct 31, 2016 at 1:33 PM, Sascha Vogt > > wrote: > > > > > Hi all, > > > > > > we're workig on a Karaf based product and have the requirement to use > > > the JVM we ship with the product. We thought that might also be > > > interesting to others, so we wanted to share our proposal / current > > > implementation (and are also willing to provide the required patches). > > > > > > Main idea is to modify the start scripts (including the service > > > wrappers?) to prefer a JVM inside the KARAF_HOME directory (ie. > > > runtime/jvm64, or just plain jvm in KARAF_HOME). Whenever such a > > > directory is present it is prefered over a JAVA_HOME env var or > whatever > > > else is in the path. > > > > > > Reason to also prefer it over JAVA_HOME is because if you run alongside > > > other Java applications on a server, JAVA_HOME might already be set for > > > other applications and the admin cannot change it. > > > > > > At the moment we have implemented the above via custom setenv scripts > we > > > ship which then sets JAVA_HOME to KARAF_HOME/runtime/jvm64. When > > > "wrapper:install" is called, this JAVA_HOME is taken to the wrapper > > > properties. > > > > > > We spoke with the Instana[1] people as their agent is also Karaf based > > > and they were interested in it as well, so we know at least one other > > > Karaf user who would welcome that :) > > > > > > Anyway, any feeback is welcome. Also of course the name of the > > > directory(ies) can be discussed. > > > > > > Greetings > > > -Sascha- > > > > > > [1]https://www.instana.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 >
Re: [Proposal] Karaf with embedded JVM
Hi Sascha, i very much like the idea. It can be a very lightweight enhancement to the start scripts, because what it basically does is that it defines a "search list" for "JAVA_HOME". Maybe it is sufficient to add that feature to the scripts and every distributor can customize the directory they prefer. 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 On Mon, Oct 31, 2016 at 1:33 PM, Sascha Vogt wrote: > Hi all, > > we're workig on a Karaf based product and have the requirement to use > the JVM we ship with the product. We thought that might also be > interesting to others, so we wanted to share our proposal / current > implementation (and are also willing to provide the required patches). > > Main idea is to modify the start scripts (including the service > wrappers?) to prefer a JVM inside the KARAF_HOME directory (ie. > runtime/jvm64, or just plain jvm in KARAF_HOME). Whenever such a > directory is present it is prefered over a JAVA_HOME env var or whatever > else is in the path. > > Reason to also prefer it over JAVA_HOME is because if you run alongside > other Java applications on a server, JAVA_HOME might already be set for > other applications and the admin cannot change it. > > At the moment we have implemented the above via custom setenv scripts we > ship which then sets JAVA_HOME to KARAF_HOME/runtime/jvm64. When > "wrapper:install" is called, this JAVA_HOME is taken to the wrapper > properties. > > We spoke with the Instana[1] people as their agent is also Karaf based > and they were interested in it as well, so we know at least one other > Karaf user who would welcome that :) > > Anyway, any feeback is welcome. Also of course the name of the > directory(ies) can be discussed. > > Greetings > -Sascha- > > [1]https://www.instana.com/ >
Re: Re-Using an ExecutorService for Felix Resolver calls
Hi Guillaume, i just updated the jira with 10 screenshots showing the threads and stack traces of them. Unfortunately with pooled threads there is no easy way to capture where they were triggered, but you can see that they all execute stacks like this: Thread "pool-17-thread-5": at org.apache.felix.resolver.ResolverImpl.mergeUses(org.apache.felix.resolver.ResolverImpl$ResolveSession, org.osgi.resource.Resource, org.apache.felix.resolver.ResolverImpl$Packages, org.osgi.resource.Capability, java.util.List, org.osgi.resource.Capability, java.util.Map, java.util.Set) (line: 1033) at org.apache.felix.resolver.ResolverImpl.computeUses(org.apache.felix.resolver.ResolverImpl$ResolveSession, java.util.Map, java.util.Map, org.osgi.resource.Resource) (line: 853) at org.apache.felix.resolver.ResolverImpl.access$500(org.apache.felix.resolver.ResolverImpl$ResolveSession, java.util.Map, java.util.Map, org.osgi.resource.Resource) at org.apache.felix.resolver.ResolverImpl$6.run() (line: 1231) at org.apache.felix.resolver.ResolverImpl$EnhancedExecutor$1.run() (line: 2442) at java.util.concurrent.ThreadPoolExecutor.runWorker(java.util.concurrent.ThreadPoolExecutor$Worker) (line: 1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run() (line: 617) at java.lang.Thread.run() (line: 745) with newCachedThreadPool() we would not end up with 8 Threads doing nothing. That would happen with a newFixedThreadPool(). a cached one would grow on demand and shrink back to 0 (like you suggested) The question for me is if this is important to configure or if this improvement would make the need for configuration go away Fabian On Tue, Oct 4, 2016 at 8:51 AM, Guillaume Nodet wrote: > It seems to me that running the features service is not something which is > done very frequently, at least in a production system, so I would rather > use a thread pool which has 0 core threads, so that we don't end up with 8 > threads doing nothing at all as with an Executors.newCachedThreadPool(). > > Are you sure the number of threads you saw are actually created by the > resolver used by the FeaturesService ? > > 2016-10-04 8:06 GMT+02:00 Fabian Lange : > > > Hey, > > > > One additional option would be to make it not configurable at all and > just > > use a java.util.concurrent.Executors.newCachedThreadPool() > > > > This would exhibit very similar properties to the current behaviour but > > avoid creating the hundreds to thousand threads we observe. Probably > nobody > > really want the current behaviour, but it usually is so quick that nobody > > cares. > > > > Fabian > > > > On Tue, Oct 4, 2016 at 7:53 AM, Fabian Lange < > fabian.la...@codecentric.de> > > wrote: > > > > > Hi, > > > what do you guys think about: > > > https://github.com/apache/karaf/pull/246 > > > > > > As noticed by me, and already reported here: https://issues.apache.or > > > g/jira/browse/FELIX-5247 > > > > > > The current default behaviour is that every "resolve()" call will > create > > a > > > new Executor Pool with number of CPU Cores as size. This is not very > > > efficient. > > > In my opinion this is unexpected behaviour by Felix, but fortunately we > > > can use other constructors. > > > > > > I left in my PR the default behaviour, but added a new one, which can > > > re-use a bounded or unbounded ThreadPoolExecutor. I did not use a > > > FixedThreadPool because i wanted to mimic the current behaviour, which > > is: > > > After the resolve call, these Threads are gone again. > > > > > > What do you guys think? Should we change the current "implicit default" > > to > > > re-use a Thread Pool? > > > Is a ThreadPoolExecutor with timeout fine to mimic the current > behaviour, > > > or would we want to change this, lets say to have a dedicated thread > pool > > > always available for Felix Resolve calls? (This would then be like > > > Executors.newFixedThreadPool()) > > > > > > I am trying to get this change into karaf 4.0.8. > > > > > > 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/ >
Re: Re-Using an ExecutorService for Felix Resolver calls
Hey, One additional option would be to make it not configurable at all and just use a java.util.concurrent.Executors.newCachedThreadPool() This would exhibit very similar properties to the current behaviour but avoid creating the hundreds to thousand threads we observe. Probably nobody really want the current behaviour, but it usually is so quick that nobody cares. Fabian On Tue, Oct 4, 2016 at 7:53 AM, Fabian Lange wrote: > Hi, > what do you guys think about: > https://github.com/apache/karaf/pull/246 > > As noticed by me, and already reported here: https://issues.apache.or > g/jira/browse/FELIX-5247 > > The current default behaviour is that every "resolve()" call will create a > new Executor Pool with number of CPU Cores as size. This is not very > efficient. > In my opinion this is unexpected behaviour by Felix, but fortunately we > can use other constructors. > > I left in my PR the default behaviour, but added a new one, which can > re-use a bounded or unbounded ThreadPoolExecutor. I did not use a > FixedThreadPool because i wanted to mimic the current behaviour, which is: > After the resolve call, these Threads are gone again. > > What do you guys think? Should we change the current "implicit default" to > re-use a Thread Pool? > Is a ThreadPoolExecutor with timeout fine to mimic the current behaviour, > or would we want to change this, lets say to have a dedicated thread pool > always available for Felix Resolve calls? (This would then be like > Executors.newFixedThreadPool()) > > I am trying to get this change into karaf 4.0.8. > > 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 >
Re-Using an ExecutorService for Felix Resolver calls
Hi, what do you guys think about: https://github.com/apache/karaf/pull/246 As noticed by me, and already reported here: https://issues.apache. org/jira/browse/FELIX-5247 The current default behaviour is that every "resolve()" call will create a new Executor Pool with number of CPU Cores as size. This is not very efficient. In my opinion this is unexpected behaviour by Felix, but fortunately we can use other constructors. I left in my PR the default behaviour, but added a new one, which can re-use a bounded or unbounded ThreadPoolExecutor. I did not use a FixedThreadPool because i wanted to mimic the current behaviour, which is: After the resolve call, these Threads are gone again. What do you guys think? Should we change the current "implicit default" to re-use a Thread Pool? Is a ThreadPoolExecutor with timeout fine to mimic the current behaviour, or would we want to change this, lets say to have a dedicated thread pool always available for Felix Resolve calls? (This would then be like Executors.newFixedThreadPool()) I am trying to get this change into karaf 4.0.8. 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
Re: Exceptions with reference to overrides.properties
Created a JIRA https://issues.apache.org/jira/browse/KARAF-4700 - and added
empty files to our distribution to avoid the error in debug logging.
Fabian
On Tue, Sep 6, 2016 at 3:34 PM, Guillaume Nodet wrote:
> Right, the obvious easiest workaround would be to create two empty files
> etc/overrides.properties
> etc/blacklisted.properties
>
> But please raise a JIRA, i'll have a look at disabling the exception at
> debug level and simply printing the message.
>
> 2016-09-06 15:23 GMT+02:00 Fabian Lange :
>
> > Addition:
> > this problem seems to affect the blacklisting feature similarly
> >
> > String blacklisted = getString("blacklisted", new
> File(System.getProperty("
> > karaf.etc"), "blacklisted.properties").toURI().toString());
> >
> > Fabian
> >
> > On Tue, Sep 6, 2016 at 3:16 PM, Fabian Lange <
> fabian.la...@codecentric.de>
> > wrote:
> >
> > > Hi Guys,
> > > it seems to me the overrides.properties mechanism could be slightly
> > > improved.
> > >
> > > I am getting a lot of these:
> > >
> > > 2016-09-06T15:00:27.258+0200 | DEBUG | pool-22-thread-1
> |
> > > Overrides| org.apache.karaf.features.core - 4.0.6 | Unable to
> > load
> > > overrides bundles list
> > > java.io.FileNotFoundException: /Users/fabian/work/karaf/etc/
> > overrides.properties
> > > (No such file or directory)
> > > at java.io.FileInputStream.open0(Native Method)[:1.8.0_71]
> > > at java.io.FileInputStream.open(FileInputStream.java:195)[:1.8.0_71]
> > > at java.io.FileInputStream.(FileInputStream.java:138)[:1.8.0_71]
> > > at java.io.FileInputStream.(FileInputStream.java:93)[:1.8.0_71]
> > > at sun.net.www.protocol.file.FileURLConnection.connect(
> > > FileURLConnection.java:90)[:1.8.0_71]
> > > at sun.net.www.protocol.file.FileURLConnection.getInputStream(
> > > FileURLConnection.java:188)[:1.8.0_71]
> > > at java.net.URL.openStream(URL.java:1045)[:1.8.0_71]
> > > at org.apache.karaf.features.internal.service.Overrides.
> > > loadOverrides(Overrides.java:108)[6:org.apache.karaf.
> > features.core:4.0.6]
> > > at org.apache.karaf.features.internal.service.FeaturesServiceImpl.
> > > getDeploymentRequest(FeaturesServiceImpl.java:1148)
> > > [6:org.apache.karaf.features.core:4.0.6]
> > > at org.apache.karaf.features.internal.service.FeaturesServiceImpl.
> > > doProvision(FeaturesServiceImpl.java:1175)
> [6:org.apache.karaf.features.
> > > core:4.0.6]
> > > at org.apache.karaf.features.internal.service.
> > FeaturesServiceImpl$1.call(
> > > FeaturesServiceImpl.java:1074)[6:org.apache.karaf.features.core:4.0.6]
> > > at java.util.concurrent.FutureTask.run(FutureTask.java:266)[:1.8.0_71]
> > > at java.util.concurrent.ThreadPoolExecutor.runWorker(
> > > ThreadPoolExecutor.java:1142)[:1.8.0_71]
> > > at java.util.concurrent.ThreadPoolExecutor$Worker.run(
> > > ThreadPoolExecutor.java:617)[:1.8.0_71]
> > > at java.lang.Thread.run(Thread.java:745)[:1.8.0_71]
> > >
> > >
> > > The logic in Overrides.java is:
> > >
> > > if (overridesUrl != null) {
> > >
> > > try (
> > >
> > > InputStream is = new URL(overridesUrl
> > > ).openStream()
> > >
> > > ) {
> > >
> > >
> > > so apparently the overridesUrl is not null.
> > >
> > > This is because https://github.com/apache/karaf/blob/
> > > 791ebb5f908e27fa389616c8bba456cf85807f4d/features/core/src/
> > > main/java/org/apache/karaf/features/internal/osgi/Activator.java#L175
> > > String overrides = getString("overrides", new File(System.getProperty("
> > > karaf.etc"), "overrides.properties").toURI().toString());
> > >
> > > so I do not have overrides, there is a default in place, which refers
> to
> > a
> > > nonexistant file.
> > > I might not need this feature and i would like to turn it "off" -
> > therefor
> > > I would need to supply overrides == null, which does not seem possible
> > > right now.
> > >
> > > Suggestions?
> > >
> > > 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/
>
Re: Exceptions with reference to overrides.properties
Addition:
this problem seems to affect the blacklisting feature similarly
String blacklisted = getString("blacklisted", new File(System.getProperty("
karaf.etc"), "blacklisted.properties").toURI().toString());
Fabian
On Tue, Sep 6, 2016 at 3:16 PM, Fabian Lange
wrote:
> Hi Guys,
> it seems to me the overrides.properties mechanism could be slightly
> improved.
>
> I am getting a lot of these:
>
> 2016-09-06T15:00:27.258+0200 | DEBUG | pool-22-thread-1 |
> Overrides| org.apache.karaf.features.core - 4.0.6 | Unable to load
> overrides bundles list
> java.io.FileNotFoundException:
> /Users/fabian/work/karaf/etc/overrides.properties
> (No such file or directory)
> at java.io.FileInputStream.open0(Native Method)[:1.8.0_71]
> at java.io.FileInputStream.open(FileInputStream.java:195)[:1.8.0_71]
> at java.io.FileInputStream.(FileInputStream.java:138)[:1.8.0_71]
> at java.io.FileInputStream.(FileInputStream.java:93)[:1.8.0_71]
> at sun.net.www.protocol.file.FileURLConnection.connect(
> FileURLConnection.java:90)[:1.8.0_71]
> at sun.net.www.protocol.file.FileURLConnection.getInputStream(
> FileURLConnection.java:188)[:1.8.0_71]
> at java.net.URL.openStream(URL.java:1045)[:1.8.0_71]
> at org.apache.karaf.features.internal.service.Overrides.
> loadOverrides(Overrides.java:108)[6:org.apache.karaf.features.core:4.0.6]
> at org.apache.karaf.features.internal.service.FeaturesServiceImpl.
> getDeploymentRequest(FeaturesServiceImpl.java:1148)
> [6:org.apache.karaf.features.core:4.0.6]
> at org.apache.karaf.features.internal.service.FeaturesServiceImpl.
> doProvision(FeaturesServiceImpl.java:1175)[6:org.apache.karaf.features.
> core:4.0.6]
> at org.apache.karaf.features.internal.service.FeaturesServiceImpl$1.call(
> FeaturesServiceImpl.java:1074)[6:org.apache.karaf.features.core:4.0.6]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)[:1.8.0_71]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(
> ThreadPoolExecutor.java:1142)[:1.8.0_71]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(
> ThreadPoolExecutor.java:617)[:1.8.0_71]
> at java.lang.Thread.run(Thread.java:745)[:1.8.0_71]
>
>
> The logic in Overrides.java is:
>
> if (overridesUrl != null) {
>
> try (
>
> InputStream is = new URL(overridesUrl
> ).openStream()
>
> ) {
>
>
> so apparently the overridesUrl is not null.
>
> This is because https://github.com/apache/karaf/blob/
> 791ebb5f908e27fa389616c8bba456cf85807f4d/features/core/src/
> main/java/org/apache/karaf/features/internal/osgi/Activator.java#L175
> String overrides = getString("overrides", new File(System.getProperty("
> karaf.etc"), "overrides.properties").toURI().toString());
>
> so I do not have overrides, there is a default in place, which refers to a
> nonexistant file.
> I might not need this feature and i would like to turn it "off" - therefor
> I would need to supply overrides == null, which does not seem possible
> right now.
>
> Suggestions?
>
> 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
>
Exceptions with reference to overrides.properties
Hi Guys,
it seems to me the overrides.properties mechanism could be slightly
improved.
I am getting a lot of these:
2016-09-06T15:00:27.258+0200 | DEBUG | pool-22-thread-1 |
Overrides| org.apache.karaf.features.core - 4.0.6 | Unable to load
overrides bundles list
java.io.FileNotFoundException:
/Users/fabian/work/karaf/etc/overrides.properties (No such file or
directory)
at java.io.FileInputStream.open0(Native Method)[:1.8.0_71]
at java.io.FileInputStream.open(FileInputStream.java:195)[:1.8.0_71]
at java.io.FileInputStream.(FileInputStream.java:138)[:1.8.0_71]
at java.io.FileInputStream.(FileInputStream.java:93)[:1.8.0_71]
at
sun.net.www.protocol.file.FileURLConnection.connect(FileURLConnection.java:90)[:1.8.0_71]
at
sun.net.www.protocol.file.FileURLConnection.getInputStream(FileURLConnection.java:188)[:1.8.0_71]
at java.net.URL.openStream(URL.java:1045)[:1.8.0_71]
at
org.apache.karaf.features.internal.service.Overrides.loadOverrides(Overrides.java:108)[6:org.apache.karaf.features.core:4.0.6]
at
org.apache.karaf.features.internal.service.FeaturesServiceImpl.getDeploymentRequest(FeaturesServiceImpl.java:1148)[6:org.apache.karaf.features.core:4.0.6]
at
org.apache.karaf.features.internal.service.FeaturesServiceImpl.doProvision(FeaturesServiceImpl.java:1175)[6:org.apache.karaf.features.core:4.0.6]
at
org.apache.karaf.features.internal.service.FeaturesServiceImpl$1.call(FeaturesServiceImpl.java:1074)[6:org.apache.karaf.features.core:4.0.6]
at java.util.concurrent.FutureTask.run(FutureTask.java:266)[:1.8.0_71]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)[:1.8.0_71]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)[:1.8.0_71]
at java.lang.Thread.run(Thread.java:745)[:1.8.0_71]
The logic in Overrides.java is:
if (overridesUrl != null) {
try (
InputStream is = new URL(overridesUrl).openStream()
) {
so apparently the overridesUrl is not null.
This is because
https://github.com/apache/karaf/blob/791ebb5f908e27fa389616c8bba456cf85807f4d/features/core/src/main/java/org/apache/karaf/features/internal/osgi/Activator.java#L175
String overrides = getString("overrides", new File(System.getProperty("
karaf.etc"), "overrides.properties").toURI().toString());
so I do not have overrides, there is a default in place, which refers to a
nonexistant file.
I might not need this feature and i would like to turn it "off" - therefor
I would need to supply overrides == null, which does not seem possible
right now.
Suggestions?
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
Re: [VOTE] Apache Karaf (Container) 4.0.6 release
Hi JB, this time my upgrade was very smooth. Plugged in the new repo compile, build and test worked. Bundling also produced the expected contents. The changes I can relate to seem to be correct and working. Thank you for the release +1 (non-binding) Fabian On Wed, Aug 24, 2016 at 6:47 AM, Jean-Baptiste Onofré wrote: > Hi all, > > I submit Karaf (Container) 4.0.6 release to your vote. > > Release Notes: > https://issues.apache.org/jira/secure/ReleaseNote.jspa?proje > ctId=12311140&version=12335477 > > Staging Repository: > https://repository.apache.org/content/repositories/orgapachekaraf-1071/ > > Git Tag: > karaf-4.0.6 > > Please vote to approve this release: > > [ ] +1 Approve the release > [ ] -1 Don't approve the release (please provide specific comments) > > This vote will be open for at least 72 hours. > > Thanks, > Regards > JB > -- > Jean-Baptiste Onofré > jbono...@apache.org > http://blog.nanthrax.net > Talend - http://www.talend.com >
Re: Why is sshd-core part of framework feature
Hi Guillaume, as far as I can see, you made the fix. Should this be ported to 4.0.x? Fabian On Fri, Jul 22, 2016 at 9:04 AM, Guillaume Nodet wrote: > I'm not sure why KARAF-3974 is flagged as fixed for 4.0.x, I don't see any > related commit on that branch. > So my guess is that it has only been fixed on master (4.1), hence the > difference you see on the sshd-core bundle. > > 2016-07-21 20:38 GMT+02:00 Fabian Lange : > > > Oh, it was removed from the 4.1 version of framework. > > > > is it staying in 4.0.x for compatibility? Or was that an omission > > > > > > > https://github.com/apache/karaf/commit/71942556ca2a7796fa6908aeec069442811d5f45 > > > > https://issues.apache.org/jira/browse/KARAF-3974 > > > > Fabian > > > > On Thu, Jul 21, 2016 at 8:12 PM, Fabian Lange < > fabian.la...@codecentric.de > > > > > wrote: > > > > > Hi, > > > as you could see from my last request about jaxb (thanks for answering, > > > still working on it) I am looking for ways to trim down karaf in > install > > > and memory size. > > > > > > I noticed that I get a bundle called sshd-core installed even when not > > > having ssh installed. > > > > > > I suspect the reason for that is that it downloads the jar so the > > ./client > > > command can actually work. > > > > > > Is there any better way to bundle it? currently it will always install > as > > > active bundle on startup even when nobody needs it. > > > > > > 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/ >
Re: Why is sshd-core part of framework feature
Oh, it was removed from the 4.1 version of framework. is it staying in 4.0.x for compatibility? Or was that an omission https://github.com/apache/karaf/commit/71942556ca2a7796fa6908aeec069442811d5f45 https://issues.apache.org/jira/browse/KARAF-3974 Fabian On Thu, Jul 21, 2016 at 8:12 PM, Fabian Lange wrote: > Hi, > as you could see from my last request about jaxb (thanks for answering, > still working on it) I am looking for ways to trim down karaf in install > and memory size. > > I noticed that I get a bundle called sshd-core installed even when not > having ssh installed. > > I suspect the reason for that is that it downloads the jar so the ./client > command can actually work. > > Is there any better way to bundle it? currently it will always install as > active bundle on startup even when nobody needs it. > > 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 >
Why is sshd-core part of framework feature
Hi, as you could see from my last request about jaxb (thanks for answering, still working on it) I am looking for ways to trim down karaf in install and memory size. I noticed that I get a bundle called sshd-core installed even when not having ssh installed. I suspect the reason for that is that it downloads the jar so the ./client command can actually work. Is there any better way to bundle it? currently it will always install as active bundle on startup even when nobody needs it. 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
Removal of JaxBUtil ?
Hi, i am looking into ways to trim down Karaf. I notices that Karaf uses JaxB to parse features.xml - However this is the only application of JaxB. Could somebody more involved help me to figure out if it is worth to replace it with manual marshalling? I assume other xmls are parsed differently? Advantage would be that the whole jaxb infrastructure could be avoided, including the contexts. I know manual parsing is a pain, but anyway, just wanted to throw this out, maybe somebody has a good suggestion. 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
Re: [UPDATE] Releases schedule
Hi, is SCR 2.0.4 in scope for Karaf 4.0.6? Fabian On Sun, Jul 3, 2016 at 8:52 PM, Jean-Baptiste Onofré wrote: > Hi all, > > just a quick update about the releases schedule. > > End of this week and during the week end, I should be able to submit > Cellar 4.0.1 and Decanter 1.1.1 to vote. > > Karaf Container 4.0.6 and 3.0.8 are planned for end of the following week. > > On the other hand, I worked on couple of PoC around Docker and karaf-boot. > I will give you more details soon. > > Regards > JB > -- > Jean-Baptiste Onofré > jbono...@apache.org > http://blog.nanthrax.net > Talend - http://www.talend.com >
Re: [VOTE] Apache Karaf 4.0.5 release (take 3)
Hi JB, +1 (non-binding) running on all our test installations now fine without problem since yesterday. Fabian On Mon, Apr 18, 2016 at 9:56 AM, Jean-Baptiste Onofré wrote: > Hi all, > > I submit Karaf Container 4.0.5 release to your vote. > > Release Note: > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140&version=12334629 > > Staging Repository: > https://repository.apache.org/content/repositories/orgapachekaraf-1061/ > > Git tag: > karaf-4.0.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 >
Re: [VOTE] Apache Karaf 4.0.5 release (take 2)
verified, no runtime downloads, everything as I like it, so +1 (non-binding) Fabian On Mon, Apr 4, 2016 at 10:38 PM, Jean-Baptiste Onofré wrote: > Hi all, > > I submit Karaf Container 4.0.5 release to your vote. > > Release Note: > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140&version=12334629 > > Staging Repository: > https://repository.apache.org/content/repositories/orgapachekaraf-1060/ > > Git tag: > karaf-4.0.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 >
Re: [CANCEL][VOTE] Apache Karaf 4.0.5 release
Yay
+1 already :)
Fabian
On Mon, Apr 4, 2016 at 10:21 PM, Jean-Baptiste Onofré
wrote:
> I did something more "drastic" to test:
> - remove all .m2/repository
> - edit etc/org.ops4j.pax.url.mvn.cfg and remove all repositories
>
> This way, if the artifact is not in system, I can see it.
>
> Actually, I already tested and reverted this afternoon. I also updated
> some dependencies just in time, like FileInstall (as you needed it ;)).
>
> Regards
> JB
>
> On 04/04/2016 09:37 PM, Fabian Lange wrote:
>
>> Hi,
>> thanks for taking care, JB!
>>
>> I can share with you how I can easily discover such stuff:
>> My etc/org.ops4j.pax.url.mvn.cfg looks like this:
>>
>>
>> org.ops4j.pax.url.mvn.defaultRepositories=file:${karaf.home}/${karaf.default.repository}@id
>> =system.repository@snapshots
>> org.ops4j.pax.url.mvn.settings=${karaf.etc}/mvn-settings.xml
>>
>> and the mvn-settings.xml looks like this:
>>
>> http://maven.apache.org/SETTINGS/1.0.0";
>>xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>>xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
>>
>> http://maven.apache.org/xsd/settings-1.0.0.xsd
>> ">
>>data/repo
>>
>>
>> This way, all at runtime downloaded stuff goes into data/repo and I can
>> easily check if this is ok, or was supposed to be packaged into the
>> distribution at build time
>>
>> Hope that helps,
>> Fabian
>>
>> On Mon, Apr 4, 2016 at 2:48 PM, Jean-Baptiste Onofré
>> wrote:
>>
>> Due to the discussion and -1, I cancel this release to prepare a new one.
>>>
>>> Regards
>>> JB
>>>
>>> On 04/01/2016 03:23 AM, Jean-Baptiste Onofré wrote:
>>>
>>> Hi all,
>>>>
>>>> I submit Karaf Container 4.0.5 release to your vote.
>>>>
>>>> Release Note:
>>>>
>>>>
>>>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140&version=12334629
>>>>
>>>>
>>>> Staging Repository:
>>>> https://repository.apache.org/content/repositories/orgapachekaraf-1059/
>>>>
>>>> Git tag:
>>>> karaf-4.0.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
>>>
>>>
>>
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
Re: [CANCEL][VOTE] Apache Karaf 4.0.5 release
Hi,
thanks for taking care, JB!
I can share with you how I can easily discover such stuff:
My etc/org.ops4j.pax.url.mvn.cfg looks like this:
org.ops4j.pax.url.mvn.defaultRepositories=file:${karaf.home}/${karaf.default.repository}@id
=system.repository@snapshots
org.ops4j.pax.url.mvn.settings=${karaf.etc}/mvn-settings.xml
and the mvn-settings.xml looks like this:
http://maven.apache.org/SETTINGS/1.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
http://maven.apache.org/xsd/settings-1.0.0.xsd
">
data/repo
This way, all at runtime downloaded stuff goes into data/repo and I can
easily check if this is ok, or was supposed to be packaged into the
distribution at build time
Hope that helps,
Fabian
On Mon, Apr 4, 2016 at 2:48 PM, Jean-Baptiste Onofré
wrote:
> Due to the discussion and -1, I cancel this release to prepare a new one.
>
> Regards
> JB
>
> On 04/01/2016 03:23 AM, Jean-Baptiste Onofré wrote:
>
>> Hi all,
>>
>> I submit Karaf Container 4.0.5 release to your vote.
>>
>> Release Note:
>>
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140&version=12334629
>>
>>
>> Staging Repository:
>> https://repository.apache.org/content/repositories/orgapachekaraf-1059/
>>
>> Git tag:
>> karaf-4.0.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
>
Re: [VOTE] Apache Karaf 4.0.5 release
Hi, i wouldn't veto the release. it is still an improvement for me. As you can see 4255 was originally opened by me (could not find it yesterday). I already worked around this problem one way, now i work around it another way. I am not sure what the percentage of custom distributions is, especially ones leaving out stuff involved in conditionals, but I would rather just document it with the release. Of course still looking forward to resolving the resolving issue :) Because of that I vote +1 (non-binding) Fabian On Sun, Apr 3, 2016 at 12:13 PM, Christian Schneider < ch...@die-schneider.net> wrote: > I think the issue you see is related to > https://issues.apache.org/jira/browse/KARAF-4255 . > It seems karaf needs the conditional bundles when doing the resolve. So I > am in favour of reverting the change and look into the change above for > next > release with the goal of making it work completely. > > So I propose to roll back the change and create a new release without it > for 4.0.5. If JB does not have the time I can take care of that. > > Christian > > 2016-04-02 22:41 GMT+02:00 Fabian Lange : > > > Guess thats it: > > > > > https://github.com/apache/karaf/commit/1b7ddc8e1da0f6d70586c7b76f4992a3f0c64f52 > > > > i would love to keep the new behaviour, as it doesn't bloat my > > distribution with stuff i do not need, but the runtime should not > download > > it then when running. > > > > Fabian > > > > On Sat, Apr 2, 2016 at 10:33 PM, Fabian Lange < > fabian.la...@codecentric.de > > > wrote: > > > >> just checked with 4.0.4 > >> In 4.0.4 the (unnecessary) conditional dependency is packaged into > system > >> directory of distribution. > >> So i would qualify this as regression. > >> > >> Fabian > >> > >> > >> On Sat, Apr 2, 2016 at 10:24 PM, Fabian Lange < > >> fabian.la...@codecentric.de> wrote: > >> > >>> Yes, not sure if this is a regression. > >>> > >>> I have "jaas" but not "aries-blueprint" still this jar is downloaded: > >>> > >>> aries-blueprint > >>>>>> > start="true">mvn:org.apache.karaf.jaas.blueprint/org.apache.karaf.jaas.blueprint.config/4.0.5 > >>> > >>> > >>> i have "scr" but neither "management" nor "webconsole, yet these > >>> download: > >>> > >>> > >>> management > >>> >>> > start-level="30">mvn:org.apache.karaf.scr/org.apache.karaf.scr.management/4.0.5 > >>> > >>> > >>> webconsole > >>> >>> > start-level="30">mvn:org.apache.felix/org.apache.felix.inventory/1.0.4 > >>> >>> > start-level="30">mvn:org.apache.felix/org.apache.felix.webconsole.plugins.ds/2.0.2 > >>> > >>> > >>> if it is not a regression this should not block the release, but it > >>> should be fixed. > >>> > >>> Fabian > >>> > >>> > >>> On Sat, Apr 2, 2016 at 10:19 PM, Fabian Lange < > >>> fabian.la...@codecentric.de> wrote: > >>> > >>>> Ok, this was with > >>>> true > >>>> > >>>> with > >>>> false > >>>> > >>>> it still is missing some stuff which is downloaded at runtime: > >>>> [image: Inline image 1] > >>>> > >>>> These seem to be conditional plugins, however none of the conditions > is > >>>> true :( > >>>> Fabian > >>>> > >>>> On Sat, Apr 2, 2016 at 9:57 PM, Fabian Lange < > >>>> fabian.la...@codecentric.de> wrote: > >>>> > >>>>> Hi, > >>>>> i am currently trying to get my custom distribution running. > >>>>> Usually a lot of stuff is put into the system folder, however after > >>>>> the upgrade a lot of dependencies are downloaded at startup, so my > >>>>> distribution was lacking them. > >>>>> > >>>>> here is a screenshot of the libs downloaded after start, not part of > >>>>> my distribution: > >>>>> [image: Inline image 1] > >>>>> > >>>>> I assume some feature definition is not respect
Re: [VOTE] Apache Karaf 4.0.5 release
Nope, the 4.0.5 plugin will not put them in the systems folder because it evaluates the conditional correctly. but at runtime even though the conditional is false, they are downloaded. The 4.0.4 plugin will incorrectly put them into systems, which prevents the download at runtime Fabian On Sat, Apr 2, 2016 at 10:53 PM, Jean-Baptiste Onofré wrote: > > > Hi Fabian > You mean that karaf download the artifacts even if they are in system > folder ???!! I didn't see this behavior. > RegardsJB > > > Sent from my Samsung device > > ---- Original message > From: Fabian Lange > Date: 02/04/2016 22:41 (GMT+01:00) > To: dev@karaf.apache.org > Subject: Re: [VOTE] Apache Karaf 4.0.5 release > > Guess thats it: > https://github.com/apache/karaf/commit/1b7ddc8e1da0f6d70586c7b76f4992a3f0c64f52 > > i would love to keep the new behaviour, as it doesn't bloat my > distribution with stuff i do not need, but the runtime should not download > it then when running. > Fabian > > On Sat, Apr 2, 2016 at 10:33 PM, Fabian Lange > wrote: > just checked with 4.0.4In 4.0.4 the (unnecessary) conditional dependency > is packaged into system directory of distribution.So i would qualify this > as regression. > Fabian > > > On Sat, Apr 2, 2016 at 10:24 PM, Fabian Lange > wrote: > Yes, not sure if this is a regression. > I have "jaas" but not "aries-blueprint" still this jar is > downloaded: aries-blueprint start-level="30" > start="true">mvn:org.apache.karaf.jaas.blueprint/org.apache.karaf.jaas.blueprint.config/4.0.5 > > i have "scr" but neither "management" nor "webconsole, yet these download: > management > start-level="30">mvn:org.apache.karaf.scr/org.apache.karaf.scr.management/4.0.5 > > webconsole start-level="30">mvn:org.apache.felix/org.apache.felix.inventory/1.0.4 > start-level="30">mvn:org.apache.felix/org.apache.felix.webconsole.plugins.ds/2.0.2 > > if it is not a regression this should not block the release, but it should > be fixed. > Fabian > > > On Sat, Apr 2, 2016 at 10:19 PM, Fabian Lange > wrote: > Ok, this was with > true > with false > it still is missing some stuff which is downloaded at runtime: > > These seem to be conditional plugins, however none of the conditions is > true :(Fabian > > On Sat, Apr 2, 2016 at 9:57 PM, Fabian Lange > wrote: > Hi,i am currently trying to get my custom distribution running.Usually a > lot of stuff is put into the system folder, however after the upgrade a lot > of dependencies are downloaded at startup, so my distribution was lacking > them. > > > here is a screenshot of the libs downloaded after start, not part of my > distribution: > I assume some feature definition is not respected correctly? > Fabian > > On Fri, Apr 1, 2016 at 3:23 AM, Jean-Baptiste Onofré > wrote: > Hi all, > > > > I submit Karaf Container 4.0.5 release to your vote. > > > > Release Note: > > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140&version=12334629 > > > > Staging Repository: > > https://repository.apache.org/content/repositories/orgapachekaraf-1059/ > > > > Git tag: > > karaf-4.0.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 > > > > > > > > > > > >
Re: [VOTE] Apache Karaf 4.0.5 release
Guess thats it: https://github.com/apache/karaf/commit/1b7ddc8e1da0f6d70586c7b76f4992a3f0c64f52 i would love to keep the new behaviour, as it doesn't bloat my distribution with stuff i do not need, but the runtime should not download it then when running. Fabian On Sat, Apr 2, 2016 at 10:33 PM, Fabian Lange wrote: > just checked with 4.0.4 > In 4.0.4 the (unnecessary) conditional dependency is packaged into system > directory of distribution. > So i would qualify this as regression. > > Fabian > > > On Sat, Apr 2, 2016 at 10:24 PM, Fabian Lange > wrote: > >> Yes, not sure if this is a regression. >> >> I have "jaas" but not "aries-blueprint" still this jar is downloaded: >> >> aries-blueprint >> > start="true">mvn:org.apache.karaf.jaas.blueprint/org.apache.karaf.jaas.blueprint.config/4.0.5 >> >> >> i have "scr" but neither "management" nor "webconsole, yet these download: >> >> >> management >> > start-level="30">mvn:org.apache.karaf.scr/org.apache.karaf.scr.management/4.0.5 >> >> >> webconsole >> > start-level="30">mvn:org.apache.felix/org.apache.felix.inventory/1.0.4 >> > start-level="30">mvn:org.apache.felix/org.apache.felix.webconsole.plugins.ds/2.0.2 >> >> >> if it is not a regression this should not block the release, but it >> should be fixed. >> >> Fabian >> >> >> On Sat, Apr 2, 2016 at 10:19 PM, Fabian Lange < >> fabian.la...@codecentric.de> wrote: >> >>> Ok, this was with >>> true >>> >>> with >>> false >>> >>> it still is missing some stuff which is downloaded at runtime: >>> [image: Inline image 1] >>> >>> These seem to be conditional plugins, however none of the conditions is >>> true :( >>> Fabian >>> >>> On Sat, Apr 2, 2016 at 9:57 PM, Fabian Lange < >>> fabian.la...@codecentric.de> wrote: >>> >>>> Hi, >>>> i am currently trying to get my custom distribution running. >>>> Usually a lot of stuff is put into the system folder, however after the >>>> upgrade a lot of dependencies are downloaded at startup, so my distribution >>>> was lacking them. >>>> >>>> here is a screenshot of the libs downloaded after start, not part of my >>>> distribution: >>>> [image: Inline image 1] >>>> >>>> I assume some feature definition is not respected correctly? >>>> >>>> Fabian >>>> >>>> >>>> On Fri, Apr 1, 2016 at 3:23 AM, Jean-Baptiste Onofré >>>> wrote: >>>> >>>>> Hi all, >>>>> >>>>> I submit Karaf Container 4.0.5 release to your vote. >>>>> >>>>> Release Note: >>>>> >>>>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140&version=12334629 >>>>> >>>>> Staging Repository: >>>>> https://repository.apache.org/content/repositories/orgapachekaraf-1059/ >>>>> >>>>> Git tag: >>>>> karaf-4.0.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 >>>>> >>>> >>>> >>> >> >
Re: [VOTE] Apache Karaf 4.0.5 release
just checked with 4.0.4 In 4.0.4 the (unnecessary) conditional dependency is packaged into system directory of distribution. So i would qualify this as regression. Fabian On Sat, Apr 2, 2016 at 10:24 PM, Fabian Lange wrote: > Yes, not sure if this is a regression. > > I have "jaas" but not "aries-blueprint" still this jar is downloaded: > > aries-blueprint >start="true">mvn:org.apache.karaf.jaas.blueprint/org.apache.karaf.jaas.blueprint.config/4.0.5 > > > i have "scr" but neither "management" nor "webconsole, yet these download: > > > management > start-level="30">mvn:org.apache.karaf.scr/org.apache.karaf.scr.management/4.0.5 > > > webconsole > start-level="30">mvn:org.apache.felix/org.apache.felix.inventory/1.0.4 > start-level="30">mvn:org.apache.felix/org.apache.felix.webconsole.plugins.ds/2.0.2 > > > if it is not a regression this should not block the release, but it should > be fixed. > > Fabian > > > On Sat, Apr 2, 2016 at 10:19 PM, Fabian Lange > wrote: > >> Ok, this was with >> true >> >> with >> false >> >> it still is missing some stuff which is downloaded at runtime: >> [image: Inline image 1] >> >> These seem to be conditional plugins, however none of the conditions is >> true :( >> Fabian >> >> On Sat, Apr 2, 2016 at 9:57 PM, Fabian Lange > > wrote: >> >>> Hi, >>> i am currently trying to get my custom distribution running. >>> Usually a lot of stuff is put into the system folder, however after the >>> upgrade a lot of dependencies are downloaded at startup, so my distribution >>> was lacking them. >>> >>> here is a screenshot of the libs downloaded after start, not part of my >>> distribution: >>> [image: Inline image 1] >>> >>> I assume some feature definition is not respected correctly? >>> >>> Fabian >>> >>> >>> On Fri, Apr 1, 2016 at 3:23 AM, Jean-Baptiste Onofré >>> wrote: >>> >>>> Hi all, >>>> >>>> I submit Karaf Container 4.0.5 release to your vote. >>>> >>>> Release Note: >>>> >>>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140&version=12334629 >>>> >>>> Staging Repository: >>>> https://repository.apache.org/content/repositories/orgapachekaraf-1059/ >>>> >>>> Git tag: >>>> karaf-4.0.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 >>>> >>> >>> >> >
Re: [VOTE] Apache Karaf 4.0.5 release
Yes, not sure if this is a regression. I have "jaas" but not "aries-blueprint" still this jar is downloaded: aries-blueprint mvn:org.apache.karaf.jaas.blueprint/org.apache.karaf.jaas.blueprint.config/4.0.5 i have "scr" but neither "management" nor "webconsole, yet these download: management mvn:org.apache.karaf.scr/org.apache.karaf.scr.management/4.0.5 webconsole mvn:org.apache.felix/org.apache.felix.inventory/1.0.4 mvn:org.apache.felix/org.apache.felix.webconsole.plugins.ds/2.0.2 if it is not a regression this should not block the release, but it should be fixed. Fabian On Sat, Apr 2, 2016 at 10:19 PM, Fabian Lange wrote: > Ok, this was with > true > > with > false > > it still is missing some stuff which is downloaded at runtime: > [image: Inline image 1] > > These seem to be conditional plugins, however none of the conditions is > true :( > Fabian > > On Sat, Apr 2, 2016 at 9:57 PM, Fabian Lange > wrote: > >> Hi, >> i am currently trying to get my custom distribution running. >> Usually a lot of stuff is put into the system folder, however after the >> upgrade a lot of dependencies are downloaded at startup, so my distribution >> was lacking them. >> >> here is a screenshot of the libs downloaded after start, not part of my >> distribution: >> [image: Inline image 1] >> >> I assume some feature definition is not respected correctly? >> >> Fabian >> >> >> On Fri, Apr 1, 2016 at 3:23 AM, Jean-Baptiste Onofré >> wrote: >> >>> Hi all, >>> >>> I submit Karaf Container 4.0.5 release to your vote. >>> >>> Release Note: >>> >>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140&version=12334629 >>> >>> Staging Repository: >>> https://repository.apache.org/content/repositories/orgapachekaraf-1059/ >>> >>> Git tag: >>> karaf-4.0.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 >>> >> >> >
Re: [VOTE] Apache Karaf 4.0.5 release
Ok, this was with true with false it still is missing some stuff which is downloaded at runtime: [image: Inline image 1] These seem to be conditional plugins, however none of the conditions is true :( Fabian On Sat, Apr 2, 2016 at 9:57 PM, Fabian Lange wrote: > Hi, > i am currently trying to get my custom distribution running. > Usually a lot of stuff is put into the system folder, however after the > upgrade a lot of dependencies are downloaded at startup, so my distribution > was lacking them. > > here is a screenshot of the libs downloaded after start, not part of my > distribution: > [image: Inline image 1] > > I assume some feature definition is not respected correctly? > > Fabian > > > On Fri, Apr 1, 2016 at 3:23 AM, Jean-Baptiste Onofré > wrote: > >> Hi all, >> >> I submit Karaf Container 4.0.5 release to your vote. >> >> Release Note: >> >> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140&version=12334629 >> >> Staging Repository: >> https://repository.apache.org/content/repositories/orgapachekaraf-1059/ >> >> Git tag: >> karaf-4.0.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 >> > >
Re: [VOTE] Apache Karaf 4.0.5 release
Hi, i am currently trying to get my custom distribution running. Usually a lot of stuff is put into the system folder, however after the upgrade a lot of dependencies are downloaded at startup, so my distribution was lacking them. here is a screenshot of the libs downloaded after start, not part of my distribution: [image: Inline image 1] I assume some feature definition is not respected correctly? Fabian On Fri, Apr 1, 2016 at 3:23 AM, Jean-Baptiste Onofré wrote: > Hi all, > > I submit Karaf Container 4.0.5 release to your vote. > > Release Note: > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140&version=12334629 > > Staging Repository: > https://repository.apache.org/content/repositories/orgapachekaraf-1059/ > > Git tag: > karaf-4.0.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 >
Re: AutoEncryptionSupport Thread running always?
Thank you! I hope my push was correct. First time using the ASF automation. Are you guys all using password prompts in git, or can I teach the asf git to take my ssh key? Fabian On Mon, Mar 28, 2016 at 11:21 AM, Jean-Baptiste Onofré wrote: > Hi Fabian, > > I quickly reviewed your change, and it looks good to me (I added a comment > in the PR). > > So you can merge IMHO. > > Thanks, > Regards > JB > > > On 03/28/2016 11:19 AM, Fabian Lange wrote: > >> Hi All, >> what is the desired review procedure? >> Shall I just go ahead and merge the change? >> >> Fabian >> >> On Wed, Mar 16, 2016 at 10:24 AM, Fabian Lange < >> fabian.la...@codecentric.de> >> wrote: >> >> Hi Guillaume, >>> thanks for the quick reply. >>> I made a ticket (KARAF-4423) and proposed a solution in >>> https://github.com/apache/karaf/pull/164 >>> >>> This also fixes the service not shutting down, because the wrong field >>> was >>> volatile (the boolean stop flag needs to be volatile, otherwise it is >>> cached by the other thread) >>> >>> Fabian >>> >>> On Wed, Mar 16, 2016 at 9:20 AM, Guillaume Nodet >>> wrote: >>> >>> Yeah, we could make the code a bit smarter and avoid starting the thread >>>> if >>>> we know the encryption support is disabled. >>>> Checking with the following code inside a try / catch block should do >>>> the >>>> trick imho >>>> encryptionSupport.getEncryption() != null >>>> >>>> >>>> 2016-03-16 8:36 GMT+01:00 Fabian Lange : >>>> >>>> Hi, >>>>> >>>>> is there a reason why said thread always runs? >>>>> at >>>>> >>>>> >>>>> >>>> org.apache.karaf.jaas.modules.properties.AutoEncryptionSupport.run(AutoEncryptionSupport.java:78) >>>> >>>>> >>>>> in org.apache.karaf.jaas.cfg i have >>>>> >>>>> encryption.enabled = false >>>>> >>>>> >>>>> and I think that means the thread does not need to run. Reason for >>>>> >>>> asking >>>> >>>>> is that I want to cut down on unnecessary threads >>>>> >>>>> >>>>> Fabian >>>>> >>>>> >>>> >>>> >>>> -- >>>> >>>> Guillaume Nodet >>>> >>>> Red Hat, Open Source Integration >>>> >>>> Email: gno...@redhat.com >>>> Web: http://fusesource.com >>>> Blog: http://gnodet.blogspot.com/ >>>> >>>> >>> >>> >> > -- > Jean-Baptiste Onofré > jbono...@apache.org > http://blog.nanthrax.net > Talend - http://www.talend.com >
Re: AutoEncryptionSupport Thread running always?
Hi All, what is the desired review procedure? Shall I just go ahead and merge the change? Fabian On Wed, Mar 16, 2016 at 10:24 AM, Fabian Lange wrote: > Hi Guillaume, > thanks for the quick reply. > I made a ticket (KARAF-4423) and proposed a solution in > https://github.com/apache/karaf/pull/164 > > This also fixes the service not shutting down, because the wrong field was > volatile (the boolean stop flag needs to be volatile, otherwise it is > cached by the other thread) > > Fabian > > On Wed, Mar 16, 2016 at 9:20 AM, Guillaume Nodet > wrote: > >> Yeah, we could make the code a bit smarter and avoid starting the thread >> if >> we know the encryption support is disabled. >> Checking with the following code inside a try / catch block should do the >> trick imho >> encryptionSupport.getEncryption() != null >> >> >> 2016-03-16 8:36 GMT+01:00 Fabian Lange : >> >> > Hi, >> > >> > is there a reason why said thread always runs? >> > at >> > >> > >> org.apache.karaf.jaas.modules.properties.AutoEncryptionSupport.run(AutoEncryptionSupport.java:78) >> > >> > in org.apache.karaf.jaas.cfg i have >> > >> > encryption.enabled = false >> > >> > >> > and I think that means the thread does not need to run. Reason for >> asking >> > is that I want to cut down on unnecessary threads >> > >> > >> > Fabian >> > >> >> >> >> -- >> >> Guillaume Nodet >> >> Red Hat, Open Source Integration >> >> Email: gno...@redhat.com >> Web: http://fusesource.com >> Blog: http://gnodet.blogspot.com/ >> > >
Re: AutoEncryptionSupport Thread running always?
Hi Guillaume, thanks for the quick reply. I made a ticket (KARAF-4423) and proposed a solution in https://github.com/apache/karaf/pull/164 This also fixes the service not shutting down, because the wrong field was volatile (the boolean stop flag needs to be volatile, otherwise it is cached by the other thread) 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 On Wed, Mar 16, 2016 at 9:20 AM, Guillaume Nodet wrote: > Yeah, we could make the code a bit smarter and avoid starting the thread if > we know the encryption support is disabled. > Checking with the following code inside a try / catch block should do the > trick imho >encryptionSupport.getEncryption() != null > > > 2016-03-16 8:36 GMT+01:00 Fabian Lange : > > > Hi, > > > > is there a reason why said thread always runs? > > at > > > > > org.apache.karaf.jaas.modules.properties.AutoEncryptionSupport.run(AutoEncryptionSupport.java:78) > > > > in org.apache.karaf.jaas.cfg i have > > > > encryption.enabled = false > > > > > > and I think that means the thread does not need to run. Reason for asking > > is that I want to cut down on unnecessary threads > > > > > > Fabian > > > > > > -- > > Guillaume Nodet > > Red Hat, Open Source Integration > > Email: gno...@redhat.com > Web: http://fusesource.com > Blog: http://gnodet.blogspot.com/ >
AutoEncryptionSupport Thread running always?
Hi, is there a reason why said thread always runs? at org.apache.karaf.jaas.modules.properties.AutoEncryptionSupport.run(AutoEncryptionSupport.java:78) in org.apache.karaf.jaas.cfg i have encryption.enabled = false and I think that means the thread does not need to run. Reason for asking is that I want to cut down on unnecessary threads Fabian
Re: Roadmap and releases schedule
Hi JB, are you considering https://github.com/apache/karaf/pull/138 for inclusion into 4.0.5? Fabian On Wed, Feb 3, 2016 at 7:36 AM, Jean-Baptiste Onofré wrote: > By the way 4.0.5 will be in preparation next week as well. > > Regards > JB > > > On 02/03/2016 07:32 AM, Jean-Baptiste Onofré wrote: > >> Hi all, >> >> I would like to provide a quick update about the releases schedule (it's >> not up to date on the current website, but it is on the new one). >> >> 1. New website: as I said yesterday, it's mostly done, I'm adding the >> last content. I should be able to promote the new website tonight or >> tomorrow. >> 2. Decanter 1.0.2: I would like to release Decanter 1.0.2 during the >> week end or beginning of next week. It will include refactorings >> (marshaller service), bug fixes (timestamp, JDBC appender, etc), new >> features (new appenders for kafka, mongodb, etc). >> 3. Cellar 4.0.1 planned middle of next week, including mostly bug fixes >> and couple of new features (cluster:status, etc). >> 4. Karaf 3.0.6: I fixed issues on the 3.x branch. Hopefully, I should be >> able to propose 3.0.6 to vote for the end of this week. >> 5. Master is now 4.1.0-SNAPSHOT. I think we could include karaf-boot >> there and start "major" dependency updates. It's also where I'm doing >> the complete dev guide refactoring, replacing the existing demos with >> bunch of samples. >> >> Thoughts ? >> Regards >> JB >> > > -- > Jean-Baptiste Onofré > jbono...@apache.org > http://blog.nanthrax.net > Talend - http://www.talend.com >
Re: Null Pointer on Feature install
Hi JB,
yes, Its possible that some installs are slower, but the initial install is
one doProvision command, so I doubt that this is noticeable, and the race
conditions I observed show that it actually is not safe (which could be
fixed, but my proposal is faster to implement).
I also noticed that there is probably excessive parsing of bundles, which I
was unable to fix so far (not a real problem except for startup speed)
https://github.com/apache/karaf/blob/master/features/core/src/main/java/org/apache/karaf/features/internal/region/Subsystem.java#L355
Subsystem#downloadBundles is recursively invoked.
The first subsystem is root, the children are all the karaf standard
features.
What is happening is that recursively download tasks are created. What this
means is that if subsystem A has a dependency to X and subsystem B has a
dependency to X, then X will be downloaded twice. Actually it might not be
downloaded twice due to policy, but at least the jar is scanned twice and
the metadata is extracted twice.
With the amount of interdependencies, this is actually quite excessive.
According to my profiling certain karaf dependencies are attempted to
download and verified a couple hundred times.
What could be done is that maybe the subsystem dependency graph is carried
over to the next subsystem, avoiding to rebuild it again.
An easier fix would be to within each subsystem first collect all locations
for "downloader.download(loc, new DownloadCallback() {}" before actually
triggering the download and its callback. But I found that this is not so
effective, as the overlap is mostly between subsystems, not within.
Anybody thinks it could be possible to share the "bundles" state between
subsystems, so that multiple downloads for the same bundle can be avoided?
Fabian
PS: There a a couple ways to see the problem. For example, just log out the
location passed
into
org.apache.karaf.features.internal.download.impl.MavenDownloadManager.MavenDownloader.download(String,
DownloadCallback) - you will see the same urls over and over.
On Wed, Jan 27, 2016 at 6:53 AM, Jean-Baptiste Onofré
wrote:
> Hi Fabian,
>
> I quick take a look on your PR and it looks good to me. I think your usage
> of the ExecutorService single thread instead of cached thread pool makes
> sense. The only "impact" that I would like to evaluate is when the resolver
> has to install "lot of" features in the same time. However, the impact is
> probably just the installation time will be a bit long, but on the other
> hand more reliable, so not a big deal ;)
>
> Let me run some tests on your PR.
>
> Thanks !
> Regards
> JB
>
>
> On 01/26/2016 10:57 PM, Fabian Lange wrote:
>
>> Hi JB,
>> it turns out this is most likely the old Issue I reported once. Having now
>> more insights into what should be done, I propose this solution:
>> https://github.com/apache/karaf/pull/138
>>
>> It basically ensures that only one provision is concurrently executing.
>> What do you think?
>>
>> Fabian
>>
>>
>> On Tue, Jan 26, 2016 at 10:19 PM, Fabian Lange <
>> fabian.la...@codecentric.de>
>> wrote:
>>
>> Hi JB,
>>> not really reproducable. We had this before, and I then introduced a
>>> locking abstraction around the features manager. This is a programmatic
>>> installation of features. So I assume that features are no longer
>>> installed
>>> concurrently.
>>>
>>> However it might race with karaf/felix bootstrap and feature
>>> installation.
>>> I only synchronized my installation
>>>
>>> What I do, is that I add a feature repository, then do a foreach and add
>>> the requirements, then fire off the install
>>>
>>> Fabian
>>>
>>>
>>> On Tue, Jan 26, 2016 at 10:16 PM, Jean-Baptiste Onofré
>>> wrote:
>>>
>>> It sounds like concurrent update of feature state in the store.
>>>>
>>>> Does it mean users install/uninstall multiple features in the same time
>>>> ?
>>>>
>>>> Any use case to reproduce it ?
>>>>
>>>> Thanks
>>>> Regards
>>>> JB
>>>>
>>>>
>>>> On 01/26/2016 09:18 PM, Fabian Lange wrote:
>>>>
>>>> Hi all,
>>>>> I am seeing a significant amount of following stacktraces reported by
>>>>> our
>>>>> users. they seem to go away with restarting, so it looks like a leak or
>>>>> race condition to me:
>>>>>
>>>>> java.lang.NullPointerException
>>>>>
>>>>> at
>>>>> java
Re: Null Pointer on Feature install
Hi JB, it turns out this is most likely the old Issue I reported once. Having now more insights into what should be done, I propose this solution: https://github.com/apache/karaf/pull/138 It basically ensures that only one provision is concurrently executing. What do you think? Fabian On Tue, Jan 26, 2016 at 10:19 PM, Fabian Lange wrote: > Hi JB, > not really reproducable. We had this before, and I then introduced a > locking abstraction around the features manager. This is a programmatic > installation of features. So I assume that features are no longer installed > concurrently. > > However it might race with karaf/felix bootstrap and feature installation. > I only synchronized my installation > > What I do, is that I add a feature repository, then do a foreach and add > the requirements, then fire off the install > > Fabian > > > On Tue, Jan 26, 2016 at 10:16 PM, Jean-Baptiste Onofré > wrote: > >> It sounds like concurrent update of feature state in the store. >> >> Does it mean users install/uninstall multiple features in the same time ? >> >> Any use case to reproduce it ? >> >> Thanks >> Regards >> JB >> >> >> On 01/26/2016 09:18 PM, Fabian Lange wrote: >> >>> Hi all, >>> I am seeing a significant amount of following stacktraces reported by our >>> users. they seem to go away with restarting, so it looks like a leak or >>> race condition to me: >>> >>> java.lang.NullPointerException >>> >>> at >>> java.io.FileOutputStream.(FileOutputStream.java:203)[:1.8.0_72] >>> >>> at >>> java.io.FileOutputStream.(FileOutputStream.java:162)[:1.8.0_72] >>> >>> at >>> org.apache.karaf.features.internal.osgi.Activator$1.getOutputStream(Activator.java:197)[7:org.apache.karaf.features.core:4.0.4] >>> >>> at >>> org.apache.karaf.features.internal.service.StateStorage.save(StateStorage.java:56)[7:org.apache.karaf.features.core:4.0.4] >>> >>> at >>> org.apache.karaf.features.internal.service.FeaturesServiceImpl.saveState(FeaturesServiceImpl.java:297)[7:org.apache.karaf.features.core:4.0.4] >>> >>> at >>> org.apache.karaf.features.internal.service.FeaturesServiceImpl.saveState(FeaturesServiceImpl.java:1154)[7:org.apache.karaf.features.core:4.0.4] >>> >>> at >>> org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:764)[7:org.apache.karaf.features.core:4.0.4] >>> >>> at >>> org.apache.karaf.features.internal.service.FeaturesServiceImpl.doProvision(FeaturesServiceImpl.java:1089)[7:org.apache.karaf.features.core:4.0.4] >>> >>> at >>> org.apache.karaf.features.internal.service.FeaturesServiceImpl$1.call(FeaturesServiceImpl.java:985)[7:org.apache.karaf.features.core:4.0.4] >>> >>> at >>> java.util.concurrent.FutureTask.run(FutureTask.java:266)[:1.8.0_72] >>> >>> at >>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)[:1.8.0_72] >>> >>> at >>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)[:1.8.0_72] >>> >>> at java.lang.Thread.run(Thread.java:745)[:1.8.0_72] >>> >>> >>> the NPE is caused by bundleContex.getDataFile(state.json) returning null. >>> The javadoc says that this could be possible, but because it works most >>> of >>> the time I speculate this might be actally a race condition, or maybe >>> leaked filehandles somewhere. >>> Anybody got pointers or ideas? >>> I am willing to make a fix, but I need to understand this more >>> >>> Fabian >>> >>> >> -- >> Jean-Baptiste Onofré >> jbono...@apache.org >> http://blog.nanthrax.net >> Talend - http://www.talend.com >> > >
Re: Null Pointer on Feature install
Hi JB, not really reproducable. We had this before, and I then introduced a locking abstraction around the features manager. This is a programmatic installation of features. So I assume that features are no longer installed concurrently. However it might race with karaf/felix bootstrap and feature installation. I only synchronized my installation What I do, is that I add a feature repository, then do a foreach and add the requirements, then fire off the install Fabian On Tue, Jan 26, 2016 at 10:16 PM, Jean-Baptiste Onofré wrote: > It sounds like concurrent update of feature state in the store. > > Does it mean users install/uninstall multiple features in the same time ? > > Any use case to reproduce it ? > > Thanks > Regards > JB > > > On 01/26/2016 09:18 PM, Fabian Lange wrote: > >> Hi all, >> I am seeing a significant amount of following stacktraces reported by our >> users. they seem to go away with restarting, so it looks like a leak or >> race condition to me: >> >> java.lang.NullPointerException >> >> at >> java.io.FileOutputStream.(FileOutputStream.java:203)[:1.8.0_72] >> >> at >> java.io.FileOutputStream.(FileOutputStream.java:162)[:1.8.0_72] >> >> at >> org.apache.karaf.features.internal.osgi.Activator$1.getOutputStream(Activator.java:197)[7:org.apache.karaf.features.core:4.0.4] >> >> at >> org.apache.karaf.features.internal.service.StateStorage.save(StateStorage.java:56)[7:org.apache.karaf.features.core:4.0.4] >> >> at >> org.apache.karaf.features.internal.service.FeaturesServiceImpl.saveState(FeaturesServiceImpl.java:297)[7:org.apache.karaf.features.core:4.0.4] >> >> at >> org.apache.karaf.features.internal.service.FeaturesServiceImpl.saveState(FeaturesServiceImpl.java:1154)[7:org.apache.karaf.features.core:4.0.4] >> >> at >> org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:764)[7:org.apache.karaf.features.core:4.0.4] >> >> at >> org.apache.karaf.features.internal.service.FeaturesServiceImpl.doProvision(FeaturesServiceImpl.java:1089)[7:org.apache.karaf.features.core:4.0.4] >> >> at >> org.apache.karaf.features.internal.service.FeaturesServiceImpl$1.call(FeaturesServiceImpl.java:985)[7:org.apache.karaf.features.core:4.0.4] >> >> at >> java.util.concurrent.FutureTask.run(FutureTask.java:266)[:1.8.0_72] >> >> at >> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)[:1.8.0_72] >> >> at >> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)[:1.8.0_72] >> >> at java.lang.Thread.run(Thread.java:745)[:1.8.0_72] >> >> >> the NPE is caused by bundleContex.getDataFile(state.json) returning null. >> The javadoc says that this could be possible, but because it works most of >> the time I speculate this might be actally a race condition, or maybe >> leaked filehandles somewhere. >> Anybody got pointers or ideas? >> I am willing to make a fix, but I need to understand this more >> >> Fabian >> >> > -- > Jean-Baptiste Onofré > jbono...@apache.org > http://blog.nanthrax.net > Talend - http://www.talend.com >
Null Pointer on Feature install
Hi all, I am seeing a significant amount of following stacktraces reported by our users. they seem to go away with restarting, so it looks like a leak or race condition to me: java.lang.NullPointerException at java.io.FileOutputStream.(FileOutputStream.java:203)[:1.8.0_72] at java.io.FileOutputStream.(FileOutputStream.java:162)[:1.8.0_72] at org.apache.karaf.features.internal.osgi.Activator$1.getOutputStream(Activator.java:197)[7:org.apache.karaf.features.core:4.0.4] at org.apache.karaf.features.internal.service.StateStorage.save(StateStorage.java:56)[7:org.apache.karaf.features.core:4.0.4] at org.apache.karaf.features.internal.service.FeaturesServiceImpl.saveState(FeaturesServiceImpl.java:297)[7:org.apache.karaf.features.core:4.0.4] at org.apache.karaf.features.internal.service.FeaturesServiceImpl.saveState(FeaturesServiceImpl.java:1154)[7:org.apache.karaf.features.core:4.0.4] at org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:764)[7:org.apache.karaf.features.core:4.0.4] at org.apache.karaf.features.internal.service.FeaturesServiceImpl.doProvision(FeaturesServiceImpl.java:1089)[7:org.apache.karaf.features.core:4.0.4] at org.apache.karaf.features.internal.service.FeaturesServiceImpl$1.call(FeaturesServiceImpl.java:985)[7:org.apache.karaf.features.core:4.0.4] at java.util.concurrent.FutureTask.run(FutureTask.java:266)[:1.8.0_72] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)[:1.8.0_72] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)[:1.8.0_72] at java.lang.Thread.run(Thread.java:745)[:1.8.0_72] the NPE is caused by bundleContex.getDataFile(state.json) returning null. The javadoc says that this could be possible, but because it works most of the time I speculate this might be actally a race condition, or maybe leaked filehandles somewhere. Anybody got pointers or ideas? I am willing to make a fix, but I need to understand this more Fabian
Re: [VOTE] Apache Karaf 4.0.4 release
+1 (non-binding) I have created our custom assembly and it was successful and passes integration tests. While I yesterday discovered a problem with the feature dependencies, that is not a 4.0.4 specific regression, but seems to be a general problem, which should not affect this release only. What I noticed with 4.0.4 is that our assembly does not contain the following two bundles, which are downloaded at runtime: org/apache/felix/org.apache.felix.metatype/1.1.2/org.apache.felix.metatype-1.1.2.jar org/jledit/core/0.2.1/core-0.2.1.jar this might indicate a packaging problem however Fabian On Sun, Jan 10, 2016 at 6:10 PM, Jean-Baptiste Onofré wrote: > Hi all, > > I submit Karaf 4.0.4 release to your vote. > > Release Notes: > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140&version=12334047 > > Staging Repository: > https://repository.apache.org/content/repositories/orgapachekaraf-1054/ > > Git Tag: > karaf-4.0.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 >
Re: [PROPOSAL] Karaf marketing
Hi,
I did not want to comment, but my new involvement with Karaf demands for it
:)
The only thing I do not like as much is the homepage/landingpage/startpage.
The 3 columns do not attract me. The content could be a bit catchier, but
most importantly, I think the graphics (rubix, gears, cloud) do not make
much sense connected to the text. I would rather remove the graphics.
The scrolling "news" scroll too fast. Or better: unpredictably. Sometimes
they seem to be stuck, sometimes they move very fast. I think I would
rather prefer to navigate the news manually. Edit: oh i can swipe it
manually, guess that needs some kind of indication.
Overall it is much nicer and modern than the old site. great work
Fabian
On Sun, Jan 10, 2016 at 6:12 PM, Jean-Baptiste Onofré
wrote:
> I will start the vote for the new website tomorrow (I will update the
> website proposal tonight, I fixed couple of things).
>
> As reminder, there's the proposal website:
> http://maven.nanthrax.net/goodies/karaf/site/
>
> Regards
> JB
>
> On 01/07/2016 10:09 AM, Jean-Baptiste Onofré wrote:
>
>> It sounds good ;)
>>
>> Let me polish couple things (couple of links are broken) and I will
>> start the vote.
>>
>> Regards
>> JB
>>
>> On 01/07/2016 10:07 AM, Serge Huber wrote:
>>
>>>
>>> On 7 janv. 2016, at 08:05, Jean-Baptiste Onofré wrote:
Hi Serge,
I applied your two proposals and updated the website on my server.
>>>
>>> Just saw that, very cool !
>>>
>>>
It looks better to me as well (I don't see a huge change about
line-height, but border-radius is fine).
>>>
>>> The line-height fixes the problem of the list on the home page under
>>> “Projects” that has the lines too close together because the
>>> line-height was set to 20px and the font-size is 18px, leaving only
>>> 2px between lines. Letting it back to its default fixes that problem.
>>>
>>> The border-radius also makes it more consistent with the look of the
>>> buttons that also have rounded corners.
>>>
>>> Let’s vote now :) Let’s get this thing published :)
>>>
>>> cheers,
>>>Serge…
>>>
>>>
Morgan also requested to add more space bottom to the top menu.
Regards
JB
On 01/06/2016 09:44 PM, Serge Huber wrote:
> I really like it but some little details have been bugging me, the
> line spacing of lists. I looked at the CSS and noticed you have a
> line-height: 20px set that seems very weird on the home page. I
> tested by deactivating it (removing it) and it seems the default
> setting works better on the pages I tested.
>
> It’s really a detail though :)
>
> I also tried adding a border-radius on the home page titles :
>
> .homepage-subtitle, .homepage-title {
> background: rgba(52,48,45,.8);
> color: #f1f1f1;
> display: inline-block;
> border-radius: 5px;
> -webkit-border-radius: 5px;
> -moz-border-radius: 5px;
> }
>
> I find it a little less rough but again that’s personal preference :)
>
> cheers,
>Serge…
>
>
> On 6 janv. 2016, at 18:17, Jean-Baptiste Onofré
>> wrote:
>>
>> Hi all,
>>
>> I updated the new website proposal on my server:
>>
>> http://maven.nanthrax.net/goodies/karaf/site/
>>
>> Please, don't forget to update your browser cache (using
>> CTRL-SHIFT-R on Firefox for instance).
>>
>> I would like to start a vote tomorrow, so please, take a tour and
>> send your feedbacks to me.
>>
>> Thanks !
>>
>> Regards
>> JB
>>
>> On 11/12/2015 07:54 AM, Jean-Baptiste Onofré wrote:
>>
>>> Hi all,
>>>
>>> I already discussed with some of you about my plan on Karaf
>>> marketing.
>>>
>>> I think clearly that we had a great project, a great team, a great
>>> tool,
>>> but we're not really good in term of promotion and marketing.
>>>
>>> Especially, we have to be clear in the message and the projects
>>> that we
>>> deliver. For instance, again, I'm sure that karaf-boot is a huge step
>>> forward in Karaf adoption. I'm not sure that all users are aware and
>>> know the purpose of Cellar, Cave, Decanter, and even some Karaf
>>> areas.
>>>
>>> In order to improve the Karaf marketing area, I would like to propose
>>> the following plan:
>>>
>>> 1. More professional website
>>> I think we have to improve both the content and the look'n feel of
>>> the
>>> website.
>>> In term of content, I think it makes sense to not emphasize on
>>> OSGi. The
>>> fact that Karaf runs OSGi is not really interesting for most of end
>>> users (of course, it is for advanced/power users). We have to explain
>>> that Karaf is modern and multi-purpose container. More over, with
>>> karaf-boot, it becomes also a bootstrapper and "run anywhere"
>>> paradigm
>>> platform.
>>> So, I started a n
Re: Time to fix a small start script issue for 4.0.4?
yes correct, indeed that is a regression and it works correctly in 4.0.2 Fabian On Mon, Dec 7, 2015 at 6:10 PM, Jean-Baptiste Onofré wrote: > Hi Fabian, > > I think it's also related to KARAF-4138. > > I'm fixing that. I guess that it works fine with Karaf 4.0.2 (it's a > regression introduced in 4.0.3), correct ? > > Regards > JB > > > On 12/07/2015 05:52 PM, Fabian Lange wrote: > >> Hi, >> >> I just was made aware that karaf fails to correctly use a directory >> containing spaces. >> >> How to reproduce on a Mac: >> >> Download latest distribution & unpack into a directory containing spaces: >> I had it in "/Users/fabian/Downloads/apache karaf" >> >> Then start it from "/Users/fabian/Downloads/apache karaf/bin" using >> "./karaf" >> >> Karaf will create and use a directory called >> "/Users/fabian/Downloads/apache%20karaf" for data and instances. >> >> Is that the launch script which incorrectly calculates KARAF_HOME? >> >> Fabian >> >> > -- > Jean-Baptiste Onofré > jbono...@apache.org > http://blog.nanthrax.net > Talend - http://www.talend.com >
Time to fix a small start script issue for 4.0.4?
Hi, I just was made aware that karaf fails to correctly use a directory containing spaces. How to reproduce on a Mac: Download latest distribution & unpack into a directory containing spaces: I had it in "/Users/fabian/Downloads/apache karaf" Then start it from "/Users/fabian/Downloads/apache karaf/bin" using "./karaf" Karaf will create and use a directory called "/Users/fabian/Downloads/apache%20karaf" for data and instances. Is that the launch script which incorrectly calculates KARAF_HOME? Fabian
Re: Proposal: New Lock for failing Karaf start if running
HI,
yes I understand the current solution. It is really nice. My request was
for a much simpler much more basic feature.
karaf.lock.exclusive
would probably be what I need. But I would not know how to implement that
Fabian
On Wed, Dec 2, 2015 at 10:15 AM, Jean-Baptiste Onofré
wrote:
> Hi Fabian,
>
> the purpose is also to be able to "prepare" the slave instance, so the
> instance has to be started somehow.
>
> However, what you propose could make sense in some use case. Maybe we can
> add a karaf.lock.exclusive property to define this behavior.
>
> WDYT ?
>
> Regards
> JB
>
>
> On 12/02/2015 09:32 AM, Fabian Lange wrote:
>
>> Hi,
>> to my surprise I saw that while Karaf has a sweet failover mechanism, it
>> does not provide means to actually prevent startup of a second instance,
>> should the use case require it.
>> i can turn Lock off, but then I can start as many instances as I like
>> (which subsequently have bundle issues due to activators not able to bind
>> ports).
>> And I can wait for previous instances to terminate by using File or JDBC
>> lock.
>> In my case I want the second start to fail.
>>
>> Would it be sufficient to subclass SimpleFileLock, and to overwrite
>>
>> boolean lock() throws Exception {
>> boolean locked = super.lock();
>> if (!locked) throw new RuntimeException("startup aborted");
>> return true;
>> }
>>
>> or would that be not a great idea?
>>
>> if you think its useful I can make this nice and package as PR
>>
>> Fabian
>>
>>
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
Proposal: New Lock for failing Karaf start if running
Hi,
to my surprise I saw that while Karaf has a sweet failover mechanism, it
does not provide means to actually prevent startup of a second instance,
should the use case require it.
i can turn Lock off, but then I can start as many instances as I like
(which subsequently have bundle issues due to activators not able to bind
ports).
And I can wait for previous instances to terminate by using File or JDBC
lock.
In my case I want the second start to fail.
Would it be sufficient to subclass SimpleFileLock, and to overwrite
boolean lock() throws Exception {
boolean locked = super.lock();
if (!locked) throw new RuntimeException("startup aborted");
return true;
}
or would that be not a great idea?
if you think its useful I can make this nice and package as PR
Fabian
Re: Upstart / SystemD scripts
Wow indeed this is much more than my script :) Thank you for working on this and especially for sharing! Will have a look this week Fabian On Tue, Dec 1, 2015 at 3:16 PM, lb wrote: > They are a starting point, I'm sure I've missed something > > On Tue, Dec 1, 2015 at 3:14 PM, Jean-Baptiste Onofré > wrote: > > > Yes, please, create a Jira. > > > > I'm reviewing the PR. > > > > Thanks, > > Regards > > JB > > > > > > On 12/01/2015 03:06 PM, lb wrote: > > > >> PR sent https://github.com/apache/karaf/pull/113 > >> Do you also need a JIRA ? > >> > >> On Tue, Dec 1, 2015 at 11:22 AM, lb wrote: > >> > >> Very simple, I had some more complex leveraging os functions like > >>> start-stop-daemon etc, I will send a PR today so JB/ou can review > >>> > >>> On Tue, Dec 1, 2015 at 11:03 AM, Fabian Lange < > >>> fabian.la...@codecentric.de > >>> > >>>> wrote: > >>>> > >>> > >>> Maybe it was filtered because unsafe content :) > >>>> uploaded it to my gists: > >>>> https://gist.github.com/CodingFabian/90d46cfdce0085ee004c > >>>> > >>>> Fabian > >>>> > >>>> On Tue, Dec 1, 2015 at 11:01 AM, lb wrote: > >>>> > >>>> Hi Fabian, > >>>>> I do not see the attachment > >>>>> > >>>>> On Tue, Dec 1, 2015 at 10:27 AM, Fabian Lange < > >>>>> > >>>> fabian.la...@codecentric.de > >>>> > >>>>> > >>>>>> wrote: > >>>>> > >>>>> Hi Luca, > >>>>>> > >>>>>> I am using the attached script on some systems, which is obviously > >>>>>> > >>>>> very > >>>> > >>>>> simple but it works. The problem with upstart is that somehow the PID > >>>>>> tracking does neither work with normal nor fork mode. I have not > >>>>>> > >>>>> narrowed > >>>> > >>>>> it down yet. > >>>>>> > >>>>>> Fabian > >>>>>> > >>>>>> > >>>>>> On Tue, Dec 1, 2015 at 10:21 AM, lb wrote: > >>>>>> > >>>>>> Hi Fabian, JB, > >>>>>>> > >>>>>>> beside my attempt to migrate the wrapper from Tanuki to YAJSW, I'm > >>>>>>> > >>>>>> also > >>>> > >>>>> working on a set of scripts for systemd, init.d, solaris smf and > >>>>>>> > >>>>>> windows > >>>> > >>>>> to > >>>>>>> start karaf without the wrapper so I think it would be nice to > >>>>>>> > >>>>>> collect > >>>> > >>>>> requirement, attention points and so on in a JIRA and provides such > >>>>>>> templates in karaf distribution (i.e. in docs/contrib/scripts). > >>>>>>> > >>>>>>> What do you think ? > >>>>>>> > >>>>>>> Regards, > >>>>>>> Luca > >>>>>>> > >>>>>>> > >>>>>>> On Mon, Nov 30, 2015 at 11:03 AM, Jean-Baptiste Onofré < > >>>>>>> > >>>>>> j...@nanthrax.net > >>>> > >>>>> > >>>>>> wrote: > >>>>>>> > >>>>>>> Hi Fabian, > >>>>>>>> > >>>>>>>> I added systemd support in JSW wrapper. > >>>>>>>> > >>>>>>>> I don't see any blocker to use start/stop/status scripts in > systemd > >>>>>>>> > >>>>>>> (or > >>>>> > >>>>>> SystemV). Of course, we can improve those scripts to have a better > >>>>>>>> > >>>>>>> usage > >>>>> > >>>>>> via systemd. Please, if you can describe the improvements in a > >>>>>>>> > >>>>>>> Jira, I > >>>> > >>>>> will > >>>>>>> > >>>>>>>> enhance it. > >>>>>>>> > >>>>>>>> Thanks, > >>>>>>>> Regards > >>>>>>>> JB > >>>>>>>> > >>>>>>>> > >>>>>>>> On 11/30/2015 10:56 AM, Fabian Lange wrote: > >>>>>>>> > >>>>>>>> Hi, > >>>>>>>>> I know that there is extensive support in Karaf for using Tanuki > >>>>>>>>> > >>>>>>>> to > >>>> > >>>>> install > >>>>>>>>> Karaf as service. > >>>>>>>>> > >>>>>>>>> I have received however comments that it is difficult to use the > >>>>>>>>> > >>>>>>>> existing > >>>>>>> > >>>>>>>> scripts: > >>>>>>>>> start/stop/status > >>>>>>>>> > >>>>>>>>> in an upstart or systemd manner. > >>>>>>>>> As far As i can tell one of the problems is how Karaf handles > >>>>>>>>> > >>>>>>>> PIDs. > >>>> > >>>>> > >>>>>>>>> Does anybody have working scripts? Or can we improve here to make > >>>>>>>>> > >>>>>>>> this > >>>>> > >>>>>> an > >>>>>>> > >>>>>>>> option besides Tanuki? > >>>>>>>>> > >>>>>>>>> Best regards, > >>>>>>>>> Fabian > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> -- > >>>>>>>> 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 > > >
Re: Upstart / SystemD scripts
Maybe it was filtered because unsafe content :) uploaded it to my gists: https://gist.github.com/CodingFabian/90d46cfdce0085ee004c Fabian On Tue, Dec 1, 2015 at 11:01 AM, lb wrote: > Hi Fabian, > I do not see the attachment > > On Tue, Dec 1, 2015 at 10:27 AM, Fabian Lange > > wrote: > > > Hi Luca, > > > > I am using the attached script on some systems, which is obviously very > > simple but it works. The problem with upstart is that somehow the PID > > tracking does neither work with normal nor fork mode. I have not narrowed > > it down yet. > > > > Fabian > > > > > > On Tue, Dec 1, 2015 at 10:21 AM, lb wrote: > > > >> Hi Fabian, JB, > >> > >> beside my attempt to migrate the wrapper from Tanuki to YAJSW, I'm also > >> working on a set of scripts for systemd, init.d, solaris smf and windows > >> to > >> start karaf without the wrapper so I think it would be nice to collect > >> requirement, attention points and so on in a JIRA and provides such > >> templates in karaf distribution (i.e. in docs/contrib/scripts). > >> > >> What do you think ? > >> > >> Regards, > >> Luca > >> > >> > >> On Mon, Nov 30, 2015 at 11:03 AM, Jean-Baptiste Onofré > > >> wrote: > >> > >> > Hi Fabian, > >> > > >> > I added systemd support in JSW wrapper. > >> > > >> > I don't see any blocker to use start/stop/status scripts in systemd > (or > >> > SystemV). Of course, we can improve those scripts to have a better > usage > >> > via systemd. Please, if you can describe the improvements in a Jira, I > >> will > >> > enhance it. > >> > > >> > Thanks, > >> > Regards > >> > JB > >> > > >> > > >> > On 11/30/2015 10:56 AM, Fabian Lange wrote: > >> > > >> >> Hi, > >> >> I know that there is extensive support in Karaf for using Tanuki to > >> >> install > >> >> Karaf as service. > >> >> > >> >> I have received however comments that it is difficult to use the > >> existing > >> >> scripts: > >> >> start/stop/status > >> >> > >> >> in an upstart or systemd manner. > >> >> As far As i can tell one of the problems is how Karaf handles PIDs. > >> >> > >> >> Does anybody have working scripts? Or can we improve here to make > this > >> an > >> >> option besides Tanuki? > >> >> > >> >> Best regards, > >> >> Fabian > >> >> > >> >> > >> > -- > >> > Jean-Baptiste Onofré > >> > jbono...@apache.org > >> > http://blog.nanthrax.net > >> > Talend - http://www.talend.com > >> > > >> > > > > >
Re: Upstart / SystemD scripts
Hi Luca, I am using the attached script on some systems, which is obviously very simple but it works. The problem with upstart is that somehow the PID tracking does neither work with normal nor fork mode. I have not narrowed it down yet. Fabian On Tue, Dec 1, 2015 at 10:21 AM, lb wrote: > Hi Fabian, JB, > > beside my attempt to migrate the wrapper from Tanuki to YAJSW, I'm also > working on a set of scripts for systemd, init.d, solaris smf and windows to > start karaf without the wrapper so I think it would be nice to collect > requirement, attention points and so on in a JIRA and provides such > templates in karaf distribution (i.e. in docs/contrib/scripts). > > What do you think ? > > Regards, > Luca > > > On Mon, Nov 30, 2015 at 11:03 AM, Jean-Baptiste Onofré > wrote: > > > Hi Fabian, > > > > I added systemd support in JSW wrapper. > > > > I don't see any blocker to use start/stop/status scripts in systemd (or > > SystemV). Of course, we can improve those scripts to have a better usage > > via systemd. Please, if you can describe the improvements in a Jira, I > will > > enhance it. > > > > Thanks, > > Regards > > JB > > > > > > On 11/30/2015 10:56 AM, Fabian Lange wrote: > > > >> Hi, > >> I know that there is extensive support in Karaf for using Tanuki to > >> install > >> Karaf as service. > >> > >> I have received however comments that it is difficult to use the > existing > >> scripts: > >> start/stop/status > >> > >> in an upstart or systemd manner. > >> As far As i can tell one of the problems is how Karaf handles PIDs. > >> > >> Does anybody have working scripts? Or can we improve here to make this > an > >> option besides Tanuki? > >> > >> Best regards, > >> Fabian > >> > >> > > -- > > Jean-Baptiste Onofré > > jbono...@apache.org > > http://blog.nanthrax.net > > Talend - http://www.talend.com > > >
Upstart / SystemD scripts
Hi, I know that there is extensive support in Karaf for using Tanuki to install Karaf as service. I have received however comments that it is difficult to use the existing scripts: start/stop/status in an upstart or systemd manner. As far As i can tell one of the problems is how Karaf handles PIDs. Does anybody have working scripts? Or can we improve here to make this an option besides Tanuki? Best regards, Fabian
Re: [PROPOSAL] Karaf 4.0.3 end of this week
Hi, you guys see a way to come up with a solution for the snapshot update issue which appears since I fixed the memory leak? Use bypass? disable cache? reset session lookup data when returning to cache? Fabian On Tue, Nov 3, 2015 at 6:46 AM, Jean-Baptiste Onofré wrote: > Hi all, > > I propose to release Karaf 4.0.3 end of this week. > > WDYT ? > > Regards > JB > -- > Jean-Baptiste Onofré > jbono...@apache.org > http://blog.nanthrax.net > Talend - http://www.talend.com >
Re: Memory Leak in pax-url
This should "fix" it, right?
System.setProperty("aether.updateCheckManager.sessionState", "bypass");
Fabian
On Mon, Nov 2, 2015 at 3:11 PM, Jean-Baptiste Onofré
wrote:
> Yes, I understand.
>
> I mean it's something to improve in Pax URL in order to use it in Karaf ;)
>
> Regards
> JB
>
>
> On 11/02/2015 03:08 PM, Fabian Lange wrote:
>
>> Hi JB,
>> unfortunately I cannot force that, I am using the pax url service behind
>> the scenes behind FeaturesService.
>>
>> Fabian
>>
>> On Mon, Nov 2, 2015 at 3:07 PM, Jean-Baptiste Onofré
>> wrote:
>>
>> Hi Fabian,
>>>
>>> I saw something similar in the Pax URL tests: for the SNAPSHOT, I used
>>> two
>>> different sessions in order to "force" the cache invalidation and
>>> retrieve
>>> the SNAPSHOT.
>>>
>>> It's something that we have to improve in Pax URL.
>>>
>>> Regards
>>> JB
>>>
>>>
>>> On 11/02/2015 02:59 PM, Fabian Lange wrote:
>>>
>>> Hi all,
>>>> there is a different issue with session caching.
>>>> "DefaultUpdateCheckManager| 5 - org.ops4j.pax.url.mvn - 2.4.3 |
>>>> Skipped remote request for
>>>> group:artifact:1.0.0-SNAPSHOT/maven-metadata.xml, already updated during
>>>> this session."
>>>>
>>>> Any quick ideas how we could fix this?
>>>>
>>>> Fabian
>>>>
>>>> On Wed, Sep 23, 2015 at 4:05 PM, Fabian Lange <
>>>> fabian.la...@codecentric.de>
>>>> wrote:
>>>>
>>>> Great service, thank you!
>>>>
>>>>>
>>>>> Fabian
>>>>>
>>>>> On Wed, Sep 23, 2015 at 4:00 PM, Jean-Baptiste Onofré >>>> >
>>>>> wrote:
>>>>>
>>>>> Hi guys,
>>>>>
>>>>>>
>>>>>> I will check the change, update to a Pax URL SNAPSHOT in Karaf (in
>>>>>> order
>>>>>> to test), do the release of Pax URL and include in Karaf ;)
>>>>>>
>>>>>> Let me create the Jira.
>>>>>>
>>>>>> Regards
>>>>>> JB
>>>>>>
>>>>>>
>>>>>> On 09/23/2015 01:49 PM, Achim Nierbeck wrote:
>>>>>>
>>>>>> Hi
>>>>>>
>>>>>>>
>>>>>>> procedure is simple, we would need a new release for Pax-URL which
>>>>>>> will
>>>>>>> be
>>>>>>> included in the next version of Karaf 4.0.2,
>>>>>>> which is supposed to be released today ;)
>>>>>>> So we might just as well hold the release train for that for another
>>>>>>> day
>>>>>>> to
>>>>>>> get Pax-URL released first.
>>>>>>>
>>>>>>> regards, Achim
>>>>>>>
>>>>>>> 2015-09-23 13:46 GMT+02:00 Fabian Lange >>>>>> >:
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> I found and fixed a memory leak in pax-url
>>>>>>>> https://github.com/ops4j/org.ops4j.pax.url/pull/16
>>>>>>>>
>>>>>>>> This crashed a couple of karaf instances I am running.
>>>>>>>>
>>>>>>>> I have not merged the fix yet (because I want some additional eyes
>>>>>>>> on
>>>>>>>> it),
>>>>>>>> but I wonder how the procedure to get the fix into karaf would be
>>>>>>>> then?
>>>>>>>> Could anybody support me here?
>>>>>>>>
>>>>>>>> Fabian
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>>
>>>>>> 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
>>>
>>>
>>
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
Re: Memory Leak in pax-url
Hi JB, unfortunately I cannot force that, I am using the pax url service behind the scenes behind FeaturesService. Fabian On Mon, Nov 2, 2015 at 3:07 PM, Jean-Baptiste Onofré wrote: > Hi Fabian, > > I saw something similar in the Pax URL tests: for the SNAPSHOT, I used two > different sessions in order to "force" the cache invalidation and retrieve > the SNAPSHOT. > > It's something that we have to improve in Pax URL. > > Regards > JB > > > On 11/02/2015 02:59 PM, Fabian Lange wrote: > >> Hi all, >> there is a different issue with session caching. >> "DefaultUpdateCheckManager| 5 - org.ops4j.pax.url.mvn - 2.4.3 | >> Skipped remote request for >> group:artifact:1.0.0-SNAPSHOT/maven-metadata.xml, already updated during >> this session." >> >> Any quick ideas how we could fix this? >> >> Fabian >> >> On Wed, Sep 23, 2015 at 4:05 PM, Fabian Lange < >> fabian.la...@codecentric.de> >> wrote: >> >> Great service, thank you! >>> >>> Fabian >>> >>> On Wed, Sep 23, 2015 at 4:00 PM, Jean-Baptiste Onofré >>> wrote: >>> >>> Hi guys, >>>> >>>> I will check the change, update to a Pax URL SNAPSHOT in Karaf (in order >>>> to test), do the release of Pax URL and include in Karaf ;) >>>> >>>> Let me create the Jira. >>>> >>>> Regards >>>> JB >>>> >>>> >>>> On 09/23/2015 01:49 PM, Achim Nierbeck wrote: >>>> >>>> Hi >>>>> >>>>> procedure is simple, we would need a new release for Pax-URL which will >>>>> be >>>>> included in the next version of Karaf 4.0.2, >>>>> which is supposed to be released today ;) >>>>> So we might just as well hold the release train for that for another >>>>> day >>>>> to >>>>> get Pax-URL released first. >>>>> >>>>> regards, Achim >>>>> >>>>> 2015-09-23 13:46 GMT+02:00 Fabian Lange : >>>>> >>>>> Hi, >>>>> >>>>>> I found and fixed a memory leak in pax-url >>>>>> https://github.com/ops4j/org.ops4j.pax.url/pull/16 >>>>>> >>>>>> This crashed a couple of karaf instances I am running. >>>>>> >>>>>> I have not merged the fix yet (because I want some additional eyes on >>>>>> it), >>>>>> but I wonder how the procedure to get the fix into karaf would be >>>>>> then? >>>>>> Could anybody support me here? >>>>>> >>>>>> Fabian >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>> 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 >
Re: Memory Leak in pax-url
Hi all, there is a different issue with session caching. "DefaultUpdateCheckManager| 5 - org.ops4j.pax.url.mvn - 2.4.3 | Skipped remote request for group:artifact:1.0.0-SNAPSHOT/maven-metadata.xml, already updated during this session." Any quick ideas how we could fix this? Fabian On Wed, Sep 23, 2015 at 4:05 PM, Fabian Lange wrote: > Great service, thank you! > > Fabian > > On Wed, Sep 23, 2015 at 4:00 PM, Jean-Baptiste Onofré > wrote: > >> Hi guys, >> >> I will check the change, update to a Pax URL SNAPSHOT in Karaf (in order >> to test), do the release of Pax URL and include in Karaf ;) >> >> Let me create the Jira. >> >> Regards >> JB >> >> >> On 09/23/2015 01:49 PM, Achim Nierbeck wrote: >> >>> Hi >>> >>> procedure is simple, we would need a new release for Pax-URL which will >>> be >>> included in the next version of Karaf 4.0.2, >>> which is supposed to be released today ;) >>> So we might just as well hold the release train for that for another day >>> to >>> get Pax-URL released first. >>> >>> regards, Achim >>> >>> 2015-09-23 13:46 GMT+02:00 Fabian Lange : >>> >>> Hi, >>>> I found and fixed a memory leak in pax-url >>>> https://github.com/ops4j/org.ops4j.pax.url/pull/16 >>>> >>>> This crashed a couple of karaf instances I am running. >>>> >>>> I have not merged the fix yet (because I want some additional eyes on >>>> it), >>>> but I wonder how the procedure to get the fix into karaf would be then? >>>> Could anybody support me here? >>>> >>>> Fabian >>>> >>>> >>> >>> >>> >> -- >> Jean-Baptiste Onofré >> jbono...@apache.org >> http://blog.nanthrax.net >> Talend - http://www.talend.com >> > >
Re: [VOTE] Apache Karaf 4.0.2 release
+1, non binding I built my custom distribution, and that worked fine from the staging repo. thanks for fixing this annoyance. Distribution passes smoke tests as before, no unusual exceptions during build or startup. I noticed that my archive was bigger (about 500k compressed), I found that Karaf ships system/org/apache/servicemix/bundles/org.apache.servicemix.bundles.not-yet-commons-ssl. Is that intentional? I also noticed a bigger change in felix framework, especially scr seems to ship with a compat module. Is there documentation on what new features I can take advantage of? Fabian On Sat, Oct 10, 2015 at 12:07 AM, Jean-Baptiste Onofré wrote: > Hi all, > > I submit Apache Karaf 4.0.2 to your vote: > > Release Notes: > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12333259&styleName=Text&projectId=12311140 > > Git tag: > karaf-4.0.2 > > Staging Repository: > https://repository.apache.org/content/repositories/orgapachekaraf-1048/ > > 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: Memory Leak in pax-url
Great service, thank you! Fabian On Wed, Sep 23, 2015 at 4:00 PM, Jean-Baptiste Onofré wrote: > Hi guys, > > I will check the change, update to a Pax URL SNAPSHOT in Karaf (in order > to test), do the release of Pax URL and include in Karaf ;) > > Let me create the Jira. > > Regards > JB > > > On 09/23/2015 01:49 PM, Achim Nierbeck wrote: > >> Hi >> >> procedure is simple, we would need a new release for Pax-URL which will be >> included in the next version of Karaf 4.0.2, >> which is supposed to be released today ;) >> So we might just as well hold the release train for that for another day >> to >> get Pax-URL released first. >> >> regards, Achim >> >> 2015-09-23 13:46 GMT+02:00 Fabian Lange : >> >> Hi, >>> I found and fixed a memory leak in pax-url >>> https://github.com/ops4j/org.ops4j.pax.url/pull/16 >>> >>> This crashed a couple of karaf instances I am running. >>> >>> I have not merged the fix yet (because I want some additional eyes on >>> it), >>> but I wonder how the procedure to get the fix into karaf would be then? >>> Could anybody support me here? >>> >>> Fabian >>> >>> >> >> >> > -- > Jean-Baptiste Onofré > jbono...@apache.org > http://blog.nanthrax.net > Talend - http://www.talend.com >
Memory Leak in pax-url
Hi, I found and fixed a memory leak in pax-url https://github.com/ops4j/org.ops4j.pax.url/pull/16 This crashed a couple of karaf instances I am running. I have not merged the fix yet (because I want some additional eyes on it), but I wonder how the procedure to get the fix into karaf would be then? Could anybody support me here? Fabian
Re: Jaas and Diagnostic boot feature not part of distribution
Hi JB, Yes 4.0.1 :) sorry I forget that detail because I am usually on the latest and greatest version. I double checked the 4.0.0 vs the 4.0.1 dist zip and can confirm your suspicion. It worked in 4.0.0 and is not working in 4.0.1 anymore. Fabian On Fri, Aug 21, 2015 at 7:18 PM, Jean-Baptiste Onofré wrote: > Hi Fabian, > > I guess you talk about 4.0.1 ? > > AFAIR, it was the case in 4.0.0, right ? ;) > > I bet it's a bug due to my change in the KarInstall goal. > > Let me check. > > Regards > JB > > > On 08/21/2015 05:23 PM, Fabian Lange wrote: > >> Hi, >> >> I am building a custom distribution, but I observed the following also >> with >> the default karaf distribution. >> despite having the features "diagnostic" and "jaas" on bootFeatures, their >> jars are not contained in the system directory. As far as I understand >> that >> is the place where all features that are contained in a distribution are >> installed to. >> As a result, jaas-boot and diagnostic-boot are always downloaded on karaf >> start from the maven repository. >> i tried to install them as boot features, but it seems they are somehow >> special cased. >> >> Is that a bug in the distribution build? >> Can I work around that and force them to be packaged into system? >> >> best regards >> Fabian >> >> > -- > Jean-Baptiste Onofré > jbono...@apache.org > http://blog.nanthrax.net > Talend - http://www.talend.com >
Jaas and Diagnostic boot feature not part of distribution
Hi, I am building a custom distribution, but I observed the following also with the default karaf distribution. despite having the features "diagnostic" and "jaas" on bootFeatures, their jars are not contained in the system directory. As far as I understand that is the place where all features that are contained in a distribution are installed to. As a result, jaas-boot and diagnostic-boot are always downloaded on karaf start from the maven repository. i tried to install them as boot features, but it seems they are somehow special cased. Is that a bug in the distribution build? Can I work around that and force them to be packaged into system? best regards Fabian
Re: [VOTE] Release Apache Karaf 4.0.1
Hi, I am hitting a roadblock building a custom distribution with staging repo. I looks like that the karaf-maven-plugin:4.0.1:assembly (default-assembly) uses an unconfigured pax-url MavenResolver: https://github.com/apache/karaf/blob/master/profile/src/main/java/org/apache/karaf/profile/assembly/Builder.java#L370 The only repository this thing knows is maven central. So of course the distribution build fails: Error resolving artifact org.apache.karaf.package:org.apache.karaf.package.core:jar:4.0.1: Could not find artifact org.apache.karaf.package:org.apache.karaf.package.core:jar:4.0.1 in central (http://repo1.maven.org/maven2/) I have yet been unsuccessful in convincing it to use ay maven settings i can actually influence and point to the staging repo. Note that this probably not a regression, but still I would love to hear if anybody else is able (with a clean local repo) to build a distribution. Fabian On Sun, Aug 16, 2015 at 11:23 PM, Fabian Lange wrote: > Hi, > release notes need to be fixed. > https://issues.apache.org/jira/browse/KARAF-3888 > is not fixed because it was reverted, reopen please. > > Going to test the upgrade tomorrow > > Fabian > > > On Sun, Aug 16, 2015 at 2:40 PM, Jamie G. > wrote: > >> Hi, >> >> This release candidate is an update patch for Apache Karaf 4.0.x. >> >> We resolved 43 issues in this release: >> >> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140&version=12332798 >> >> Staging repository: >> https://repository.apache.org/content/repositories/orgapachekaraf-1039/ >> >> Release git tags: >> 4.0.1 >> >> Please vote to approve this release: >> >> [ ] +1 Approve the release >> [ ] -1 Veto the release (please provide specific comments) >> >> This vote will be open for 72 hours. >> > >
Re: [VOTE] Release Apache Karaf 4.0.1
Hi, release notes need to be fixed. https://issues.apache.org/jira/browse/KARAF-3888 is not fixed because it was reverted, reopen please. Going to test the upgrade tomorrow Fabian On Sun, Aug 16, 2015 at 2:40 PM, Jamie G. wrote: > Hi, > > This release candidate is an update patch for Apache Karaf 4.0.x. > > We resolved 43 issues in this release: > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140&version=12332798 > > Staging repository: > https://repository.apache.org/content/repositories/orgapachekaraf-1039/ > > Release git tags: > 4.0.1 > > Please vote to approve this release: > > [ ] +1 Approve the release > [ ] -1 Veto the release (please provide specific comments) > > This vote will be open for 72 hours. >
