Hi Steven, Let me try to reproduce on a simple test case.
I don’t see yet the relationship between the prefixes generated (which are not bad IMHO) and the OOM (I’m suspecting more like a loop in the features XML definition). Just a reminder: in Karaf itself, we don’t use the generate-features MOJO, we write the features XML/JSON by hand (largely better to have a complete control). Regards JB > Le 27 nov. 2021 à 22:15, Steven Huypens <steven.huyp...@gmail.com> a écrit : > > Hi Bernd, > > That's what I did : > > 1) Compile all code with Java 8, create distro with Java 8, run with Java 8 > --> Works > 2) Compile all code with Java 8, create distro with Java 8, run with Java > 11 --> Works > 3) Compile all code with Java 8, create distro with Java 11, run with Java > 11 --> Doesn't work, app goes OOM > 4) Compile all code with Java 11, create distro with Java 11, run with Java > 11 --> Doesn't work, app goes OOM > > The only difference between (2) and (3) is the prefix in > org.apache.karaf.features.xml, and if I remove that manually, the app works > as expected. I also think the generated org.apache.karaf.features.xml is > OK, but I have no clue why the application goes OOM with it. > > Kind regards, > Steven > > > > > > On Sat, Nov 27, 2021 at 10:02 PM Bernd Eckenfels <e...@zusammenkunft.net> > wrote: > >> Yes looked in the wrong Schema. I think, don’t worry about the prefixes, >> as long as the elements are correctly qualified (the processing elements in >> your case with ns3:) they are equivalent. Your memory problems have likely >> another cause. But as stated, it might be a good idea to list the repos and >> features in both running instances and compare them, just to be sure. >> >> (Besides the maven plugin probably should define a few fixed prefixes to >> make it better readable) >> >> Not sure why the maven plug-in is so sensitive to the jaxb version (if >> executed with java11 it needs to provide its own). Can you maybe run both >> builds with the same JDK? >> >> Gruss >> Bernd >> -- >> http://bernd.eckenfels.net >> ________________________________ >> Von: Steven Huypens <steven.huyp...@gmail.com> >> Gesendet: Saturday, November 27, 2021 9:56:04 PM >> An: dev@karaf.apache.org <dev@karaf.apache.org> >> Betreff: Re: karaf-maven-plugin generates another >> org.apache.karaf.features.xml with Java 8/Java 11 >> >> Hi Bernd, >> >> - I do see 'blacklistedRepositories' in >> http://karaf.apache.org/xmlns/features-processing/v1.0.0 >> - With the namespace-prefix my app goes OOM immediately, so I cannot >> compare both running systems. >> - I tried adding the prefix to each child, but that did not help >> >> Kind regards, >> Steven >> >> On Sat, Nov 27, 2021 at 9:23 PM Bernd Eckenfels <e...@zusammenkunft.net> >> wrote: >> >>> In that case maybe the child (deny* list?) is ignored, not sure how >> strict >>> the parser is in regards to namespaces. I don’t see a blacklistRepository >>> element in the Schema anyway. It’s maybe best you inspect the running >>> systems with feature:* commands and look for differences. >>> >>> >>> >>> -- >>> http://bernd.eckenfels.net >>> ________________________________ >>> Von: Steven Huypens <steven.huyp...@gmail.com> >>> Gesendet: Saturday, November 27, 2021 8:58:20 PM >>> An: dev@karaf.apache.org <dev@karaf.apache.org> >>> Betreff: Re: karaf-maven-plugin generates another >>> org.apache.karaf.features.xml with Java 8/Java 11 >>> >>> Hi Bernd, >>> >>> Thanks for your response. The child elements have no prefix, eg. >>> <blacklistedRepositories></blacklistedRepositories> >>> >>> I'm sorry but I do not understand what you mean. You think part of my >>> org.apache.karaf.features.xml was previously ignored ? I haven't double >>> checked, but that would really surprise me because we have quite some >>> blacklistedFeatures en blacklistedBundles which would cause problems if >>> ignored. >>> >>> Best regards, >>> Steven >>> >>> On Sat, Nov 27, 2021 at 8:22 PM Bernd Eckenfels <e...@zusammenkunft.net> >>> wrote: >>> >>>> Hello Steven >>>> >>>> How do the child elements of that element look like? Are they using >>>> default/f/ns2 prefix and maybe the (semantically equivalent) change >>> affects >>>> your memory only because the old form ignored a actual entry for >>> dependency? >>>> >>>> Bernd >>>> >>>> -- >>>> http://bernd.eckenfels.net >>>> ________________________________ >>>> Von: Romain Manni-Bucau <rmannibu...@gmail.com> >>>> Gesendet: Samstag, November 27, 2021 8:14 PM >>>> An: dev >>>> Betreff: Re: karaf-maven-plugin generates another >>>> org.apache.karaf.features.xml with Java 8/Java 11 >>>> >>>> Hi Steven, >>>> >>>> >>>> Maybe force jaxb version to an earlier one in karag pluhin dependencies >>> in >>>> your pom. >>>> >>>> >>>> Le sam. 27 nov. 2021 à 20:05, Steven Huypens <steven.huyp...@gmail.com >>> >>> a >>>> écrit : >>>> >>>>> Hi all, >>>>> >>>>> I tried to create my custom Karaf distribution (using >>> karaf-maven-plugin >>>>> 4.3.2) with Java 11 for the first time, and I noticed a difference in >>> the >>>>> resulting org.apache.karaf.features.xml >>>>> >>>>> The line >>>>> >>>>> <featuresProcessing xmlns=" >>>>> http://karaf.apache.org/xmlns/features-processing/v1.0.0"; xmlns:f=" >>>>> http://karaf.apache.org/xmlns/features/v1.6.0";> >>>>> >>>>> has been changed into >>>>> >>>>> <ns3:featuresProcessing xmlns:ns2=" >>>>> http://karaf.apache.org/xmlns/features/v1.6.0"; xmlns:ns3=" >>>>> http://karaf.apache.org/xmlns/features-processing/v1.0.0";> >>>>> >>>>> which means a namespace has been added. Unfortunately this little >>> change >>>>> has a big impact because now my app immediately runs OutOfMemory >> when I >>>>> start Karaf. There is very little DEBUG-logging, the behaviour is >>>> somewhat >>>>> like described in https://issues.apache.org/jira/browse/KARAF-6068 >>>>> >>>>> Removing the namespace fixes the problem. >>>>> >>>>> >>>>> >>>>> Do you have any idea how I can prevent my app from going OOM after >> this >>>>> change ? Or how I can prevent the namespace from being added with >> Java >>>> 11 ? >>>>> It would be nice to understand the exact problem here. >>>>> >>>>> >>>>> >>>>> Kind regards, >>>>> Steven >>>>> >>>> >>> >>
