Re: Minho Qusetion
Hi JB, My project has until recently worked well using Karaf for loading new Vaadin views as OSGi jars. Changed policy at Vaadin has made the use of OSGi virtually impossible and I have been forced into the Spring Boot world. Much to my surprise, Spring Boot has turned out to be great for coding and debugging my code. Missing is the ability to add new views on the fly which karaf kindly offered. I have tried to find a way to add new views to Spring Boot during a restart but no success. Minho seems to be a possible solution to this problem but the learning curve seems to be very steep. If Minho was promoted as a way to add some OSGi functionality to Spring boot, you may have a winner. If this is possible, some examples of how to do it could lead to a more reasonable learning curve. Also, now we are venturing into java 20 and 21 it seems that Spring Boot has taken early steps to incorporate projects loom, panama etc.. OSGi may be falling behind with these projects. Paul Fraser On 18/09/2023 7:34 pm, Jean-Baptiste Onofré wrote: Hi Paul, Yes, that's the idea: having a central/shared registry gathering beans from OSGi, Spring Boot, CDI, whatever. The "dynamic" approach (adding/removing applications managed by a app manager like Spring Boot, OSGi, ...) is also a target. To be honest, currently, Minho is not moving forward due to the low interest we got. If we have clear signs that people are interested in colocation and Minho runtime paradigm, it could change :) Regards JB On Mon, Sep 18, 2023 at 6:29 AM Paul Fraser wrote: Hi, Cannot quite get my head around Apache Minho but-- Can OSGi services be somehow added to the Spring Boot application at runtime or even at Spring Boot restart? In effect having Spring Boot acting like an OSGi runtime with services being added and removed as required. Is Minho going to proceed? Paul Fraser
Minho Qusetion
Hi, Cannot quite get my head around Apache Minho but-- Can OSGi services be somehow added to the Spring Boot application at runtime or even at Spring Boot restart? In effect having Spring Boot acting like an OSGi runtime with services being added and removed as required. Is Minho going to proceed? Paul Fraser
Re: Feature XML generation
Hi JB, "I'm thinking about removing the generate mojo as some point." Please do not remove it, it is most useful when using Vaadin which pulls in many bundles. Paul Fraser On 12/05/2023 3:00 am, Jean-Baptiste Onofré wrote: Hi Ryan IMHO, it's always better to create the features XML by hand (and verify). I'm thinking about removing the generate mojo as some point. Regards JB On Tue, May 9, 2023 at 3:58 PM Ryan Moquin wrote: I've been getting the same error as mentioned in KARAF-5999 (https://issues.apache.org/jira/browse/KARAF-5999), but I'm just trying to generate the features xml for a subproject. This of course happened after I upgraded everything to Camel 3 due to the CXF feature range usage. Is this going to be fixed soon? I need to decide if I need to either revert back to the older Camel or figure out another solution to this error: Failed to execute goal org.apache.karaf.tooling:karaf-maven-plugin:4.2.16:features-generate-descriptor (create-features) on project dp-processor: Unable to create features.xml file: org.apache.maven.plugin.MojoExecutionException: Cannot locate file for feature: org.apache.cxf.karaf:apache-cxf:xml:features:[3,4) at null -> [Help 1] Hopefully it's something that can be rectified soon. Thanks! Ryan
Re: osgi serviceloader missing in 4.4.3
Hi Maurice, We both belong to a very exclusive club, those who are adventurous enough to tackle OSGi/Karaf with Vaadin. Thanks for your link to twelvemonkeys and the spi-fly.html. The spi-fly.html is a much clearer explanation than previous explanations I have read. I have my Karaf/Vaadin project working well with Karaf 4.3.x but the switch to 4.4.x takes some time due to the move away from the OSGi cmpn bundle. Along with the info you have provided, I am now digging deep into the karaf code to establish why service loader works out of the box in 4.3.x and not 4.4.x. Paul On 7/2/23 23:12, Maurice Betzel wrote: Hi, Are you using Aries SPI Fly? https://aries.apache.org/documentation/modules/spi-fly.html An example of dependencies needed in the kar maven module: https://github.com/Maurice-Betzel/twelvemonkeys-osgi *From:*Paul Fraser *Sent:* dinsdag 7 februari 2023 11:20 *To:* user@karaf.apache.org *Subject:* osgi serviceloader missing in 4.4.3 * CAUTION:*This email originated from outside of Gaston Schul. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hi, 4.3.6 out of the box has the Aries org.apache.aries.spifly.dynamic.bundle loaded and service loading works OK. 4.4.3 does not have this bundle loaded and as a consequence service loading (for me) does not work. In 4.3.6 I cannot find what causes this bundle to be loaded as it is not listed in startup.properties and I cannot find a feature in features.cfg that handles it. feature:info spifly does not indicate that it handles the dynamic bundle either. What am I missing and what needs to be added to handle service loading in 4.4.3. Regards Paul Fraser Al onze verrichtingen geschieden op basis van de Algemene voorwaarden der Expediteurs van België, gepubliceerd in de bijlage tot het Belgisch Staatsblad dd. 24 juni 2005 onder nr. 0090237. De tekst van deze voorwaarden wordt op uw verzoek gratis toegezonden. All our transactions are subject to the General Conditions of the Belgian Forwarders Association which have been published under nr. 0090237 in the "Bijlage tot het Belgisch Staatsblad" dated June 24th, 2005, and is available free of charge upon request. Toutes nos opérations se font sur base des Conditions Générales des Expéditeurs de Belgique. Le texte en a été publié dans l' Annexe au Moniteur Belge du 24 juin 2005 sous le n° 0090237. Ce texte sera vous envoyé gratuitment sur demande. Email confidentiality notice: This email and any files transmitted with it are confidential and intended only for the use of the recipient. If you have received this email in error please notify its sender.
osgi serviceloader missing in 4.4.3
Hi, 4.3.6 out of the box has the Aries org.apache.aries.spifly.dynamic.bundle loaded and service loading works OK. 4.4.3 does not have this bundle loaded and as a consequence service loading (for me) does not work. In 4.3.6 I cannot find what causes this bundle to be loaded as it is not listed in startup.properties and I cannot find a feature in features.cfg that handles it. feature:info spifly does not indicate that it handles the dynamic bundle either. What am I missing and what needs to be added to handle service loading in 4.4.3. Regards Paul Fraser
Anyone using Multiple Karaf Instances Successfully?
Hi, In trying to add instances to a fresh karaf install (4.3.6) I am getting errors in the new instance log files, both when creating instances in the console and also in code using InstanceService. Console created instances report "started" in instance:list and code created instances do not get beyond reporting "starting" but they both have log errors. It would be most helpful if someone can confirm they are using multiple instances without any problems. Paul Fraser
Access config properties programmatically
Hi, The karaf docs state "Apache Karaf stores and loads all configuration in files located in the |etc| folder." To access and/or set properties in code do the files have to be loaded as properties files in code and then saved back after changes or does karaf have a simple method to manipulate properties? Karaf docs and googling for a way to set "log level" in code provides a very confusing array of suggestions. Karaf test code seems to use executeCommand to do it using the console commands. Paul Fraser
Re: Maven Compile Kars
Excellent, Paul, Thanks for the pointer, Paul On 17/1/23 03:42, Paul Spencer wrote: Paul, Although I have not generated a KAR with an Maven recover build, I suspect you will need to add dependencies to the KAR pom to control the build order. See https://maven.apache.org/guides/mini/guide-multiple-modules.html Paul Spencer On Jan 15, 2023, at 4:42 PM, Paul Fraser wrote: Hi, When I run maven on my project the Kars are in many cases compiled before some of the contained bundles. This results in the kar(s) not containing the latest bundles. Is there a way to force the maven reactor to place kar(s) last on the Reactor Build Order? Paul Fraser
Maven Compile Kars
Hi, When I run maven on my project the Kars are in many cases compiled before some of the contained bundles. This results in the kar(s) not containing the latest bundles. Is there a way to force the maven reactor to place kar(s) last on the Reactor Build Order? Paul Fraser
Re: Config in Feature file question
Hi Ephemeris, I missed the overide setting, thanks for the pointer. Paul Fraser On 25/9/22 18:28, Ephemeris Lappis wrote: Hello. I think you can change that using an option : override="false">URL You should change the "override" value to "true" See this page I've used for my own works : https://karaf.apache.org/manual/latest/provisioning I hope this will help you. Regards. Ephemeris Lappis Le 25/09/2022 à 05:30, Paul Fraser a écrit : Hi, When using the config functionality in a feature file it creates a config file in the karaf/etc directory. In my case, if the config is changed in the feature file, when karaf is rerun the config file in karaf/etc is not updated. Is this the desired result? It seems to me that the config file in etc should be upgraded. Paul Fraser
Config in Feature file question
Hi, When using the config functionality in a feature file it creates a config file in the karaf/etc directory. In my case, if the config is changed in the feature file, when karaf is rerun the config file in karaf/etc is not updated. Is this the desired result? It seems to me that the config file in etc should be upgraded. Paul Fraser
Create Instance Programmatically
Hi, What functionality is available in Karaf to create instances in code rather than in the console? Is there a preferred technique? Are there any examples available? Paul Fraser
Kars not expanding into karaf/data/kar directory
Hi, Karaf 4.3.6, Ubuntu 20.04 Copy kar into deploy directory and the expanded kar is not in the karaf/data/kar directory. In a clean install on a new vps it creates a new .m2 directory and places the kar contents there. When run on an existing system with an existing .m2 repo the system runs OK. If I rename the existing .m2 it creates a new one and the system does not start. Has anyone experienced this situation? The problem prevents an installation of a karaf based system from running on a fresh vps. Paul Fraser
Let's Encrypt and Karaf
Hi, Karaf keystore and ports etc. are setup in org.ops4j.pax.web.cfg. Let's Encrypt places cert and key pems in a place of it's choosing and uses these locations for later upgrades. How is this managed with a karaf http server? Paul Fraser
Karaf and LetsEncrypt
Hi, Attempting to get a LetsEncrypt certificate for a server running Vaadin in Karaf(4.3.6) jetty http on Ubuntu 20.04. CertBot asks for the webapp root. Where does this exist in the Karaf http feature environment? Paul Fraser
Re: [ANN] Apache Karaf runtime 4.3.6 has been released
Hi JB, Great result Cleanall works as planned. Deployer runs any kars or jars in deploy directory at startup. All my code runs without problem. Thanks for the great effort in getting 4.3.6 out. Paul Fraser On 15/1/22 4:26 pm, Jean-Baptiste Onofre wrote: The Apache Karaf team is pleased so announce Apache Karaf runtime 4.3.6 release. This release is an important release on the Karaf 4.3.x series containing: - upgrade to Pax Logging 2.0.14 with log4j 2.17.1 (fixing CVE-2021-44832) - prepare JDK 18 support - fix deployment issue by upgrading to Apache Felix FileInstall 3.7.4 - and much more! The Release Notes are available here: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140&version=12351123 Download: http://karaf.apache.org/download.html Enjoy! The Apache Karaf team
Re: Change to bin/karaf clean
Hi JB, On 23/12/21 4:00 pm, Jean-Baptiste Onofre wrote: Hi Paul Clean all are argument to karaf script doesn’t exist, only clean exists. So basically, doing ./bin/karaf clean or ./binn/karaf clean all is the same (all is just ignored): I looked in the script and could not see anything, perhaps because it was not there 😁 https://github.com/apache/karaf/blob/main/main/src/main/java/org/apache/karaf/main/Main.java karaf.clean.all exists in etc/system.properties. Do you want me to add clean.all argument to bin/karaf (allowing you to do ./bin/karaf clean.all for instance) ? Just cleanall without the dot if possible. e.g. bin/karaf cleanall Thanks, Paul
Change to bin/karaf clean
Hi, Since the change to "bin/karaf clean" where the log is not cleaned, a statement was made earlier in this group along the lines that "bin/karaf clean all" was the way to produce the previous clean functionality. This does not work and I have been unable to find the correct method. Anyone able to provide the correct technique? Paul Fraser
Re: Jaxb in Karaf environment problem
Thanks, Richard,
All it needs is a gentle hint and someone taking the time to provide the
hint.
Paul Fraser
On 15/12/21 11:13 pm, Richard Hierlmeier wrote:
How do you create the JAXBContext?
You have to use the newInstance-method with the class loader that has
access to the ObjectFactory class
Regards
Richard
Am Mi., 15. Dez. 2021 um 11:09 Uhr schrieb Paul Fraser
mailto:pa...@qnenet.com>>:
Hi,
Have created xsd file from xml file and used xjc to generate the java
classes.
When run, the system reports "no ObjectFactory class file found"
but it
exists with the generated java classes produced by xjc.
Is there something about Karaf or Osgi with Jaxb that causes this
problem?
Where should I be looking to fix this?
Karaf 4.3.3, Java 11
Regards
Paul Fraser
Jaxb in Karaf environment problem
Hi, Have created xsd file from xml file and used xjc to generate the java classes. When run, the system reports "no ObjectFactory class file found" but it exists with the generated java classes produced by xjc. Is there something about Karaf or Osgi with Jaxb that causes this problem? Where should I be looking to fix this? Karaf 4.3.3, Java 11 Regards Paul Fraser
Re: Different result between Linux and Windows
Hi JB, On 25/10/21 4:03 pm, JB Onofré wrote: Use <_noee>true on maven-bundle-plugin wrapping to avoid the requirement. Not sure how or where to use this. Are you able to point me to an example? Paul Fraser It’s because the JRE wrapping tag name could be different. Regards JB Le 25 oct. 2021 à 06:57, Paul Fraser a écrit : Hi, I am using a Vaadin addon ckeditor-vaadin_2.2.0, karaf 4.3.3, intellij latest. The addon specifies java 11 in the pom maven-compiler-plugin 3.8.1 11 It has to be wrapped by karaf. system runs OK in linux mint but fails in Windows as follows- [caused by: Unable to resolve wrap_file__C__Users_paulf_qneCustomKaraf_karaf_data_kar_qaddonbaseweb-0.0.1_com_wontlost_ckeditor-vaadin_2.2.0_ckeditor- vaadin-2.2.0.jar/0.0.0: missing requirement [wrap_file__C__Users_paulf_qneCustomKaraf_karaf_data_kar_qaddonbaseweb-0.0.1_com_wontlost_ckeditor- vaadin_2.2.0_ckeditor-vaadin-2.2.0.jar/0.0.0] osgi.ee; filter:="(&(osgi.ee=JavaSE)(version=11))"]]] How can this be handled in karaf? Paul Fraser
Different result between Linux and Windows
Hi, I am using a Vaadin addon ckeditor-vaadin_2.2.0, karaf 4.3.3, intellij latest. The addon specifies java 11 in the pom maven-compiler-plugin 3.8.1 11 It has to be wrapped by karaf. system runs OK in linux mint but fails in Windows as follows- [caused by: Unable to resolve wrap_file__C__Users_paulf_qneCustomKaraf_karaf_data_kar_qaddonbaseweb-0.0.1_com_wontlost_ckeditor-vaadin_2.2.0_ckeditor- vaadin-2.2.0.jar/0.0.0: missing requirement [wrap_file__C__Users_paulf_qneCustomKaraf_karaf_data_kar_qaddonbaseweb-0.0.1_com_wontlost_ckeditor- vaadin_2.2.0_ckeditor-vaadin-2.2.0.jar/0.0.0] osgi.ee; filter:="(&(osgi.ee=JavaSE)(version=11))"]]] How can this be handled in karaf? Paul Fraser
Another problem with deploy folder 4.3.3
Hi, Add afeature.kar to deploy folder after fresh start (bin/karaf debug clean) of Karaf. Works OK. Restart Karaf (bin/karaf) log reports "afeature.kar already exists remove before retrying" (not the exact log entry). Not sure, but I think this is a new problem in 4.3.3. I presume Karaf should ignore anything in the deploy folder which is already installed. Changes to the way deploy folder works in 4.3.3 have caused some significant changes required by applications upgrading from 4.3.2. Has the problem with 4.3.3 where it ignores initial content in the deploy folder at startup been fixed in 4.3.4? Paul Fraser
Multiple Kars Install
Hi, Karaf kar install code offers the option of installing kars without bundles being installed and started. All required kar bundles can then be installed and started together. Is this a technique the system is designed to use? Paul Fraser
How to detect Feature or Kar install is complete
Hi, What methods are available to detect Feature or Kar install is complete if a system needs to wait for completion of a previous feature or kar? OpenHAB inspects the list returned from FeatureService or KarService to find if the required addon is in the list. Any other method suggestions? Paul Fraser
Re: FileInstaller with 4.3.3
Yes, running without clean works OK in my case. Paul Fraser On 23/9/21 6:45 pm, Jean-Baptiste Onofré wrote: I guess it works fine without the clean arg right ? Regards JB On 22/09/2021 13:15, Jesse White wrote: We're hitting a similar problem with the deploy/ folder and can reproduce with a vanilla distribution of Karaf 4.3.3. On Mac OS w/ JDK 11: tar zxvf apache-karaf-4.3.3.tar.gz && cd apache-karaf-4.3.3 cp /tmp/confd-telemetry-feature.xml deploy/ ./bin/karaf clean karaf@root()> feature:info confd-telemetry-auto Feature not found Similar test with Karaf 4.3.2 shows: karaf@root()> feature:info confd-telemetry-auto Feature confd-telemetry-auto 1.0.0 Feature configuration: org.opennms.features.telemetry.listeners-single-port-flows org.opennms.features.telemetry.listeners-JTI-Listener org.opennms.features.telemetry.listeners-NXOS-Listener ... Here's a reference to the feature file in question: https://gist.github.com/j-white/1574f34cb94dc2d9166ae9805bd4ba3b <https://gist.github.com/j-white/1574f34cb94dc2d9166ae9805bd4ba3b> Thanks for all the effort in maintaining the distribution - looking forward to getting R7 up and running with JDK 17! Best, Jesse *From:* Jean-Baptiste Onofre *Sent:* Tuesday, September 21, 2021 9:39 AM *To:* user@karaf.apache.org *Subject:* Re: FileInstaller with 4.3.3 WARNING: This email originated outside of NantHealth. DO NOT CLICK links or attachments unless you recognize the sender and are expecting this email. Yes, I tried both, no clean, clean as argument, clean in config.properties. All works fine. Can you share some details about your test case and environment (especially if you are on Windows or Unix) ? Regards JB Le 21 sept. 2021 à 15:00, Matthias Leinweber a écrit : For me it's a custom dist. Did you do a clean start? Am Di., 21. Sept. 2021 um 14:28 Uhr schrieb Jean-Baptiste Onofre : Hi, I did several test and it works fine for me. Here’s the very simplest test: - Starting from Karaf 4.3.3 vanilla - I put commons-lang-2.6.jar in the deploy folder (while Karaf is stopped) - then, I’m starting Karaf with bin/karaf - When I checked the bundle:list: 54 │ Active │ 10 │ 2.6.7 │ OPS4J Pax Url - wrap: 55 │ Active │ 80 │ 2.6 │ Commons Lang So, you can see commons-lang installed and active, meaning the deployers deployed it from the deploy folder. It works for me. Can you elaborate a bit your test case ? Is it a custom distribution ? Regards JB > Le 20 sept. 2021 à 08:29, Paul Fraser a écrit : > > Hi JB, > > Any result on this check? > > Paul Fraser > > On 17/9/21 9:55 pm, JB Onofré wrote: >> I checked etc I will check deploy now. >> >> Regards >> JB >> >>> Le 17 sept. 2021 à 12:29, Paul Fraser a écrit : >>> >>> Hi JB, >>> >>> In my case the problem occurs using the deploy folder. >>> >>> Exact same code in 4.3.2 works, 4.3.3 does not install the deploy folder files. >>> >>> Paul >>> >>>> On 17/9/21 7:04 pm, Jean-Baptiste Onofré wrote: >>>> Hi, >>>> >>>> did you updated the etc location in etc/config.properties (in the felix.fileinstall.dir property) ? >>>> >>>> I just tried and it works fine for me. Here's my test case: >>>> >>>> 1. I created etc/my.config.cfg containing foo=bar >>>> 2. I'm starting karaf >>>> 3. I can see the config loaded: >>>> >>>> karaf@root()> config:list "(service.pid=my.config)" >>>> >>>> >>>> >>>> >>>> >>>> Pid: my.config >>>> BundleLocation: ? >>>> Properties: >>>> felix.fileinstall.filename = file:/home/jbonofre/Workspace/karaf/assemblies/apache-karaf/target/apache-karaf-4.3.4-SNAPSHOT/etc/my.config.cfg >>>> foo = bar >>>> service.pid = my.config >>>> >>>> Can you share your test case ? >>>> >>>> Regards >>>> JB >>>> >>>> >>>> >>>>> On 16/09/2021 14:31, Matthias Leinweber wrote: >>>>> Hello, >>>>> >>>>> I am having a strange issue after I updated my assembly to 4.3.3. I am using a custom file installer location which I deploy with a feature. >>>>> >>>>> The strange thing is that the folder is not processed automatically at startup, but if I touch a single file in the folder all others files get processed as well. >>>>> >>>>> Any ideas? >>>>> >>>>> br, >>>>> Matthias CONFIDENTIALITY NOTICE This e-mail message and any attachments are only for the use of the intended recipient and may contain information that is privileged, confidential or exempt from disclosure under applicable law. If you are not the intended recipient, any disclosure, distribution or other use of this e-mail message or attachments is prohibited. If you have received this e-mail message in error, please delete and notify the sender immediately. Thank you.
Re: 4.3.3 bin/karaf debug clean problem
Hi JB, In previous emails to this list I have and also Matthias have reported that 4.3.3 does not recognize the contents of the deploy directory unless one of the files is touched or the features are copied into the deploy folder. This may be related to this problem and we await your check to confirm or otherwise if there is a bug in fileinstall in 4.3.3 which is not occurring in 4.3.2. Paul On 20/9/21 8:47 pm, Jean-Baptiste Onofre wrote: Hi Paul, It depends how you « Install » the bundles. For instance, if you drop the bundles in the deploy folder, Karaf deployer will « reinstall » them. Regards JB Le 20 sept. 2021 à 12:34, Paul Fraser a écrit : Hi, If I use "bin/karaf debug clean" the active bundles are removed and the log file is retained. If I use "bin/karaf debug clean.all" the data file is removed but the active bundles remain active. I have also tried "cleanall" but in reading the jira I think clean.all is the correct option . Paul Fraser On 19/9/21 3:05 pm, Jean-Baptiste Onofre wrote: Hi Paul, See https://issues.apache.org/jira/browse/KARAF-7146 Now a simple clean keep the log file. Cleanall removes all. Regards JB Le 19 sept. 2021 à 01:09, Paul Fraser a écrit : Hi, With my installation of 4.3.3, when running Karaf with bin/karaf debug clean the data cache is cleaned but the karaf log remains. If I delete the data directory before running karaf, the log is a fresh one. Anything changed in 4.3.3 that might cause this? Paul Fraser
Re: 4.3.3 bin/karaf debug clean problem
Hi, If I use "bin/karaf debug clean" the active bundles are removed and the log file is retained. If I use "bin/karaf debug clean.all" the data file is removed but the active bundles remain active. I have also tried "cleanall" but in reading the jira I think clean.all is the correct option . Paul Fraser On 19/9/21 3:05 pm, Jean-Baptiste Onofre wrote: Hi Paul, See https://issues.apache.org/jira/browse/KARAF-7146 Now a simple clean keep the log file. Cleanall removes all. Regards JB Le 19 sept. 2021 à 01:09, Paul Fraser a écrit : Hi, With my installation of 4.3.3, when running Karaf with bin/karaf debug clean the data cache is cleaned but the karaf log remains. If I delete the data directory before running karaf, the log is a fresh one. Anything changed in 4.3.3 that might cause this? Paul Fraser
Re: FileInstaller with 4.3.3
Hi JB, Any result on this check? Paul Fraser On 17/9/21 9:55 pm, JB Onofré wrote: I checked etc I will check deploy now. Regards JB Le 17 sept. 2021 à 12:29, Paul Fraser a écrit : Hi JB, In my case the problem occurs using the deploy folder. Exact same code in 4.3.2 works, 4.3.3 does not install the deploy folder files. Paul On 17/9/21 7:04 pm, Jean-Baptiste Onofré wrote: Hi, did you updated the etc location in etc/config.properties (in the felix.fileinstall.dir property) ? I just tried and it works fine for me. Here's my test case: 1. I created etc/my.config.cfg containing foo=bar 2. I'm starting karaf 3. I can see the config loaded: karaf@root()> config:list "(service.pid=my.config)" Pid:my.config BundleLocation: ? Properties: felix.fileinstall.filename = file:/home/jbonofre/Workspace/karaf/assemblies/apache-karaf/target/apache-karaf-4.3.4-SNAPSHOT/etc/my.config.cfg foo = bar service.pid = my.config Can you share your test case ? Regards JB On 16/09/2021 14:31, Matthias Leinweber wrote: Hello, I am having a strange issue after I updated my assembly to 4.3.3. I am using a custom file installer location which I deploy with a feature. The strange thing is that the folder is not processed automatically at startup, but if I touch a single file in the folder all others files get processed as well. Any ideas? br, Matthias
4.3.3 bin/karaf debug clean problem
Hi, With my installation of 4.3.3, when running Karaf with bin/karaf debug clean the data cache is cleaned but the karaf log remains. If I delete the data directory before running karaf, the log is a fresh one. Anything changed in 4.3.3 that might cause this? Paul Fraser
Cave 4.2.1 with Karaf 4.3.3
Attempting to experiment with cave results in karaf@root()> feature:install cave-deployer org.apache.felix.resolver.reason.ReasonException: Unable to resolve root: missing requirement [root] osgi.identity; osgi.identity=cave-deployer; type=karaf.feature; version="[4.2.1,4.2.1]"; filter:="(&(osgi.identity=cave-deployer)(type=karaf.feature)(version>=4.2.1)(version<=4.2.1))" [caused by: Unable to resolve cave-deployer/4.2.1: missing requirement [cave-deployer/4.2.1] osgi.identity; osgi.identity=org.apache.karaf.cave.deployer.service; type=osgi.bundle; version="[4.2.1,4.2.1]"; resolution:=mandatory [caused by: Unable to resolve org.apache.karaf.cave.deployer.service/4.2.1: missing requirement [org.apache.karaf.cave.deployer.service/4.2.1] osgi.wiring.package; filter:="(&(osgi.wiring.package=org.osgi.framework)(version>=1.8.0)(!(version>=1.9.0)))"]] Does cave need an update? Paul Fraser
Re: FileInstaller with 4.3.3
Hi JB, In my case the problem occurs using the deploy folder. Exact same code in 4.3.2 works, 4.3.3 does not install the deploy folder files. Paul On 17/9/21 7:04 pm, Jean-Baptiste Onofré wrote: Hi, did you updated the etc location in etc/config.properties (in the felix.fileinstall.dir property) ? I just tried and it works fine for me. Here's my test case: 1. I created etc/my.config.cfg containing foo=bar 2. I'm starting karaf 3. I can see the config loaded: karaf@root()> config:list "(service.pid=my.config)" Pid: my.config BundleLocation: ? Properties: felix.fileinstall.filename = file:/home/jbonofre/Workspace/karaf/assemblies/apache-karaf/target/apache-karaf-4.3.4-SNAPSHOT/etc/my.config.cfg foo = bar service.pid = my.config Can you share your test case ? Regards JB On 16/09/2021 14:31, Matthias Leinweber wrote: Hello, I am having a strange issue after I updated my assembly to 4.3.3. I am using a custom file installer location which I deploy with a feature. The strange thing is that the folder is not processed automatically at startup, but if I touch a single file in the folder all others files get processed as well. Any ideas? br, Matthias
Re: FileInstaller with 4.3.3
Hi, With 4.3.2 and standard deploy folder, at startup, any files in deploy folder were processed. With 4.3.3 files in deploy folder are ignored. Paul Fraser On 16/9/21 10:31 pm, Matthias Leinweber wrote: Hello, I am having a strange issue after I updated my assembly to 4.3.3. I am using a custom file installer location which I deploy with a feature. The strange thing is that the folder is not processed automatically at startup, but if I touch a single file in the folder all others files get processed as well. Any ideas? br, Matthias
Karaf, java 9 and11 and JLink
Hi, During the learning process on Java 9 and 11 it occurred to me that perhaps we could have a karaf module which contains a private jvm. Is this possible? Paul Fraser
karaf-maven-plugin Generate Features Destination
Hi, Vaadin is using the karaf-maven-plugin to generate the features file and is being placed in the target directory. I cannot find a way to set a target location in the plugin docs. Is it possible to locate the features file outside the target directory using the plugin? Paul Fraser
Content of Kar Files
Hi, When creating a kar file for a feature that has prerequisites, all bundles of the prerequisite are included in the kar. This can result in large kar files when the kar feature only adds little to the overall system. Most of the requirements of the new kar are already in the karaf system folder. Is there a way to not include bundles in a kar that are already in the karaf system folder? prerequisite and dependency attributes on the feature make no difference. Paul Fraser
Kars with Kars
Hi, v4.3. I have 2 projects with a feature in each. Project 1 and Project 2. Project 1 creates a kar which contains all of it's dependencies. Project 2 has project 1 as a dependent feature and is also compiled as a kar. The resulting project 2 kar does not contain project 1. Should it? What is the process to be followed with "stacked" features in a final kar? Paul Fraser <>
Bundle shutdown order
Hi, Using netty-all bundle (wrapped) in a feature of it's own with a start-level set to 80 causes error on features using it because it shuts down before it should. If karaf (4.3) supposed to shut down bundles in reverse order to their star-order? The only way I have to be able to prevent this error is to include netty in a custom assembly. Paul Fraser <>
JB Email Bounce
Hi, I have had an email to JB's nanthrax email address bounce, anyone else experience this? Paul Fraser <>
Karsf 4.3 and Vaadin Flow V19
Hi, Karaf 4.3 and Vaadin Flow V19. I am attempting to create a demo of the new Vaadin 19 https://github.com/vaadin/base-starter-flow-osgi I have built and run it successfully as per the repo where it uses a bnd approach. My karaf attempt, https://github.com/QNENet/vaadindemo, fails with the error below. If I comment out "mvn:com.vaadin/flow-osgi/6.0-SNAPSHOT" entry in the demofeatures module the system builds but will not run, of course. It seems that the Karaf feature I add to demofeatures, pax-http-whiteboard does not provide the necessary "org.osgi.service.http.context" V19 of Vaadin now gives us the opportunity to have a first class GUI in Karaf so any help to get this going will be of value to the Karaf infrastructure. Paul Fraser -- Error executing command: Unable to resolve root: missing requirement [root] osgi.identity; osgi.identity=demo; type=karaf.feature; version="[1.0.0.SNAPSHOT,1.0.0.SNAPSHOT]"; filter:="(&(osgi.identity=demo)(type=karaf.feature)(version>=1.0.0.SNAPSHOT)(version<=1.0.0.SNAPSHOT))" [caused by: Unable to resolve demo/1.0.0.SNAPSHOT: missing requirement [demo/1.0.0.SNAPSHOT] osgi.identity; osgi.identity=com.vaadin.flow.osgi; type=osgi.bundle; version="[6.0.0.202101100021,6.0.0.202101100021]"; resolution:=mandatory [caused by: Unable to resolve com.vaadin.flow.osgi/6.0.0.202101100021: missing requirement [com.vaadin.flow.osgi/6.0.0.202101100021] osgi.wiring.package; filter:="(&(osgi.wiring.package=org.osgi.service.http.context)(version>=1.1.0)(!(version>=2.0.0)))"]] - <>
Re: Upgrading Features
On 18/11/2020 11:40 pm, Jean-Baptiste Onofre wrote: I can enhance the Kar service to detect an existing feature and upgrade it. In my opinion this would be well worthwhile. Paul Fraser <>
Re: Karaf running in background
Hi JB, I am using Installbuilder for installation on the VPS and my installer runs bin/start. My initial attempts with the installer actually setup and ran the wrapper etc. for auto restart, but the install ends up with all he files as root so I will have to set up as a wrapper service after install to allow auto restart. Unfortunately I have reinstalled and lost the logs but I am pretty sure that my code is at fault. From memory it was related to an array idx out of bounds. So the question probably is, what mode should I start in to allow recovery from a runtime error? It actually ran for about 2 weeks before the error.. I have 2 other vps's running for about a month with exactly the same code without a problem so far. Paul On 14/08/2020 6:36 pm, Jean-Baptiste Onofre wrote: Hi, How do you run Karaf ? Using bin/start or bin/karaf server ? What kind of error do you have ? Regards JB Le 14 août 2020 à 07:31, Paul Fraser a écrit : Hi, Running Karaf in a VPS in background mode. Error occurs and cannot gain access to karaf instance with ssh. The only way I have been able to fix is to reinstall. The stop script does not work in this case. Is there a way to gain control through the vps terminal? Paul Fraser <>
Karaf running in background
Hi, Running Karaf in a VPS in background mode. Error occurs and cannot gain access to karaf instance with ssh. The only way I have been able to fix is to reinstall. The stop script does not work in this case. Is there a way to gain control through the vps terminal? Paul Fraser <>
Re: Problem with Factory Components
Thanks, JB, On the ball again, copied to user list for the benefit of others. Paul On 12/08/2020 5:52 pm, Jean-Baptiste Onofre wrote: That’s because the requirement service org.osgi.service.component.ComponentFactory is not present. A simple workaround is to provide this capability in the src feature (or your own feature), adding: osgi.service;objectClass=org.osgi.service.component.ComponentFactory;effective:=active So, no need new bnd version or whatever, just have to provide the capability. I will add this in the scr feature for convenience. Regards JB <>
Problem with Factory Components
Hi, There has been some discussion in the past 6 months of a problem with capabilities and requirements for Factory Components. BJHargrave has fixed this problem in bnd/issues/4243 and 4252 with the release of bnd 5.2. What is the situation with karaf 4.3 SNAPSHOT which for me is failing asking for org.osgi.serviceComponentFactory? Paul Fraser <>
Re: Karaf Camel OSGi
Excellent, Sounds as if it is all under control.. Paul On 10/08/2020 4:13 pm, Jean-Baptiste Onofre wrote: Hi Paul, In the example, I used blueprint just as a loader (to avoid to create the CamelContext by hand). But, I also have an example where I create CamelContext by hand and register as a service (just have to find it). About the message on the mailing list, the subject is "[HEADS UP/PROPOSAL] "New" Camel Karaf for 3.5.0", where you can see: "2. Remove osgi-activator component to use whiteboard pattern I removed osgi-activator component to use RouteBuilder extended/production ready whiteboard pattern, using service property. 3. Introduction of CamelContextConfigurer whiteboard Camel-core-osgi now provided CamelContextConfigurer interface allowing you to create and configure CamelContext smoothly." Regards JB Le 10 août 2020 à 07:59, Paul Fraser mailto:pa...@qnenet.com>> a écrit : Thanks, JB, Good news. Is the blueprint route necessary in your example or just provided as an option? I cannot find the camel mailing list discussion, can you provide a clue to the topic and which list? Paul On 10/08/2020 3:32 pm, Jean-Baptiste Onofre wrote: Hi, Yes, it’s fully possible: https://github.com/apache/karaf/tree/master/examples/karaf-camel-example/karaf-camel-example-java I’m also preparing a "native" DS support (as explained on the Camel mailing list). Regards JB Le 10 août 2020 à 07:13, Paul Fraser mailto:pa...@qnenet.com>> a écrit : Hi, Blindly ventured into Karaf Camel code and used DefaultCamelContext for a single project wide camel context in a DS Activator. Did not work. Research turned up a question from Alex Soto answered by Claus Ibsen. (Jan 2020) Claus stated you have to use OsgiCamelContext and if you do you are on your own. He also states that Blueprint is the only approach continuing. Then I find camel-core-osgi 3.5.0-SNAPSHOT which at least creates a camel context in a DS Activator. Before I go off and learn Blueprint,is it possible and practical to build a system for production with Camel Java Routes in bundles using camel-core-osgi? Paul Fraser <>
Re: Karaf Camel OSGi
Thanks, JB, Good news. Is the blueprint route necessary in your example or just provided as an option? I cannot find the camel mailing list discussion, can you provide a clue to the topic and which list? Paul On 10/08/2020 3:32 pm, Jean-Baptiste Onofre wrote: Hi, Yes, it’s fully possible: https://github.com/apache/karaf/tree/master/examples/karaf-camel-example/karaf-camel-example-java I’m also preparing a "native" DS support (as explained on the Camel mailing list). Regards JB Le 10 août 2020 à 07:13, Paul Fraser mailto:pa...@qnenet.com>> a écrit : Hi, Blindly ventured into Karaf Camel code and used DefaultCamelContext for a single project wide camel context in a DS Activator. Did not work. Research turned up a question from Alex Soto answered by Claus Ibsen. (Jan 2020) Claus stated you have to use OsgiCamelContext and if you do you are on your own. He also states that Blueprint is the only approach continuing. Then I find camel-core-osgi 3.5.0-SNAPSHOT which at least creates a camel context in a DS Activator. Before I go off and learn Blueprint,is it possible and practical to build a system for production with Camel Java Routes in bundles using camel-core-osgi? Paul Fraser <>
Karaf Camel OSGi
Hi, Blindly ventured into Karaf Camel code and used DefaultCamelContext for a single project wide camel context in a DS Activator. Did not work. Research turned up a question from Alex Soto answered by Claus Ibsen. (Jan 2020) Claus stated you have to use OsgiCamelContext and if you do you are on your own. He also states that Blueprint is the only approach continuing. Then I find camel-core-osgi 3.5.0-SNAPSHOT which at least creates a camel context in a DS Activator. Before I go off and learn Blueprint,is it possible and practical to build a system for production with Camel Java Routes in bundles using camel-core-osgi? Paul Fraser <>
Re: Karaf 4.3 Assembly add Camel
Thanks, Francois, No wonder I have been driving myself silly. Should it work OK when installed via console, which does not complain? Paul On 6/08/2020 5:25 pm, Francois Papon wrote: Hi Paul, This is an error related to Camel, we will fix it. regards fpa...@apache.org Le 06/08/2020 à 08:07, Paul Fraser a écrit : Hi, Building assembly Karaf 4.3.0-SNAPSHOT, pom attached. If I build assembly without Camel and add Camel via console works OK. Why is version 4.2.9 resolve the problem and what should I add to the pom to fix? Listening for transport dt_socket at address: 5005 org.apache.felix.resolver.reason.ReasonException: Unable to resolve root: missing requirement [root] osgi.identity; osgi.identity=feature; type=karaf.feature; version="[4.2.9,4.2.9]"; filter:="(&(osgi.identity=feature)(type=karaf.feature)(version>=4.2.9)(version<=4.2.9))" [caused by: Unable to resolve feature/4.2.9: missing requirement [feature/4.2.9] osgi.identity; osgi.identity=org.apache.karaf.features.core; type=osgi.bundle; version="[4.2.9,4.2.9]"; resolution:=mandatory [caused by: Unable to resolve org.apache.karaf.features.core/4.2.9: missing requirement [org.apache.karaf.features.core/4.2.9] osgi.wiring.package; filter:="(&(osgi.wiring.package=org.osgi.service.resolver)(version>=1.0.0)(!(version>=1.1.0)))"]] at org.apache.felix.resolver.Candidates$MissingRequirementError.toException(Candidates.java:1341) at org.apache.felix.resolver.ResolverImpl.doResolve(ResolverImpl.java:434) at org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:421) at org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:375) at org.apache.karaf.features.internal.region.SubsystemResolver.resolve(SubsystemResolver.java:257) at org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:391) at org.apache.karaf.features.internal.service.FeaturesServiceImpl.doProvision(FeaturesServiceImpl.java:1062) at org.apache.karaf.features.internal.service.FeaturesServiceImpl.lambda$doProvisionInThread$13(FeaturesServiceImpl.java:998) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:748) Caused by: org.apache.felix.resolver.reason.ReasonException: Unable to resolve feature/4.2.9: missing requirement [feature/4.2.9] osgi.identity; osgi.identity=org.apache.karaf.features.core; type=osgi.bundle; version="[4.2.9,4.2.9]"; resolution:=mandatory [caused by: Unable to resolve org.apache.karaf.features.core/4.2.9: missing requirement [org.apache.karaf.features.core/4.2.9] osgi.wiring.package; filter:="(&(osgi.wiring.package=org.osgi.service.resolver)(version>=1.0.0)(!(version>=1.1.0)))"] at org.apache.felix.resolver.Candidates$MissingRequirementError.toException(Candidates.java:1341) ... 12 more Caused by: org.apache.felix.resolver.reason.ReasonException: Unable to resolve org.apache.karaf.features.core/4.2.9: missing requirement [org.apache.karaf.features.core/4.2.9] osgi.wiring.package; filter:="(&(osgi.wiring.package=org.osgi.service.resolver)(version>=1.0.0)(!(version>=1.1.0)))" at org.apache.felix.resolver.Candidates$MissingRequirementError.toException(Candidates.java:1341) ... 13 more Thanks Paul Fraser <>
Karaf 4.3 Assembly add Camel
Hi, Building assembly Karaf 4.3.0-SNAPSHOT, pom attached. If I build assembly without Camel and add Camel via console works OK. Why is version 4.2.9 resolve the problem and what should I add to the pom to fix? Listening for transport dt_socket at address: 5005 org.apache.felix.resolver.reason.ReasonException: Unable to resolve root: missing requirement [root] osgi.identity; osgi.identity=feature; type=karaf.feature; version="[4.2.9,4.2.9]"; filter:="(&(osgi.identity=feature)(type=karaf.feature)(version>=4.2.9)(version<=4.2.9))" [caused by: Unable to resolve feature/4.2.9: missing requirement [feature/4.2.9] osgi.identity; osgi.identity=org.apache.karaf.features.core; type=osgi.bundle; version="[4.2.9,4.2.9]"; resolution:=mandatory [caused by: Unable to resolve org.apache.karaf.features.core/4.2.9: missing requirement [org.apache.karaf.features.core/4.2.9] osgi.wiring.package; filter:="(&(osgi.wiring.package=org.osgi.service.resolver)(version>=1.0.0)(!(version>=1.1.0)))"]] at org.apache.felix.resolver.Candidates$MissingRequirementError.toException(Candidates.java:1341) at org.apache.felix.resolver.ResolverImpl.doResolve(ResolverImpl.java:434) at org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:421) at org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:375) at org.apache.karaf.features.internal.region.SubsystemResolver.resolve(SubsystemResolver.java:257) at org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:391) at org.apache.karaf.features.internal.service.FeaturesServiceImpl.doProvision(FeaturesServiceImpl.java:1062) at org.apache.karaf.features.internal.service.FeaturesServiceImpl.lambda$doProvisionInThread$13(FeaturesServiceImpl.java:998) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:748) Caused by: org.apache.felix.resolver.reason.ReasonException: Unable to resolve feature/4.2.9: missing requirement [feature/4.2.9] osgi.identity; osgi.identity=org.apache.karaf.features.core; type=osgi.bundle; version="[4.2.9,4.2.9]"; resolution:=mandatory [caused by: Unable to resolve org.apache.karaf.features.core/4.2.9: missing requirement [org.apache.karaf.features.core/4.2.9] osgi.wiring.package; filter:="(&(osgi.wiring.package=org.osgi.service.resolver)(version>=1.0.0)(!(version>=1.1.0)))"] at org.apache.felix.resolver.Candidates$MissingRequirementError.toException(Candidates.java:1341) ... 12 more Caused by: org.apache.felix.resolver.reason.ReasonException: Unable to resolve org.apache.karaf.features.core/4.2.9: missing requirement [org.apache.karaf.features.core/4.2.9] osgi.wiring.package; filter:="(&(osgi.wiring.package=org.osgi.service.resolver)(version>=1.0.0)(!(version>=1.1.0)))" at org.apache.felix.resolver.Candidates$MissingRequirementError.toException(Candidates.java:1341) ... 13 more Thanks Paul Fraser http://maven.apache.org/POM/4.0.0"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd";> 4.0.0 net.qnenet qneassembly 4.3.0-SNAPSHOT pom QNEAssembly org.apache.karaf.features framework 4.3.0-SNAPSHOT kar org.apache.karaf.features framework 4.3.0-SNAPSHOT features xml runtime org.apache.karaf.features standard 4.3.0-SNAPSHOT features xml org.apache.camel.karaf apache-camel 3.5.0-SNAPSHOT features xml runtime org.apache.maven.plugins maven-resources-plugin process-resources resources org.apache.maven.plugins maven-remote-resources-plugin true org.apache.karaf.tooling karaf-maven-plugin install-kar compile assembly
Re: Including http in assembly
Hi, Adding pax-url-aether to bootFeatures fixed this problem for me. Paul On 5/08/2020 3:53 pm, Paul Fraser wrote: Hi, Try to build custom assembly in 4.3.0-SNAPSHOT with http and http-whiteboard available. http http-whiteboard Without these 2 features being added the assemby works Ok and I can add these 2 features in the console and all works as expected. These 2 features list as being unistalled in a full feature:list. What is needed to have the assembly behave the same as the console? Paul Fraser <>
Including http in assembly
Hi, Try to build custom assembly in 4.3.0-SNAPSHOT with http and http-whiteboard available. http http-whiteboard Without these 2 features being added the assemby works Ok and I can add these 2 features in the console and all works as expected. These 2 features list as being unistalled in a full feature:list. What is needed to have the assembly behave the same as the console? Paul Fraser <>
Re: Vaadin Flow and Apache Karaf
Hi Julian, After experimenting with your code for a while I decided to jump in the deep end and start from the V14 OSGi Starter. I have ended up with a working Karaf project using the original Vaadin MainView based on Component and setting the required setup to run in comptability mode. My requirement is to use Designer to create the html templates but my effort fails to load the static templates. The repo is at https://github.com/QNENet/karafvaadin and I have raised a forum request https://vaadin.com/forum/thread/18356178/osgi-resource-loading-in-compatabilty-mode Regards Paul Fraser P.S. The current Designer 4.5.7 is a brilliant tool for developing V14 views, I just hope we can sort out the problem using compatabiltiy mode. On 19/09/2019 1:27 am, Julian Feinauer wrote: Hey, I decided to post again an update just to learn something... : ) The Demo I posted sets up a felix instance with the bundles listed below. I am able to start that in karaf If I copy all over to deploy BUT its not working due to NPEs or stuff and I guess there are some conflicts as things like the servlet container are already in a karaf bundle... Could it be possible to just take out some jars (and add some bundles / features to karaf) and then make the whole thing run? Julian Appendix: List of jars: animal-sniffer-annotations-1.9.jar asm-debug-all-5.0.3.jar atmosphere-runtime-2.4.30.vaadin1.jar byte-buddy-1.9.3.jar commons-fileupload-1.3.3.jar commons-io-2.6.jar commons-lang3-3.0.jar flow-client-1.4.3.jar flow-data-1.4.3.jar flow-html-components-1.4.3.jar flow-osgi-1.4.3.jar flow-push-1.4.3.jar flow-server-1.4.3.jar gentyref-1.2.0.vaadin1.jar gwt-elemental-2.8.2.vaadin2.jar iron-a11y-announcer-2.1.0.jar iron-a11y-keys-behavior-2.1.1.jar iron-fit-behavior-2.2.1.jar iron-flex-layout-2.0.3.jar iron-icon-2.1.0.jar iron-iconset-svg-2.2.1.jar iron-list-2.0.19.jar iron-media-query-2.1.0.jar iron-meta-2.1.1.jar iron-overlay-behavior-2.3.4.jar iron-resizable-behavior-2.1.1.jar iron-scroll-target-behavior-2.1.1.jar jansi-1.17.1.jar jetty-client-9.4.12.v20180830.jar jetty-http-9.4.12.v20180830.jar jetty-io-9.4.12.v20180830.jar jetty-jmx-9.4.12.v20180830.jar jetty-security-9.4.12.v20180830.jar jetty-server-9.4.12.v20180830.jar jetty-servlet-9.4.12.v20180830.jar jetty-util-9.4.12.v20180830.jar jetty-webapp-9.4.12.v20180830.jar jetty-xml-9.4.12.v20180830.jar jline-3.7.0.jar jsoup-1.11.2.jar org.apache.aries.spifly.core-internal-1.0.12.jar org.apache.aries.spifly.dynamic.bundle-1.0.12.jar org.apache.aries.spifly.static.bundle-1.0.12.jar org.apache.aries.spifly.static.tool-1.0.12.jar org.apache.aries.spifly.weaver-internal-1.0.12.jar org.apache.aries.util-1.1.3.jar org.apache.felix.bundlerepository-2.0.10.jar org.apache.felix.gogo.command-1.0.2.jar org.apache.felix.gogo.jline-1.1.0.jar org.apache.felix.gogo.runtime-1.1.0.jar org.apache.felix.http.base-4.0.4.jar org.apache.felix.http.jetty-4.0.6.jar org.apache.felix.http.servlet-api-1.1.2.jar org.apache.felix.scr.annotations-1.12.0.jar org.apache.felix.scr.compat-1.0.4.jar org.apache.felix.scr.ds-annotations-1.2.10.jar org.apache.felix.scr-2.1.10.jar org.osgi.core-6.0.0.jar org.osgi.service.serviceloader-1.0.0.jar ph-commons-9.1.2.jar ph-css-6.1.1.jar polymer-2.7.0.jar project-base-osgi-1.0-SNAPSHOT.jar shadycss-1.8.0.jar slf4j-api-1.7.25.jar slf4j-simple-1.7.25.jar tomcat-servlet-api-8.0.9.jar vaadin-accordion-1.0.0.jar vaadin-accordion-flow-1.0.3.jar vaadin-app-layout-1.0.2.jar vaadin-app-layout-flow-1.1.1.jar vaadin-button-2.1.5.jar vaadin-button-flow-1.3.2.jar vaadin-checkbox-2.2.7.jar vaadin-checkbox-flow-1.3.1.jar vaadin-combo-box-4.2.8.jar vaadin-combo-box-flow-2.1.3.jar vaadin-context-menu-4.3.4.jar vaadin-context-menu-flow-2.0.1.jar vaadin-control-state-mixin-2.1.3.jar vaadin-core-13.0.4.jar vaadin-custom-field-1.0.1.jar vaadin-custom-field-flow-2.0.2.jar vaadin-date-picker-3.3.4.jar vaadin-date-picker-flow-1.3.0.jar vaadin-details-1.0.1.jar vaadin-details-flow-1.0.1.jar vaadin-development-mode-detector-2.0.0.jar vaadin-dialog-2.2.1.jar vaadin-dialog-flow-1.3.0.jar vaadin-element-mixin-2.1.3.jar vaadin-form-layout-2.1.2.jar vaadin-form-layout-flow-1.3.1.jar vaadin-grid-5.3.3.jar vaadin-grid-flow-3.0.3.jar vaadin-icons-4.2.2.jar vaadin-icons-flow-1.3.1.jar vaadin-iron-list-flow-1.3.0.jar vaadin-item-2.1.0.jar vaadin-list-box-1.1.0.jar vaadin-list-box-flow-1.3.0.jar vaadin-list-mixin-2.1.2.jar vaadin-login-1.0.0.jar vaadin-login-flow-1.0.0.jar vaadin-lumo-styles-1.4.2.jar vaadin-lumo-theme-1.4.3.jar vaadin-material-styles-1.2.2.jar vaadin-material-theme-1.4.3.jar vaadin-notification-1.2.1.jar vaadin-notification-flow-1.3.0.jar vaadin-ordered-layout-1.1.0.jar vaadin-ordered-layout-flow-1.3.0.jar vaadin-overlay-3.2.11.jar vaadin-progress-bar-1.1.0.jar vaadin-progress-bar-flow-1.3.0.jar vaadin-radio-button-1.1.5.jar vaadin-radio-button-flow-1.3.1.jar vaadin-select-2.0.4.jar vaadin-select-flow-1.0.0.jar vaadin-slf4j-jdk14-1.6.1.jar vaadin-split-layout-4.1.0.jar
Re: KarService Problem
On 23/05/2020 3:19 pm, Paul Fraser wrote:
JB,
But it works when installed in the deplo folder.
There is something different when deployed from the deploy folder and when it is cllaed with the
feature service.
== PLEASE IGNORE...The following is rubbish is Rubbish
=
I get the same problem if I try featureService.install("web-console")
==
Paul
On 23/05/2020 3:13 pm, Jean-Baptiste Onofre wrote:
The piece of code you mention in the FeatureService is about the provisioning, so
resolution/download of the artifact.
Maybe your features XML contained in the Kar contains "bad" URL ? Do you use only mvn URL in the
features XML packaged in the KAR (no file URL for instance) ?
Don’t you have something in the karaf.log ?
Anyway, if you can reproduce on a simple kar and send to me I will check and
try to reproduce.
Regards
JB
Le 23 mai 2020 à 07:09, Paul Fraser a écrit :
JB,
The kar file is being exploded OK and the system bogs down when resolving the
contained features.
Paul
On 23/05/2020 3:03 pm, Paul Fraser wrote:
JB,
Did you see my second email which indicates the problem in in the Feature
Service?
Paul
On 23/05/2020 3:01 pm, Jean-Baptiste Onofre wrote:
If nothing happen, I bet it’s the URL resolution download.
If the kar file is large, it can take time to download as Karaf is "caching"
the Kar file.
Did you wait long ? Maybe a thread dump would help.
Regards
JB
Le 23 mai 2020 à 06:56, Paul Fraser a écrit :
JB,
More information in my follow up mail.
Comments inline.
On 23/05/2020 2:24 pm, Jean-Baptiste Onofre wrote:
Hi,
Can you describe a bit the problem ?
Does the path is a valid URL (file, http, mvn) to the Kar file ?
The exact same kar file works when added to deploy folder so I do not think the file format
could be the problem.
Kar:install command (and the service) are part of the itest, so they work at
least here.
Understood.
Maybe you are on Windows platform ?
Linux Mint Sonje
Regards
JB
Le 22 mai 2020 à 13:28, Paul Fraser a écrit :
Hi,
Using
karService#install(karPath.toUri) fails
but copying the kar jar into the deploy folder works.
Can anyone with an inner knowledge of both approaches offer any advice as to possible cause
of the failure of the karService in this case?
Or suggest where I should be looking to find the cause.
Thanks,
Paul Fraser
Re: KarService Problem
Thanks JB,
Will do some more investigation.
Paul
On 23/05/2020 3:59 pm, Jean-Baptiste Onofre wrote:
And by the way: I never use the deploy folder, so yes, all is install via
service using URL.
I really think your issue is about mvn/url resolution.
Regards
JB
Le 23 mai 2020 à 07:48, Paul Fraser a écrit :
JB,
Inline.
On 23/05/2020 3:26 pm, Jean-Baptiste Onofre wrote:
The difference is in the resolution.
When you use the deploy folder: when you drop the kar in the deploy folder,
it’s directly resolved from there. That’s the difference.
Same when you do feature:install webconsole: webconsole is not part of karaf
standard distribution, so it’s not in the system folder, meaning that karaf
needs to download artifact from remote repos to install.
Maybe your issue is about the remove maven repositories (no internet
connection, or missing repo in etc/org.ops4j.pax.url.mvn.cfg). If Karaf doesn’t
do anything, it’s possible that you have a proxy or firewall blocking download
from remote repos, so you have to wait timeout.
The kar url is a file:// url and is available in a folder next to the Karaf
install.
It is happening with all of my kars under the same situation.
Silly question, but, apart from the ITest, have you used the kar and or feature
service to instal kars and features as distinct from dropping in deploy folder?
Paul
I bet if you populate the system folder, it works.
Regards
JB
Le 23 mai 2020 à 07:19, Paul Fraser a écrit :
JB,
But it works when installed in the deplo folder.
There is something different when deployed from the deploy folder and when it
is cllaed with the feature service.
I get the same problem if I try featureService.install("web-console")
Paul
On 23/05/2020 3:13 pm, Jean-Baptiste Onofre wrote:
The piece of code you mention in the FeatureService is about the provisioning,
so resolution/download of the artifact.
Maybe your features XML contained in the Kar contains "bad" URL ? Do you use
only mvn URL in the features XML packaged in the KAR (no file URL for instance) ?
Don’t you have something in the karaf.log ?
Anyway, if you can reproduce on a simple kar and send to me I will check and
try to reproduce.
Regards
JB
Le 23 mai 2020 à 07:09, Paul Fraser a écrit :
JB,
The kar file is being exploded OK and the system bogs down when resolving the
contained features.
Paul
On 23/05/2020 3:03 pm, Paul Fraser wrote:
JB,
Did you see my second email which indicates the problem in in the Feature
Service?
Paul
On 23/05/2020 3:01 pm, Jean-Baptiste Onofre wrote:
If nothing happen, I bet it’s the URL resolution download.
If the kar file is large, it can take time to download as Karaf is "caching"
the Kar file.
Did you wait long ? Maybe a thread dump would help.
Regards
JB
Le 23 mai 2020 à 06:56, Paul Fraser a écrit :
JB,
More information in my follow up mail.
Comments inline.
On 23/05/2020 2:24 pm, Jean-Baptiste Onofre wrote:
Hi,
Can you describe a bit the problem ?
Does the path is a valid URL (file, http, mvn) to the Kar file ?
The exact same kar file works when added to deploy folder so I do not think the
file format could be the problem.
Kar:install command (and the service) are part of the itest, so they work at
least here.
Understood.
Maybe you are on Windows platform ?
Linux Mint Sonje
Regards
JB
Le 22 mai 2020 à 13:28, Paul Fraser a écrit :
Hi,
Using
karService#install(karPath.toUri) fails
but copying the kar jar into the deploy folder works.
Can anyone with an inner knowledge of both approaches offer any advice as to
possible cause of the failure of the karService in this case?
Or suggest where I should be looking to find the cause.
Thanks,
Paul Fraser
Re: KarService Problem
JB,
Inline.
On 23/05/2020 3:26 pm, Jean-Baptiste Onofre wrote:
The difference is in the resolution.
When you use the deploy folder: when you drop the kar in the deploy folder,
it’s directly resolved from there. That’s the difference.
Same when you do feature:install webconsole: webconsole is not part of karaf
standard distribution, so it’s not in the system folder, meaning that karaf
needs to download artifact from remote repos to install.
Maybe your issue is about the remove maven repositories (no internet
connection, or missing repo in etc/org.ops4j.pax.url.mvn.cfg). If Karaf doesn’t
do anything, it’s possible that you have a proxy or firewall blocking download
from remote repos, so you have to wait timeout.
The kar url is a file:// url and is available in a folder next to the Karaf
install.
It is happening with all of my kars under the same situation.
Silly question, but, apart from the ITest, have you used the kar and or feature service to instal
kars and features as distinct from dropping in deploy folder?
Paul
I bet if you populate the system folder, it works.
Regards
JB
Le 23 mai 2020 à 07:19, Paul Fraser a écrit :
JB,
But it works when installed in the deplo folder.
There is something different when deployed from the deploy folder and when it
is cllaed with the feature service.
I get the same problem if I try featureService.install("web-console")
Paul
On 23/05/2020 3:13 pm, Jean-Baptiste Onofre wrote:
The piece of code you mention in the FeatureService is about the provisioning,
so resolution/download of the artifact.
Maybe your features XML contained in the Kar contains "bad" URL ? Do you use
only mvn URL in the features XML packaged in the KAR (no file URL for instance) ?
Don’t you have something in the karaf.log ?
Anyway, if you can reproduce on a simple kar and send to me I will check and
try to reproduce.
Regards
JB
Le 23 mai 2020 à 07:09, Paul Fraser a écrit :
JB,
The kar file is being exploded OK and the system bogs down when resolving the
contained features.
Paul
On 23/05/2020 3:03 pm, Paul Fraser wrote:
JB,
Did you see my second email which indicates the problem in in the Feature
Service?
Paul
On 23/05/2020 3:01 pm, Jean-Baptiste Onofre wrote:
If nothing happen, I bet it’s the URL resolution download.
If the kar file is large, it can take time to download as Karaf is "caching"
the Kar file.
Did you wait long ? Maybe a thread dump would help.
Regards
JB
Le 23 mai 2020 à 06:56, Paul Fraser a écrit :
JB,
More information in my follow up mail.
Comments inline.
On 23/05/2020 2:24 pm, Jean-Baptiste Onofre wrote:
Hi,
Can you describe a bit the problem ?
Does the path is a valid URL (file, http, mvn) to the Kar file ?
The exact same kar file works when added to deploy folder so I do not think the
file format could be the problem.
Kar:install command (and the service) are part of the itest, so they work at
least here.
Understood.
Maybe you are on Windows platform ?
Linux Mint Sonje
Regards
JB
Le 22 mai 2020 à 13:28, Paul Fraser a écrit :
Hi,
Using
karService#install(karPath.toUri) fails
but copying the kar jar into the deploy folder works.
Can anyone with an inner knowledge of both approaches offer any advice as to
possible cause of the failure of the karService in this case?
Or suggest where I should be looking to find the cause.
Thanks,
Paul Fraser
Re: KarService Problem
JB,
But it works when installed in the deplo folder.
There is something different when deployed from the deploy folder and when it is cllaed with the
feature service.
I get the same problem if I try featureService.install("web-console")
Paul
On 23/05/2020 3:13 pm, Jean-Baptiste Onofre wrote:
The piece of code you mention in the FeatureService is about the provisioning,
so resolution/download of the artifact.
Maybe your features XML contained in the Kar contains "bad" URL ? Do you use
only mvn URL in the features XML packaged in the KAR (no file URL for instance) ?
Don’t you have something in the karaf.log ?
Anyway, if you can reproduce on a simple kar and send to me I will check and
try to reproduce.
Regards
JB
Le 23 mai 2020 à 07:09, Paul Fraser a écrit :
JB,
The kar file is being exploded OK and the system bogs down when resolving the
contained features.
Paul
On 23/05/2020 3:03 pm, Paul Fraser wrote:
JB,
Did you see my second email which indicates the problem in in the Feature
Service?
Paul
On 23/05/2020 3:01 pm, Jean-Baptiste Onofre wrote:
If nothing happen, I bet it’s the URL resolution download.
If the kar file is large, it can take time to download as Karaf is "caching"
the Kar file.
Did you wait long ? Maybe a thread dump would help.
Regards
JB
Le 23 mai 2020 à 06:56, Paul Fraser a écrit :
JB,
More information in my follow up mail.
Comments inline.
On 23/05/2020 2:24 pm, Jean-Baptiste Onofre wrote:
Hi,
Can you describe a bit the problem ?
Does the path is a valid URL (file, http, mvn) to the Kar file ?
The exact same kar file works when added to deploy folder so I do not think the
file format could be the problem.
Kar:install command (and the service) are part of the itest, so they work at
least here.
Understood.
Maybe you are on Windows platform ?
Linux Mint Sonje
Regards
JB
Le 22 mai 2020 à 13:28, Paul Fraser a écrit :
Hi,
Using
karService#install(karPath.toUri) fails
but copying the kar jar into the deploy folder works.
Can anyone with an inner knowledge of both approaches offer any advice as to
possible cause of the failure of the karService in this case?
Or suggest where I should be looking to find the cause.
Thanks,
Paul Fraser
Re: KarService Problem
JB, The kar file is being exploded OK and the system bogs down when resolving the contained features. Paul On 23/05/2020 3:03 pm, Paul Fraser wrote: JB, Did you see my second email which indicates the problem in in the Feature Service? Paul On 23/05/2020 3:01 pm, Jean-Baptiste Onofre wrote: If nothing happen, I bet it’s the URL resolution download. If the kar file is large, it can take time to download as Karaf is "caching" the Kar file. Did you wait long ? Maybe a thread dump would help. Regards JB Le 23 mai 2020 à 06:56, Paul Fraser a écrit : JB, More information in my follow up mail. Comments inline. On 23/05/2020 2:24 pm, Jean-Baptiste Onofre wrote: Hi, Can you describe a bit the problem ? Does the path is a valid URL (file, http, mvn) to the Kar file ? The exact same kar file works when added to deploy folder so I do not think the file format could be the problem. Kar:install command (and the service) are part of the itest, so they work at least here. Understood. Maybe you are on Windows platform ? Linux Mint Sonje Regards JB Le 22 mai 2020 à 13:28, Paul Fraser a écrit : Hi, Using karService#install(karPath.toUri) fails but copying the kar jar into the deploy folder works. Can anyone with an inner knowledge of both approaches offer any advice as to possible cause of the failure of the karService in this case? Or suggest where I should be looking to find the cause. Thanks, Paul Fraser
Re: KarService Problem
JB, Did you see my second email which indicates the problem in in the Feature Service? Paul On 23/05/2020 3:01 pm, Jean-Baptiste Onofre wrote: If nothing happen, I bet it’s the URL resolution download. If the kar file is large, it can take time to download as Karaf is "caching" the Kar file. Did you wait long ? Maybe a thread dump would help. Regards JB Le 23 mai 2020 à 06:56, Paul Fraser a écrit : JB, More information in my follow up mail. Comments inline. On 23/05/2020 2:24 pm, Jean-Baptiste Onofre wrote: Hi, Can you describe a bit the problem ? Does the path is a valid URL (file, http, mvn) to the Kar file ? The exact same kar file works when added to deploy folder so I do not think the file format could be the problem. Kar:install command (and the service) are part of the itest, so they work at least here. Understood. Maybe you are on Windows platform ? Linux Mint Sonje Regards JB Le 22 mai 2020 à 13:28, Paul Fraser a écrit : Hi, Using karService#install(karPath.toUri) fails but copying the kar jar into the deploy folder works. Can anyone with an inner knowledge of both approaches offer any advice as to possible cause of the failure of the karService in this case? Or suggest where I should be looking to find the cause. Thanks, Paul Fraser
Re: KarService Problem
JB, More information in my follow up mail. Comments inline. On 23/05/2020 2:24 pm, Jean-Baptiste Onofre wrote: Hi, Can you describe a bit the problem ? Does the path is a valid URL (file, http, mvn) to the Kar file ? The exact same kar file works when added to deploy folder so I do not think the file format could be the problem. Kar:install command (and the service) are part of the itest, so they work at least here. Understood. Maybe you are on Windows platform ? Linux Mint Sonje Regards JB Le 22 mai 2020 à 13:28, Paul Fraser a écrit : Hi, Using karService#install(karPath.toUri) fails but copying the kar jar into the deploy folder works. Can anyone with an inner knowledge of both approaches offer any advice as to possible cause of the failure of the karService in this case? Or suggest where I should be looking to find the cause. Thanks, Paul Fraser
Re: KarService Problem
Hi, V 4.2.8 The problem is occuring when the future does not return and no error is thrown in this code- https://github.com/apache/karaf/blob/262343a5f60b29967a3c72a198f6427b5a6bf5e9/features/core/src/main/java/org/apache/karaf/features/internal/service/FeaturesServiceImpl.java#L967 The system just hangs and the console will not respond to ctrl-D, but responds to ctrl-c On 22/05/2020 9:28 pm, Paul Fraser wrote: Hi, Using karService#install(karPath.toUri) fails but copying the kar jar into the deploy folder works. Can anyone with an inner knowledge of both approaches offer any advice as to possible cause of the failure of the karService in this case? Or suggest where I should be looking to find the cause. Thanks, Paul Fraser
KarService Problem
Hi, Using karService#install(karPath.toUri) fails but copying the kar jar into the deploy folder works. Can anyone with an inner knowledge of both approaches offer any advice as to possible cause of the failure of the karService in this case? Or suggest where I should be looking to find the cause. Thanks, Paul Fraser
Re: Handling legacy libraries in OSGi/Karaf - Karat Meet-up chat questions
Hi, Thanks to all involved with the Zoom meetup. Getting up at 1am (AU time) for a 2am meeting to stare at a computer for 2 hours was a stretch but well worth the effort. The 90% improvement in cost by Netflix when using Karaf was an outstanding fact presented. Paul Fraser On 1/05/2020 6:27 am, Francois Papon wrote: Yes! I'm joining Achim, community is very important for the project, don't hesitate to share proposals and ideas :) Every questions and feedbacks are welcome, this how we can improve Apache Karaf and make it great for the users! PS: kudo to JB and Achim for the organization, it was perfect! regards, François fpa...@apache.org Le 30/04/2020 à 21:25, Achim Nierbeck a écrit : Hey People, don't be intimidated by other on this list :) If you have questions or ideas on answering others, don't hesitate to do so. TBH, when I was a Karaf noob I just hang out here with a bunch of ideas what needed be improved regarding the web-container. So someone told me to just do it. AFAIRC that's been JB and Guillaume :) I would love to see a vibrant community on this list again, so there is no question not worth to be asked and no answer to simple to be said. take care, Achim P.S. was lot's of fun today, thanks to all that participated Am Do., 30. Apr. 2020 um 21:13 Uhr schrieb Maurice Betzel <mailto:m.bet...@gaston-schul.com>>: I did have some stuff regarding this on github. Aries Spi-Fly and bundeling non Osgi stuff: https://github.com/Maurice-Betzel/twelvemonkeys-osgi Even native code can be bundled: https://github.com/Maurice-Betzel/lmdb-osgi -- Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html -- 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>
Re: Karaf and Libjitsi
Hi Francois, Many thanks for doing this and to JB who probably asked you to do it :-) . Hopefully this will assist others wanting to play with conferencing and other AV apps. Regards Paul Fraser On 1/05/2020 7:37 am, Francois Papon wrote: Hi Paul, I pushed a PR just to fix the dependencies in the feature.xml. I have it works on a fresh Apache Karaf 4.3.0-RC1. You need to add some export package from the JRE in the etc/jre.properties. I added some quotes in the README.md. https://github.com/QNENet/qneav/pull/1 I agree with JB for the usage of private dependencies, I will push another PR with this design. regards, François fpa...@apache.org Le 16/04/2020 à 08:12, Paul Fraser a écrit : Hi JB, On 13/04/2020 3:54 pm, Jean-Baptiste Onofre wrote: I guess you are talking about dependencies like *ch.imvs.sdes4j.srtp right ?* * * *I think the easiest way is both a small wrapping (to embed such dependencies as private) and a features XML.* * * *I can do that easily if it’s helpful for you.* The dependencies causing concern are as listed in the attached feature.xml Can you give me a clue as to what you have in mind or how to create "*a small wrapping (to embed such dependencies as private"?* * * Regards Paul Fraser* *
Re: Karaf and Libjitsi
Hi JB,
On 13/04/2020 3:54 pm, Jean-Baptiste Onofre wrote:
I guess you are talking about dependencies like *ch.imvs.sdes4j.srtp right ?*
*
*
*I think the easiest way is both a small wrapping (to embed such dependencies as private) and a
features XML.*
*
*
*I can do that easily if it’s helpful for you.*
The dependencies causing concern are as listed in the attached feature.xml
Can you give me a clue as to what you have in mind or how to create "*a small wrapping (to
embed such dependencies as private"?*
*
*
Regards
Paul Fraser*
*
http://karaf.apache.org/xmlns/features/v1.6.0";>
QNE Audio Visual Features
mvn:ch.imvs/sdes4j/1.1.3
mvn:org.jitsi/bccontrib/1.0
mvn:org.jitsi/fmj/1.0-SNAPSHOT
mvn:net.java.dev.jna/jna/4.1.0
mvn:commons-codec/commons-codec/1.14
mvn:org.jitsi/libjitsi/${project.version}
mvn:org.jitsi/jain-sip-ri-ossonly/1.2.98c7f8c-jitsi-oss1
mvn:org.jitsi/zrtp4j-light/4.1.0-jitsi-1-SNAPSHOT
mvn:org.jitsi/jitsi-lgpl-dependencies/1.2-1-gfc49658
mvn:net.qnenet.qneav/qavailablemediadevices/${project.version}
mvn:net.qnenet.qneav/qavreceivetransmit/${project.version}
Re: Karaf and Libjitsi
Hi JB, That would be MORE than most helpfull, I have been trying to make some headway for a week. This is my early struggle code https://github.com/QNENet/qneav Paul On 13/04/2020 3:54 pm, Jean-Baptiste Onofre wrote: Hi Paul, I guess you are talking about dependencies like *ch.imvs.sdes4j.srtp right ?* * * *I think the easiest way is both a small wrapping (to embed such dependencies as private) and a features XML.* * * *I can do that easily if it’s helpful for you.* * * *Regards* *JB * Le 13 avr. 2020 à 07:36, Paul Fraser mailto:pa...@qnenet.com>> a écrit : Hi, As video conferencing is the flavour of the month at the moment I have attempted to create a feature based on Libjitsi https://github.com/jitsi/libjitsi Cloning and building with maven only takes a few minutes and builds without problems. But when I try to create a feature based on the AVTransmit2 and AVReceive2 I get into trouble with the dependencies required to be included in the feature. Some of the depencies, which are quite cleary available in my maven .m2 , fail to be found when running the maven build for the feature. During this current "lockup/in" someone with a better understanding (than me) of maven and karaf feature requirements might like to spend an hour or so checking if it is possible to get Libjitsi running in Karaf. Regards Paul Fraser
Karaf and Libjitsi
Hi, As video conferencing is the flavour of the month at the moment I have attempted to create a feature based on Libjitsi https://github.com/jitsi/libjitsi Cloning and building with maven only takes a few minutes and builds without problems. But when I try to create a feature based on the AVTransmit2 and AVReceive2 I get into trouble with the dependencies required to be included in the feature. Some of the depencies, which are quite cleary available in my maven .m2 , fail to be found when running the maven build for the feature. During this current "lockup/in" someone with a better understanding (than me) of maven and karaf feature requirements might like to spend an hour or so checking if it is possible to get Libjitsi running in Karaf. Regards Paul Fraser
Having trouble using KarService#install.
Hi, Having trouble using KarService#install. I have created a simple example of what I am trying to do at https://github.com/QNENet/qkardeployerexample I have not been able to work out how to setup "kardeployerfeatures" which is used to deploy kartest. Any assistance gratefully accepted and if we get it to work it could be left up for the benefit of others. Regards Paul Fraser
Re: FeaturesService Code Examples
Thanks, Markus, Looks to be a worthwhile example of the process. Paul Fraser On 26/11/2019 6:10 pm, Markus Rathgeb wrote: Hi, openHAB uses the feature service programmatically, too. So, for an example you could also look at: https://github.com/openhab/openhab-core/blob/c50766d7c37a19f634e88fbe47b03b90215ab398/bundles/org.openhab.core.karaf/src/main/java/org/openhab/core/karaf/internal/FeatureInstaller.java#L115 I never checked that code if it is done correctly but for some inspiration... Am Fr., 22. Nov. 2019 um 06:01 Uhr schrieb Jean-Baptiste Onofré : Hi Paul, You can use Cave Deployer that deal with features service, locally or remotely (using JMX). Regards JB On 22/11/2019 05:59, Paul Fraser wrote: Hi, Now at the stage of wanting to install, uninstall and do all of the clever karaf things in code, but I cannot locate any usefull examples. My attempts so far have failed as there seems to be peculiar forms of presenting feature repo and feature names in code and the required work flow eludes me. I have checked out the itest test code in the karaf distribution but the code is rather difficult to follow and I have not found suitable snippets. Any where I should be looking for inspiration? Paul Fraser -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com
FeaturesService Code Examples
Hi, Now at the stage of wanting to install, uninstall and do all of the clever karaf things in code, but I cannot locate any usefull examples. My attempts so far have failed as there seems to be peculiar forms of presenting feature repo and feature names in code and the required work flow eludes me. I have checked out the itest test code in the karaf distribution but the code is rather difficult to follow and I have not found suitable snippets. Any where I should be looking for inspiration? Paul Fraser
Re: Karaf pax.web 2 Servlets 2 ports
Hi JB, As usual, thanks for your very fast reply. A full example would be most valuable. I will try and work through the blog and will let you know how I go. Paul On 8/11/2019 7:52 pm, Jean-Baptiste Onofré wrote: Hi Paul, You can take a look on: http://blog.nanthrax.net/?p=352 You can setup two connector in jetty.xml and then bind a servlet to vhost. It doesn't use whiteboard, but you can define the vhost as service property. I can also add a full example in Karaf if you think it makes sense. Regards JB On 08/11/2019 09:43, Paul Fraser wrote: Hi, https://github.com/ops4j/org.ops4j.pax.web/tree/master/samples/whiteboard-extended has been offered as an example of serving on 2 ports, for example with the karaf jetty setup. How and where are the port values set? These examples are 3 years old, is there anything more recent (Karaf 4.2.6) and perhaps simpler ? Paul Fraser
Karaf pax.web 2 Servlets 2 ports
Hi, https://github.com/ops4j/org.ops4j.pax.web/tree/master/samples/whiteboard-extended has been offered as an example of serving on 2 ports, for example with the karaf jetty setup. How and where are the port values set? These examples are 3 years old, is there anything more recent (Karaf 4.2.6) and perhaps simpler ? Paul Fraser
Whereis http://karaf.apache.org/xmlns/features/v1.6.0
Hi, The latest version showing is http://karaf.apache.org/xmlns/features/v1.5.0 It is probaly in the code somewhere but I cannot find it. Paul Fraser
Re: Wait for feature install to complete
I mean the deploy folder, not the install folder... On 26/09/2019 3:59 pm, Paul Fraser wrote: Hi, The order of starting features can be controlled by using prerequisite in the feature tag. What technique is available or what method can be used to prevent a feature being installed until a prequisite feature has completed processing? If I place feature1 (the prerequisite) in the install folder followed by placing feature2 in the install folder all is OK. Regards Paul Fraser
Wait for feature install to complete
Hi, The order of starting features can be controlled by using prerequisite in the feature tag. What technique is available or what method can be used to prevent a feature being installed until a prequisite feature has completed processing? If I place feature1 (the prerequisite) in the install folder followed by placing feature2 in the install folder all is OK. Regards Paul Fraser
Section 4.17.1 Http Service
Hi, Documentation 4.0x, Http Service section states thet the Http service can be checked by feature:install http followed by localhost:8181 With both fresh installs of 4.2.5 and 4.2.6 this results in Unable to connect. Is this expected to work as suggested or is there something missing in the docs? Paul Fraser
Re: Using port 80 with org.ops4j.pax.web
Thanks, JB, That what I was after, Karaf does not care what port is specified. Paul On 3/09/2019 3:53 pm, Jean-Baptiste Onofré wrote: Hi Paul, It's not directly related to Karaf but more on the user who's running it. For instance, on Linux, to use port < 1024, the user has to have permission. By default, only root can use ports < 1024. Regards JB On 03/09/2019 07:42, Paul Fraser wrote: Hi, Using org.osgi.service.http.port=80 in the web.cfg file does not work for me. Is this the typical problem with ports under 1024 or should it be possible? Paul Fraser
Using port 80 with org.ops4j.pax.web
Hi, Using org.osgi.service.http.port=80 in the web.cfg file does not work for me. Is this the typical problem with ports under 1024 or should it be possible? Paul Fraser
Feature Update Technique
Hi, What is the current technique for updating a feature? I have tried feature:refresh and the feature:repo-refresh. The only way I have succeeded so far is a complete maven rebuild and restart of Karaf. Researching previous discussions suggest creating and installing a new version of the feature works OK. Paul Fraser
Re: Debugging Itests
Hi Again, Is it possible in an itest to debug into the inner karaf runtime? To try and debug into the "listBundleCommand" test in the Karaf Itest example I tried 1. Set breakpoint on "String httpPort = ..." in the "public Option[] config()" method in the itest code. 2. Set breakpoint at first line in "listBundleCommand" test. 3. Set a remote configuration in Intellij with port 5005. 4. start karaf with bin/karaf debug. 5. console displays "Listening for transport dt at address: 5005 6. Karaf starts up with branding and prompt. 7. Shift-F9 in intellij starts a debug session. 8. Debug console displays "Connected to the target VM, address: 'localhost:5005", transport: 'socket' 9. Run test (debug) 10. Debugger stops at breakpoint '1' above. 11. Does not stop at breakpoint '2' above. 12. "listBundleCommand" test runs to completion and output as expected. If it can be done, what am I missing? Paul Fraser
Re: Debugging Itests
Hi, On 2/06/2019 7:20 am, Paul Fraser wrote: Hmm, Over thinking the problem..I was looking in the wrong place. When setting up MavenArtifactUrlReference I had the artifact "type" being set AFTER "versionAsInProject" Fixed this and the Karaf magic worked. My comments (above) are rubbish. The order of the build of the MavenArtifactUrlReference does not matter. Paul Fraser
Re: Staged Boot Question
Hi JB, I did not explain the assistance I was seeking in my last mail very well. Is it possible to set a value for featuresBoot in the features.cfg file as part of the assembly (pom) process? If so, what do I need to do? The staged value shown below is the value I need to set. Paul Fraser On 3/06/2019 12:31 pm, Paul Fraser wrote: This works perfectly but problem is how to set this value from assembly pom. featuresBoot = \ framework/4.2.5, \ (standard/4.2.5, pax-http/7.2.8)\ (vaadin-flow-base),\ vaadin-flow Paul On 3/06/2019 7:22 am, Paul Fraser wrote: Hi JB, Thanks for your perseverence so far. Trying to get correct feature install order using "requirement" as you suggest. Spifly dynamic bundle exposes capability "osgi.extender=osgi.serviceloader.registrar" Attached file has snippet of my approach. But does not work for me, yet. Paul
Re: Staged Boot Question
Hi, This works perfectly but problem is how to set this value from assembly pom. featuresBoot = \ framework/4.2.5, \ (standard/4.2.5, pax-http/7.2.8)\ (vaadin-flow-base),\ vaadin-flow Paul On 3/06/2019 7:22 am, Paul Fraser wrote: Hi JB, Thanks for your perseverence so far. Trying to get correct feature install order using "requirement" as you suggest. Spifly dynamic bundle exposes capability "osgi.extender=osgi.serviceloader.registrar" Attached file has snippet of my approach. But does not work for me, yet. Paul
Re: Staged Boot Question
Hi JB,
Thanks for your perseverence so far.
Trying to get correct feature install order using "requirement" as you suggest.
Spifly dynamic bundle exposes capability
"osgi.extender=osgi.serviceloader.registrar"
Attached file has snippet of my approach. But does not work for me, yet.
Paul
Vaadin Flow Base
osgi.extender;filter:="(osgi.extender=osgi.serviceloader.registrar)"
mvn:com.vaadin/flow-server/${vaadin.version}
mvn:com.vaadin/flow-push/${vaadin.version}
mvn:com.vaadin/flow-data/${vaadin.version}
..
..
===
org.apache.karaf.tooling
karaf-maven-plugin
standard
pax-http
vaadin-flow
wrapper
1.8
Re: Staged Boot Question
On 2/06/2019 4:13 pm, Jean-Baptiste Onofré wrote:
In your case, you should have (standard, http),vaadin-flow.
So, how would this be represented in the assembly pom, also if concrete
standard features are used?
Brackets in my tests are ignored in the assembly pom.
standard
{standard,pax-http)
vaadin-flow
Paul
By the way, I recommend to not use standard meta feature in boot, but
rather the concrete features defined by standard meta feature.
Regards
JB
On 02/06/2019 07:26, Paul Fraser wrote:
Sounds good.
How do I handle it in the assembly pom to get it into features.cfg?
standard
{pax-http)
vaadin-flow
If only one level, how is standard staged?
Or should vaadin-flow be placed in ?
Paul
On 2/06/2019 3:06 pm, Jean-Baptiste Onofré wrote:
Hi,
yes, stage boot is present, and used.
Currently, it supports one level (I plan to add several levels).
You can do (in etc/org.apache.karaf.features.cfg):
featuresBoot=(...),...
The features in the parentheses will be started before the one outside
of the parentheses.
Regards
JB
On 02/06/2019 07:03, Paul Fraser wrote:
Hi,
Back in 2016 there was some discussion about predicable boot feature
startup order.
Staged boot was mentioned and the solution involved parentheses, but
current documentation does not mention "staged boot".
Is this functionality still available?
How and where are the parentheses used if staged boot available?
My need relates to previous discussion about service loading. I have an
absolute need for aries dynamic spyfly to be running before the vaadin
flow server is activated.
At present, the only way I can get the correct order is to include
pax-http in my assembly and start a vaadin flow feature containing the
vaadin server after karaf is running.
Paul Fraser
Re: Staged Boot Question
Sounds good.
How do I handle it in the assembly pom to get it into features.cfg?
standard
{pax-http)
vaadin-flow
If only one level, how is standard staged?
Or should vaadin-flow be placed in ?
Paul
On 2/06/2019 3:06 pm, Jean-Baptiste Onofré wrote:
Hi,
yes, stage boot is present, and used.
Currently, it supports one level (I plan to add several levels).
You can do (in etc/org.apache.karaf.features.cfg):
featuresBoot=(...),...
The features in the parentheses will be started before the one outside
of the parentheses.
Regards
JB
On 02/06/2019 07:03, Paul Fraser wrote:
Hi,
Back in 2016 there was some discussion about predicable boot feature
startup order.
Staged boot was mentioned and the solution involved parentheses, but
current documentation does not mention "staged boot".
Is this functionality still available?
How and where are the parentheses used if staged boot available?
My need relates to previous discussion about service loading. I have an
absolute need for aries dynamic spyfly to be running before the vaadin
flow server is activated.
At present, the only way I can get the correct order is to include
pax-http in my assembly and start a vaadin flow feature containing the
vaadin server after karaf is running.
Paul Fraser
Staged Boot Question
Hi, Back in 2016 there was some discussion about predicable boot feature startup order. Staged boot was mentioned and the solution involved parentheses, but current documentation does not mention "staged boot". Is this functionality still available? How and where are the parentheses used if staged boot available? My need relates to previous discussion about service loading. I have an absolute need for aries dynamic spyfly to be running before the vaadin flow server is activated. At present, the only way I can get the correct order is to include pax-http in my assembly and start a vaadin flow feature containing the vaadin server after karaf is running. Paul Fraser
Re: Debugging Itests
Hmm,
Over thinking the problem..I was looking in the wrong place.
When setting up MavenArtifactUrlReference I had the artifact "type" being set AFTER
"versionAsInProject"
Fixed this and the Karaf magic worked.
Thanks JB and Francois for your assistance.
Also, https://www.youtube.com/watch?v=qNmBZjJcups&feature=youtu.be Eclipsecon presentation by Łukasz
Dywicki has been very helpful.
In fact, the presentation by Lukasz, fortunately, caused me to take a new look at Karaf, which I
have been ignoring for years.
Support on this list during this learning phase has been outstanding, thanks..
Paul
On 2/06/2019 2:06 am, Jean-Baptiste Onofré wrote:
You need debugConfiguration only if you want to specify the port.
By default it's 5005 (not random), so, yes, it should work straight forward.
Regards
JB
On 01/06/2019 14:04, Paul Fraser wrote:
On 1/06/2019 7:10 pm, Jean-Baptiste Onofré wrote:
Actually, if you run in debug mode directly in intellij, it works,
nothing special is required.
Does this mean it is not necessary to uncomment
"KarafDistributionOption.debugConfiguration("5005", true)"?
Are you running your itests in IntelliJ ?
Yes. Trying to..
It seems that somewhere the port for the connection to the java vm is
not being set to 5005 but a random high value.
Should the port for the vm be set to 5005 by Karaf when debugging?
Paul
Regards
JB
On 01/06/2019 08:09, Paul Fraser wrote:
On 1/06/2019 4:03 pm, Jean-Baptiste Onofré wrote:
Hi Paul,
What Pax Exam version are you using ?
pax exam 4.13.1 and Karaf 4.2.5
Paul
Regards
JB
On 01/06/2019 08:01, Paul Fraser wrote:
Hi,
The example itests code has line
"KarafDistributionOption.debugConfiguration("8889", true) commented
out.
Presumably, the idea is to uncomment and debug of the itest becomes
possible. (for intellij set port to 5005 and remote debug config
set in
intellij)
When I try to debug the target connects -
"Connected to the target VM, address: '127.0.0.1:52458', transport:
'socket' " and then
"Listening for transport dt_socket at address:5005"
If I run debugging outside an itest with "bin\karaf debug" , it works.
What am I missing in the debug itests case?
Paul Fraser
Re: Debugging Itests
On 1/06/2019 7:10 pm, Jean-Baptiste Onofré wrote:
Actually, if you run in debug mode directly in intellij, it works,
nothing special is required.
Does this mean it is not necessary to uncomment "KarafDistributionOption.debugConfiguration("5005",
true)"?
Are you running your itests in IntelliJ ?
Yes. Trying to..
It seems that somewhere the port for the connection to the java vm is not being set to 5005 but a
random high value.
Should the port for the vm be set to 5005 by Karaf when debugging?
Paul
Regards
JB
On 01/06/2019 08:09, Paul Fraser wrote:
On 1/06/2019 4:03 pm, Jean-Baptiste Onofré wrote:
Hi Paul,
What Pax Exam version are you using ?
pax exam 4.13.1 and Karaf 4.2.5
Paul
Regards
JB
On 01/06/2019 08:01, Paul Fraser wrote:
Hi,
The example itests code has line
"KarafDistributionOption.debugConfiguration("8889", true) commented out.
Presumably, the idea is to uncomment and debug of the itest becomes
possible. (for intellij set port to 5005 and remote debug config set in
intellij)
When I try to debug the target connects -
"Connected to the target VM, address: '127.0.0.1:52458', transport:
'socket' " and then
"Listening for transport dt_socket at address:5005"
If I run debugging outside an itest with "bin\karaf debug" , it works.
What am I missing in the debug itests case?
Paul Fraser
Re: Debugging Itests
On 1/06/2019 4:03 pm, Jean-Baptiste Onofré wrote:
Hi Paul,
What Pax Exam version are you using ?
pax exam 4.13.1 and Karaf 4.2.5
Paul
Regards
JB
On 01/06/2019 08:01, Paul Fraser wrote:
Hi,
The example itests code has line
"KarafDistributionOption.debugConfiguration("8889", true) commented out.
Presumably, the idea is to uncomment and debug of the itest becomes
possible. (for intellij set port to 5005 and remote debug config set in
intellij)
When I try to debug the target connects -
"Connected to the target VM, address: '127.0.0.1:52458', transport:
'socket' " and then
"Listening for transport dt_socket at address:5005"
If I run debugging outside an itest with "bin\karaf debug" , it works.
What am I missing in the debug itests case?
Paul Fraser
Debugging Itests
Hi,
The example itests code has line "KarafDistributionOption.debugConfiguration("8889", true) commented
out.
Presumably, the idea is to uncomment and debug of the itest becomes possible. (for intellij set port
to 5005 and remote debug config set in intellij)
When I try to debug the target connects -
"Connected to the target VM, address: '127.0.0.1:52458', transport: 'socket' "
and then
"Listening for transport dt_socket at address:5005"
If I run debugging outside an itest with "bin\karaf debug" , it works.
What am I missing in the debug itests case?
Paul Fraser
Assembly Archetype 4.2.5 Error
Hi, Assembly generated from unchanged pom created by Assembly archetype 4.2.5 results in this error.. "Caused by: java.lang.IllegalStateException: HttpService must be implementing Pax-Web WebContainer!" Is this possibly a bug or should I look elsewhere? Any guidance welcome.. Paul Fraser Apache Karaf (4.2.5) Hit '' for a list of available commands and '[cmd] --help' for help on a specific command. Hit '' or type 'system:shutdown' or 'logout' to shutdown Karaf. org.apache.karaf.features.internal.util.MultiException: Error restarting bundles: Activator start error in bundle org.ops4j.pax.web.pax-web-extender-whiteboard [143]. at org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:1005) at org.apache.karaf.features.internal.service.FeaturesServiceImpl.doProvision(FeaturesServiceImpl.java:1058) at org.apache.karaf.features.internal.service.FeaturesServiceImpl.lambda$doProvisionInThread$13(FeaturesServiceImpl.java:994) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:748) Suppressed: org.osgi.framework.BundleException: Activator start error in bundle org.ops4j.pax.web.pax-web-extender-whiteboard [143]. at org.apache.felix.framework.Felix.activateBundle(Felix.java:2290) at org.apache.felix.framework.Felix.startBundle(Felix.java:2146) at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:998) at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:984) at org.apache.karaf.features.internal.service.BundleInstallSupportImpl.startBundle(BundleInstallSupportImpl.java:161) at org.apache.karaf.features.internal.service.FeaturesServiceImpl.startBundle(FeaturesServiceImpl.java:1149) at org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:997) ... 6 more Caused by: java.lang.IllegalStateException: HttpService must be implementing Pax-Web WebContainer! at org.ops4j.pax.web.extender.whiteboard.internal.ExtendedHttpServiceRuntime.serviceChanged(ExtendedHttpServiceRuntime.java:110) at org.ops4j.pax.web.extender.whiteboard.internal.ExtendedHttpServiceRuntime.serviceChanged(ExtendedHttpServiceRuntime.java:44) at org.ops4j.pax.web.extender.whiteboard.internal.util.tracker.ReplaceableService.bind(ReplaceableService.java:86) at org.ops4j.pax.web.extender.whiteboard.internal.util.tracker.ReplaceableService$Customizer.addingService(ReplaceableService.java:105) at org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:941) at org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:870) at org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:256) at org.osgi.util.tracker.AbstractTracked.trackInitial(AbstractTracked.java:183) at org.osgi.util.tracker.ServiceTracker.open(ServiceTracker.java:318) at org.osgi.util.tracker.ServiceTracker.open(ServiceTracker.java:261) at org.ops4j.pax.web.extender.whiteboard.internal.util.tracker.ReplaceableService.start(ReplaceableService.java:72) at org.ops4j.pax.web.extender.whiteboard.internal.ExtendedHttpServiceRuntime.start(ExtendedHttpServiceRuntime.java:155) at org.ops4j.pax.web.extender.whiteboard.internal.Activator.start(Activator.java:98) at org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:697) at org.apache.felix.framework.Felix.activateBundle(Felix.java:2240) ... 12 more karaf@root()> org.ops4j.pax.swissbox.tracker.ServiceLookupException: gave up waiting for service org.apache.karaf.features.BootFinished at org.ops4j.pax.swissbox.tracker.ServiceLookup.getService(ServiceLookup.java:199) at org.ops4j.pax.swissbox.tracker.ServiceLookup.getService(ServiceLookup.java:136) at org.ops4j.pax.exam.inject.internal.ServiceInjector.injectField(ServiceInjector.java:89) at org.ops4j.pax.exam.inject.internal.ServiceInjector.injectDeclaredFields(ServiceInjector.java:69) at org.ops4j.pax.exam.inject.internal.ServiceInjector.injectFields(ServiceInjector.java:61) at org.ops4j.pax.exam.invoker.junit.internal.ContainerTestRunner.createTest(ContainerTestRunner.java:68) at org.junit.runners.BlockJUnit4ClassRunner$1.runReflectiveCall(BlockJUnit4ClassRunner.java:266) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) at org.junit.runners.BlockJUnit4ClassRunner.methodBlock(BlockJUnit4ClassRunner.java:263) at org.ops4j.pax.exam.invoker.junit.internal.ContainerTestRunner.runChildWithRetry(ContainerTestRunner.java:84) at org.ops
Re: Intellij and Karaf Archetypes
Hi Matthias, Thanks for our reply. Since sending my post to the list I have been able to get the archetypes into the intellij list by adding them to the UserArchetypes.xml file which is to be found in windows in the users directory ".IdeaIC2019.1\system\Maven\Indices" in my intellij installation. I had no idea that using the command line archetype technique would put the archetypes in the intellij list. I will check this out later. Paul On 30/05/2019 6:20 pm, Matthias Wegner wrote: Hi Paul, Just follow the documentation of https://karaf.apache.org/manual/latest/#_archetypes and use the latest version 4.2.5. In the Karaf-doc this command fills the catalog.xml again. Ps: maybe a look at the second example in https://nightofprompt.home.blog/2019/05/23/karaf-part1/ helps. Regards, Matthias Am 30.05.2019 um 06:24 schrieb Paul Fraser mailto:pa...@qnenet.com>>: Hi, I have had the latest IntelliJ working with karaf and the Karaf archetypes were available when adding new modules and each archetype had drop down list of avaliable versions. Somehow, I have lost these entries in the archetype list and need to have them back. I cannot find a karaf archetype catalog.xml file. What do I need to do to have these archetype list entries back? Paul Fraser
Intellij and Karaf Archetypes
Hi, I have had the latest IntelliJ working with karaf and the Karaf archetypes were available when adding new modules and each archetype had drop down list of avaliable versions. Somehow, I have lost these entries in the archetype list and need to have them back. I cannot find a karaf archetype catalog.xml file. What do I need to do to have these archetype list entries back? Paul Fraser
Re: Problem with SpiFly serviceloader
Hi Benjamin, It gets installed as part of the "http" feature which I have installed. It is showing as ACTIVE in the bundle list. "aries-proxy" feature is also required for asm support of the dynamic bundle and it is installed and ACTIVE in my installation. Paul On 26/05/2019 4:36 pm, Benjamin Graf wrote: Hi Paul, did you install mvn:org.apache.aries.spifly/org.apache.aries.spifly.dynamic.bundle/1.2.1? It's not listed in your feature file. I think that's all you need. Regards Benjamin Am 26.05.2019 um 06:33 schrieb Jean-Baptiste Onofré: Hi, osgi.serviceloader.registrar package is part of OSGi R7 (so Karaf 4.3.x, not 4.2.x). Don't you use bndtools to create your bundle ? Regards JB On 25/05/2019 21:46, Paul Fraser wrote: Hi Francois, 4.2.5 On 26/05/2019 12:57 am, Francois Papon wrote: Hi Paul, Wich version of Karaf are you using? regards, François fpa...@apache.org Le 25/05/2019 à 08:48, Paul Fraser a écrit : Hi, Attached are some details of the code I am having problem with. The end of the instantiator-error.txt file clearly indicates the problem but I have not been able to solve it. "missing requirement [kOSGiInstantiator/1.0.0.SNAPSHOT] osgi.extender; filter="(osgi.extender=osgi.serviceloader.registrar)" Karaf features for handling serviceloader seem to require "aries-proxy" and "http" to provide all thats needed. What am I missing? Paul Fraser
Re: Problem with SpiFly serviceloader
Hi Francois, 4.2.5 On 26/05/2019 12:57 am, Francois Papon wrote: Hi Paul, Wich version of Karaf are you using? regards, François fpa...@apache.org Le 25/05/2019 à 08:48, Paul Fraser a écrit : Hi, Attached are some details of the code I am having problem with. The end of the instantiator-error.txt file clearly indicates the problem but I have not been able to solve it. "missing requirement [kOSGiInstantiator/1.0.0.SNAPSHOT] osgi.extender; filter="(osgi.extender=osgi.serviceloader.registrar)" Karaf features for handling serviceloader seem to require "aries-proxy" and "http" to provide all thats needed. What am I missing? Paul Fraser
Problem with SpiFly serviceloader
Hi,
Attached are some details of the code I am having problem with.
The end of the instantiator-error.txt file clearly indicates the problem but I have not been able to
solve it.
"missing requirement [kOSGiInstantiator/1.0.0.SNAPSHOT] osgi.extender;
filter="(osgi.extender=osgi.serviceloader.registrar)"
Karaf features for handling serviceloader seem to require "aries-proxy" and "http" to provide all
thats needed.
What am I missing?
Paul Fraser
karaf@root()> feature:install vaadin-flow-mainview
Error executing command: Unable to resolve root: missing requirement [root]
osgi.identity; osgi.identity=vaadin-flow; type=karaf.feature;
version="[1.0.0.SNAPSHOT,1.0.0.SNAPSHOT]";
filter:="(&(osgi.identity=vaadin-flow)(type=karaf.feature)(version>=1.0.0.SNAPSHOT)(version<=1.0.0.SNAPSHOT))"
[caused by: Unable to resolve vaadin-flow/1.0.0.SNAPSHOT: missing requirement
[vaadin-flow/1.0.0.SNAPSHOT] osgi.identity;
osgi.identity=vaadin-flow-instantiator; type=karaf.feature [caused by: Unable
to resolve vaadin-flow-instantiator/1.0.0.SNAPSHOT: missing requirement
[vaadin-flow-instantiator/1.0.0.SNAPSHOT] osgi.identity;
osgi.identity=kOSGiInstantiator; type=osgi.bundle;
version="[1.0.0.SNAPSHOT,1.0.0.SNAPSHOT]"; resolution:=mandatory [caused by:
Unable to resolve kOSGiInstantiator/1.0.0.SNAPSHOT: missing requirement
[kOSGiInstantiator/1.0.0.SNAPSHOT] osgi.extender;
filter="(osgi.extender=osgi.serviceloader.registrar)"]]]
http://maven.apache.org/POM/4.0.0"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd";>
kViews
net.qnenet.kSite
1.0-SNAPSHOT
../pom.xml
4.0.0
net.qnenet.kSite.kViews
kOSGiInstantiator
bundle
QNENet :: KSite :: KViews :: KOSGiInstantiator
kOSGiInstantiator OSGi bundle project.
4.1.0
6.0.0
org.osgi
org.osgi.core
${osgi.version}
provided
com.vaadin
flow-server
1.4.2
compile
net.qnenet.kSite.kViews
kViewManager
1.0-SNAPSHOT
compile
org.apache.felix
maven-bundle-plugin
${maven-bundle-plugin.version}
true
${project.artifactId}
${project.version}
net.qnenet.kSite.kViews*;version=${project.version}
*
osgi.extender; filter="(osgi.extender=osgi.serviceloader.registrar)"
osgi.serviceloader; osgi.serviceloader=com.vaadin.flow.di.Instantiator
*
org.apache.maven.plugins
maven-compiler-plugin
1.8
1.8
256M
http://karaf.apache.org/xmlns/features/v1.4.0";>
mvn:net.qnenet.kSite.kUtils/kUtilsFeatures/1.0-SNAPSHOT/xml/features
Vaadin Flow Base
scr
http
http-whiteboard
mvn:com.vaadin/flow-server/1.4.2
mvn:com.vaadin/flow-push/1.4.2
mvn:com.vaadin/flow-data/1.4.2
mvn:com.vaadin/flow-client/1.4.2
mvn:com.vaadin/flow-html-components/1.4.2
mvn:com.vaadin/flow-osgi/1.4.2
mvn:com.vaadin/vaadin-lumo-theme/1.4.2
mvn:com.vaadin/vaadin-material-theme/1.4.2
mvn:org.jsoup/jsoup/1.11.3
mvn:com.vaadin.external.gwt/gwt-elemental/2.8.2.vaadin2
mvn:com.vaadin.external/gentyref/1.2.0.vaadin1
mvn:com.helger/ph-css/6.1.1
mvn:com.helger/ph-commons/9.2.1
mvn:javax.servlet/javax.servlet-api/3.1.0
mvn:commons-io/commons-io/2.6
mvn:net.bytebuddy/byte-buddy/1.9.8
mvn:commons-fileupload/commons-fileupload/1.3.3
mvn:com.vaadin.external.slf4j/vaadin-slf4j-jdk14/1.6.1
mvn:org.apache.commons/commons-lang3/3.9
mvn:com.fasterxml.jackson.core/jackson-annotations/2.9.8
mvn:com.fasterxml.jackson.core/jackson-core/2.9.8
mvn:com.fasterxml.jackson.core/jackson-databind/2.9.8
Va
Cellar Ports, Firewalls and Nat
Hi, After installing karaf and installing cellar on a hosted VPS all works and the cluster commands are recognized. Also doing same on lan works. Trying same on a remote system behind a firewall (local system modem) and forwarding port 5701 I can install and start cellar with SSH OK but the cluster command is not recognized. Could this be related to port access or is something else suggested by the problem? Also, is there available or contemplated a port forwarding feature for Karaf? Paul Fraser
Re: Close console after running start.bat
more info.. The console that remains, is titled "Administrator: Karaf. Karaf is running OK in the background for both linux and windows but of course stops if the console is closed in the windows verssion. Paul On 15/05/2019 9:03 pm, Paul Fraser wrote: Hi, Using Installbuilder to create installers for Linux 64 and Win 64, to run Karaf 4.2.5 in the background. The linux version (developed on a linux 64 machine) works well by using '&' as argument to start script . The installer closes and no console remains. The windows version installer (developed on win 10 machine) closes if an '&' is used same as the linux version but a console remains containing message "karaf.bat: Ignoring predefined value for KARAF_HOME" With no argument to start.bat in windows the installer does not close. Any suggestions as to how to handle the start script in windows? Paul Fraser
Close console after running start.bat
Hi, Using Installbuilder to create installers for Linux 64 and Win 64, to run Karaf 4.2.5 in the background. The linux version (developed on a linux 64 machine) works well by using '&' as argument to start script . The installer closes and no console remains. The windows version installer (developed on win 10 machine) closes if an '&' is used same as the linux version but a console remains containing message "karaf.bat: Ignoring predefined value for KARAF_HOME" With no argument to start.bat in windows the installer does not close. Any suggestions as to how to handle the start script in windows? Paul Fraser
