Re: [VOTE] Apache Karaf OSGi runtime 4.4.6 release
+1 Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le mer. 10 avr. 2024 à 07:28, Grzegorz Grzybek a écrit : > Hello > > +1 > > regards > Grzegorz Grzybek > > wt., 9 kwi 2024 o 19:16 Robert Varga napisał(a): > > > On 09/04/2024 15.33, Jean-Baptiste Onofré wrote: > > > Hi folks, > > > > > > I submit Apache Karaf OSGi runtime 4.4.6 release to your vote. > > > > > > > [snip] > > > > > Please vote to approve this release: > > > [ ] +1 Approve the release > > > [ ] -1 Don't approve the release (please provide specific comments) > > > > +1, thanks a ton! > > > > Passes basic ODL checks with both Java 17 and 21. > > > > Regards, > > Robert > > >
Re: [PROPOSAL] Apache Karaf 4.5.x with Java 17+
+1 Le dim. 7 avr. 2024 à 08:49, Jean-Baptiste Onofré a écrit : > Hi folks, > > I'm preparing the Karaf 4.4.6 release using Java 11+. It will provide > Spring 6.x features requiring Java 17. As Karaf 4.4.x still uses Camel > 3.2.x (Java 11+), it will be up to the user to choose Java 11 (with > Camel working) or Java 17+ (with Spring working). > > With the effort ongoing for camel-karaf 4.x (with Java 17+ support), I > propose to target Karaf 4.5.x to Java 17+ and remove support of Java > 11. > If it's OK for you, I will update Jenkinsfile to use Java 17 by > default on main (instead of Java 11 today), and update the resources > to target Java 17. > > Thoughts ? > > Regards > JB >
Re: [VOTE] Apache Karaf OSGi runtime 4.4.4 release
+1 Le mer. 13 sept. 2023 à 01:53, Jakub Herkel a écrit : > +1 (non binding) > > best regards > > Jakub > > On Tue, Sep 12, 2023 at 5:06 PM Jean-Baptiste Onofré > wrote: > > > > Hi guys, > > > > After long weeks of wait, I submit Apache Karaf OSGi runtime 4.4.4 > > release to your vote. > > > > This release is a maintenance release bringing fixes and dependency > updates. > > Especially this release includes: > > - fix race condition between the FeaturesService and > FeatureDeploymentListener > > - fix --patch-module on Instance startup > > - add exec:groovy shell command > > - dependency updates including CVE fixes (Johnzon, BouncyCastle, > > Commons FileUpload) > > - better JDK20 support > > > > You can take a look on the Release Notes for details: > > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12352693 > > > > Maven Staging Repository: > > https://repository.apache.org/content/repositories/orgapachekaraf-1186/ > > > > Dist Staging Repository: > > https://dist.apache.org/repos/dist/dev/karaf/4.4.4/ > > > > Git tag: > > karaf-4.4.4 > > > > Please vote to approve this release: > > [ ] +1 Approve the release > > [ ] -1 Don't approve the release (please provide specific comments) > > > > This vote will be open for at least 72 hours. > > > > Regards > > JB >
Re: Karaf issues under JDK20
Hi Mark, Doesn't https://github.com/apache/karaf/pull/1723 solves it? Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le mar. 11 juil. 2023 à 13:30, Mark Derricutt a écrit : > Hey all, > > I was wondering if/when a new release was going to drop supporting JDK20, > or I guess - more, JDK21 now since that’s not too far off. > > Anyway, I was updating my still-in-progress branch to switch up from JDK8 > to JDK20 and noticed that it no longer seems to start up properly - all I > get is: > > smx3 | karaf: Ignoring predefined value for KARAF_HOME > smx3 | karaf: Enabling Java debug options: > -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=5005 > smx3 | Listening for transport dt_socket at address: 5005 > smx3 | Jul 11, 2023 11:12:25 PM org.apache.karaf.main.Main launch > smx3 | INFO: Installing and starting initial bundles > smx3 | Jul 11, 2023 11:12:25 PM org.apache.karaf.main.Main launch > smx3 | INFO: All initial bundles installed and set to start > smx3 | Jul 11, 2023 11:12:25 PM > org.apache.karaf.main.Main$KarafLockCallback lockAcquired > smx3 | INFO: Lock acquired. Setting startlevel to 100 > > and then nothing. No logging, not output, nadda. When running just > ./bin/shell I get a very bare Karaf shell prompt with bundles starting. In > order to run under JDK20, I’ve copied a manually patched jre.properties > file > with a jdk20 entry, and interestingly I note even tho jdk19 is already in > the Karaf 4.4.3 distribution, I can only set javase in karaf-maven-plugin > to > 18 (but that’s a side track). > > When looking at the running process, I see a lot of JVM arguments for > > --add-exports=java.base/sun.net.www.protocol.file=ALL-UNNAMED > > > with an = between —add-exports and its argument, altho when looking at > > https://docs.oracle.com/en/java/javase/20/migrate/migrating-jdk-8-later-jdk-releases.html#GUID-2F61F3A9-0979-46A4-8B49-325BA0EE8B66 > it > seems the format is documented as: > > --add-exports java.management/com.sun.jmx.remote.internal=ALL-UNNAMED > > > with a space. I first noticed that when my own overriden > KARAF_SYSTEM_OPTS variable > was broken, so I don’t know if this is causing my issues, or if this has > changed recently somewhere in JDK builds. > > Anyway, I’ve been scratching my head for a while now trying to eek out some > form of error to be logged that might guide me, but so far nothing - anyone > got any suggestions on where I should poke around next to try and diagnose > things? > > Mark > > -- > "Great artists are extremely selfish and arrogant things" — Steven Wilson, > Porcupine Tree >
Re: Towards releases
+1 Side note: will cave and wg be kept in an "attic" page somewhere on the website? Just wondering about people using it and not finding any data about it anymore. Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le jeu. 6 avr. 2023 à 09:14, Jean-Baptiste Onofré a écrit : > Hi guys, > > I'm resuming the work on: > - Karaf runtime releases preparation > - Karaf Decanter & Cellar releases > - Remove Winegrower and Cave from website > > I will keep you posted asap. > > Regards > JB > > On Thu, Jan 26, 2023 at 8:31 AM Jean-Baptiste Onofré > wrote: > > > > Hi guys, > > > > FYI, I'm almost done to prepare new Decanter and Cellar releases. > > > > I will move forward with the votes during the weekend. > > > > After these releases, I propose to move forward on the subprojects > > cleanup (cave, ...) as we discussed on the mailing list. > > > > I will keep you posted. > > > > Regards > > JB >
Re: [PROPOSAL] Create integration (ServiceMix like) distribution in Karaf OSGi runtime
Hi JB, Whereas I can understand the intent I also see it will be hard because: 1. Default distro never matches well (even smix got custom distro) 2. Features are there for that exact need If I rephrase my point I guess the request looks more like "get us back what vendors abandon" but this was mainly about support and contracts, here we'll not get that so it looks to me we already provide that: karaf + features (+ optionally custom build if really needed). Not sticking to that sounds like you will get like hundreds of distro - without thinking too hard I see: * cloud one (prometheus/health/log/...) * jaxrs whiteboard * jaxrs whiteboard + jpa (web profile like) * http whiteboard only * amq * amq + jpa * kafka * kafka + jpa * pulsar * pulsar + jpa * ... (and all potential matrix) Since features were designed to avoid that I think it makes sens to avoid to go that path, it would also be consistent with the cloud spirit - even if the move is not actual most companies target some cloud mindset, in particular a better dep control - which means lighter distros. Hope it makes sense. Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le jeu. 19 janv. 2023 à 09:27, Jean-Baptiste Onofré a écrit : > Hi Romain, > > It's a request to move "natively" to Karaf: most SMX users already > moved to Karaf, but they asked for a ready to go distribution. The few > SMX uses are looking for a similar distribution in Karaf (just to > avoid creating a distribution themselves). > > So, I see more as a new distribution in the Karaf OSGi runtime project > than a new subproject. > > Regards > JB > > On Wed, Jan 18, 2023 at 1:49 PM Romain Manni-Bucau > wrote: > > > > Hi JB, > > > > Is there a community behind or did people already moved to Karaf so this > is > > just about killing smix project officially. > > > > Trying to see if it is mainly about having really itests and enriching > > features.xml (theorically nothing new) or creating a new distro and > almost > > a subproject. > > > > > > Le mer. 18 janv. 2023 à 13:44, Jean-Baptiste Onofré a > > écrit : > > > > > Hi guys, > > > > > > The ServiceMix community is discussing about moving most of the SMX > > > parts into Karaf (the useful parts ;) ). > > > > > > As part of this move, the "main" ServiceMix distribution is mainly a > > > Karaf assembly. > > > > > > Currently, we have two distributions: "standard" > > > (apache-karaf-x.x.x.tar.gz) and "minimal" > > > (apache-karaf-minimal-x.x.x.tar.gz). > > > > > > I propose to add a new distribution (in assemblies): > > > apache-karaf-integration-x.x.x.tar.gz containing ready to go > > > Karaf/Camel/CXF/ActiveMQ smooth integration. > > > Concretely, it means: > > > - we will have integration features repository XML > > > - we will have a distribution based on this features repository > > > - we will have itest on this distribution with the best coverage we can > > > > > > If there is no objection, I will create the Jira and create a PR (as I > > > have almost all ready :)). > > > > > > Thoughts ? > > > > > > Regards > > > JB > > > >
Re: [VOTE] Accept karaf-camel as new Apache Karaf subproject
Le mer. 18 janv. 2023 à 20:17, Andrea Cosentino a écrit : > Il mer 18 gen 2023, 20:06 Romain Manni-Bucau ha > scritto: > > > Le mer. 18 janv. 2023 à 19:43, Andrea Cosentino a > > écrit : > > > > > Hello, > > > > > > The point is just one in relation to OSGi metadata. The components will > > be > > > consumed, also, by runtimes that don't need OSGi metadata, so why all > the > > > components should be with OSGi metadata and packaged as bundles? > > > > > > > I'm maybe a bit dumb but why all the work and meta for quarkus and spring > > boot if the reasoning is right? > > I perfectly understand spring or quarkus have their own programming > > model/runtime so need specific code and meta but then how is OSGi > > different? > > > > A simple example is that you should be able to drop most jandex indices > if > > your statement is true. > > > > My point is related more to have the components as bundles with OSGi > metadata. To me they should be just JAR. > Mainly the reason I'm saying this about supporting camel-karaf because > the work wi be on the shoulders of 1 developer and this is not right for me > and for the community. > Sure but osgi bundles always had been designed to be just jars as much as a jar with a jandex index or even with a custom manifest metadata or a json containing the pom description ;). But I fully share with you the ownership point. Any bundle (more generally meta maintenance) should be owned by the core code writer otherwise we end in weird state all the time, in particular when parts are optionals or need some specific loading mecanism (serviceloader for ex). The lifecycle is also an issue in time, we already are there with features around whiteboards for ex and camel itself has a hard time ensuring components work together so fear camel can be a bit big to have this enrichment work done properly outside camel in a project with less task force than camel itself. > Just this. > > > > > > > > > > > I don't see the reason why. At least the OSGi metadata should be > > generated > > > under camel Karaf project, instead of being part of the core components > > > > > > > I think the exact opposite since handling metadata in a 3rd always got > > proven not working very well for end user. > > SMix did a bunch of forks for that reason - which was enabling users but > > also a big constrait since users were not able to use the actual binaries > > for ex. > > Having metada on the fly is a neat solution but does not work very long, > > even when you have a bunch of people to maintain is - graalvm metadata > > repository is poorly usable for that reason today so for the camel > > ecosystem it sounds impossible to do with a good quality and being able > to > > say "next release" at each release for end users is just not an option - > > but what it would mean concretely to not handle it in camel. > > > > > > > > > > I see there is a veto about moving to apache Karaf. It was already a > mess > > > before to maintain the features and release camel-karaf with Camel 3, > in > > > the end there were one contributor (myself) taking care of them, with > > some > > > sporadic help. I really don't have the capacity in the future. > > > > > > > Guess it joins my previous point and actually justifies it should be in > > camel project or not at the end since it looks like the status of the > > camel-osgi ecosystem as of today - inter projects. > > > > > > > > > > If the situation is this, as Camel PMC we'll need to discuss this and > > > eventually discontinue, deprecating or make the camel-karaf releases > > > optional. > > > > > > > +1 if there is no real ownership, better to go to attic than have a not > > living project IMHO > > > > > > > > > > Thanks. > > > > > > > > > > > > Il mer 18 gen 2023, 19:27 Matt Pavlovich ha > > scritto: > > > > > > > I have a similar question on this point-- > > > > > > > > > On Jan 18, 2023, at 12:02 PM, Łukasz Dywicki > > > > wrote: > > > > > > > > > > 6) I do not see any sign of what is going to happen with OSGi > > metadata > > > > which is present for Apache Camel 3.x components. Is Camel 4.x going > to > > > > retain OSGi metadata? > > > > > > > > How is maintaining OGSI metadata in Camel a concern? > > > > > > > > Thanks, > > > > Matt Pavlovich > > > > > >
Re: [VOTE] Accept karaf-camel as new Apache Karaf subproject
Le mer. 18 janv. 2023 à 19:43, Andrea Cosentino a écrit : > Hello, > > The point is just one in relation to OSGi metadata. The components will be > consumed, also, by runtimes that don't need OSGi metadata, so why all the > components should be with OSGi metadata and packaged as bundles? > I'm maybe a bit dumb but why all the work and meta for quarkus and spring boot if the reasoning is right? I perfectly understand spring or quarkus have their own programming model/runtime so need specific code and meta but then how is OSGi different? A simple example is that you should be able to drop most jandex indices if your statement is true. > > I don't see the reason why. At least the OSGi metadata should be generated > under camel Karaf project, instead of being part of the core components > I think the exact opposite since handling metadata in a 3rd always got proven not working very well for end user. SMix did a bunch of forks for that reason - which was enabling users but also a big constrait since users were not able to use the actual binaries for ex. Having metada on the fly is a neat solution but does not work very long, even when you have a bunch of people to maintain is - graalvm metadata repository is poorly usable for that reason today so for the camel ecosystem it sounds impossible to do with a good quality and being able to say "next release" at each release for end users is just not an option - but what it would mean concretely to not handle it in camel. > > I see there is a veto about moving to apache Karaf. It was already a mess > before to maintain the features and release camel-karaf with Camel 3, in > the end there were one contributor (myself) taking care of them, with some > sporadic help. I really don't have the capacity in the future. > Guess it joins my previous point and actually justifies it should be in camel project or not at the end since it looks like the status of the camel-osgi ecosystem as of today - inter projects. > > If the situation is this, as Camel PMC we'll need to discuss this and > eventually discontinue, deprecating or make the camel-karaf releases > optional. > +1 if there is no real ownership, better to go to attic than have a not living project IMHO > > Thanks. > > > > Il mer 18 gen 2023, 19:27 Matt Pavlovich ha scritto: > > > I have a similar question on this point-- > > > > > On Jan 18, 2023, at 12:02 PM, Łukasz Dywicki > > wrote: > > > > > > 6) I do not see any sign of what is going to happen with OSGi metadata > > which is present for Apache Camel 3.x components. Is Camel 4.x going to > > retain OSGi metadata? > > > > How is maintaining OGSI metadata in Camel a concern? > > > > Thanks, > > Matt Pavlovich >
Re: [VOTE] Accept karaf-camel as new Apache Karaf subproject
Any hope to evaluate the "bunch" of users which would move to this new project and not spring-boot/quarkus/anything-hype-cause-$$? Can be great to see if the community wants to focus on karaf or aggregation on the long run due to available/active resources. If we have proofs there is a need and community supporters I would be +1else it can be a good bad idea as we say soletimes. Just my 2cts Le mer. 18 janv. 2023 à 13:46, Jean-Baptiste Onofré a écrit : > Correct, I mentioned this in my previous email (camel-karaf to > karaf-camel). > > Regards > JB > > On Wed, Jan 18, 2023 at 1:26 PM Claus Ibsen wrote: > > > > Hi > > > > And the source code java package names needs to be migrated as well > > org.apache.camel.karaf -> org.apache.karaf.camel > > > > And documentation is moved over to Apache Karaf, where the karaf camel > > releases its own new set of documentation/website. > > > > The existing Camel Karaf 3.x will be maintained as-is until its EOL. > > > > > > > > > > > > On Wed, Jan 18, 2023 at 12:14 PM Claus Ibsen > wrote: > > > > > Hi > > > > > > This SHOULD also mean that the project should be known as karaf-camel > > > AND that the artifacts released for download and maven central should > have > > > changed GAVs > > > > > > groupId = org.apache.karaf.camel > > > artifactId = karaf-camel-xxx > > > version = x.y.z > > > > > > For version then it may want to follow the Camel version, eg 4.0.0 > > > > > > > > > > > > > > > > > > > > > On Wed, Jan 18, 2023 at 11:03 AM Jean-Baptiste Onofré > > > > wrote: > > > > > >> Hi guys, > > >> > > >> The Apache Camel community proposed to move Camel Karaf to the Apache > > >> Karaf project (as a new subproject). > > >> > > >> As a reminder, Camel Karaf provides: > > >> - support Camel Contexts/Routes as OSGi services (camel-core-osgi) > > >> - Camel components specific to OSGi and Karaf (camel-blueprint, > > >> camel-scr, ...) > > >> - wrapping of Camel components as Karaf features (providing a features > > >> repository XML) > > >> > > >> I think there are a bunch of users using camel-karaf, so, from a > > >> community perspective, it would be great to maintain it. > > >> Furthermore, I already have some ideas to improve karaf-camel, like > > >> avoiding to wrap each Camel component as an OSGi bundle, but instead > > >> creating a kind of Uber jar to simplify deployment and have more > > >> reliable behavior. > > >> > > >> Concretely, accepting camel-karaf as Karaf subproject would mean: > > >> - maintain the existing code, and improving it, preparing kind of > > >> roadmap for camel-karaf > > >> - deal with Camel versions and components (and all difficulties that > > >> it could cause in an OSGi context :) ) > > >> - maintain camel-karaf specific documentation > > >> - vote for the releases (the PMC members would be the Karaf ones, so > > >> binding vote from Karaf PMC members) > > >> > > >> I submit accepting camel-karaf (so karaf-camel :)) as new Karaf > > >> subproject to your vote: > > >> > > >> Please vote to approve this release: > > >> [ ] +1 Approve camel-karaf as new Karaf subproject > > >> [ ] -1 Don't approve camel-karaf as new Karaf subproject (please > > >> provide specific comments) > > >> > > >> This vote will be open for at least 72 hours. > > >> > > >> Thanks, > > >> Regards > > >> JB > > >> > > > > > > > > > -- > > > Claus Ibsen > > > - > > > @davsclaus > > > Camel in Action 2: https://www.manning.com/ibsen2 > > > > > > > > > -- > > Claus Ibsen > > - > > @davsclaus > > Camel in Action 2: https://www.manning.com/ibsen2 >
Re: [PROPOSAL] Create integration (ServiceMix like) distribution in Karaf OSGi runtime
Hi JB, Is there a community behind or did people already moved to Karaf so this is just about killing smix project officially. Trying to see if it is mainly about having really itests and enriching features.xml (theorically nothing new) or creating a new distro and almost a subproject. Le mer. 18 janv. 2023 à 13:44, Jean-Baptiste Onofré a écrit : > Hi guys, > > The ServiceMix community is discussing about moving most of the SMX > parts into Karaf (the useful parts ;) ). > > As part of this move, the "main" ServiceMix distribution is mainly a > Karaf assembly. > > Currently, we have two distributions: "standard" > (apache-karaf-x.x.x.tar.gz) and "minimal" > (apache-karaf-minimal-x.x.x.tar.gz). > > I propose to add a new distribution (in assemblies): > apache-karaf-integration-x.x.x.tar.gz containing ready to go > Karaf/Camel/CXF/ActiveMQ smooth integration. > Concretely, it means: > - we will have integration features repository XML > - we will have a distribution based on this features repository > - we will have itest on this distribution with the best coverage we can > > If there is no objection, I will create the Jira and create a PR (as I > have almost all ready :)). > > Thoughts ? > > Regards > JB >
Re: [PROPOSAL] Apache Karaf Minho 0.1 release?
Hi JB, Got the idea but didn't see any user message about Minho not got any feedback from the enterprise project it comes from it would still be used so thought it was still just a PoC and therefore was not worth a release. If there are real users let's do it! Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le jeu. 29 déc. 2022 à 06:42, Jean-Baptiste Onofré a écrit : > Hi Jamie, > > Yes, good point about Release Notes (and README) mentioning Sunny. > > I will update the README.md with note about that. > > Thanks, > Regards > JB > > On Wed, Dec 28, 2022 at 2:56 PM Jamie G. wrote: > > > > No objection to making the release to help facilitate its progress to > > Apache Sunny. > > > > I trust the Release notes/page will include instructions to users to > > look to the new project home. > > > > On Wed, Dec 28, 2022 at 9:30 AM Romain Manni-Bucau > > wrote: > > > > > > Hi, > > > > > > No blocker even if I have to admit I don't see which user would adopt > it > > > right now as it is presented as a shutdown, probably rewrite and there > is > > > no user base yet too (= if nobody is explicitly awaiting for it you can > > > save you some time probably, in particular in this period ;)). > > > > > > Romain Manni-Bucau > > > @rmannibucau <https://twitter.com/rmannibucau> | Blog > > > <https://rmannibucau.metawerx.net/> | Old Blog > > > <http://rmannibucau.wordpress.com> | Github < > https://github.com/rmannibucau> | > > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book > > > < > https://www.packtpub.com/application-development/java-ee-8-high-performance > > > > > > > > > > > Le mer. 28 déc. 2022 à 13:44, Jean-Baptiste Onofré a > > > écrit : > > > > > > > Hi guys, > > > > > > > > As you probably know, we are "moving" Karaf Minho to a new Apache > > > > project named Apache Sunny (the resolution proposal has been > submitted > > > > to the Apache board). > > > > > > > > Before doing this move, I would like to propose to submit Apache > Karaf > > > > Minho 0.1 to vote. > > > > The purpose is: > > > > 1. to allow users to have an "official" release > > > > 2. to have a kind of snapshot of Karaf Minho before the move to > Sunny. > > > > > > > > No objection ? > > > > > > > > Regards > > > > JB > > > > >
Re: [PROPOSAL] Apache Karaf Minho 0.1 release?
Hi, No blocker even if I have to admit I don't see which user would adopt it right now as it is presented as a shutdown, probably rewrite and there is no user base yet too (= if nobody is explicitly awaiting for it you can save you some time probably, in particular in this period ;)). Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le mer. 28 déc. 2022 à 13:44, Jean-Baptiste Onofré a écrit : > Hi guys, > > As you probably know, we are "moving" Karaf Minho to a new Apache > project named Apache Sunny (the resolution proposal has been submitted > to the Apache board). > > Before doing this move, I would like to propose to submit Apache Karaf > Minho 0.1 to vote. > The purpose is: > 1. to allow users to have an "official" release > 2. to have a kind of snapshot of Karaf Minho before the move to Sunny. > > No objection ? > > Regards > JB >
Re: [PROPOSAL] Create new Apache project proposal with Minho
+1, makes sense since the adoption here leads to some issues which does not look like trivial to solve community wise. Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le lun. 28 nov. 2022 à 11:27, Jean-Baptiste Onofré a écrit : > Hi guys, > > In regards of the discussion we have around Karaf log, the different > comments about Karaf vs Minho, clearly, we have two different visions > and communities: > - the Karaf community very likes Karaf as it is today (powered by > OSGi) and not willing to move to something else > - the Minho community would be "decoupled" from existing Karaf > community, coming from other projects like spring boot, microprofile, > etc > > So, it means that we would have two different communities in the Karaf > "umbrella", which is not ideal, and actually it can cause branding > issues. > We can have the issue where Minho at Karaf will "block" some users and > contributors because they will "couple" Minho to Karaf (which is not > the case). > > So, IMHO, it would be cleaner to keep Karaf to what it is today (an > OSGi runtime) and move Minho to its own project. > > I would call for a vote to remove Minho from Karaf and create a > project proposal based on it (and a couple of additional features). > > Thoughts ? > > Regards > JB >
Re: [DISCUSS] Adopt new Karaf logo
Hi Did you test antora which supports multiversion and repo to build a consistent website? Sounds like a better plan than docusaurus to me. Otherwise +1 Le mar. 1 nov. 2022 à 14:57, Jean-Baptiste Onofré a écrit : > Hi Maurice, > > Yes, that's also my view on cloud: "any computing exposed to the > Internet", meaning it could be on prem, cloud VM, k8s, whatever. > > Showing the sympa instead of boxes is a good idea, but I think it will > be hard with a small sized image. That could work on a large "welcome" > image. Let me show on the website proposal (I plan to send the email > here about the website asap). > > Thanks! > Regards > JB > > On Tue, Nov 1, 2022 at 2:50 PM Maurice Betzel > wrote: > > > > Like it, > > > > I guess a Cloud is the modern accepted way for management levels to > depict computers running 'in' the internet, regardless if the cluster is > running on premise or a hybrid one, or contains microservices or not. > > Potentially add some symbols to the boxes as attached, but that might be > an issue with the image resolution. > > > > Met vriendelijke groet / Mit freundlichen Grüßen / Kind regards, > > Maurice Betzel > > Principal Software Engineer > > Gaston Schul Group > > Department ICT > > Kazernestraat 10 > > 5928 NL Venlo > > > > 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. > > >
Re: [VOTE] Apache Karaf runtime 4.4.0 release
+1 Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le mar. 19 avr. 2022 à 09:32, Grzegorz Grzybek a écrit : > +1 > > Thanks for your work JBO! > > regards > Grzegorz Grzybek > > wt., 19 kwi 2022 o 08:24 Jean-Baptiste Onofré > napisał(a): > > > Hi guys, > > > > I submit Apache Karaf runtime 4.4.0 release to your vote. > > This release is a new milestone, starting the 4.4.x series. > > > > This release includes: > > - OSGi R8 support > > - Pax Web 8.x upgrade > > - Pax Logging 2.1.x upgrade > > - and much much more ! > > > > You can take a look on the Release Notes for details: > > > > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12349243 > > > > Maven Staging Repository: > > https://repository.apache.org/content/repositories/orgapachekaraf-1173/ > > > > Dist Staging Repository: > > https://dist.apache.org/repos/dist/dev/karaf/4.4.0/ > > > > Git tag: > > karaf-4.4.0 > > > > Please vote to approve this release: > > [ ] +1 Approve the release > > [ ] -1 Don't approve the release (please provide specific comments) > > > > This vote will be open for at least 72 hours. > > > > Regards > > JB > > >
Re: Karaf 5 shell and native
The only limitation - but also to be light and native friendly - is to not use embed jar so some karaf stuff is not compatible and will not to reach graal stage. However rest is compatible and afaik console, ssh, jaxrs whiteboard, etc run well. Im not sure i would go heavy to stay cloud friendly by default (cronjob and deployment) but we can always enhance the plugin to support cepage from features + jar sorting at build time (graph resolution) for ex, think it can solve most of it staying on the core values (light, cloud, stateless, standalone or embeddable). Hope it makes sense. Le sam. 19 févr. 2022 à 02:22, Bernd Eckenfels a écrit : > Yes winegrower can be a good base, it seems customary for Karaf to build > on those technologies. It would somehow be good if the build uses the same > feature and maven infrastructure and when the prerequisites are also used > with karaf binaries (shell and client command as well as a karaf cli). > > I haven’t tried how compatible it would be with Karaf/Gogo commands yet. > > Gruss > Bernd > > > -- > http://bernd.eckenfels.net > ____ > Von: Romain Manni-Bucau > Gesendet: Tuesday, February 8, 2022 1:12:14 PM > An: dev > Betreff: Re: Karaf 5 shell and native > > Hi, > > I thought winegrower was the one targetting native support by design - and > already has its arthur knight > https://geronimo.apache.org/arthur/winegrower-knight.html - and Karaf 5 > the opposite: aggregation and optimization of heterogeneous runtimes in a > single JVM. > Did I miss anything? > > Romain Manni-Bucau > @rmannibucau <https://twitter.com/rmannibucau> | Blog > <https://rmannibucau.metawerx.net/> | Old Blog > <http://rmannibucau.wordpress.com> | Github < > https://github.com/rmannibucau> | > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book > < > https://www.packtpub.com/application-development/java-ee-8-high-performance > > > > > Le mar. 8 févr. 2022 à 13:09, Łukasz Dywicki a > écrit : > > > I did have some small attempts turning basic apps into native images and > > I believe it is very good idea, yet I am not sure if Karaf (or OSGi per > > say) is ready for that. I am glad you are opening this topic as I am > > interested in anyone succeeded in making a native image which can keep > > OSGi semantics. ;-) > > I think problem with native images lies somewhere else than command line > > handling, as we rely on jansi and jline which are used in other > > ecosystems which are deep in native compilation. > > Because Karaf stuff is promoting modulith approach you might have > > multiple apps and services running at the same time. This means that > > native compilation might be more complicated as some of classes will > > obviously get shared across multiple places, the asynchronous nature of > > service activation might result in scenarios where you simply have to > > "warm up" app long enough so you catch all places which are touched by > > java reflection api. Its also possible that without valid preparation > > you will be pulling some libraries in different versions. I am not sure > > how graal is handling that. Given that even netty could produce troubles > > with native image I am a little bit afraid how verbose is preparation > > for more complicated applications. > > > > Best, > > Łukasz > > > > On 7.02.2022 08:14, Bernd Eckenfels wrote: > > > Hello, > > > > > > I wonder are there any plans for native image and tree shaking for > > karaf5? > > > > > > Especially I think we need a shell framework (like quarkus/picocli) > > which allows a fast stand-alone cli. At least if karaf plans to play in > > this space. I like the OSGi console command abstraction, so it would be a > > good candidate if one can proceed to write (Developer and ops) commands > > this way and then compile it. > > > > > > This could even abstract away some of the more arcane to use maven > steps > > (archetype) and add new things like development server or even client.sh. > > > > > > Gruss > > > Bernd > > > > > > > > > -- > > > http://bernd.eckenfels.net > > > > > >
Re: Karaf 5 shell and native
Hi, I thought winegrower was the one targetting native support by design - and already has its arthur knight https://geronimo.apache.org/arthur/winegrower-knight.html - and Karaf 5 the opposite: aggregation and optimization of heterogeneous runtimes in a single JVM. Did I miss anything? Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le mar. 8 févr. 2022 à 13:09, Łukasz Dywicki a écrit : > I did have some small attempts turning basic apps into native images and > I believe it is very good idea, yet I am not sure if Karaf (or OSGi per > say) is ready for that. I am glad you are opening this topic as I am > interested in anyone succeeded in making a native image which can keep > OSGi semantics. ;-) > I think problem with native images lies somewhere else than command line > handling, as we rely on jansi and jline which are used in other > ecosystems which are deep in native compilation. > Because Karaf stuff is promoting modulith approach you might have > multiple apps and services running at the same time. This means that > native compilation might be more complicated as some of classes will > obviously get shared across multiple places, the asynchronous nature of > service activation might result in scenarios where you simply have to > "warm up" app long enough so you catch all places which are touched by > java reflection api. Its also possible that without valid preparation > you will be pulling some libraries in different versions. I am not sure > how graal is handling that. Given that even netty could produce troubles > with native image I am a little bit afraid how verbose is preparation > for more complicated applications. > > Best, > Łukasz > > On 7.02.2022 08:14, Bernd Eckenfels wrote: > > Hello, > > > > I wonder are there any plans for native image and tree shaking for > karaf5? > > > > Especially I think we need a shell framework (like quarkus/picocli) > which allows a fast stand-alone cli. At least if karaf plans to play in > this space. I like the OSGi console command abstraction, so it would be a > good candidate if one can proceed to write (Developer and ops) commands > this way and then compile it. > > > > This could even abstract away some of the more arcane to use maven steps > (archetype) and add new things like development server or even client.sh. > > > > Gruss > > Bernd > > > > > > -- > > http://bernd.eckenfels.net > > >
Re: [PROPOSAL] Karaf 5
Since it will act as a container/orchestrator we could play on the "container" and use "karaf-crystal" or even "karaf-millesime" or something in this spirit? The overall point is to avoid to "simply" look like karaf 4+1 which is limiting and karaf 4 will stay IMHO even wih karaf 5 (said this way the naming is obviously wrong :D). Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le lun. 7 févr. 2022 à 09:29, Jean-Baptiste Onofré a écrit : > Hi, > > If we want to dedicated repo (which I'm not against), we have to find a > name keeping the karaf branding. > That's why I wanted to keep the karaf repo. > > What's about karaf-runtime repo ? > > Regards > JB > > On 07/02/2022 08:37, Romain Manni-Bucau wrote: > > Hi > > > > think it makes sense to keep another repo. > > However it probably does not to have the version in it (when it will be > v6 > > why would the repo be named v5 ;)). > > Since it is a new project, wider than karaf4, I guess it should be > renamed > > (karaf-xxx) instead of merged to an unrelated project, no? > > > > Romain Manni-Bucau > > @rmannibucau <https://twitter.com/rmannibucau> | Blog > > <https://rmannibucau.metawerx.net/> | Old Blog > > <http://rmannibucau.wordpress.com> | Github < > https://github.com/rmannibucau> | > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book > > < > https://www.packtpub.com/application-development/java-ee-8-high-performance > > > > > > > > Le lun. 7 févr. 2022 à 08:31, Grzegorz Grzybek a > > écrit : > > > >> Hello > >> > >> Great to hear about Karaf5 progress. Do I understand correctly that you > >> think about `K5` branch in apache/karaf repo? If there's no common > history, > >> why simply not https://github.com/apache/karaf5 ? > >> > >> regards > >> Grzegorz Grzybek > >> > >> pon., 7 lut 2022 o 08:25 Francois Papon > >> napisał(a): > >> > >>> Of course ;) > >>> > >>> On 07/02/2022 08:22, JB Onofré wrote: > >>>> Let’s wait for others feedback on the mailing list. > >>>> > >>>>> Le 7 févr. 2022 à 08:08, Francois Papon < > francois.pa...@openobject.fr > >>> > >>> a écrit : > >>>>> > >>>>> I can manage the creation of the branch and move the code source. > >>>>> > >>>>> regards, > >>>>> > >>>>> François > >>>>> > >>>>>> On 07/02/2022 08:05, Francois Papon wrote: > >>>>>> +1, we can use a dedicated branch :) > >>>>>> > >>>>>> regards, > >>>>>> > >>>>>> Francois > >>>>>> > >>>>>>> On 07/02/2022 08:02, Jean-Baptiste Onofre wrote: > >>>>>>> Hi, > >>>>>>> > >>>>>>> It sounds good to me. > >>>>>>> > >>>>>>> The K5 repo is currently on my GitHub: > >>>>>>> > >>>>>>> https://github.com/jbonofre/karaf5 > >>>>>>> > >>>>>>> I propose: > >>>>>>> > >>>>>>> 1. To keep main for karaf-4.4.x for now > >>>>>>> 2. Fix K4 like assembly on K5 (just have to push some new services) > >>>>>>> 3. Push Karaf 5 on K5 branch > >>>>>>> 4. Improve documentation on K5 branch to show what’s a service, and > >>> so, allow anyone to contribute service/distribution > >>>>>>> > >>>>>>> ETA: end of this week if no objection. > >>>>>>> > >>>>>>> Regards > >>>>>>> JB > >>>>>>> > >>>>>>> > >>>>>>>> Le 7 févr. 2022 à 07:56, Francois Papon < > >>> francois.pa...@openobject.fr> a écrit : > >>>>>>>> > >>>>>>>> Hi, > >>>>>>>> > >>>>>>>> As we have some users that asking questions about Karaf 5 the next > >>> Karaf generation, I think it would be nice to move the current repo to > >>> master. > >>>>>>>> > >>>>>>>> It could be a good booster if we want to move forward on this for > a > >>> first RC. > >>>>>>>> > >>>>>>>> Thoughts? > >>>>>>>> > >>>>>>>> Regards, > >>>>>>>> > >>>>>>>> François > >>>>>>>> > >>> > >> > > >
Re: [PROPOSAL] Karaf 5
Hi think it makes sense to keep another repo. However it probably does not to have the version in it (when it will be v6 why would the repo be named v5 ;)). Since it is a new project, wider than karaf4, I guess it should be renamed (karaf-xxx) instead of merged to an unrelated project, no? Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le lun. 7 févr. 2022 à 08:31, Grzegorz Grzybek a écrit : > Hello > > Great to hear about Karaf5 progress. Do I understand correctly that you > think about `K5` branch in apache/karaf repo? If there's no common history, > why simply not https://github.com/apache/karaf5 ? > > regards > Grzegorz Grzybek > > pon., 7 lut 2022 o 08:25 Francois Papon > napisał(a): > > > Of course ;) > > > > On 07/02/2022 08:22, JB Onofré wrote: > > > Let’s wait for others feedback on the mailing list. > > > > > >> Le 7 févr. 2022 à 08:08, Francois Papon > > > a écrit : > > >> > > >> I can manage the creation of the branch and move the code source. > > >> > > >> regards, > > >> > > >> François > > >> > > >>> On 07/02/2022 08:05, Francois Papon wrote: > > >>> +1, we can use a dedicated branch :) > > >>> > > >>> regards, > > >>> > > >>> Francois > > >>> > > >>>> On 07/02/2022 08:02, Jean-Baptiste Onofre wrote: > > >>>> Hi, > > >>>> > > >>>> It sounds good to me. > > >>>> > > >>>> The K5 repo is currently on my GitHub: > > >>>> > > >>>> https://github.com/jbonofre/karaf5 > > >>>> > > >>>> I propose: > > >>>> > > >>>> 1. To keep main for karaf-4.4.x for now > > >>>> 2. Fix K4 like assembly on K5 (just have to push some new services) > > >>>> 3. Push Karaf 5 on K5 branch > > >>>> 4. Improve documentation on K5 branch to show what’s a service, and > > so, allow anyone to contribute service/distribution > > >>>> > > >>>> ETA: end of this week if no objection. > > >>>> > > >>>> Regards > > >>>> JB > > >>>> > > >>>> > > >>>>> Le 7 févr. 2022 à 07:56, Francois Papon < > > francois.pa...@openobject.fr> a écrit : > > >>>>> > > >>>>> Hi, > > >>>>> > > >>>>> As we have some users that asking questions about Karaf 5 the next > > Karaf generation, I think it would be nice to move the current repo to > > master. > > >>>>> > > >>>>> It could be a good booster if we want to move forward on this for a > > first RC. > > >>>>> > > >>>>> Thoughts? > > >>>>> > > >>>>> Regards, > > >>>>> > > >>>>> François > > >>>>> > > >
Re: [VOTE] Apache Karaf runtime 4.3.6 release
+1 Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le mar. 11 janv. 2022 à 12:06, Roedl Lukas a écrit : > +1 (non-binding) > > regards, > Lukas > > -Ursprüngliche Nachricht- > Von: Jean-Baptiste Onofre > Gesendet: Montag, 10. Januar 2022 21:09 > An: dev@karaf.apache.org > Betreff: [VOTE] Apache Karaf runtime 4.3.6 release > > Hi everyone, > > I submit Apache Karaf runtime 4.3.6 to your vote. > > This release includes: > - upgrade to Pax Logging 2.0.14 with log4j 2.17.1 (fixing CVE-2021-44832) > - prepare support for JDK 18 > - fix issue on Apache Felix FileInstall 3.7.4 fixing deployment issue > - and much more! > > Please take a look on Release Notes for details ! > > Release Notes: > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12351123 > > Staging Maven Repository: > https://repository.apache.org/content/repositories/orgapachekaraf-1170/ > > Staging Dist Repository: > https://dist.apache.org/repos/dist/dev/karaf/4.3.6/ > > Git tag: > karaf-4.3.6 > > Please vote to approve this release: > > [ ] +1 Approve the release > [ ] -1 Don't approve the release (please provide specific comments) > > This vote will be open for at least 72 hours. > > Regards > JB >
Re: [PROPOSAL] Change log4j2 default config to xml (or json)
Hmm, I kind of think it is a very biased statement Matt - not blaming, let me explain: > @Romain- I think heterogenous is a great goal— however, with complex hierarchal configurations, the “simplicity” of properties is lost in the structure. Default Log4j2 as properties is illegible by any UX/DX standard. As with features, having structured format (ie xml) for complex data is more manageable. On my window I just check how many properties/cfg (I merge both formats since they are close enough) files used by dev and ops and how many XML, no real war there, cfg always wins. That said you are right, features should be more compatible with config admin and have in its etc/cfg file the ability to define the equivalent of features.xml. Since features are backed by POJO it is not crazy to do IMHO. > The Developer Experience (DX) gap here is dev-on-laptop writing a simple REST service/camel route, etc and then deploying to karaf has a very different experience with logging. This is especially true for developers without a lot of experience and/or are new to karaf. You assume dev use xml with log4j2 but it is not that straight forward, properties are still used but json won a lot of traction too but the key point here is not the format but the dev env. If you mean that testing a camel route in an environment fully unrelated to the target has a different shape then you are right but it is true for everything, even deploying a war in tomcat or wildfly is different, you see my point? I'd really like to emphasis the fact that homogeneous is always the goal if you intend to go to prod - while you can do whatever you like with some more advanced/not default setup. The dev is a small part of a software and the cheapest one so if you want dev to spend 5 more minutes to convert a xml in proprties i'm tempted to say be it but if you force the full pipeline to use multiple tooling (xml and properties) to handle/generate/validate/check the configuration files then you also need to add the cost to manage these automotion dependencies and the related knowledge of the people working with it. It is a tree so a cost of 1 in dev area becomes a cost of 10 very quickly on the full chain...and when it does not hit the prod as expected and you don't notice you deployed something wrong it can be way more expensive. This is one of the reason log4j2 was not adopted before v2.4 which added back properties syntax. Hope my thinking and why I hope Karaf sticks to plain properties is clearer. Now there is one note about that: it is trivia to write a maven plugin dropping the log4j2.xml and moving it to a log4j2.properties at build time which should give you the best of the two world when dev are writing the prod files directly in the project itself so think are good and already cover that, it is just not a karaf native thing IMHO but more a build helper which would sit in log4j2 project (thinking out loud). Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le mar. 28 déc. 2021 à 17:42, Jean-Baptiste Onofre a écrit : > Hi > > You mean org.ops4j.pax.logging config PID right (so today > etc/org.ops4j.pax.logging.cfg). > > It’s already possible to refresh a log4j XML in org.ops4j.pax.logging. So > basically, etc/org.ops4j.pax.logging.cfg just contain the location of the > log4j.xml. > > I think it’s good enough. > > My point is that, if you proposal is to have etc/org.ops4j.pax.logging.xml > instead of etc/org.ops4j.pax.logging.cfg, that should be optional, and I > think it’s not a good idea. > I still prefer to have an indirection where etc/org.ops4j.pax.logging.cfg > points to log4j XML or JSON file. > > Regards > JB > > > Le 28 déc. 2021 à 17:32, Matt Pavlovich a écrit : > > > > @JB- To be clear, the request is for the log4j2 config file to be in xml > or json, not supporting json or xml log formats > > > > @Romain- I think heterogenous is a great goal— however, with complex > hierarchal configurations, the “simplicity” of properties is lost in the > structure. Default Log4j2 as properties is illegible by any UX/DX standard. > As with features, having structured format (ie xml) for complex data is > more manageable. > > > > The Developer Experience (DX) gap here is dev-on-laptop writing a simple > REST service/camel route, etc and then deploying to karaf has a very > different experience with logging. This is especially true for developers > without a lot of experience and/or are new to karaf. > > > > My suggestion is about trying to unify the log4j2 property file so de
Re: [PROPOSAL] Change log4j2 default config to xml (or json)
My 2cts would be that log4j2 or any configuration in karaf should be homogeneous with other config files. Since OSGi is .cfg (enriched properties) by design, I think it is better to stick to this or something very close *by default*. Making the config formats heterogeneous will make your tooling heterogeneous too or more complex at least which is not worth it in almost all cases. Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le mar. 28 déc. 2021 à 05:41, Jean-Baptiste Onofre a écrit : > By the way, just a reminder: a good point about properties format in > pax-logging-log4j2 service is that it doesn’t require extra dependency. > Using xml/json format needs additional dependency/packages/bundles in the > Karaf distribution. > Just a side note. > > Regards > JB > > > Le 27 déc. 2021 à 19:33, Matt Pavlovich a écrit : > > > > I’ve created a proposal JIRA KARAF-7307 ( > https://issues.apache.org/jira/browse/KARAF-7307 < > https://issues.apache.org/jira/browse/KARAF-7307>) to track any specifics. > > > > As the subject mentions— I think it would be beneficial to users to > change the default configuration for log4j2 to XML (or maybe JSON). > > > > Notes: > > > > 1. Documentation for the properties format is fragmented and incomplete— > especially for advanced features such as routing, etc > > 2. XML format is the more natural format for log4j2 > > 3. Allow for developers targeting karaf runtime to use the same > log4j2.xml config file in their dev projects that is used in karaf runtime > (using a org.ops4j.pax.logging.cfg requires developers to add add’l > configuration to their code projects) > > > > Thoughts? > > > > Thanks, > > Matt > > > > > >
Re: [VOTE] Apache Karaf runtime 4.3.5 release
+1 Le dim. 19 déc. 2021 à 22:34, Jean-Baptiste Onofré a écrit : > Hi everyone, > > I submit Apache Karaf runtime 4.3.5 to your vote. > This release includes Pax Logging 2.0.13 update: > - with logback 1.2.9 upgrade, fixing CVE-2021-42550 > - with log4j 2.17.0 upgrade, fixing CVE-2021-45105 > > Please take a look on Release Notes for details ! > > Release Notes: > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12350856 > > Staging Maven Repository: > https://repository.apache.org/content/repositories/orgapachekaraf-1167/ > > Staging Dist Repository: > https://dist.apache.org/repos/dist/dev/karaf/4.3.5/ > > Git tag: > karaf-4.3.5 > > Please vote to approve this release: > > [ ] +1 Approve the release > [ ] -1 Don't approve the release (please provide specific comments) > > This vote will be open for at least 72 hours. > > Regards > JB > >
Re: [VOTE] Apache Karaf runtime 4.2.13 release
+1 Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le ven. 17 déc. 2021 à 15:20, Matt Pavlovich a écrit : > +1 (non-binding) > > > On Dec 16, 2021, at 8:02 AM, Jean-Baptiste Onofré > wrote: > > > > Hi all, > > > > I submit Apache Karaf 4.2.13 to your vote. > > > > This version includes 8 fixes and improvements. Especially, it includes > Pax Logging 1.11.11 update, upgrading to log4j 2.16.0 fixing CVE-2021-44228 > and CVE-2021-45046. > > > > Please take a look on Release Notes for details. > > > > Release Notes: > > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12350548 > > > > Staging Maven Repository: > > https://repository.apache.org/content/repositories/orgapachekaraf-1166/ > > > > Staging Dist Repository: > > https://dist.apache.org/repos/dist/dev/karaf/4.2.13/ > > > > Git tag: > > karaf-4.2.13 > > > > > > Please vote to approve this release: > > > > [ ] +1 Approve the release > > [ ] -1 Don't approve the release (please provide specific comments) > > > > This vote will be open for at least 72 hours. > > > > Regards > > JB > > > >
Re: [VOTE] Apache Karaf runtime 4.3.4 release (take #3)
+1 Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le mer. 15 déc. 2021 à 08:21, Roedl Lukas a écrit : > +1 (non-binding) > > regards, > Lukas > > -Ursprüngliche Nachricht- > Von: JB Onofré > Gesendet: Mittwoch, 15. Dezember 2021 05:44 > An: dev@karaf.apache.org > Betreff: [VOTE] Apache Karaf runtime 4.3.4 release (take #3) > > Hi everyone, > > I submit Apache Karaf runtime 4.3.4 to your vote (take #3). > > This release includes dependency upgrades, fixes, and improvements, > especially: > > - upgrade to Pax Logging 2.0.12, upgrading to log4j2 2.0.15, fixing > important security issue (CVE-2021-44228) and fixing JNDI issue > - align dependencies versions between Karaf and Pax * > - fix missing system export packages > - fix on Karaf features json support > - fix features autoRefresh configuration handling > - fix on sshd session handling > - update to sshd 2.8.0 > - lot of pax * updates > - and much more ! > > Please take a look on Release Notes for details ! > > Release Notes: > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12350547 > > Staging Maven Repository: > https://repository.apache.org/content/repositories/orgapachekaraf-1165/ > > Staging Dist Repository: > https://dist.apache.org/repos/dist/dev/karaf/4.3.4/ > > Git tag: > karaf-4.3.4 > > Please vote to approve this release: > > [ ] +1 Approve the release > [ ] -1 Don't approve the release (please provide specific comments) > > This vote will be open for at least 72 hours. > > Regards > JB > >
Re: [VOTE] Apache Karaf runtime 4.3.4 release (take #2)
> What's the difference between cutting a new release right after the > release and just postponing this release (again) to include this log4j > version? > I'd rather have a 4.3.4 accepted by our consumers instead of everyone just > waiting for the 4.3.5 ;) (just my 2cts and experience feedback about willing a perfect release) Consumers waiting for something unrelated to log4j2 can adopt it 1 week before ;), and as JB said, there is no security enhancement in 2.16 - and some other parts of the JVM/libs are way more dangerous :p - so guess it is better to release and move forward than keeping postponing which can delay for more than 1 month the adoption (keep in mind we are in the last work week in a lot of country since Xmas is coming ;)). Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le mar. 14 déc. 2021 à 10:26, Jean-Baptiste Onofré a écrit : > OK, so, let me prepare Pax Logging 2.0.12 then and cancel this vote to > include this new Pax Logging version. > > Regards > JB > > On 14/12/2021 10:20, Achim Nierbeck wrote: > > tbh. What's the difference between cutting a new release right after the > > release and just postponing this release (again) to include this log4j > > version? > > I'd rather have a 4.3.4 accepted by our consumers instead of everyone > just > > waiting for the 4.3.5 ;) > > > > my 2 cents :) > > > > regards, Achim > > > > > > Am Di., 14. Dez. 2021 um 10:09 Uhr schrieb Jean-Baptiste Onofré < > > j...@nanthrax.net>: > > > >> There's no big change between log4j 2.15 and 2.16 (in term of CVE). So, > >> I would leave this vote running, and prepare Pax Logging/Karaf new > >> release after (pretty soon). > >> > >> Regards > >> JB > >> > >> On 14/12/2021 09:30, Bernd Eckenfels wrote: > >>> If you have any reason to delay it some more, a new pax logging with > >> log4j 2.0.16 should be close by ,) Log4j finally disabled JNDI and > removed > >> the lookup code. Otherwise another minor release would also be an > option. > >>> -- > >>> http://bernd.eckenfels.net > >>> > >>> Von: Francois Papon > >>> Gesendet: Tuesday, December 14, 2021 8:49:24 AM > >>> An: dev@karaf.apache.org > >>> Betreff: Re: [VOTE] Apache Karaf runtime 4.3.4 release (take #2) > >>> > >>> +1 (binding) > >>> > >>> Thanks JB! > >>> > >>> regards, > >>> > >>> Francois > >>> > >>> On 13/12/2021 16:24, Jean-Baptiste Onofré wrote: > >>>> Hi everyone, > >>>> > >>>> I submit Apache Karaf runtime 4.3.4 to your vote (take #2). > >>>> > >>>> This release includes dependency upgrades, fixes, and improvements, > >>>> especially: > >>>> > >>>> - upgrade to Pax Logging 2.0.11, upgrading to log4j2 2.0.15, fixing > >>>> important security issue (CVE-2021-44228) > >>>> - align dependencies versions between Karaf and Pax * > >>>> - fix missing system export packages > >>>> - fix on Karaf features json support > >>>> - fix features autoRefresh configuration handling > >>>> - fix on sshd session handling > >>>> - update to sshd 2.8.0 > >>>> - lot of pax * updates > >>>> - and much more ! > >>>> > >>>> Please take a look on Release Notes for details ! > >>>> > >>>> Release Notes: > >>>> > >> > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12350547 > >>>> > >>>> > >>>> Staging Maven Repository: > >>>> > https://repository.apache.org/content/repositories/orgapachekaraf-1164/ > >>>> > >>>> Staging Dist Repository: > >>>> https://dist.apache.org/repos/dist/dev/karaf/4.3.4/ > >>>> > >>>> Git tag: > >>>> karaf-4.3.4 > >>>> > >>>> Please vote to approve this release: > >>>> > >>>> [ ] +1 Approve the release > >>>> [ ] -1 Don't approve the release (please provide specific comments) > >>>> > >>>> This vote will be open for at least 72 hours. > >>>> > >>>> Regards > >>>> JB > >>> > >> > > > > >
Re: [VOTE] Apache Karaf runtime 4.3.4 release (take #2)
+1 (to release), in terms of actual security 2.15 or 2.16 does not change much and karaf has some expected changes so let it go and redo one after if wished IMHO Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le mar. 14 déc. 2021 à 09:30, Bernd Eckenfels a écrit : > If you have any reason to delay it some more, a new pax logging with log4j > 2.0.16 should be close by ,) Log4j finally disabled JNDI and removed the > lookup code. Otherwise another minor release would also be an option. > -- > http://bernd.eckenfels.net > > Von: Francois Papon > Gesendet: Tuesday, December 14, 2021 8:49:24 AM > An: dev@karaf.apache.org > Betreff: Re: [VOTE] Apache Karaf runtime 4.3.4 release (take #2) > > +1 (binding) > > Thanks JB! > > regards, > > Francois > > On 13/12/2021 16:24, Jean-Baptiste Onofré wrote: > > Hi everyone, > > > > I submit Apache Karaf runtime 4.3.4 to your vote (take #2). > > > > This release includes dependency upgrades, fixes, and improvements, > > especially: > > > > - upgrade to Pax Logging 2.0.11, upgrading to log4j2 2.0.15, fixing > > important security issue (CVE-2021-44228) > > - align dependencies versions between Karaf and Pax * > > - fix missing system export packages > > - fix on Karaf features json support > > - fix features autoRefresh configuration handling > > - fix on sshd session handling > > - update to sshd 2.8.0 > > - lot of pax * updates > > - and much more ! > > > > Please take a look on Release Notes for details ! > > > > Release Notes: > > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12350547 > > > > > > Staging Maven Repository: > > https://repository.apache.org/content/repositories/orgapachekaraf-1164/ > > > > Staging Dist Repository: > > https://dist.apache.org/repos/dist/dev/karaf/4.3.4/ > > > > Git tag: > > karaf-4.3.4 > > > > Please vote to approve this release: > > > > [ ] +1 Approve the release > > [ ] -1 Don't approve the release (please provide specific comments) > > > > This vote will be open for at least 72 hours. > > > > Regards > > JB >
Re: [VOTE] Apache Karaf runtime 4.3.4 release
+1 looks good on my apps. Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le mar. 7 déc. 2021 à 08:16, Grzegorz Grzybek a écrit : > Hello > > +1 (binding) > > BTW - here’s how Karaf 4.3.4 works with Pax Web 8 (soon in Karaf 4.4): > > karaf@root()> install -s mvn:io.hawt/hawtio-osgi/2.14.1/war > Bundle ID: 76 > > karaf@root()> web:wab-list > Context Path │ Bundle ID │ Symbolic Name │ State│ Base URL > > ─┼───┼─┼──┼─ > /hawtio │ 76│ io.hawt.hawtio-osgi │ Deployed │ > http://127.0.0.1:8181/hawtio > > karaf@root()> web:context-list > Bundle ID │ Symbolic Name │ Context > Path │ Context Name │ Rank │ Service ID │ Type │ Scope │ > Registration Properties > > ──┼───┼──┼──┼──┼┼┼─┼── > 70│ org.ops4j.pax.web.pax-web-extender-whiteboard │ / > │ default │ 0│ 0 │ Whiteboard │ static* │ > osgi.http.whiteboard.context.name=default > │ │ > │ │ │││ │ > osgi.http.whiteboard.context.path=/ > 76│ io.hawt.hawtio-osgi │ /hawtio > │ /hawtio │ MAX │ 0 │ WAB│ static* │ > osgi.http.whiteboard.context.path=/hawtio > > *) This context is using ServletContextHelper/HttpContext without > resolving an org.osgi.framework.ServiceReference. > > karaf@root()> web:servlet-list > Bundle ID │ Name │ Class >│ Context Path(s) │ URLs │ Type │ > Context Filter > > ──┼───┼───┼─┼──┼──┼─── > 76│ default │ > org.ops4j.pax.web.service.jetty.internal.web.JettyResourceServlet │ > /hawtio │ /│ WAB │ - > 76│ jolokia-agent │ > io.hawt.web.servlets.JolokiaConfiguredAgentServlet │ > /hawtio │ /jolokia/* │ WAB │ - > 76│ jolokia-proxy │ io.hawt.web.proxy.ProxyServlet >│ /hawtio │ /proxy/* │ WAB │ - > 76│ keycloak │ io.hawt.web.auth.keycloak.KeycloakServlet >│ /hawtio │ /keycloak/* │ WAB │ - > 76│ login │ io.hawt.web.auth.LoginServlet >│ /hawtio │ /auth/login │ WAB │ - > 76│ logout│ io.hawt.web.auth.LogoutServlet >│ /hawtio │ /auth/logout │ WAB │ - > 76│ plugin│ io.hawt.web.plugin.PluginServlet >│ /hawtio │ /plugin/*│ WAB │ - > 76│ user │ > io.hawt.web.auth.keycloak.KeycloakUserServlet │ > /hawtio │ /user/* │ WAB │ - > > regards > Grzegorz Grzybek > > wt., 7 gru 2021 o 05:59 Jean-Baptiste Onofré napisał(a): > > > Hi everyone, > > > > I submit Apache Karaf runtime 4.3.4 to your vote. > > > > This release includes dependency upgrades, fixes, and improvements, > > especially: > > > > - align dependencies versions between Karaf and Pax * > > - fix missing system export packages > > - fix on Karaf features json support > > - fix features autoRefresh configuration handling > > - fix on sshd session handling > > - update to sshd 2.8.0 > > - lot of pax * updates > > - and much more ! > > > > Please take a look on Release Notes for details ! > > > > Release Notes: > > > > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12350547 > > > > Staging Maven Repository: > > https://repository.apache.org/content/repositories/orgapachekaraf-1162/ > > > > Staging Dist Repository: > > https://dist.apache.org/repos/dist/dev/karaf/4.3.4/ > > > > Git tag: > > karaf-4.3.4 > > > > Please vote to approve this release: > > > > [ ] +1 Approve the release > > [ ] -1 Don't approve the release (please provide specific comments) > > > > This vote will be open for at least 72 hours. > > > > Regards > > JB > > >
Re: karaf-maven-plugin generates another org.apache.karaf.features.xml with Java 8/Java 11
Hi Steven, Maybe force jaxb version to an earlier one in karag pluhin dependencies in your pom. Le sam. 27 nov. 2021 à 20:05, Steven Huypens a écrit : > Hi all, > > I tried to create my custom Karaf distribution (using karaf-maven-plugin > 4.3.2) with Java 11 for the first time, and I noticed a difference in the > resulting org.apache.karaf.features.xml > > The line > > http://karaf.apache.org/xmlns/features-processing/v1.0.0; xmlns:f=" > http://karaf.apache.org/xmlns/features/v1.6.0;> > > has been changed into > > http://karaf.apache.org/xmlns/features/v1.6.0; xmlns:ns3=" > http://karaf.apache.org/xmlns/features-processing/v1.0.0;> > > which means a namespace has been added. Unfortunately this little change > has a big impact because now my app immediately runs OutOfMemory when I > start Karaf. There is very little DEBUG-logging, the behaviour is somewhat > like described in https://issues.apache.org/jira/browse/KARAF-6068 > > Removing the namespace fixes the problem. > > > > Do you have any idea how I can prevent my app from going OOM after this > change ? Or how I can prevent the namespace from being added with Java 11 ? > It would be nice to understand the exact problem here. > > > > Kind regards, > Steven >
Re: Pax Web 8 performance (different JDKs)
The gc is way better on modern jdk, even 11 (post update 6x IIRC for openjdk but not oracle jdk which was more conservative). There was also quite a bunch of optim in common operations - like some String ones. Can be a way to explain why it is faster. Le lun. 13 sept. 2021 à 08:05, Grzegorz Grzybek a écrit : > Hello JBO > > Pax Web 8 own "Karaf tests" work (since yesterday) on Karaf 4.3.3. > Everything should work on all Osgi Core R6+ runtimes > (pax-exam-container-native tests use osgi.core 6.0.0 / Felix 5.6.12) > > regards > Grzegorz Grzybek > > niedz., 12 wrz 2021 o 21:10 Jean-Baptiste Onofre > napisał(a): > > > Hi Greg > > > > Thanks for the update and great results ! > > > > I’m running a new build/pass and I will test in 4.3.x. > > > > What I have in mind is to prepare 4.4.x with Pax Web 8 and OSGi R8. > > > > So, I would create karaf-4.3.x branch and update main to OSGi R8/Pax Web > 8. > > > > Thoughts ? > > > > Regards > > JB > > > > > Le 12 sept. 2021 à 19:30, Grzegorz Grzybek a > > écrit : > > > > > > Good evening! > > > > > > I've just pushed last commit before 8.0.0.GA. This commit fixed the > > compilation and test problems under JDK17. > > > > > > Current state is: > > > - all the tasks I've planned for 8.0.0.GA are finished > > > - all the tests (unit, pax-exam-container-native, > > pax-exam-container-karaf) work on JDK 8, JDK 11 and JDK 17 > > > > > > I expected that everything would work few percent slower on JDK 11 than > > on JDK 8 (I observed this performance downgrade on several occasions). > What > > I didn't expect is that generally everything works faster on JDK 17 than > on > > JDK 8! > > > > > > Here's the table: > > > > > > > > > > > > I hope to write more about "what is Pax Web 8" soon and that the week > of > > Sep 13-17 will be the week of the release. > > > > > > kind regards > > > Grzegorz Grzybek > > > > >
Re: [VOTE] Apache Karaf runtime 4.3.3 release
+1 Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le ven. 3 sept. 2021 à 14:49, Jamie G. a écrit : > +1 > > Cheers, > Jamie > > On Thu, Sep 2, 2021 at 3:52 PM Steinar Bang wrote: > > > > >>>>> Jean-Baptiste Onofré : > > > > > Please vote to approve this release: > > > > > [ ] +1 Approve the release > > > [ ] -1 Don't approve the release (please provide specific comments) > > > > Once I remembered to add the staging maven repository, my karaf 4.3.2 > > applications loaded as normal and seems to be running normally. > > > > Also ssh in works, once I've uncommented the user and group in > > users.properties and shell history works, and pasting into the shell > > works (all of which are important for my debian packaged karaf). > > > > So from me, it is: > > > > +1 (non-binding) > > >
Re: Conscious Language Checker
Hi, Guess you need to exclude all release*.md, most *.xml and *.properties (legacy *must* not be fixed since it would break). A codemod could fix all the other issues (code) but would also break all consumers so as for the past renaming I'm really -1 on such rework which do not solve the community issue it tries to solve (actually it makes it more complex when the term is kind of used for years). So in terms of actions I think the clc could use a clc.properties or clc.json in the repository (please no yaml) to exclude all false positive warnings which would lead to almost nothing in karaf (it is the same on other repos I reviewed, mainly noise warnings). Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le lun. 30 août 2021 à 09:43, Francois Papon a écrit : > Hi, > > I checked the result of the Karaf repo analysis and I don't know how we > could fix the thousand of issues... > > https://clc.diversity.apache.org/analysis.html?project=karaf.git > > The most are related to the blacklist feature so It will be a huge > effort and a migration step for users. > > Thoughts? > > regards, > > -- > François > fpa...@apache.org > >
Re: Problem after install pax-trans-tm-narayana with Karaf 4.3.2
isnt it a java 11 change (for mjar useless feature)? -> https://github.com/openjdk/jdk11u/blob/master/src/java.base/unix/classes/sun/net/www/protocol/jar/JarFileFactory.java#L154 Last time i checked OSGi ecosystem (some libs are) was not ready for this change leading to some issues like that. Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le jeu. 20 mai 2021 à 08:29, Grzegorz Grzybek a écrit : > Hello > > > bundle://6a2c22d1-9b1f-46a3-b973-3d9276b47679_60.0:1/arjuna-5.10.6.Final.jar#runtime > looks weird... I've never seen such URL before. Anyone can point to related > Felix change about these URLs? > > I'm currently deep in Pax Web 8 refactoring and I deal with > bundle/bundleentry resources, but this one looks strange. > > Normally, Felix uses bundle://30.0:0/WEB-INF/lib/primefaces-7.0.jar and > Equinox uses > bundleentry://30.fwk1976804832/WEB-INF/lib/primefaces-7.0.jar... > > regards > Grzegorz Grzybek > > czw., 20 maj 2021 o 08:17 Benjamin Graf > napisał(a): > > > Hi, > > > > it seems there is a bug with embedded resources. I think it is caused by > > Felix and not Karaf itself. > > > > How to reproduce: > > > > - Clean start of plain Karaf 4.3.2 > > > > - feature:install pax-transx-tm-narayana > > > > Result: > > > > 2021-05-20T08:16:02,787 | WARN | paxtransx-config-1-thread-1 | > > pax-transx-tm-narayana | 60 - > > org.ops4j.pax.transx.pax-transx-tm-narayana - 0.5.0 | Error starting > > service > > java.lang.reflect.InvocationTargetException: null > > at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native > > Method) ~[?:?] > > at > > > jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > > > > ~[?:?] > > at > > > jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > > > > ~[?:?] > > at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?] > > at > > org.jboss.narayana.osgi.jta.internal.Activator.doStart(Activator.java:49) > > ~[?:?] > > at > > > org.ops4j.pax.transx.tm.impl.AbstractActivator.run(AbstractActivator.java:115) > > > > ~[?:?] > > at > > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) > > [?:?] > > at java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?] > > at > > > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) > > > > [?:?] > > at > > > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > > > > [?:?] > > at java.lang.Thread.run(Thread.java:829) [?:?] > > Caused by: java.lang.IllegalStateException: Stream handler unavailable > > due to: null > > at > > > org.apache.felix.framework.URLHandlersStreamHandlerProxy.openConnection(URLHandlersStreamHandlerProxy.java:311) > > > > ~[?:?] > > at java.net.URL.openConnection(URL.java:1099) ~[?:?] > > at > > > jdk.internal.loader.URLClassPath$JarLoader.getJarFile(URLClassPath.java:815) > > > > ~[?:?] > > at > > jdk.internal.loader.URLClassPath$JarLoader$1.run(URLClassPath.java:758) > > ~[?:?] > > at > > jdk.internal.loader.URLClassPath$JarLoader$1.run(URLClassPath.java:751) > > ~[?:?] > > at java.security.AccessController.doPrivileged(Native Method) ~[?:?] > > at > > > jdk.internal.loader.URLClassPath$JarLoader.ensureOpen(URLClassPath.java:750) > > > > ~[?:?] > > at > > jdk.internal.loader.URLClassPath$JarLoader.(URLClassPath.java:725) > > ~[?:?] > > at jdk.internal.loader.URLClassPath$3.run(URLClassPath.java:493) > > ~[?:?] > > at jdk.internal.loader.URLClassPath$3.run(URLClassPath.java:476) > > ~[?:?] > > at java.security.AccessController.doPrivileged(Native Method) ~[?:?] > > at > > jdk.internal.loader.URLClassPath.getLoader(URLClassPath.java:475) ~[?:?] > > at > > jdk.internal.loader.URLClassPath.getLoader(URLClassPath.java:444) ~[?:?] > > at > > jdk.internal.loader.URLClassPath.getResource(URLClassPath.java:313) > ~[?:?] > > at java.net.URLClassLoader$1.run(URLClas
Re: JAAS in Karaf4/5
Hi Le mer. 19 mai 2021 à 11:31, Bernd a écrit : > Hello, > > I noticed that Karaf provides quite useful principals for Roles, Groups and > Client. But if I want to consume or create those principals in my own code, > I have to depend on the karaf-boot bundle. > > I wonder: > > a) would it make sense for Karaf5 to move the classes to a more focused API > jar. That would be helpful if I want to build a Microservice Servlet which > should also run in other containers or if I just dont want to depend on the > -boot bunfle. > For karaf 5 I don't know but a reusable module makes sense to me. TomEE got some but not being released independently makes it poorly reusable/perceived. Maybe a neutral home can help (subproject or incubator?). > > b) would it make sense to provide utilities (JAASContext.getClientIP() or > something) > > c) would it make sense to add this to the logger so that it can add this > (subject/ip) to all log lines generated with active JAAS context. > guess it is already supported with attributes or things like that in access valve or alike (mdc for ex) > > d) if I have my own http listener, is there a filter I can use to establish > the JAAS login and especially also attach the http-client IP principal? > attributes, subjects and friends should enable that, main trick is to authenticate in the used context for the request to attach it to the right context AFAIK - but you still use a single jaas context > > e) we are using Felix RSA/fastbin, I wonder if somebody has experience with > adding instance-level authentication to something like this (and to RMI)? > f) do an optimized jaas context (a lot an be speed up in most cases ;)) in a "home" > > Gruss > Bernd >
Re: Non-Deterministic startup order
Hi Paul, Did you use the last 4.3 release? Startup bundles shouldn't be randomized anymore. For features it is a bit more complicated since it is a tree so guess order can't really be assumed without side effects (whereas it can for a flat list of bundles). Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le mer. 5 mai 2021 à 17:07, Paul Stanley a écrit : > Hi. > > When building and running karaf the boot order for the initial set of > startup bundles is being randomised, within their start levels. As result > we are seeing non-deterministic behaviour between development and release > builds of custom karaf platforms. > > Please can you change the karaf.features.core and the karaf.profile.core > to use LinkedHashMaps and Sets, to preserve the order of bundles as > discovered in the feature.xml files. > > Thanks > Paul > >
Re: Error running test org.apache.karaf.itests.BundleTest#listCommand
Hi Do you use eclipse or some IDE visiting target/ during the test? Can make it happen. Le dim. 18 avr. 2021 à 17:48, Jean-Baptiste Onofre a écrit : > Hi Vassil, > > Don’t you have two tests running ? > > I never had this issue (but I’m not using Windows), and Jenkins works fine. > > Do you have a simple test case to reproduce ? > > Regards > JB > > > Le 18 avr. 2021 à 12:58, Васил Зорев a écrit > : > > > > Reposted from the user mailing list: > > > > Hello, > > > > I tried to run some of the unit tests in the itests project to check an > issue, but most of them failed. The most common error is that pax exam > couldn't start the container as it failed to replace the > etc\org.ops4j.pax.logging.cfg file. > > > > Caused by: java.nio.file.FileSystemException: > C:\Users\vasil\IdeaProjects\karaf\itests\test\target\exam\95aa38e2-a6a1-405e-8072-afe35347a34e\etc\org.ops4j.pax.logging.cfg: > The process cannot access the file because it is being used by another > process. > > at > java.base/sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:92) > > ... (full log attached) > > > > I have checked out karaf sources version 4.2.12-SNAPSHOT from some time > ago (probably a few months). > > > > Please find attached the intellij test log. > > It failed the same way when I executed the test as part of the maven > build. > > > > I added a breakpoint at the place where the FileSystemException is > thrown and examined the open file handles of this file in Sysinternals > Process Explorer. Seems there are two open file handles for it, both by the > same java process that is executing the test (screenshots attached). > > > > Please let me know if this is a known issue on my end if i can already > resolve it, is it version dependent or something else? Also I can provide > further details if needed. > > > > Regards, > > Vassil > > > >
Re: [VOTE] Apache Karaf runtime 4.3.1 release
+1 (small side note/workaround: the resolver fix is needed on k8s only if the allocated cpu are not enough = it generally works in prod since you allocate enough ;)) Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le mar. 30 mars 2021 à 06:10, Jean-Baptiste Onofre a écrit : > Hi Robert, > > You mean cancel this RC to cut a new one for Jackson upgrade, or upgrade > Jackson for 4.3.2 ? > > Regards > JB > > > Le 29 mars 2021 à 18:12, Robert Varga a écrit : > > > > On 29/03/2021 15:14, Jean-Baptiste Onofre wrote: > >> Hi everyone, > > > > Hello JB, > > > >> I submit Apache Karaf runtime 4.3.1 to your vote. > >> > >> This release includes bunch of dependency upgrades, fixes, and > improvements, especially: > > > > ODL smoke tests look good. Version alignment is on par with 4.2.11, so > > also okay. > > > > I noticed the candidate is still using Jackson 2.11.3 in the enterprise > > feature. Would it be possible to bump to > > https://github.com/FasterXML/jackson/wiki/Jackson-Release-2.11.4 ? > > > > Thanks, > > Robert > > > >
Re: [INFO] Apache Karaf 5 will be internally based on OSGi R8
Le jeu. 25 mars 2021 à 09:35, Grzegorz Grzybek a écrit : > Thanks Romain for the details! (see inline) > > czw., 25 mar 2021 o 08:31 Romain Manni-Bucau > napisał(a): > > > Le jeu. 25 mars 2021 à 07:13, Grzegorz Grzybek a > > écrit : > > > > > Good morning! > > > > > > śr., 24 mar 2021 o 19:57 Romain Manni-Bucau > > > napisał(a): > > > > > > > in terms of arch yes, the key feature is to have a tree classloader > and > > > not > > > > a graph (drops all the build complexity of OSGi and enable scanning > > > > pluggability, yeah). > > > > > > > > > > Graph → Tree sounds like OSGi → JavaEE... > > > This can prevent user feature to install a bundle that overrides system > > > services I know that (without "134 Subsystem Service Specification" > > and > > > without hooks) effectively OSGi runtime is "flat" - every bundle wire > is > > > equal and resolution rules apply. Also every OSGi service is equal and > > > service rank is taken into account. > > > > > > > Yes and no, a service registration can still use @Priority or a SPI > method > > to be sorted, only thing it can prevent is to put conflicting deps in the > > same bootstrap classloader (that said these days OSGi is rarely used for > > that and since by design the bootstrap loader will be a single app - ie > > without any conflict at build time - it is actually sane). > > > > In JavaEE, a WAR can (mostly) configure some providers, so e.g., > DocumentBuilderFactory may return WAR-specific instance. But it's not > possible to affect this service loading in other WARs. > In OSGi, a bundle can register some service that'll become the valid > service for remaining bundles. > So I understand that Karaf 5 keeps the OSGi philosophy here, right? > Yes and not, the small language trick is do you speak of bootstrap services or profile or app in Karaf 5. Bootstrap services can do whatever they want (ie same as OSGi in terms of impact even if technicaly it is not linked) but all other layers (profile+app) must stay static and almost immutable. > > > > > > > > > > > > I'm trying to imagine how "it’s powered by OSGi R8 (but you will see > that > > > it’s more an internal point)" works - is the "Level1: Karaf itself" a > > > graph-based layer of bundle classloaders, while applications are given > > > their own single classloader (kind of like WebSphere is (was?) based on > > > OSGi and WARs/EARs hand single classloader or like Wildfly/EAP that's > > > internally a graph of JBoss Modules, while WARs/EARs have single > > > classloader)? > > > > > > java.util.ServiceLoader is dynamic in nature and is a final (IMO) and > > quite > > > elegant discovery solution in tree-(ClassLoader)-based monoliths where > > you > > > "deploy" applications. And it's reflection based. > > > > > > > Last point does not have to be true, see some graalvm integrations for > > example, it is reflection less depends how you handle the build phase but > > being reflection "full" by default enables to keep the tooling (testing) > > working without breaking your IDE. > > > > Mind that I'm not very experienced with Graal/Quarkus, so my questions may > be invalid ;) > I was expecting it to come at some point - and btw we can note the fun thing that the big change is GraalVM but everybody speaks of Quarkus which is just a rebranding of already existing things, no technology jump by itself ;). My vision is that karaf 5 fulfills the microservices pitfalls and drawback by bringing back a well know and secure deployment alternative to all that. Indeed graal-ifying your app will make it save some memory, maybe some CPU cycle in some cases but if you optimize your java code you can get the same in terms of CPU cycles (and even faster in some cases). In terms of bootstrap you can same a few ms due to the classloading but not much more and CDS already solves part of it (at the cost of memory). So for long running apps graal cost is wayy more than the runtime gain and I guess it is where Karaf 5 will sit, long running aggregated and unified apps (by providing a single admin interface for all kind of apps and not a different one for spring/spring-boot, microprofile, ee, osgi etc). Hope it makes sense and I'm not too far from what JB had in mind but this is where I see a looot of value for such a design. > > > > > > > > > How about graal/quarkus? > > > Let me be clear here - quarkus/graal/native approach is cool and makes
Re: [INFO] Apache Karaf 5 will be internally based on OSGi R8
in terms of arch yes, the key feature is to have a tree classloader and not
a graph (drops all the build complexity of OSGi and enable scanning
pluggability, yeah).
In terms of service since the launcher is a monolith it has the key
advantage to be able to scan all then dispatch so I guess we can just have
a ServiceLoader kind of SPI for "module service" impls and order them as
needed. a ModuleService { setModuleServiceRegistry(Registry); } would then
do the trick probably, no need of fancy IoC for such low level framework
IMHO.
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>
Le mer. 24 mars 2021 à 19:13, Jean-Baptiste Onofre a
écrit :
> Hi Romain,
>
> About OSGi, the way I did it (up to now), it’s as you describe:
>
> - Karaf "launcher"
> — Libraries service
> — Profiles service
> — SpringBootModuleService
> — OsgiModuleService
> — MicroprofileModuleService (not yet started)
>
> The framework is only started when the first OSGi module is deployed.
>
> If the user deploys only SpringBoot apps in Karaf, he won’t have any OSGi
> framework.
>
> Is it what you expected ?
>
> On Karaf "launcher", we have services available (for now just using
> karaf.getService("id")).
>
> I would love your feedback here. Thoughts ?
>
> Regards
> JB
>
> > Le 24 mars 2021 à 19:03, Romain Manni-Bucau a
> écrit :
> >
> > Le mer. 24 mars 2021 à 17:35, Jean-Baptiste Onofre a
> > écrit :
> >
> >> Actually, spec like as DocuentBuilder would be rather a library, shared
> by
> >> all launchers.
> >>
> >
> > Ok but what about jackson? the same?
> >
> > Joke apart what if spring-boot-app1 uses one impl and spring-boot-app2
> uses
> > another one?
> >
> > Think at the end there is the JVM, the framework stack which is isolated
> > from the app and the apps or it does not move the ball very far from what
> > we have today.
> >
> > Until there is it is EE server - in terms of architecture not scope/impl.
> > But the gold of this solution is the ability to configure the leakage
> > between layers/profiles to let an app override and potentially
> > aggregate/share parts. Obvious example is the http service which can leak
> > in spring boot app to override the servlet layer enabling to admistrate
> it
> > globally. Another more advanced solution is to deploy app1 and app2
> called
> > each other through a kafka topic and replace kafka stack by a local event
> > (event admin or not is an impl detail), imagine the perf boost and admin
> > simplicity it will bring - all that meaning saving a lot of green piece
> of
> > paper for managers ;).
> >
> > My only "?" as of today is: why OSGi, this technology is not really
> needed
> > for such a project (for ex this module provides it wihout OSGi
> >
> https://github.com/Talend/component-runtime/tree/master/container/container-core
> )
> > and can bring several drawbacks like the slowness to upgrade libs due to
> > meta, the blockers to add libs due to the lack of OSGi support, the
> > enforcement of architecture teams to adopt OSGi to use that solution etc.
> > Why not making OSGi a launcher as spring boot or microprofile, sounds to
> be
> > at the same level to me.
> >
> >
> >>
> >> I would rather say that Karaf 5 is a runtime in the way of launcher. If
> we
> >> consider an application server as launcher + some key turn features,
> then
> >> Karaf5 could be considered as an new light app server.
> >>
> >> You are right: for now, each spring boot app is in its own class loader,
> >> embedding its own spring version.
> >> However, a spring boot module (karaf 5 terminology uses module more than
> >> app) can use a profile. A profile basically brings a class loader where
> you
> >> can override spring boot module dependencies.
> >>
> >> Great questions: Karaf 5 MVP is a first attempt, it will be refine for
> >> sure. I just want to have a first running version to share with you all
> and
> >> chat about.
> >>
> >> Regards
> >> JB
> >>
> >>> Le 24 mars 2021 à 16:55, Grzegorz Grzybek a
> >> écrit :
> >>>
> >>> Thanks for the insight ;)
> >>>
> >
Re: Renaming master branch as main branch
Ok :( Le lun. 15 mars 2021 à 07:49, Jean-Baptiste Onofre a écrit : > Hi guys, > > I created a Jira for infra to rename master branch as main: > > https://issues.apache.org/jira/browse/INFRA-21576 > > Thanks, > Regards > JB >
Re: [VOTE] Apache Karaf runtime 4.2.11 release
+1 (non binding) Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le mer. 10 mars 2021 à 05:47, Jean-Baptiste Onofre a écrit : > Hi, > > Crap I missed that one (Greg and I worked on many alignement). > > I will align for next cycle (not a big deal). > > Regards > JB > > > Le 9 mars 2021 à 23:27, Robert Varga a écrit : > > > > On 09/03/2021 12:56, Jean-Baptiste Onofre wrote: > >> Hi everyone, > >> > >> I submit Apache Karaf runtime 4.2.11 to your vote. > > > > [snip] > > > > I ran smoke tests with odlparent-7.0.x. > > > > There are two new misalignments between karaf-4.2.11 and pax-web-7.2.23: > > - javax.interceptor-api/1.2.2 vs 1.2 > > - org.apache.servicemix.bundles.javax-inject/1_3 vs 1_2 > > > > I found nothing obviously wrong and we can monkey-patch this > > inconsistency downstream. > > > > +1, non-binding. > > > > Regards, > > Robert > > > >
Re: [PROPOSAL] Disable autoRefresh on features service by default and simple optional features service
+1 for a runtime (or immutable) distribution, makes a lot of sense Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le ven. 8 janv. 2021 à 13:43, Jean-Baptiste Onofre a écrit : > Yes, yes, that’s the "updated" proposal. > > autoRefresh didn’t exist before my PR, and, initially, I proposed to > change it to false on 4.3.x. But according to your valuable comment, I > think it’s better to introduce the property but keep it to true by default > (as it is today). > > Regards > JB > > > Le 8 janv. 2021 à 09:32, Daniel Las a > écrit : > > > > Hi, > > > > Don't we have Karaf version 4.3.0 with autoRefresh=true by default and > you > > propose to change autoRefresh=false by default in 4.3.x ? > > > > Regards > > > > pt., 8 sty 2021 o 08:38 Jean-Baptiste Onofre > napisał(a): > > > >> Hi, > >> > >> I guess you didn’t read fully my message ;) > >> > >> My proposal is: > >> > >> - introduce the property and keep "true" (as it is today) on Karaf 4.2.x > >> - introduce the property and set to "false" (change) on Karaf 4.3.x. > >> > >> Regards > >> JB > >> > >> Le 8 janv. 2021 à 08:16, Daniel Las a écrit : > >> > >> Hi, > >> > >> It looks like some kind of backward incompatible change introduced > within > >> patch version change. I personally would like to keep auto refresh "on" > by > >> default as this is expected/desired behavior for me. > >> > >> Regards > >> > >> pt., 8 sty 2021 o 07:31 Jean-Baptiste Onofre > napisał(a): > >> > >>> Hi everyone, > >>> > >>> We got several user feedback, complaining about unexpected and cascaded > >>> (unrelated) refresh while installing features. > >>> > >>> As reminder, a refresh can happen when: > >>> - bundle A imports package foo:1 and a bundle provides newer foo > package > >>> version. In that case, the features service will refresh A to use the > >>> newest package version. > >>> - bundle A has an optional import to package foo and a bundle provides > >>> this package. In that case, the features service will refresh A to > actually > >>> use the import as it’s a "resolved" optional. > >>> - bundle A is wired to bundle B (from a package perspective or > >>> requirement) and B is refreshed. In that case, the features service > will > >>> refresh A as B is itself refreshed (for the previous reasons for > instance). > >>> This can cause "cascading" refresh. > >>> > >>> A refresh means that a bundle can be restarted (if the bundle contains > an > >>> activator or similar (DS component, blueprint bundle)). > >>> > >>> In this PR https://github.com/apache/karaf/pull/1287, I propose to > >>> introduce a new property autoRefresh in > etc/org.apache.karaf.features.cfg > >>> to disable the auto refresh by the features service (and let the user > >>> decides when he wants to trigger refresh with bundle:refresh command > for > >>> instance). > >>> I propose to keep autoRefresh=true on 4.2.x and turn autoRefresh=false > on > >>> 4.3.x. > >>> > >>> Thoughts ? > >>> > >>> On the other hand (and to prepare the "path" to Karaf5), I have > created a > >>> new "simple features service" (PR will be open soon) that: > >>> > >>> - just take the features definition in order (ignoring start level) > >>> - ignore requirement/capability (no resolver) > >>> - no auto refresh > >>> > >>> Basically, if you have the following feature definition: > >>> > >>> > >>> bar > >>> A > >>> B > >>> > >>> > >>> The features service will fully install/start bar feature first, then > >>> bundle A, then bundle B. > >>> To use this "simple features services, you just have to replace > >>> org.apache.karaf.features.core by org.apache.karaf.features.simple > bundle > >>> in etc/startup.properties (or custom distribution). > >>> > >>> It’s similar to the Karaf 5 extension behavior (I will share complete > >>> details about Karaf 5 and its concepts (module, extension, …) very > soon, > >>> but that’s another thread ;)). > >>> > >>> The big advantages of this approach is: > >>> - predictable/deterministic provisioning (if it works fine, it works > >>> again) > >>> - faster deployment (I estimated the gain to about 70%) > >>> > >>> Thoughts ? > >>> > >>> If you agree, I will move forward on both tasks. > >>> > >>> Thanks, > >>> Regards > >>> JB > >>> > >> > >> > >> -- > >> Daniel Łaś > >> CTO at Empirica S.A. > >> +48 695 616181 > >> > >> > >> > > > > -- > > Daniel Łaś > > CTO at Empirica S.A. > > +48 695 616181 > >
Re: [PROPOSAL] Disable autoRefresh on features service by default and simple optional features service
Hi all, What about creating a new karaf distro with the new configs? Not sure of the naming but idea is to have a "karaf-future" default setup, this way you get less surprises when it becomes the default. For all dev driven flow it will fit more (whereas the backward compatible default option fits better ops IMHO). Can't it enable to get the best of both worlds somehow? Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le ven. 8 janv. 2021 à 11:18, Jean-Baptiste Onofre a écrit : > Understood, and it makes sense. > > So, autoRefresh property will be present on 4.2.x and 4.3.x but still > "true" by default. > > And focus on Karaf 5 for some "conceptual" changes ;) > > Regards > JB > > > Le 8 janv. 2021 à 10:57, Robert Varga a écrit : > > > > On 08/01/2021 09:07, Grzegorz Grzybek wrote: > >> But summarizing, I'd keep autoRefresh=true in all the scenarios, where > >> Karaf is used as "application server" and switch it to > autoRefresh=false in > >> µservices / custom distro / single start mode. And looking forward > Karaf 5 > >> and new feature mechanism, I'd rather turn autoRefresh off in Karaf 5... > > > > +1. > > > > I would advise against changing behavior of 4.3.x -- it is exactly these > > sorts of changes which make even minor Karaf bumps a major uncertainty > > -- and have historically inflicted more frustration than I care to > > remember :( > > > > Regards, > > Robert > > > >
Re: [VOTE] Apache Winegrower 1.0.1 release
+1 Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le mar. 17 nov. 2020 à 21:07, Francois Papon a écrit : > +1 (binding) > > regards, > > François > fpa...@apache.org > > Le 17/11/2020 à 19:06, Jean-Baptiste Onofre a écrit : > > Hi everyone, > > > > I submit Winegrower 1.0.1 to your vote. It’s a maintenance release on > Winegrower 1.0.0. > > > > Release Notes: > > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12349356 > > > > Staging Repository: > > https://repository.apache.org/content/repositories/orgapachekaraf-1151/ > <https://repository.apache.org/content/repositories/orgapachekaraf-1151/> > > > > Staging Dist: > > https://dist.apache.org/repos/dist/dev/karaf/winegrower/1.0.1/ < > https://dist.apache.org/repos/dist/dev/karaf/winegrower/1.0.1/> > > > > Git tag > > winegrower-1.0.1 > > > > Please vote to approve this release: > > > > [ ] +1 Approve the release > > [ ] -1 Don't approve the release (please provide specific comments) > > > > This vote will be open for at least 72 hours. > > > > Regards > > JB > > > > >
Re: [winegrower] when can we expect a 1.0.1?
Guess it is a long night ;). Any blocker? Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le lun. 9 nov. 2020 à 15:53, Jean-Baptiste Onofre a écrit : > Hi, > > +1 > > I’m deploying new set of SNAPSHOTs. > I propose to submit winegrower 1.0.1 to vote tonight. > > Regards > JB > > > Le 9 nov. 2020 à 15:25, Romain Manni-Bucau a > écrit : > > > > Hi everyone, > > > > We have 4 enhancements/fixes in winegrower land ( > > https://issues.apache.org/jira/projects/KARAF/versions/12349356). > > Don't really know the effort to do the release (I know the build is just > > about "mvn release:prepare release:perform" and dist area likely a fn in > > your bashrc but don't know about the site to be concrete) but it can be > > neat to let them go out when some PMC has some cycles. > > > > Wdyt? > > > > Romain Manni-Bucau > > @rmannibucau <https://twitter.com/rmannibucau> | Blog > > <https://rmannibucau.metawerx.net/> | Old Blog > > <http://rmannibucau.wordpress.com> | Github < > https://github.com/rmannibucau> | > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book > > < > https://www.packtpub.com/application-development/java-ee-8-high-performance > > > >
[winegrower] when can we expect a 1.0.1?
Hi everyone, We have 4 enhancements/fixes in winegrower land ( https://issues.apache.org/jira/projects/KARAF/versions/12349356). Don't really know the effort to do the release (I know the build is just about "mvn release:prepare release:perform" and dist area likely a fn in your bashrc but don't know about the site to be concrete) but it can be neat to let them go out when some PMC has some cycles. Wdyt? Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance>
Re: Thinking about Karaf 5 modulith runtime
To enhance what JB says there are other things to consider I think: 1. There is space for a "docker destructor" (everybody does a microservice to read a config file these days, when the company hosting it in the cloud checks the costs it realizes it can be reduced by at last 10 generally, without perf or dev/responsabilities impact - what uservices are for). Here the new subproject makes a lot of sense for me 2. If you look the landscape today you have the choice between spring boot or microprofile (or play but point is the same), ie a single company project (yes MP is that as well since quarkus killed others in terms of communication and even without respecting any of the spec it promotes, it wins the $$ fight as expected, in particular since IBM and RH merged). Indeed cloud makes vendor locking less important, but mainly for hosted service, not for dev when the company have to maintain its project. OSGi was an alternative until it goes to Eclipse (I agree it looks like a cemetery) and moreover the overlayer OSGi specs adds to Jakarta/underlying specs (often breaking part of them) + the build constraints it implies does not help - here Winegrower helps a lot though without loosing OSGi libs. So overall, if you are a company and want to bet on the future in terms of stack you don't have the choice anymore. At Geronimo we proposed to "fork" our Microprofile implementations to have a vendor neutral stack but seems dev are far from stack decisions and therefore it will not help much. All that to say that 1 can be an interesting future for karaf and maybe in some year become the TLP and Karaf the subproject. I also think it is the moment to think about it to not wait for Karaf to have to go to attic. Karaf is a launcher (main) + some tools (features mainly), it does not have to leave that space, it will just leave the scope of this space IMHO. Hope it makes sense. Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le lun. 9 nov. 2020 à 06:20, Jean-Baptiste Onofre a écrit : > Hi Lukasz, > > And thanks for your feedback. I think it’s a fair feedback about the > current situation. > > I think Karaf is one thing and OSGi is another one (for a project > perspective). > So, we can drive Karaf roadmap to something different if it makes sense. > > Remember, first ServiceMix version was Spring focus before moving to OSGi. > So the other way around can be true. > > We can use OSGi internally, and provide some user facing different > approaches. > > Karaf devx/tool is the first thing to achieve: improve developer > experience, simplify test and runtime assembly. > > I agree that we don’t have the marketing power of Pivotal (we are "real" > open source project after all ;)) and we don’t have a single company > providing marketing power. > > I think we have two personas: > > 1. People already using Karaf, and for them, we have to improve and > provide a better runtime generally speaking for sure > 2. People not using Karaf, using spring boot, cdi, whatever. I doubt we > will convince them to switch to Karaf with another programming framework. > The purpose is more to try to attract them with a runtime directly > supporting their applications but providing adhoc features out of the box > for them (the purpose of a runtime). > > That’s what I have in mind for now: improve (thanks for devx and other new > features), and attract. > > Regards > JB > > > Le 9 nov. 2020 à 02:42, Łukasz Dywicki a écrit : > > > > I am quite late for this discussion and haven't watched your ApacheCon > > talk, hence pardon my points if they're wrong. > > > > Reorganizing code base is highly appreciated since karaf source tree > > grew since 2.x without any major changes in directory structure. > > Till these days it is confusing to me where "enterprise" features come > > from (in terms of maven POM) and where "framework-static" lives. > > I do believe that improving tooling and docs will help a lot. I keep > > getting into troubles with tooling every-so-often. > > > > > > The question where Karaf should or could go.. that's quite difficult to > > answer. From what I see OSGi marketplace is shrinking year-to-year and > > recent move/merger of OSGi Alliance with Eclipse Foundation is, in my > > personal opinion, result of deep organization failure. It simply did not > > attract enough of people to use, promote and pay for their certification. > > Besid
Re: Thinking about Karaf 5 modulith runtime
This is a very interesting approach and I wouldn't keep OSGi a backbone but one of the supported runtime (as spring-boot, microprofile or even javaee...oops jakartaee, why not?). So overall OSGi flavor would be a karaf 4 in a karaf 5 to illustrate the idea. Being able to aggregate runtimes in a single JVM has a great value but it must not come with all the build requirements (and prerequirements to tests for instance) so something lighter than OSGi, probably closer to tomcat/servlet classloading default model (parent with the "container", children with the apps) makes a lot of sense. I wouldn't call it karaf 5 (please dont do AMQ5-AMQ6 error), but as karaf is the industrialization of an OSGi runtime it makes sense to have an industrialization of a generic runtime, it is the next step IMO and I already envision the "merge" of a docker-compose/k8s recipe with 10 uservices in a single JVM, financial department will love it and dev will keep doing what they want, everybody will be happy ;). Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le mer. 4 nov. 2020 à 08:52, Grzegorz Grzybek a écrit : > śr., 4 lis 2020 o 08:35 Jean-Baptiste Onofre napisał(a): > > > That’s a great feedback ! > > > > Today, we are "challenged" by other approach. I still believe that we > have > > a great asset in the runtime ecosystem. > > > > My thinking now is more to still use OSGi internally (and let people do > > OSGi on Karaf if they want) but open the scope to other > framework/approach > > (spring boot, micro profile, etc). We would embrace a wider community and > > expend our use cases. > > With François, I think we already identified some improvements patch > > (lighter/immutable runtime, tooling, …), but I would love to have > feedback > > from the community to drive the roadmap. > > > > Thanks Greg ! You made my day ;) > > > > :) > I'll definitely think outside of OSGi box after I finish my current > assignment (work). > > regards > Grzegorz > > > > Regards > > JB > > > > > Le 4 nov. 2020 à 07:43, Grzegorz Grzybek a > écrit > > : > > > > > > śr., 4 lis 2020 o 07:41 Jean-Baptiste Onofre > > napisał(a): > > > > > >> What do you mean by "impossible" ? Removing OSGi from the picture, or > > >> thinking about Karaf future ? ;) > > >> > > > > > > I meant I see OSGi everywhere and that's all I do for last 6+ years, so > > > it's hard for me to NOT think about OSGi ;) > > > If I was asked to help shaping Karaf 5, I'd still think OSGi-first... > > > > > > regards > > > Grzegorz Grzybek > > > > > > > > >> > > >> Regards > > >> JB > > >> > > >>> Le 4 nov. 2020 à 06:27, Grzegorz Grzybek a > > écrit > > >> : > > >>> > > >>>> > > >>>> don’t think OSGi focus > > >>>> > > >>> > > >>> For now it's impossible for me ;) Looks like I need some OSGi-REST... > > ;) > > >>> > > >>> regards > > >>> Grzegorz > > >>> > > >>> śr., 4 lis 2020 o 06:16 Jean-Baptiste Onofre > > >> napisał(a): > > >>> > > >>>> Hi > > >>>> > > >>>> Not yet, I’m working locally on changing the structure. > > >>>> > > >>>> And I don’t want to be influenced or influence for now ;) > > >>>> > > >>>> So, I would love your overall thinking in term of approach, > features, > > >>>> vision, and again generally speaking (don’t think OSGi focus, or one > > >>>> particular use case, more global). > > >>>> > > >>>> Regards > > >>>> JB > > >>>> > > >>>>> Le 4 nov. 2020 à 06:09, Grzegorz Grzybek a > > >> écrit > > >>>> : > > >>>>> > > >>>>> Hello > > >>>>> > > >>>>> Great news! Is this branch already available in Karaf's git repo? > > >>>>> > > >>>>> regards and stay safe! > > >>>>> Grzegorz Grzybek > > >>>>> > > >>>>> śr., 4 lis 2020 o 05:59 Jean-Baptiste Onofre > > >>>> napisał(a): > > >>>>> > > >>>>>> Hi guys, > > >>>>>> > > >>>>>> François and I started to think about Karaf 5 and give an even > > modern > > >>>>>> flavor to Karaf, including potentially lot of refactoring and > > changes. > > >>>> We > > >>>>>> think it’s a must have in our patch to the "main modulith > runtime". > > >>>>>> > > >>>>>> Before sharing all details (some have been shared during my talk > at > > >>>>>> ApacheCon), we want to move forward on a PoC branch. > > >>>>>> > > >>>>>> However, we would love to have your inputs and thoughts (think > wide > > >> ;)). > > >>>>>> > > >>>>>> So, please, if you have ideas, comments, criticism ;), send me an > > >> email > > >>>>>> and I will reply and eventually include your points in the PoC. > > >>>>>> > > >>>>>> Thanks ! > > >>>>>> Regards > > >>>>>> JB > > >>>> > > >>>> > > >> > > >> > > > > >
Re: [VOTE] Apache Winegrower 1.0.0 release
+1, thanks a lot! Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le ven. 30 oct. 2020 à 09:08, Francois Papon a écrit : > +1 (binding) > > regards, > > François > fpa...@apache.org > > Le 30/10/2020 à 08:00, Jean-Baptiste Onofre a écrit : > > Hi everyone, > > > > I submit Winegrower 1.0.0 to your vote. This is the first Winegrower > release, bootstrapping the project. > > > > We know that some works have to be done on the documentation and example > fronts, but this release is fully usable and provide a concrete alternative > to existing framework. > > As for Karaf 4.3.0, I’m preparing a blog post about Winegrower. > > > > Staging Repository: > > https://repository.apache.org/content/repositories/orgapachekaraf-1150/ > <https://repository.apache.org/content/repositories/orgapachekaraf-1150/> > > > > Staging Dist: > > https://dist.apache.org/repos/dist/dev/karaf/winegrower/1.0.0/ < > https://dist.apache.org/repos/dist/dev/karaf/winegrower/1.0.0/> > > > > Please vote to approve this release: > > > > [ ] +1 Approve the release > > [ ] -1 Don't approve the release (please provide specific comments) > > > > This vote will be open for at least 72 hours. > > > > Regards > > JB > > > > >
Re: [VOTE] Apache Karaf (runtime) 4.3.0 release
+1, thanks a lot JB Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le lun. 26 oct. 2020 à 17:22, Jean-Baptiste Onofre a écrit : > Hi guys, > > After several weeks of work, I’m happy to submit Apache Karaf (runtime) > 4.3.0 release to your vote. > > I’m preparing a blog post for some details. Here’s a highlight of some key > points: > > - OSGi R7 > - JDK 11+ > - JSON configuration format support > - Better features definition (using requirements/capabilities) > - BoM to simplify your dependencies > - and bunch of dependencies updates and bug fixes > > Release Notes: > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12343304 > < > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12343304 > > > > Staging Repository: > https://repository.apache.org/content/repositories/orgapachekaraf-1149/ < > https://repository.apache.org/content/repositories/orgapachekaraf-1149/> > > Staging Dist: > https://dist.apache.org/repos/dist/dev/karaf/4.3.0 < > https://dist.apache.org/repos/dist/dev/karaf/4.3.0> > > Git tag: > karaf-4.3.0 > > Please vote to approve this release: > > [ ] +1 Approve the release > [ ] -1 Don't approve the release (please provide specific comments) > > This vote will be open for at least 72 hours. > > Thanks, > Regards > JB
Re: Apache Karaf 4.3.0 release on the fly
Great news, R7 really makes OSGi fresher compared to R6! Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le sam. 24 oct. 2020 à 09:40, Francois Papon a écrit : > Great news! > > Thanks JB! > > regards, > > François > fpa...@apache.org > > Le 24/10/2020 à 08:31, Jean-Baptiste Onofre a écrit : > > Hi, > > > > Karaf 4.3.0 is now ready for vote. > > > > I’m cutting the release, I will send the vote email during the weekend. > > > > Regards > > JB >
Re: Features resolver investigation for 4.3.0 and 4.2.11
Thought that as well but camel, cxf, jaxrs whiteboard etc are other examples where order is importantbut the symbolic names should be sufficient to guarantee a good order in most cases too Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le ven. 16 oct. 2020 à 10:24, Jean-Baptiste Onofre a écrit : > Yeah, agree that it’s weird to not have seen before ;) > > My guess is that people maybe have more "splitter/dynamic" features than > "our" scenario (even if it’s a valid one) and also have super fast machine. > Here, the application "imposes" a startup order which is not the case in > pure OSGi (by design, it’s dynamic, so it can react later). > > So, I’m pretty sure, it’s not really a problem with "dynamic ready" > modules. Here’s we identified the issue due to SpiFly and CDI. > > Don’t get my wrong, it should be improved, but not a big deal for OSGi > designed module. > > Regards > JB > > > Le 16 oct. 2020 à 07:30, Romain Manni-Bucau a > écrit : > > > > To try to help on the different points you mention: > > > > 1.a prerequisite is good when you have two stagings - order to respect > to > > install a full feature - so it is a very rare and limited case (in my > app I > > have 5 for ex) > > 1.b requirements doesn't help with the order (until a framework > extension), > > just with "start" which fails so you can still have a bundle starting and > > not having some dependency so at the end order is still required > > 2. the comparator is not sufficient by itself, all the Set and Map are > not > > sorted in karaf featureservice/felix resolver so they also break the > order > > > > So at the end I think the order is a requirement of the features - but > > still amazed it didnt pop up before. > > > > Romain Manni-Bucau > > @rmannibucau <https://twitter.com/rmannibucau> | Blog > > <https://rmannibucau.metawerx.net/> | Old Blog > > <http://rmannibucau.wordpress.com> | Github < > https://github.com/rmannibucau> | > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book > > < > https://www.packtpub.com/application-development/java-ee-8-high-performance > > > > > > > > Le ven. 16 oct. 2020 à 05:59, Jean-Baptiste Onofre a > > écrit : > > > >> The comparator based on symbolic name is to have something deterministic > >> but doesn’t necessary match. > >> I would like to check If using requirement in a feature would help (I’m > >> afraid it would block the installation but not guarantee the order > though). > >> > >> So, I think it’s worth to evaluate/improve the comparator to have > >> something more "user logic". > >> > >> I will create a Jira and check different scenario. > >> > >> Regards > >> JB > >> > >>> Le 15 oct. 2020 à 17:43, Łukasz Dywicki a écrit > : > >>> > >>> What you say makes a lot of sense. I was just refering to behavior > which > >>> I think is there since new resolver come into play. > >>> Making it a bit more deterministic is definitely fair (yet expensive in > >>> debugging) point to take. > >>> > >>> Cheers, > >>> Łukasz > >>> > >>> > >>> On 15.10.2020 17:32, Romain Manni-Bucau wrote: > >>>> Fact is if features are not installed in reversed graph order it is > not > >>>> really reliable an you can't install an app and be sure it will work, > >> even > >>>> if you sorted manually the bundles. > >>>> The ResourceComparator sorts by symbolic names which makes the > >> deployment > >>>> deterministic but potentially random from an user perspective > >>>> (uncontrollable). > >>>> Then the featureservice+resolve use a list of hashmap (or hashset) > which > >>>> also randomizes the installation. > >>>> Guess using at least a reversed dijkstra distance (or tree deepness in > >> some > >>>> simple cases) from the feature to sort bundles installation order is > >> worth > >>>> it to make it more natural and controlled for end users. > >>>> > >>>>
Re: Features resolver investigation for 4.3.0 and 4.2.11
To try to help on the different points you mention: 1.a prerequisite is good when you have two stagings - order to respect to install a full feature - so it is a very rare and limited case (in my app I have 5 for ex) 1.b requirements doesn't help with the order (until a framework extension), just with "start" which fails so you can still have a bundle starting and not having some dependency so at the end order is still required 2. the comparator is not sufficient by itself, all the Set and Map are not sorted in karaf featureservice/felix resolver so they also break the order So at the end I think the order is a requirement of the features - but still amazed it didnt pop up before. Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le ven. 16 oct. 2020 à 05:59, Jean-Baptiste Onofre a écrit : > The comparator based on symbolic name is to have something deterministic > but doesn’t necessary match. > I would like to check If using requirement in a feature would help (I’m > afraid it would block the installation but not guarantee the order though). > > So, I think it’s worth to evaluate/improve the comparator to have > something more "user logic". > > I will create a Jira and check different scenario. > > Regards > JB > > > Le 15 oct. 2020 à 17:43, Łukasz Dywicki a écrit : > > > > What you say makes a lot of sense. I was just refering to behavior which > > I think is there since new resolver come into play. > > Making it a bit more deterministic is definitely fair (yet expensive in > > debugging) point to take. > > > > Cheers, > > Łukasz > > > > > > On 15.10.2020 17:32, Romain Manni-Bucau wrote: > >> Fact is if features are not installed in reversed graph order it is not > >> really reliable an you can't install an app and be sure it will work, > even > >> if you sorted manually the bundles. > >> The ResourceComparator sorts by symbolic names which makes the > deployment > >> deterministic but potentially random from an user perspective > >> (uncontrollable). > >> Then the featureservice+resolve use a list of hashmap (or hashset) which > >> also randomizes the installation. > >> Guess using at least a reversed dijkstra distance (or tree deepness in > some > >> simple cases) from the feature to sort bundles installation order is > worth > >> it to make it more natural and controlled for end users. > >> > >> Hope it makes sense. > >> > >> Romain Manni-Bucau > >> @rmannibucau <https://twitter.com/rmannibucau> | Blog > >> <https://rmannibucau.metawerx.net/> | Old Blog > >> <http://rmannibucau.wordpress.com> | Github < > https://github.com/rmannibucau> | > >> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book > >> < > https://www.packtpub.com/application-development/java-ee-8-high-performance > > > >> > >> > >> Le jeu. 15 oct. 2020 à 17:28, Łukasz Dywicki a > écrit : > >> > >>> I am not sure if that's feature resolver issue. It is rather related to > >>> bundle resolver which determines installation order. > >>> As far I remember from my last debugging session in this area bundles > >>> are installed in computed "dependency" order. It might be that leaf/1 > >>> has no direct dependencies on any of its children hence it is installed > >>> first. > >>> Note, that I don't know details on how present feature resolution works > >>> and if its just supplier for graph elements or separate graph computed > >>> by same algorithm as bundles. > >>> > >>> Best, > >>> Łukasz > >>> > >>> > >>> On 15.10.2020 15:47, Jean-Baptiste Onofre wrote: > >>>> Hi guys, > >>>> > >>>> Romain found an issue on the feature resolver about the features > >>> ordering. > >>>> > >>>> For instance, if we have the following features descriptor: > >>>> > >>>> > >>>> > >>>>mvn:foo/nested1/2 > >>>> > >>>> > >>>>mvn:foo/nested21/3 > >>>> > >>>> > >>>>
Re: Features resolver investigation for 4.3.0 and 4.2.11
Fact is if features are not installed in reversed graph order it is not really reliable an you can't install an app and be sure it will work, even if you sorted manually the bundles. The ResourceComparator sorts by symbolic names which makes the deployment deterministic but potentially random from an user perspective (uncontrollable). Then the featureservice+resolve use a list of hashmap (or hashset) which also randomizes the installation. Guess using at least a reversed dijkstra distance (or tree deepness in some simple cases) from the feature to sort bundles installation order is worth it to make it more natural and controlled for end users. Hope it makes sense. Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le jeu. 15 oct. 2020 à 17:28, Łukasz Dywicki a écrit : > I am not sure if that's feature resolver issue. It is rather related to > bundle resolver which determines installation order. > As far I remember from my last debugging session in this area bundles > are installed in computed "dependency" order. It might be that leaf/1 > has no direct dependencies on any of its children hence it is installed > first. > Note, that I don't know details on how present feature resolution works > and if its just supplier for graph elements or separate graph computed > by same algorithm as bundles. > > Best, > Łukasz > > > On 15.10.2020 15:47, Jean-Baptiste Onofre wrote: > > Hi guys, > > > > Romain found an issue on the feature resolver about the features > ordering. > > > > For instance, if we have the following features descriptor: > > > > > > > > mvn:foo/nested1/2 > > > > > > mvn:foo/nested21/3 > > > > > > nested21 > > mvn:foo/nested2/2 > > > > > > nested1 > > nested2 > > mvn:foo/leaf/1 > > > > > > > > When installing leaf feature, we expect the following order (for bundles > installation): > > 1. foo/nested1/2 bundle (nested1 feature) > > 2. foo/nested21/3 bundle (nested21 feature) > > 3. foo/nested2/2 bundle (nested2 feature) > > 4. foo/leaf/1 bundle (leaf feature) > > > > However, the order is not this one. During test, we saw that the order > is mvn:foo/leaf/1, mvn:foo/nested1/2, mvn:foo/nested21/3, mvn:foo/nested2/2. > > > > We can see that the leaf bundle is installed before the bundles from > inner/transitive features. > > > > I would like to investigate this behavior and improve this (I would like > to check if it’s also the case in previous versions). > > > > As the target of Karaf 4.3.0 is this week end, I would take some time to > check and compare. > > > > I will keep you posted. > > > > Regards > > JB > > >
Re: More often releases/back on regular pace
Hi JB, Think one key point for this ambition is to be able to ensure releases don't depend on a single man (whatever his quality is ;)). Checking on apache index it seems around 3-4 PMC are active (I can be wrong since I don't follow the list accurately from very long so happy if it is more), what about having planned (each two months?) releases and rotating in the PMC for the releases? The big advantage is that it enables fallbacks when needed and avoids to put pressure on a single man which is also a positive sign community wide and for the project IMHO. It can also enable to highlight that some points can be too hard and needs some love (not sure if accurate but thinking out loud it can be to split the repo in smaller ones to make releases easier, to make the build parallelizable, to automate dist upload, to automate site update with a "main" or script, etc...). Hope it makes some sense. Just my 2cts indeed. Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le mer. 7 oct. 2020 à 06:13, Jean-Baptiste Onofre a écrit : > Hi guys, > > I would like to be back on more regular/stable release cycle for Karaf. > Again, I was a little bit too ambitious in release content and it means > that releases have been postponed several times. > That’s not good and we should have some more stable/regular: my bad. > > So, now, the release should be more driven by time more than content. > Starting from now, I will try to keep regular releases. > It’s very important in the new Karaf direction, given the opportunity to > include more regularly coming features. > > Thanks, > Regards > JB
Re: Winegrower milestone?
Up? Know you didnt write which monday but think it is time ;) Le mer. 1 juil. 2020 à 10:10, Francois Papon a écrit : > +1 > > regards, > > François > fpa...@apache.org > > Le 01/07/2020 à 10:08, Romain Manni-Bucau a écrit : > > +1 > > > > Romain Manni-Bucau > > @rmannibucau <https://twitter.com/rmannibucau> | Blog > > <https://rmannibucau.metawerx.net/> | Old Blog > > <http://rmannibucau.wordpress.com> | Github < > https://github.com/rmannibucau> | > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book > > < > https://www.packtpub.com/application-development/java-ee-8-high-performance > > > > > > > > Le mer. 1 juil. 2020 à 09:50, Jean-Baptiste Onofre a > > écrit : > > > >> Hi, > >> > >> As discussed together yesterday, I plan to add couple of new samples > (with > >> blog/documentation) and cepages for the end of this week. > >> > >> Then, I will submit a Winegrower 1.0 release to vote (probably on > Monday). > >> > >> Thoughts ? > >> > >> Regards > >> JB > >> > >>> Le 1 juil. 2020 à 08:55, Romain Manni-Bucau a > >> écrit : > >>> Hi everyone, > >>> > >>> wonder if we could get a winegrower milestone - kind of preview > release. > >>> there are several use cases it already makes sense even if OSGi support > >> is > >>> partial and it eases a lot the testing, cloud delivery and JVM boot > >>> optimization (CDS or graal support which is simpler than with a native > >> OSGi > >>> container) so I think it makes sense to let it go out with a "not yet > >>> final" flag. > >>> > >>> wdyt? > >>> > >>> Romain Manni-Bucau > >>> @rmannibucau <https://twitter.com/rmannibucau> | Blog > >>> <https://rmannibucau.metawerx.net/> | Old Blog > >>> <http://rmannibucau.wordpress.com> | Github < > >> https://github.com/rmannibucau> | > >>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book > >>> < > >> > https://www.packtpub.com/application-development/java-ee-8-high-performance > >> >
Re: [HEADS UP] Docker friendly runtime with env variables compliant configuration
Looks good to me
@Steinar: it is in the PR (see System.getenv part ;))
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>
Le mer. 30 sept. 2020 à 11:44, Steinar Bang a écrit :
> >>>>> Jean-Baptiste Onofre :
>
> > Hi,
> > In this PR: https://github.com/apache/karaf/pull/1206 <
> https://github.com/apache/karaf/pull/1206>
>
> > I have implemented the interpolation.
>
> > It means that you can use the following for instance:
>
> > export
> ORG_APACHE_KARAF_FEATURES_FEATURESREPOSITORIES='${featuresRepositories},mvn:org.apache.karaf.decanter/apache-karaf-decanter/2.5.0/xml/features'
>
> > Does it look good to you ?
>
> Yes. :-)
>
> But we also need a ORG_APACHE_KARAF_FEATURES_FEATURESBOOT (as Romain
> Manni-Bucau mentioned)
>
>
Re: [HEADS UP] Docker friendly runtime with env variables compliant configuration
An interesting update your feature request makes me think about is to copy
the original value in .original and then let the new value reuse this.
Example (using env format assuming it is not interpolated/does not require
escaping where set):
ORG_APACHE_KARAF_FEATURES_FEATURESREPOSITORIES=mvn:my/repo/1.0/xml/features,${featuresRepositories.original}
ORG_APACHE_KARAF_FEATURES_FEATURESBOOT=${featuresBoot.original},my-feature
Guess it just needs to
call org.apache.felix.utils.properties.InterpolationHelper#performSubstitution
on the new properties then drop the additional ones.
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>
Le mar. 29 sept. 2020 à 18:07, Steinar Bang a écrit :
> >>>>> Jean-Baptiste Onofre :
>
> > Thoughts ?
>
> Not directly environment variable releated, but one thing I would like
> to see, is a simple way to add one or more feature repositories, and to
> add one or more features to the boot set.
>
> That's what I've done in my karaf based docker images.
>
> I've done it by copying in org.apache.karaf.features.cfg from a karaf
> distro and adding the feature repositories to featuresRepositories and
> the features to featuresBoot.
>
> That works great!
>
> But as you may remember: switching the karaf version and copying in the
> org.apache.karaf.features.cfg from an old karaf version can have strange
> results.
>
>
Re: [HEADS UP] Docker friendly runtime with env variables compliant configuration
LGTM now, thanks for the work!
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>
Le mar. 29 sept. 2020 à 08:10, Jean-Baptiste Onofre a
écrit :
> Done, I’m doing a full test.
>
> Regards
> JB
>
> > Le 29 sept. 2020 à 07:59, Romain Manni-Bucau a
> écrit :
> >
> > Hi JB,
> >
> > for the env part it looks exactly what I would expect but for system
> > properties I wouldnt normalize the key (uppercase+replace dots by
> > underscrores), it should just be "pid + "." + key" I think. Normalization
> > is not only to look like common practise but also cause dots are not
> > accepted in env var IIRC. Since it is not the case for system props, no
> > reason to apply that transformation IMHO.
> > Last small note is that env should win over system properties so second
> > "if" should be preceeded by an "else" IMHO.
> >
> > Hope it makes sense.
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> | Blog
> > <https://rmannibucau.metawerx.net/> | Old Blog
> > <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
> >
> >
> > Le mar. 29 sept. 2020 à 07:16, Jean-Baptiste Onofre a
> > écrit :
> >
> >> By the way, ConfigurationPlugin is R7 so Karaf 4.3.x.
> >>
> >> For Karaf 4.2.x, I will use the ${env} notation in cfg files using the
> >> same var names as working on 4.3.
> >>
> >> Regards
> >> JB
> >>
> >>> Le 29 sept. 2020 à 05:56, Jean-Baptiste Onofre a
> >> écrit :
> >>>
> >>> Hi,
> >>>
> >>> I’ve updated the PR to use ConfigurationPlugin.
> >>>
> >>> NB: when using ConfigurationPlugin, if you use
> >> configuration.getProperties() you will have the default values (not
> >> interpolated). To get the actual property values, you have to use
> >> configuration.getProcessedProperties(). With
> >> configuration.getProcessedProperties(), you will the interpolated value.
> >>> In order to avoid to confuse users, I also updated configRepository and
> >> config:* commands to use getProcessedProperties() by default.
> >>>
> >>> I’m doing a pass on other Karaf modules.
> >>>
> >>> Regards
> >>> JB
> >>>
> >>>> Le 28 sept. 2020 à 11:39, Romain Manni-Bucau
> a
> >> écrit :
> >>>>
> >>>> +1, I'd try to push for a built-in support -
> >>>> (.).toUpperCase(ROOT).replace('.', '_') - to make
> it
> >>>> generic and not specific to some entries. It would also enable to not
> >> have
> >>>> to rename these env variables or have to maintain some fallbacks.
> >>>> What about just implementing a felix config admin configuration
> plugin?
> >>>> sounds less invasive and better on the long run? Did you give it a
> try?
> >>>>
> >>>> Romain Manni-Bucau
> >>>> @rmannibucau <https://twitter.com/rmannibucau <
> >> https://twitter.com/rmannibucau>> | Blog
> >>>> <https://rmannibucau.metawerx.net/ <https://rmannibucau.metawerx.net/
> >>
> >> | Old Blog
> >>>> <http://rmannibucau.wordpress.com <http://rmannibucau.wordpress.com/
> >>
> >> | Github <https://github.com/rmannibucau <
> https://github.com/rmannibucau>>
> >> |
> >>>> LinkedIn <https://www.linkedin.com/in/rmannibucau <
> >> https://www.linkedin.com/in/rmannibucau>> | Book
> >>>> <
> >>
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >> <
> >>
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >>>>
> >>>>
> >>>>
> >>>> Le lun. 28 sept. 2020 à 11:12, Jean-Baptiste Onofre >> <mailto:j...@nanthrax.net>> a
> >>>> écrit :
> >>>>
> >>>>> Fair
Re: [HEADS UP] Docker friendly runtime with env variables compliant configuration
Hi JB,
for the env part it looks exactly what I would expect but for system
properties I wouldnt normalize the key (uppercase+replace dots by
underscrores), it should just be "pid + "." + key" I think. Normalization
is not only to look like common practise but also cause dots are not
accepted in env var IIRC. Since it is not the case for system props, no
reason to apply that transformation IMHO.
Last small note is that env should win over system properties so second
"if" should be preceeded by an "else" IMHO.
Hope it makes sense.
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>
Le mar. 29 sept. 2020 à 07:16, Jean-Baptiste Onofre a
écrit :
> By the way, ConfigurationPlugin is R7 so Karaf 4.3.x.
>
> For Karaf 4.2.x, I will use the ${env} notation in cfg files using the
> same var names as working on 4.3.
>
> Regards
> JB
>
> > Le 29 sept. 2020 à 05:56, Jean-Baptiste Onofre a
> écrit :
> >
> > Hi,
> >
> > I’ve updated the PR to use ConfigurationPlugin.
> >
> > NB: when using ConfigurationPlugin, if you use
> configuration.getProperties() you will have the default values (not
> interpolated). To get the actual property values, you have to use
> configuration.getProcessedProperties(). With
> configuration.getProcessedProperties(), you will the interpolated value.
> > In order to avoid to confuse users, I also updated configRepository and
> config:* commands to use getProcessedProperties() by default.
> >
> > I’m doing a pass on other Karaf modules.
> >
> > Regards
> > JB
> >
> >> Le 28 sept. 2020 à 11:39, Romain Manni-Bucau a
> écrit :
> >>
> >> +1, I'd try to push for a built-in support -
> >> (.).toUpperCase(ROOT).replace('.', '_') - to make it
> >> generic and not specific to some entries. It would also enable to not
> have
> >> to rename these env variables or have to maintain some fallbacks.
> >> What about just implementing a felix config admin configuration plugin?
> >> sounds less invasive and better on the long run? Did you give it a try?
> >>
> >> Romain Manni-Bucau
> >> @rmannibucau <https://twitter.com/rmannibucau <
> https://twitter.com/rmannibucau>> | Blog
> >> <https://rmannibucau.metawerx.net/ <https://rmannibucau.metawerx.net/>>
> | Old Blog
> >> <http://rmannibucau.wordpress.com <http://rmannibucau.wordpress.com/>>
> | Github <https://github.com/rmannibucau <https://github.com/rmannibucau>>
> |
> >> LinkedIn <https://www.linkedin.com/in/rmannibucau <
> https://www.linkedin.com/in/rmannibucau>> | Book
> >> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >>
> >>
> >>
> >> Le lun. 28 sept. 2020 à 11:12, Jean-Baptiste Onofre <mailto:j...@nanthrax.net>> a
> >> écrit :
> >>
> >>> Fair enough (and I agree ;)).
> >>>
> >>> Regards
> >>> JB
> >>>
> >>>> Le 28 sept. 2020 à 11:09, Grzegorz Grzybek a
> >>> écrit :
> >>>>
> >>>> I'd stick to explicit approach for now and leave "implicit" one for
> >>> later ;)
> >>>>
> >>>> regards
> >>>> Grzegorz Grzybek
> >>>>
> >>>> pon., 28 wrz 2020 o 11:08 Jean-Baptiste Onofre <mailto:j...@nanthrax.net> >>> j...@nanthrax.net <mailto:j...@nanthrax.net>>> napisał(a):
> >>>>
> >>>>> Just to be clear: today I’m using an "explicit" approach, where the
> >>> config
> >>>>> contains something like:
> >>>>>
> >>>>> sshPort=${env:KARAF_SSH_PORT:-8101}
> >>>>>
> >>>>> But we can also have "implicit" approach (with some more changes
> >>> required).
> >>>>>
> >>>>> Regards
> >>>>> JB
> >>>>>
> >>>>>> Le 28 sept. 2020 à 11:07, Jean-Baptiste Onofre <mailto:j...@nanthrax.net>> a
> >>>>> écrit :
> >>>>>>
> >>>>>> H
Re: [HEADS UP] Docker friendly runtime with env variables compliant configuration
+1, I'd try to push for a built-in support -
(.).toUpperCase(ROOT).replace('.', '_') - to make it
generic and not specific to some entries. It would also enable to not have
to rename these env variables or have to maintain some fallbacks.
What about just implementing a felix config admin configuration plugin?
sounds less invasive and better on the long run? Did you give it a try?
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>
Le lun. 28 sept. 2020 à 11:12, Jean-Baptiste Onofre a
écrit :
> Fair enough (and I agree ;)).
>
> Regards
> JB
>
> > Le 28 sept. 2020 à 11:09, Grzegorz Grzybek a
> écrit :
> >
> > I'd stick to explicit approach for now and leave "implicit" one for
> later ;)
> >
> > regards
> > Grzegorz Grzybek
> >
> > pon., 28 wrz 2020 o 11:08 Jean-Baptiste Onofre j...@nanthrax.net>> napisał(a):
> >
> >> Just to be clear: today I’m using an "explicit" approach, where the
> config
> >> contains something like:
> >>
> >> sshPort=${env:KARAF_SSH_PORT:-8101}
> >>
> >> But we can also have "implicit" approach (with some more changes
> required).
> >>
> >> Regards
> >> JB
> >>
> >>> Le 28 sept. 2020 à 11:07, Jean-Baptiste Onofre a
> >> écrit :
> >>>
> >>> Hi,
> >>>
> >>> At beginning, I did a very simple change in Karaf Main: for instance,
> >> you would be able to do
> >>>
> >>> Bin/karaf -Dpid:prop=value
> >>>
> >>> And I init the configuration file with the value.
> >>>
> >>> However, system properties are not super easy with docker.
> >>>
> >>> That’s why I preferred the env variable approach.
> >>>
> >>> Now, about env variable, I just leverage what we already have in Karaf
> >> (just updating the default configuration file).
> >>>
> >>> I can do a new iteration where (in configadmin repository), I’m
> checking
> >> ALL env variables to find one matching.
> >>> It would mean something like:
> >>>
> >>> $ export KARAF.MY_PID.prop=value
> >>>
> >>> For instance.
> >>>
> >>> We would need a "env variable format".
> >>>
> >>> Thoughts ?
> >>>
> >>> Regards
> >>> JB
> >>>
> >>>> Le 28 sept. 2020 à 10:59, Grzegorz Grzybek >> <mailto:gr.grzy...@gmail.com <mailto:gr.grzy...@gmail.com>>> a écrit :
> >>>>
> >>>> Hello
> >>>>
> >>>> Good idea!
> >>>>
> >>>> Shouldn't configadmin do it by default?
> >>>>
> >>>> Like dissect "KARAF_SSH_PORT" or similar env variables into:
> >>>> - prefix (KARAF_) - rejected
> >>>> - PID pointer (e.g., SSH → org.apache.karaf.shell)
> >>>> - property (e.g PORT → sshPort)
> >>>> ?
> >>>>
> >>>> This way it could be done in one place... Just my random observation,
> >>>> because I can't dig this problem further for now ;)
> >>>>
> >>>> regards
> >>>> Grzegorz Grzybek
> >>>>
> >>>> pon., 28 wrz 2020 o 10:51 Jean-Baptiste Onofre <mailto:j...@nanthrax.net>
> >> <mailto:j...@nanthrax.net <mailto:j...@nanthrax.net>> j...@nanthrax.net <mailto:j...@nanthrax.net> <mailto:j...@nanthrax.net
> j...@nanthrax.net>>>>
> >> napisał(a):
> >>>>
> >>>>> Hi guys,
> >>>>>
> >>>>> In order to easily use Karaf in docker container, I created the
> >> following
> >>>>> PR:
> >>>>>
> >>>>> https://github.com/apache/karaf/pull/1203 <
> https://github.com/apache/karaf/pull/1203> <
> >> https://github.com/apache/karaf/pull/1203 <
> https://github.com/apache/karaf/pull/1203>> <
> >> https://github.com/apache/karaf/pull/1203 <
> https://github.com/apache/karaf/pull/1203> <
> >> https://github.com/apache/karaf/pull/1203 <
> https://github.com/apache/karaf/pull/1203>>>
Re: Apache Karaf runtime 4.3.0 - Decision taken
+1, thanks to the spec usage the upgrade should be smooth anyway and not
even a "major" of karaf IMO.
Also very happy to not go directly to felix http which is a great impl of
the spec but does not support some pure servlet features as pax does which
is a big drawback IMO for users.
Good decision!
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>
Le lun. 7 sept. 2020 à 08:49, Achim Nierbeck
a écrit :
> Hi,
>
> I fully support the decision to go for 7.3.x for now.
> I'm also fully aware of the work Greg did to Pax Web and what it needs to
> get finished :)
> So from my point of view, this is the best we as a community can do right
> now.
> I wish I would be able to help Greg more than I did.
> So nobody is to blame here, sometimes we have to face the facts :)
>
> regards, Achim
>
> Am Sa., 5. Sept. 2020 um 18:57 Uhr schrieb Francois Papon <
> francois.pa...@openobject.fr>:
>
> > Hi guys,
> >
> > Nobody has to be blame.
> >
> > All this project are community projects and all contributions are
> > important.
> >
> > Thanks for all the great work made on PaxWeb!
> >
> > regards,
> >
> > François
> > fpa...@apache.org
> >
> > Le 05/09/2020 à 05:57, Jean-Baptiste Onofre a écrit :
> > > Hi Grzegorz
> > >
> > > Thanks for all the details.
> > >
> > > And don’t get me wrong: I don’t blame anyone and there’s no worry at
> all
> > !
> > >
> > > The purpose is just to move forward on 4.3.0.
> > >
> > > So, after a long thinking, Karaf 4.3.0 with Pax Web 7.3.x is the
> smarter
> > and reliable move IMHO.
> > > We will update to Pax Web 8 when ready.
> > >
> > > Thanks again for all your effort in Pax Web 8 and your great work.
> > > I also take part of the blame to not have helped you more (it’s gonna
> > change, promise).
> > >
> > > Regards
> > > JB
> > >
> > >> Le 4 sept. 2020 à 18:51, Grzegorz Grzybek a
> > écrit :
> > >>
> > >> Hello
> > >>
> > >> I'm the one responsible for the delay of Pax Web 8, but also (to
> > >> counterweight the blame), I'm the one who picked up the master branch
> > and
> > >> tried to refactor it the way I did with Pax Logging ;)
> > >>
> > >> As we know, felix-http is a great OSGi CMPN R7 Whiteboard (and Http
> > >> Service) implementation where everything is implemented in a single
> > >> "dispatcher servlet" added to single Jetty's ServletContextHandler.
> > >> On the other hand, Pax Web is waaay more (WARs, JSPs, "mapping"
> > >> whiteboard, welcome files, etc.).
> > >>
> > >> My initial goal about "refactor Pax Web" was actually
> > >> https://ops4j1.jira.com/browse/PAXWEB-1123 ("HTTP Whiteboard and
> > selection
> > >> of the ServletContextHelper") - what could possibly go wrong? :) When
> I
> > >> checked how Pax Web 7.x (and current master branch) handles
> "contexts",
> > >> after a few months of looking/reading at the code (started April
> 2019!)
> > I
> > >> decided to refactor the core model of Pax Web, where each web
> "element"
> > may
> > >> be associated with one or MORE "osgi contexts" which in turn point to
> a
> > >> single "servlet context" (in N:1) relation.
> > >>
> > >> I described the design in
> > >>
> >
> http://karaf.922171.n3.nabble.com/Fwd-PAX-WEB-State-of-Pax-Web-8-td4058782.html
> > >>
> > >> So, the actual Whiteboard spec compliance is almost done and it was
> very
> > >> deep refactoring indeed (I tried to preserve the great work of others)
> > and
> > >> these standard bits are missing:
> > >> - tests for preprocessors (because the machinery is already there)
> > >> - tests for changing registration properties of ServletContextHelper
> > OSGi
> > >> service
> > >> - per ServletContextHelper session handling
> > >>
> > >> So we're very close to felix-http.
> > >>
> > >> The problem is that because I refactored the "core&
Re: [HEADS UP] Releases schedule: 4.2.10, 4.3.0.RC2, Winegrower 1.0
Hi Greg, AFAIK there is no "bye bye" ;). ServletContainerInitializer are not in he whiteboard so you make them behave as you want and any servlet container has 2 impl of the servlet context, one for SCI and one for the runtime (where most registration methods throw exceptions). So it means pax-web can keep being whiteboard++ (ie whiteboard + SCI) by having these 2 (sadly custom) impl too and rewire it to the runtime properly. I fear you will need to do as for http felix impl - ie a filter chain dispatcher - but this is not crazy and solves all the issues you mentionned enabling to have all the desired features. Indeed, pax wouldnt 1-1 delegate to the servlet container but it would be http whiteboard compatible and still support JSF, JSP, etc.. Hope it makes sense. Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le lun. 31 août 2020 à 08:29, Jean-Baptiste Onofre a écrit : > Hi Grzegorz > > Enjoy your vacation, and thanks for the update about Pax Web 8. > > Waiting for your return, let me try to move forward on JSP/JSF support. > > I will keep you posted. > > Regards > JB > > > Le 31 août 2020 à 08:24, Grzegorz Grzybek a > écrit : > > > > Hello > > > > I'm on PTO till Tuesday, I'm back to work on Sep 2nd. > > > > About Pax Web 8 - indeed, I don't want to hold Karaf 4.3.0 any longer. > > Whiteboard pattern is actually ready (everything defined in Whiteboard > spec > > is in place except tests for Preprocessors and per-context session > > handling). The problem is that what Pax Web 7 already had is still > missing. > > > > Long story short - Pax Web 7 handled ServletContainerInitializers well > and > > it's the fundamental thing to handle JSPs and JSFs. But what I had to > > change for Whiteboard compliance is actually a bit incompatible with > those > > customizers (most importantly - dynamic "ServletContext.addServlet()" > > according to Whiteboard specification should throw > > UnsupportedOperationException - so bye bye JSFs). > > > > I already have an idea how to "fix" this, but this will again delay Pax > Web > > 8 a bit. > > > > regards > > Grzegorz Grzybek > > > > pon., 31 sie 2020 o 06:19 Jean-Baptiste Onofre > napisał(a): > > > >> Hi guys, > >> > >> A quick update about the releases schedule. > >> > >> For both Karaf runtime 4.2.10 and 4.3.0.RC2, I have some dependency > >> releases in progress (Felix FileInstall, Pax Exam, etc). > >> I will submit these releases to vote this week. > >> > >> About 4.3.0.RC2 specifically, I will ping Greg today to see where we are > >> on Pax Web 8.0 and help him on that. > >> As I don’t want to hold 4.3.0 GA too much, we will evaluate a new time > the > >> effort for Pax Web 8.0 and eventually define Felix Jetty as default > >> (temporary). > >> > >> About Winegrower 1.0, I have several updates ready (I just have to > create > >> the PRs), a couple of new cepages to add. So the 1.0 release will be in > >> vote during this week. > >> > >> Regards > >> JB > >> > >>> Le 20 août 2020 à 15:23, Jean-Baptiste Onofre a > écrit > >> : > >>> > >>> Hi guys, > >>> > >>> As we are getting close to Pax Web 8.0, I think it’s the good timing to > >> release Karaf Runtime 4.3.0.RC2 with Pax Web 8.0-SNAPSHOT. > >>> It would give us time to move forward on 4.3.0 later faster. > >>> > >>> Karaf 4.3.0 is blocked by Pax Web for too long now, so, let’s move > >> forward at least on RC2. > >>> > >>> On the other hand, Karaf 4.2.10 is in preparation, as well as > Winegrower > >> 1.0 (I’m working on cepages). > >>> > >>> I will send some updates about new coming features on which we are > >> working (spring boot support, devx, flat resolver, and so on). > >>> > >>> Regards > >>> JB > >> > >> > >
Re: [PROPOSAL] Renaming terms
+0, it will make some people feel better (not sure but what i read) and some other feel worse since it is 1-1 in terms of meaning and positive/negative sense. However it is a breaking change to be useful which hurts everyone so maybe an user vote is better than a dev one? Le lun. 27 juil. 2020 à 19:51, Jean-Baptiste Onofre a écrit : > No, I don’t think it’s accurate to Karaf. > > Standby means that the instance is not "active", but actually, in the case > of Karaf, it’s active and replicate the "master/active". > > That’s why I proposed primary/secondary. We can also use active/replica if > you think it’s more accurate. > > Regards > JB > > > Le 27 juil. 2020 à 18:26, Matt Pavlovich a écrit : > > > > My $0.02, the ‘primary’ ’secondary’ numeric-style terms can be > misleading, since you can have multiple ’slave’ nodes and lock recovery is > non-deterministic. So the ’secondary’ node doesn’t mean it is ’second’ in > line to take over. > > > > Thoughts on aligning with the proposed terms same as ActiveMQ? > > > > master -> ‘active’ > > slave -> ’standby' > > > > -Matt Pavlovich > > > >> On Jul 27, 2020, at 1:21 AM, Jean-Baptiste Onofre > wrote: > >> > >> Hi guys, > >> > >> I would like to propose new wording in some Karaf designs: > >> > >> - In Karaf runtime, I would like to rename master/slave to > primary/secondary > >> - in Cellar, I would like to rename blacklist/whitelist to allowlist > and deny list > >> > >> Thoughts ? > >> > >> Regards > >> JB > > > >
Re: [HEADS UP] Apache Karaf releases plan
Hi Mike, Since it is pluggable yes but the side notes are: 1. YAML generator/parsers are not consistent even if there is a kind of spec and it iq quite error prone (see all the mess around k8s and the wrapper to not manipulate yaml directly) 2. It is not a pure json AFAIK but an OSGi flavor with comments (not even the Johnzon built-in flavor - C-style - but a spec version) so good to stay aligned on the spec and felix IMO Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le mer. 22 juil. 2020 à 08:42, Mike Hummel a écrit : > Hello, > > it would be more common to use yaml instead of json for human readable > configurations... > > Is this an option? > > Best Regards, > > Mike > > > On 8. Jul 2020, at 08:49, Jean-Baptiste Onofre wrote: > > > > Hi, > > > > Yes, it’s feature support in json format. Inner parser is Johnson (but > pluggable). > > > > Regards > > JB > > > >> Le 8 juil. 2020 à 08:41, Steinar Bang a écrit : > >> > >> Thanks for the update, JB! > >> > >> Out of curiosity: What's "Features JSON"? Karaf features to pull in JSON > >> support? If so, which parser? Jackson? GSON? Something else...? > >> > >> Thanks! > >> > >> > >> - Steinar > >> > > > >
Re: [VOTE] Apache Karaf Cellar 4.2.0 release
+1 (non binding) Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le mer. 15 juil. 2020 à 07:22, Jean-Baptiste Onofre a écrit : > Hi everyone, > > I submit Apache Karaf Cellar 4.2.0 to your vote. > > This release is the first one on Cellar 4.2.x series. The > design/architecture is similar to Cellar 4.1.x with lot of fixes and > updates. > A complete refactoring is planned for Cellar 4.3.x. > > Release Notes: > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12344252 > < > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12344252 > > > > Staging Repository: > https://repository.apache.org/content/repositories/orgapachekaraf-1145/ < > https://repository.apache.org/content/repositories/orgapachekaraf-1145/> > > Staging dist: > https://dist.apache.org/repos/dist/dev/karaf/cellar/4.2.0/ < > https://dist.apache.org/repos/dist/dev/karaf/cellar/4.2.0/> > > Git tag: > cellar-4.2.0 > > Please vote to approve this release: > > [ ] +1 Approve the release > [ ] -1 Don't approve the release (please provide specific comments) > > This vote will be open for at least 72 hours. > > Thanks, > Regards > JB
Re: [DISCUSSION] Apache Karaf 4.3.0 and Pax Web
A few comments to previous answer - hoping it is not too "off track": 1. Advantage of tomcat (or more generally selecting the servlet container) is generally you share the tooling in the company. If you are a one software company then you don't care but if you industrialize and build a shared stack it is important to be able to select a particular impl to instrument this one particularly. 2. I didn't see anything in httpservice which can't be implemented on top of servlet - whatever impl - and always wondered why pax didn't pick to just integrate with the servlet layer. I know today it integrates lower level to be dynamic but it is trivial - and required in r7 - to be dynamic at whiteboard level and not container level (regex pattern out of my head) so can be a later refacto which can simplify pax web a lot since there is only one impl to maintain. Then it is just a matter of making servlet containers OSGi friendly (think tomcat is, jetty too, not sure for undertow). Hope I'm not too "off". Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le mar. 7 juil. 2020 à 13:43, Francois Papon a écrit : > Hi, > > I think the most important thing is to be more flexible for the releases > roadmap of Karaf. > > If it's possible, we need to avoid blockers from other projects and in > this case, it's not directly related to Karaf / R7. > > May be we could propose multiple alternative to the users to choose > their implementation of the http service and just provide a lightweight > impl by default. > > regards, > > François > fpa...@apache.org > > Le 07/07/2020 à 11:27, Jean-Baptiste Onofre a écrit : > > Hi, > > > > See my comment inline > > > >> Le 7 juil. 2020 à 11:22, Romain Manni-Bucau a > écrit : > >> > >> Hi JB, > >> > >> I see more issues using felix http: > >> > >> 1. it only supports felix today AFAIK which directly impacts the > production > >> since then your monitoring/observability/instrumentation can be to redo > so > >> for me it is way more impacting than the dev side - and more vicious > > Good point, we can have impact with Equinox, true. > > > >> 2. felix is a fatjar so you can't upgrade jetty when needed which is > also a > >> big loss compared to not having R7 IMHO > > That’s a discussion standpoint. Having a fat jar can be seen as a good > point as upgrading Jetty (or Tomcat, or undertow) is not always (never ;)) > "smooth" at Pax Web. > > > >> How far is paxweb from R7? Not being 100% compliant is fine IMO while: > >> a. it can be manually switched to a compliant impl if required > >> b. there is no regression from previous version > >> > > I think we are pretty close just for R7, but we also started a large > refactoring (maybe it was too "ambitious"). > > So, another approach would by to start from Pax Web 7.2.x and just > update the minimal set to R7 (new HTTP service). > > > > Regards > > JB > > > >> Indeed just my 2cts, > >> Romain Manni-Bucau > >> @rmannibucau <https://twitter.com/rmannibucau> | Blog > >> <https://rmannibucau.metawerx.net/> | Old Blog > >> <http://rmannibucau.wordpress.com> | Github < > https://github.com/rmannibucau> | > >> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book > >> < > https://www.packtpub.com/application-development/java-ee-8-high-performance > > > >> > >> > >> Le mar. 7 juil. 2020 à 11:18, Jean-Baptiste Onofre a > >> écrit : > >> > >>> Hi everyone, > >>> > >>> It’s more than a year now that we started Apache Karaf 4.3.0 release > >>> process, fully supporting OSGi R7. > >>> > >>> If the 4.3.0 distribution is ready, we are blocked by Pax Web. I’m > >>> concerned about that as R8 will be there and we will have issue in Pax > Web > >>> again. > >>> > >>> Greg started a huge effort heading to Pax Web 8.0.0 with a large > >>> refactoring. > >>> However, the process is long and painful. > >>> So, I think it’s fair to have a discussion about the HTTP service in > Karaf > >>> and "relationship" with Pax Web. > >>> > >>> I see three options for
Re: [DISCUSSION] Apache Karaf 4.3.0 and Pax Web
Hi JB, I see more issues using felix http: 1. it only supports felix today AFAIK which directly impacts the production since then your monitoring/observability/instrumentation can be to redo so for me it is way more impacting than the dev side - and more vicious 2. felix is a fatjar so you can't upgrade jetty when needed which is also a big loss compared to not having R7 IMHO How far is paxweb from R7? Not being 100% compliant is fine IMO while: a. it can be manually switched to a compliant impl if required b. there is no regression from previous version Indeed just my 2cts, Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le mar. 7 juil. 2020 à 11:18, Jean-Baptiste Onofre a écrit : > Hi everyone, > > It’s more than a year now that we started Apache Karaf 4.3.0 release > process, fully supporting OSGi R7. > > If the 4.3.0 distribution is ready, we are blocked by Pax Web. I’m > concerned about that as R8 will be there and we will have issue in Pax Web > again. > > Greg started a huge effort heading to Pax Web 8.0.0 with a large > refactoring. > However, the process is long and painful. > So, I think it’s fair to have a discussion about the HTTP service in Karaf > and "relationship" with Pax Web. > > I see three options for Karaf 4.3.0: > > 1. We are able to release Pax Web 8.0.0 (with R7 support) and so, no > brainer, we can move forward. > 2. Instead of using Pax Web by default, we "switch" to Felix HTTP by > default. For the "pure" HTTP service, it will be transparent but it would > have two impacts: > * the configuration changes (as obviously etc/org.ops4j.pax.web.cfg > doesn’t exist anymore) > * users using WebContainer PaxWeb API instead of HTTP service won’t work > 3. We consider that Pax Web as it is today is not flexible enough and too > painful, and we start an even larger refactoring on Pax Web. > > The reason why I’m bringing this discussion on the mailing list: we really > need a clear plan and release 4.3.0 (I would really love to release 4.3.0 > mid July max, so we need a plan). > > Thoughts ? > > Regards > JB
Re: Winegrower milestone?
+1 Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le mer. 1 juil. 2020 à 09:50, Jean-Baptiste Onofre a écrit : > Hi, > > As discussed together yesterday, I plan to add couple of new samples (with > blog/documentation) and cepages for the end of this week. > > Then, I will submit a Winegrower 1.0 release to vote (probably on Monday). > > Thoughts ? > > Regards > JB > > > Le 1 juil. 2020 à 08:55, Romain Manni-Bucau a > écrit : > > > > Hi everyone, > > > > wonder if we could get a winegrower milestone - kind of preview release. > > there are several use cases it already makes sense even if OSGi support > is > > partial and it eases a lot the testing, cloud delivery and JVM boot > > optimization (CDS or graal support which is simpler than with a native > OSGi > > container) so I think it makes sense to let it go out with a "not yet > > final" flag. > > > > wdyt? > > > > Romain Manni-Bucau > > @rmannibucau <https://twitter.com/rmannibucau> | Blog > > <https://rmannibucau.metawerx.net/> | Old Blog > > <http://rmannibucau.wordpress.com> | Github < > https://github.com/rmannibucau> | > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book > > < > https://www.packtpub.com/application-development/java-ee-8-high-performance > > > >
Winegrower milestone?
Hi everyone, wonder if we could get a winegrower milestone - kind of preview release. there are several use cases it already makes sense even if OSGi support is partial and it eases a lot the testing, cloud delivery and JVM boot optimization (CDS or graal support which is simpler than with a native OSGi container) so I think it makes sense to let it go out with a "not yet final" flag. wdyt? Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance>
Re: [VOTE] Apache Karaf Decanter 2.5.0 release
+1 (sanity checks mainly and a small app test) Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le jeu. 18 juin 2020 à 08:56, Jean-Baptiste Onofre a écrit : > Hi all, > > I submit Apache Karaf Decanter 2.5.0 release to your vote. It’s a major > release on the Decanter 2.x series, containing bug fixes, improvements and > new features, especially: > > * extended REST support in REST collector and appender (REST verbs, basic > authentication, custom headers, ...) > * "connected" mode on the socket collector > * streaming mode on the socket appender > * new Pax Web Jetty handler collector > > Take a look on the Release Notes for details. > > Release Notes: > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12348163 > < > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12348163 > > > > Git Tag: > Decanter-2.5.0 > > Staging Repository: > https://repository.apache.org/content/repositories/orgapachekaraf-1144/ < > https://repository.apache.org/content/repositories/orgapachekaraf-1144/> > > Staging Dist: > https://dist.apache.org/repos/dist/dev/karaf/decanter/2.5.0/ < > https://dist.apache.org/repos/dist/dev/karaf/decanter/2.5.0/> > > Please vote to approve this release: > > [ ] +1 Approve the release > [ ] -1 Don't approve the release (please provide specific comments) > > This vote will be open for at least 72 hours. > > Regards > JB
Re: [HEADS UP] Three new features proposal this week
I guess the local repo or system repo is not a big deal (after all both can
be used as maven repo in pax so it is only different for startup jars) but
the key point for me is: can the resolver be dynamic and compute anything
or is it just an ordered deployment with precomputed start+refreshes -
should likely impact the underlying OSGi framework too.
If this last concept is reached with a state (OSGi state) computed at build
time then Karaf would become a real cloud killer option IMHO.
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>
Le mer. 6 mai 2020 à 20:06, Matt Pavlovich a écrit :
>
>
> > On May 6, 2020, at 10:45 AM, Steinar Bang wrote:
> >
> >> 2. Improve build tool (part of devx) for build time resolution
> >
> > Hm... can this be used to fill up the system directory when creating a
> > docker image on top of the official image?
> >
>
> Have you looked at using local-repo? We’ve had good success copying
> artifacts into the local-repo to ship an all-in-one, vs applying on top of
> system. Not married to one way or the other, but might be good to talk it
> through as far as the default tooling behavior and if there is a suggested
> convention on what should be in “system/“ vs “local-repo/“.
>
> etc/org.ops4j.pax.url.mvn.cfg:
> ...
> file:${karaf.home}/local-repo@snapshots@id=karaf.local-repo
>
>
>
Re: [HEADS UP] Three new features proposal this week
Don't want to hijack this thread which is very interesting in terms of user features IMHO but it is important to mention that quarkus is "just" a wrapper around graalvm as Geronimo Arthur is (even if Quarkus has a way more complete ecosystem) and that we already have OSGi graalvm integrations so I suspect karaf-quarkus is kind of the same as putting karaf in a war in a tomcat, doable but... That said making Karaf immutable at build time (and the underlying osgi system with its "state" already provisionned) is a great and important feature for K8s (not microservices or docker which are other things IMHO ;)). Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le mer. 6 mai 2020 à 10:47, Grzegorz Grzybek a écrit : > :) > > I was thinking about karaf-quarkus extension. But I'm not experienced > enough (with Quarkus) to provide any solution (for now). > > regards > Grzegorz Grzybek > > śr., 6 maj 2020 o 10:45 Romain Manni-Bucau > napisał(a): > > > s/quarkus/karaf/ ;) > > > > Romain Manni-Bucau > > @rmannibucau <https://twitter.com/rmannibucau> | Blog > > <https://rmannibucau.metawerx.net/> | Old Blog > > <http://rmannibucau.wordpress.com> | Github < > > https://github.com/rmannibucau> | > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book > > < > > > https://www.packtpub.com/application-development/java-ee-8-high-performance > > > > > > > > > Le mer. 6 mai 2020 à 10:44, Grzegorz Grzybek a > > écrit : > > > > > Hello > > > > > > BTW. Wiring/resolving reqs/caps at build time is perfect use-case for > > > Quarkus ;) > > > > > > regards > > > Grzegorz Grzybek > > > > > > śr., 6 maj 2020 o 10:39 Christian Schneider > > > napisał(a): > > > > > > > I agree that for microservices the resolver should be run at build > time > > > and > > > > use static for the runtime. > > > > That also avoids all the refresh issues for optional packages. > > > > > > > > Christian > > > > > > > > Am Mi., 6. Mai 2020 um 09:05 Uhr schrieb Guillaume Nodet < > > > > gno...@apache.org > > > > >: > > > > > > > > > The resolver pain can be absorbed at build time when building the > > > > assembly > > > > > if the target is a micro-service. > > > > > The maven plugin can easily be used to build a customized > > distribution, > > > > > totally removing the need for the resolver at runtime. > > > > > You were thinking to fill a gap between the dynamic/standard and > the > > > > static > > > > > distributions ? I'm not yet convinced there's a real gap between > > those > > > 2 > > > > > scenarii. > > > > > > > > > > Guillaume > > > > > > > > > > Le mer. 6 mai 2020 à 06:59, Jean-Baptiste Onofre > a > > > > > écrit : > > > > > > > > > > > The problem is that regular resolver makes sense for > > > "dynamic/standard" > > > > > > distribution, but very painful for "cloud/light/straight" > runtime. > > > > > > > > > > > > The proposal is to have a lighter version of the resolver to be > > > faster > > > > > and > > > > > > predictable. > > > > > > > > > > > > Regards > > > > > > JB > > > > > > > > > > > > > Le 5 mai 2020 à 11:50, Achim Nierbeck > > > > .INVALID> > > > > > > a écrit : > > > > > > > > > > > > > > +1 for most. > > > > > > > only objection to the "Simple" Resolver, therefore -1 on that. > > > > > > > I fear we do more harm then improvement. > > > > > > > As Grzegorz already said, it's the way it is, not because we > love > > > > > complex > > > > > > > stuff, but because bundle resolving is complex. > > > > > > > Especially due to the new req/cap inside bundles. > > > > > > > Actually to w
Re: [HEADS UP] Three new features proposal this week
s/quarkus/karaf/ ;) Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le mer. 6 mai 2020 à 10:44, Grzegorz Grzybek a écrit : > Hello > > BTW. Wiring/resolving reqs/caps at build time is perfect use-case for > Quarkus ;) > > regards > Grzegorz Grzybek > > śr., 6 maj 2020 o 10:39 Christian Schneider > napisał(a): > > > I agree that for microservices the resolver should be run at build time > and > > use static for the runtime. > > That also avoids all the refresh issues for optional packages. > > > > Christian > > > > Am Mi., 6. Mai 2020 um 09:05 Uhr schrieb Guillaume Nodet < > > gno...@apache.org > > >: > > > > > The resolver pain can be absorbed at build time when building the > > assembly > > > if the target is a micro-service. > > > The maven plugin can easily be used to build a customized distribution, > > > totally removing the need for the resolver at runtime. > > > You were thinking to fill a gap between the dynamic/standard and the > > static > > > distributions ? I'm not yet convinced there's a real gap between those > 2 > > > scenarii. > > > > > > Guillaume > > > > > > Le mer. 6 mai 2020 à 06:59, Jean-Baptiste Onofre a > > > écrit : > > > > > > > The problem is that regular resolver makes sense for > "dynamic/standard" > > > > distribution, but very painful for "cloud/light/straight" runtime. > > > > > > > > The proposal is to have a lighter version of the resolver to be > faster > > > and > > > > predictable. > > > > > > > > Regards > > > > JB > > > > > > > > > Le 5 mai 2020 à 11:50, Achim Nierbeck > > .INVALID> > > > > a écrit : > > > > > > > > > > +1 for most. > > > > > only objection to the "Simple" Resolver, therefore -1 on that. > > > > > I fear we do more harm then improvement. > > > > > As Grzegorz already said, it's the way it is, not because we love > > > complex > > > > > stuff, but because bundle resolving is complex. > > > > > Especially due to the new req/cap inside bundles. > > > > > Actually to work around some of the "crappy" req/cap with bundles, > > with > > > > > features did help in the past. > > > > > > > > > > regards, Achim > > > > > > > > > > > > > > > Am Mo., 4. Mai 2020 um 09:44 Uhr schrieb Francois Papon < > > > > > francois.pa...@openobject.fr>: > > > > > > > > > >> +1 for all > > > > >> > > > > >> regards, > > > > >> > > > > >> François > > > > >> fpa...@apache.org > > > > >> > > > > >> Le 04/05/2020 à 09:26, Grzegorz Grzybek a écrit : > > > > >>> Hello > > > > >>> > > > > >>> ad1) About JAXB. Currently, > > > > >>> `org.apache.karaf.features.internal.model.processing` package > > > contains > > > > >> not > > > > >>> that complex model for "Feature override and blacklisting", which > > > reads > > > > >>> etc/org.apache.karaf.features.xml file to _alter_ features model > > > using > > > > >>> `org.apache.karaf.features.internal.service.FeaturesProcessor`. > > > > >>> Nothing that can't be done without JAXB. But I'd have to rewrite > > some > > > > >> code > > > > >>> to use StAX/SAX instead. > > > > >>> > > > > >>> ad2) as long as the _model_ read from JSON feature files is still > > > > rooted > > > > >> at > > > > >>> org.apache.karaf.features.internal.model.Features class, it's > fine > > > wrt > > > > >>> _feature processing_ ;) > > > > >>> > > > > >>> ad3) +1 for simpler resolver. But I remember it's complex not for > > the > > > > >> sake > > > > &g
Re: [VOTE] Apache Karaf Decanter 2.4.0 release
+1 (non binding) Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le mar. 28 avr. 2020 à 08:35, Andrea Cosentino a écrit : > +1 (non-binding) > > -- > Andrea Cosentino > -- > Apache Camel PMC Chair > Apache Karaf Committer > Apache Servicemix PMC Member > Email: ancosen1...@yahoo.com > Twitter: @oscerd2 > Github: oscerd > > > > > > > On Friday, April 24, 2020, 08:44:59 AM GMT+2, Jean-Baptiste Onofre < > j...@nanthrax.net> wrote: > > > > > > Hi everyone, > > As discussed previously on the mailing list, I submit Apache Karaf > Decanter 2.4.0 to your vote. > > It’s a major release on the Decanter 2.x series, containing a bug fix on > the Prometheus appender feature, and new features, especially: > > - New processing layer with aggregator (see blog > http://blog.nanthrax.net/?p=1016 <http://blog.nanthrax.net/?p=1016>) > - New collectors (prometheus, Elasticsearch, configadmin, redis, oshi) > (see blog http://blog.nanthrax.net/?p=1019 < > http://blog.nanthrax.net/?p=1019>) > > Take a look on the Release Notes for details. > > Release Notes: > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12346613 > < > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12346613 > > > > Git Tag: > decanter-2.4.0 > > Staging Repository: > https://repository.apache.org/content/repositories/orgapachekaraf-1141/ < > https://repository.apache.org/content/repositories/orgapachekaraf-1141/> > > Staging Dist: > https://dist.apache.org/repos/dist/dev/karaf/decanter/2.4.0/ < > https://dist.apache.org/repos/dist/dev/karaf/decanter/2.4.0/> > > Please vote to approve this release: > > [ ] +1 Approve the release > [ ] -1 Don't approve the release (please provide specific comments) > > This vote will be open for at least 72 hours. > > Regards > JB >
Re: [VOTE] Apache Karaf Decanter 2.3.0 release
+1 (NON non binging) Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le ven. 3 avr. 2020 à 07:21, Jean-Baptiste Onofre a écrit : > Casting my own +1 (binding) > > Regards > JB > > > Le 1 avr. 2020 à 13:49, Jean-Baptiste Onofre a écrit : > > > > Hi all, > > > > I submit Apache Karaf Decanter 2.3.0 release to your vote. It’s a major > release on the Decanter 2.x series, containing bug fixes, improvements and > new features, especially: > > > > - Complete new alerting service with powerful new features (see blog > http://blog.nanthrax.net/?p=991 <http://blog.nanthrax.net/?p=991>) > > - New prometheus appender (see blog http://blog.nanthrax.net/?p=1002 < > http://blog.nanthrax.net/?p=1002>) > > - Camel MessageHistory support > > - Velocity templates support in email alerter > > - and much more ! > > > > Take a look on the Release Notes for details. > > > > Release Notes: > > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12345165 > < > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12345165 > > > > > > Git Tag: > > Decanter-2.3.0 > > > > Staging Repository: > > https://repository.apache.org/content/repositories/orgapachekaraf-1140/ > <https://repository.apache.org/content/repositories/orgapachekaraf-1140/> > > > > Staging Dist: > > https://dist.apache.org/repos/dist/dev/karaf/decanter/2.3.0/ < > https://dist.apache.org/repos/dist/dev/karaf/decanter/2.3.0/> > > > > Please vote to approve this release: > > > > [ ] +1 Approve the release > > [ ] -1 Don't approve the release (please provide specific comments) > > > > This vote will be open for at least 72 hours. > > > > Regards > > JB > >
Re: [PROPOSAL] Introduce spec features to simplify users experience
+1, jdk9plus should disappear to make karaf frictionless IMHO Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le jeu. 5 mars 2020 à 10:13, Jean-Baptiste Onofre a écrit : > Hi guys, > > Several users reported issues with JDK 9+ about spec packages. > > Users are struggling about spec packages since JDK 9+ and "classic" > questions are: > > - who’s provide the package ? > - should I use spec bundles and where they are located ? > - should I change bin/karaf to use —add-module ? > - should I use lib/jdk9plus and update etc/jre.properties ? > > IMHO, the always preferred approach should be spec bundles. > > To improve users experience with JDK9+, I would like to create a new > features repository: spec. > This features repository XML will provide spec feature (JAXB, JAXP, …) > that other projects and users can leverage. > It would reduce the coupling with JDK packages and a straight forward > usage. > > Thoughts ? > > Regards > JB
bug in inc?
Hi everyone, in bin/inc, localeHome function, the KARAF_HOME variable is always unset to be initialized the if block just after. I assume it is to enforce the home to be "current" location but I don't see the point since then the script will not work if not using a standard karaf layout (OS installation for ex). It also logs a warning for nothing in several cases: > karaf: Ignoring predefined value for KARAF_HOME Wonder if there is any issue to drop the unset block if it is set? Was it to avoid versions issues? If so, can't we check the major through a lib file check? Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance>
Winegrower, one more step with requirements
Hi all, Just to let you know that I did a PR on winegrower to start to add some basic requirement support. Goal was not this one originally but to be able to run OSGi-CDI on winegrower. Here is the PR: https://github.com/apache/karaf-winegrower/pull/4 We don't have yet what is generally called a "resolver" but we enable to use some capability based extender with such PR. Guess it will need some more refinements (only getRequiredWires is impl but not getProvidedWires for ex) but I think it is enough for a first PR. Hope it makes sense. Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance>
Re: Setting security provider for Karaf 4.3.0-SNAPSHOT
This is a one way choice so then bouncycastle becomes a jre provided lib (as jaxb was) for consumers and bundles are no more working or use other actual instances making it potentially corrupted if bundles and part of the boot - potentially not just karaf jars -must share bc. Also note it would prevent some osgi manifest feature (capabilities) to work if bc gets it at some point. So guess the boot logic using it must be moved to early bundles too. Can be part of the jaxb work since it is exactly the same issue. Wdyt? Le dim. 2 févr. 2020 à 16:53, Benjamin Graf a écrit : > Hi together, > > how going on with this topic. Actually bouncastle is the defacto > standard security library for karaf and bundled by default. So taking > the approach explained by Robert sounds reasonable to upstream to Karaf > itself and moving libs to from system to boot and maybe even register > org.apache.karaf.security.providers = > org.bouncycastle.jce.provider.BouncyCastleProvider. Something to be > solved before 4.3RC2? > > Regards, > > Benjamin > > On 15.01.2020 17:00, Robert Varga wrote: > > On 15/01/2020 16:25, Benjamin Graf wrote: > >> Hi, > >> > >> I'm actually playing around with the latest 4.3.0-SNAPSHOT. I recognize > >> that the ssh bundle is using bouncycastle for reading pem files right > >> now (KARAF-6383). The "issue" I'm facing is that if I like to set > >> bouncycastle as the security provider via > >> "org.apache.karaf.security.providers = > >> org.bouncycastle.jce.provider.BouncyCastleProvider" I have to distribute > >> the same bundle twice or otherwise have to remove it from system and add > >> needed packages to "org.osgi.framework.bootdelegation". > >> > >> Anybody seeing a better solution? > > Not sure, but in OpenDaylight we have two fragment bundles which attach > > to framework bundle and expose all of BouncyCastle to OSGi: > > > > > https://github.com/opendaylight/odlparent/tree/master/karaf/bcpkix-framework-ext > > > https://github.com/opendaylight/odlparent/tree/master/karaf/bcprov-framework-ext > > > > perhaps these should be upstreamed (but then we upgrade BC much more > > quickly than we upgrade Karaf). > > > > Regards, > > Robert > > > >
Re: [VOTE] Apache Karaf Runtime 4.3.0.RC1 release
+1 and thanks a lot for this effort! Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le mar. 28 janv. 2020 à 08:46, Francois Papon a écrit : > +1 (binding) > > regards, > > François > fpa...@apache.org > > Le 27/01/2020 à 21:21, Jean-Baptiste Onofré a écrit : > > Hi all, > > > > In the preparation to Apache Karaf Runtime 4.3.0 GA, I submit 4.3.0.RC1 > > release to your vote. > > This release is not supposed to be production ready, it's the first RC > > on 4.3.x series. > > It supports OSGi R7 at "low level" (framework, resolver, ...). The > > missing part to be fully R7 is Pax Web on which we are working. However, > > I would like to give a chance to users to already start some tests and > > provide feedback. > > I already plan a RC2 before releasing 4.3.0 "official GA". > > > > As it's a RC1, the Release Notes is not "official", but you have it > > extracted from Jira > > > https://issues.apache.org/jira/sr/jira.issueviews:searchrequest-printable/temp/SearchRequest.html?jqlQuery=project+%3D+KARAF+AND+status+in+%28Resolved%2C+Closed%29+AND+fixVersion+%3D+4.3.0+ORDER+BY+created+DESC%2C+priority+DESC%2C+updated+DESC=1000 > > > > Staging Repository: > > https://repository.apache.org/content/repositories/orgapachekaraf-1139 > > > > Staging Dist: > > https://dist.apache.org/repos/dist/dev/karaf/4.3.0.RC1/ > > > > Git Tag: > > karaf-4.3.0.RC1 > > > > Please vote to approve this release: > > > > [ ] +1 Approve the release > > [ ] -1 Don't approve the release (please provide specific comments) > > > > Remember that's it's a RC, so, feel free to test and provide feedback, > > it will be very helpful to prepare 4.3.0 GA. > > > > This vote will be open for at least 72 hours. > > > > Thanks, > > Regards > > JB >
Re: Jdk9plus: materialize it or not
Side note: dropping javax.annotation and its declaration in jre-9 i managed to move forward and no issue since jre part of karaf uses the jre automatically and other parts use the bundle i deployed. So likely some work to do but kind of confirm it is a good option. Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le mar. 28 janv. 2020 à 07:05, Grzegorz Grzybek a écrit : > Thanks Robert > > At least I was able to see `Multi-Release` jars/bundles in action. In Pax > Logging 2.0.x I did this to make Log4j2 work under JDK8 and JDK9+ > < > https://github.com/ops4j/org.ops4j.pax.logging/blob/logging-2.0.2/pax-logging-api/osgi.bnd#L103 > > > . > > regards > Grzegorz Grzybek > > pon., 27 sty 2020 o 13:47 Robert Varga napisał(a): > > > On 27/01/2020 09:26, Grzegorz Grzybek wrote: > > > Thanks for explanation. I told you - I've never used anything above > > JDK8... > > > > > > And I know this Jigsaw thing brings more trouble than benefits... > Anyone > > of > > > you using JDK9+ modules at all? Or only making workarounds for them? :) > > > > Well, there is a project tracking JPMS modules in Central here: > > https://github.com/sormuras/modules :) > > > > OpenDaylight current development release does require JDK11 (for > > VarHandles mostly) and we do have a number of automatic modules and a > > few explicit modules. > > > > This is low-priority work as we are waiting for OSGi R7-compliant Karaf > > (due to > > https://blog.osgi.org/2018/02/osgi-r7-highlights-java-9-support.html and > > SCR annotation improvements). Once we have that, I expect the pace of > > JPMS adoption to pick up. With > > https://blog.osgi.org/2019/09/osgi-connect-revisited.html it may > > actually be useful in the future :) > > > > Regards, > > Robert > > > > >
Re: Jdk9plus: materialize it or not
Hi @Grzegorz, Well, JDK dropped JAXB and endorsing so it must be a bundle now, putting it in the classpath is a workaround but not the other way around regarding JRE rules now. Now one of the liked features of OSGi is to be dynamic and updatable and using the JRE breaks that by design and you don't have the OSGi integration (bundle activator quite often) since it comes with the JRE so has the lifecycle of the JRE. This is why for me, if the boot classpath is more than OSGi container and a small config reader utility (caricaturally karaf main), it is a design pitfall. I'm also thinking to vendors doing custom karaf distros and on this side they must be able to be secured and use the same distro on multiple JRE and this is one issue which shouldn't require properties customizations IMHO. Hope it makes sense. Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le lun. 27 janv. 2020 à 09:01, Grzegorz Grzybek a écrit : > Hello > > I didn't work much with JDK9 (though JDK15 builds are already > available[1]...). But maybe (if it's the only problem) `osgi.contract` can > be added to system bundle via `jre.properties`? > > I mean - we're ~10 years after Xerces hell already and I hope JAXB and > other "endorsed standards" can be handled at lowest possible level... I > admire what spec bundles do, but it still (IMO) look like a workaround of > some fundamental problem related to adjusting JDK itself to OSGi... > > regards > Grzegorz Grzybek > === > [1]: https://jdk.java.net/15/ > > pon., 27 sty 2020 o 08:38 Jean-Baptiste Onofré > napisał(a): > > > It makes sense to me. > > > > Let me create Jira and work on an improvement about that. > > > > Thanks for the proposal ! > > > > Regards > > JB > > > > On 27/01/2020 08:17, Romain Manni-Bucau wrote: > > > Yep, also means karaf.main must not depend on these ones but > technically > > it > > > sounds very feasible and saner in terms of architecture (launcher > > > responsability vs container like one). > > > > > > Le lun. 27 janv. 2020 à 08:14, Jean-Baptiste Onofré > a > > > écrit : > > > > > >> Hi Romain, > > >> > > >> So, basically, your proposal is to remove jdk9plus and "force" use of > > >> spec bundles, right ? > > >> > > >> It makes sense to me, but it means that any spec has to be a bundle > and > > >> started in early stage of the boot process. > > >> If it's possible, it makes sense. > > >> > > >> Regards > > >> JB > > >> > > >> On 27/01/2020 08:11, Romain Manni-Bucau wrote: > > >>> Hi all, > > >>> > > >>> Playing with the r7 branch i tried to build an osgi-cdi distro but > > >> stumbled > > >>> upon the fact jdk9plus folder breaks resolution chain quite easily > when > > >>> switching of jdk. > > >>> > > >>> Long story short, having annotation, activation (and potentially jaxb > > >> but i > > >>> didnt need this one ;)) does not enable to have them as bundle in the > > >> same > > >>> version - so to do dynamic updates too ;) - and they miss > osgi.contract > > >>> entry config. > > >>> > > >>> I wonder if there is any rational to have them at all, sounds like > > karaf > > >>> can boot without them and just move to bundles all the logic > > potentially > > >>> needing them so no need to patch the classpath for java >= 9 IMHO. > > >>> > > >>> Did I miss anything? > > >>> Is it something to plan to clean up for karaf 4.3.0? > > >>> > > >> > > >> -- > > >> Jean-Baptiste Onofré > > >> jbono...@apache.org > > >> http://blog.nanthrax.net > > >> Talend - http://www.talend.com > > >> > > > > > > > -- > > Jean-Baptiste Onofré > > jbono...@apache.org > > http://blog.nanthrax.net > > Talend - http://www.talend.com > > >
Re: Jdk9plus: materialize it or not
Yep, also means karaf.main must not depend on these ones but technically it sounds very feasible and saner in terms of architecture (launcher responsability vs container like one). Le lun. 27 janv. 2020 à 08:14, Jean-Baptiste Onofré a écrit : > Hi Romain, > > So, basically, your proposal is to remove jdk9plus and "force" use of > spec bundles, right ? > > It makes sense to me, but it means that any spec has to be a bundle and > started in early stage of the boot process. > If it's possible, it makes sense. > > Regards > JB > > On 27/01/2020 08:11, Romain Manni-Bucau wrote: > > Hi all, > > > > Playing with the r7 branch i tried to build an osgi-cdi distro but > stumbled > > upon the fact jdk9plus folder breaks resolution chain quite easily when > > switching of jdk. > > > > Long story short, having annotation, activation (and potentially jaxb > but i > > didnt need this one ;)) does not enable to have them as bundle in the > same > > version - so to do dynamic updates too ;) - and they miss osgi.contract > > entry config. > > > > I wonder if there is any rational to have them at all, sounds like karaf > > can boot without them and just move to bundles all the logic potentially > > needing them so no need to patch the classpath for java >= 9 IMHO. > > > > Did I miss anything? > > Is it something to plan to clean up for karaf 4.3.0? > > > > -- > Jean-Baptiste Onofré > jbono...@apache.org > http://blog.nanthrax.net > Talend - http://www.talend.com >
Jdk9plus: materialize it or not
Hi all, Playing with the r7 branch i tried to build an osgi-cdi distro but stumbled upon the fact jdk9plus folder breaks resolution chain quite easily when switching of jdk. Long story short, having annotation, activation (and potentially jaxb but i didnt need this one ;)) does not enable to have them as bundle in the same version - so to do dynamic updates too ;) - and they miss osgi.contract entry config. I wonder if there is any rational to have them at all, sounds like karaf can boot without them and just move to bundles all the logic potentially needing them so no need to patch the classpath for java >= 9 IMHO. Did I miss anything? Is it something to plan to clean up for karaf 4.3.0?
Re: Heading to Karaf runtime 4.3.0.RC1
Awesome, this will already be big and enable to use aries osgi-cdi which is a big step for osgi ecosystem imho. Thanks a lot JB. Le ven. 24 janv. 2020 à 05:38, Jean-Baptiste Onofré a écrit : > Hi guys, > > Just to let you know that the first OSGi R7 support is done: > > https://github.com/apache/karaf/pull/995 > > I will merge this PR later today, and I will prepare a 4.3.0.RC1. > > To have a full OSGi R7 support, you still need to: > > - work on Pax Web to update whiteboard and other part to have full R7 > support here. Greg and I are working on this. > - implement log.stream and log.admin services in Pax Logging (minor, Pax > Logging core is already R7). > > So, in order to give you a try, I will cut 4.3.0.RC1 today or during the > weekend. > > Thanks > > Regards > JB > -- > Jean-Baptiste Onofré > jbono...@apache.org > http://blog.nanthrax.net > Talend - http://www.talend.com >
Re: [VOTE] Apache Karaf Runtime 4.2.8 release (take #2)
+1 (non binding) - for some asf itests and "simple" apps (no multipart in them ;)) Le dim. 19 janv. 2020 à 22:49, Jean-Baptiste Onofré a écrit : > Hi all, > > I submit Apache Karaf runtime 4.2.8 to your vote. This is a > maintenance release on the 4.2.x series, bringing updates, improvements > and fixes. > > Release Notes: > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12346100 > > Staging Repository: > https://repository.apache.org/content/repositories/orgapachekaraf-1138 > > Staging Dist: > https://dist.apache.org/repos/dist/dev/karaf/4.2.8/ > > Git Tag: > karaf-4.2.8 > > Please vote to approve this release: > > [ ] +1 Approve the release > [ ] -1 Don't approve the release (please provide specific comments) > > This vote will be open for at least 72 hours. > > Thanks, > Regards > JB > -- > Jean-Baptiste Onofré > jbono...@apache.org > http://blog.nanthrax.net > Talend - http://www.talend.com >
Re: Setting security provider for Karaf 4.3.0-SNAPSHOT
+1 a temp classloader using local resolution or plain reimpl of pem read does not sound terrible to me Le mer. 15 janv. 2020 à 16:25, Benjamin Graf a écrit : > Hi, > > I'm actually playing around with the latest 4.3.0-SNAPSHOT. I recognize > that the ssh bundle is using bouncycastle for reading pem files right > now (KARAF-6383). The "issue" I'm facing is that if I like to set > bouncycastle as the security provider via > "org.apache.karaf.security.providers = > org.bouncycastle.jce.provider.BouncyCastleProvider" I have to distribute > the same bundle twice or otherwise have to remove it from system and add > needed packages to "org.osgi.framework.bootdelegation". > > Anybody seeing a better solution? Maybe an enhancement needed? > > Regards > > Benjamin > > >
Re: staticcm module not 1.6 compatible?
Hmm, it is required by spec (104.12.1 of https://osgi.org/specification/osgi.cmpn/7.0.0/service.cm.html) and used by consumers like osgi-cdi since it is in the API through @RequireConfigurationAdmin. So not sure there is a choice to support it on karaf side. wdyt? Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le dim. 12 janv. 2020 à 20:59, Jean-Baptiste Onofré a écrit : > It depends of the requirements. As usage, the package capability is > mostly enough. That's why it was not required. > > However, it makes sense for extend. > > Regards > JB > > On 12/01/2020 18:55, Romain Manni-Bucau wrote: > > Hi all, > > > > Is it normal master staticcm module does not exposes osgi.implementation? > > ([1]) > > It breaks its usage in several frameworks on top of it. > > > > [1] https://github.com/jbonofre/karaf/pull/25 > > > > Romain Manni-Bucau > > @rmannibucau <https://twitter.com/rmannibucau> | Blog > > <https://rmannibucau.metawerx.net/> | Old Blog > > <http://rmannibucau.wordpress.com> | Github < > https://github.com/rmannibucau> | > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book > > < > https://www.packtpub.com/application-development/java-ee-8-high-performance > > > > > > -- > Jean-Baptiste Onofré > jbono...@apache.org > http://blog.nanthrax.net > Talend - http://www.talend.com >
staticcm module not 1.6 compatible?
Hi all, Is it normal master staticcm module does not exposes osgi.implementation? ([1]) It breaks its usage in several frameworks on top of it. [1] https://github.com/jbonofre/karaf/pull/25 Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance>
Re: [VOTE] Apache Karaf runtime 4.2.8 release
+1 (non binding) Le dim. 12 janv. 2020 à 12:34, Jean-Baptiste Onofré a écrit : > Hi all, > > I submit Apache Karaf runtime 4.2.8 to your vote. This is a > maintenance release on the 4.2.x series, bringing updates, improvements > and fixes. > > Release Notes: > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12346100 > > Staging Repository: > https://repository.apache.org/content/repositories/orgapachekaraf-1137 > > Staging Dist: > https://dist.apache.org/repos/dist/dev/karaf/4.2.8/ > > Git Tag: > karaf-4.2.8 > > Please vote to approve this release: > > [ ] +1 Approve the release > [ ] -1 Don't approve the release (please provide specific comments) > > This vote will be open for at least 72 hours. > > Thanks, > Regards > JB > -- > Jean-Baptiste Onofré > jbono...@apache.org > http://blog.nanthrax.net > Talend - http://www.talend.com >
Re: Happy new Karaf year !
Happy new year everyone, may karaf be with you ;) Le mer. 1 janv. 2020 à 12:52, Grzegorz Grzybek a écrit : > Happy new year to everyone! > > regards > Grzegorz Grzybek > > śr., 1 sty 2020 o 07:23 Jean-Baptiste Onofré napisał(a): > > > Hi everyone, > > > > on behalf of the Karaf team, I wish you a happy new year ! > > > > For sure, 2020 will be a Karaf year with lot of new features and ideas > > coming. Following the kloud initiative, we are now focusing on the > > developer experience. > > We are looking forward new users, new big players using Karaf, new > > contributors. > > > > Again, an excellent new year for you all. > > > > Regards > > JB > > -- > > Jean-Baptiste Onofré > > jbono...@apache.org > > http://blog.nanthrax.net > > Talend - http://www.talend.com > > >
Re: [DISCUSS] JMX Default Context
Hi
Since each instance will get its own port the name is pointless IMO until
all instances are shown in the same jmx tree but here the name would be a
jmx properties so +1 to not have the name in the url (probably with a
comment in the cfg to get back current behavior for users relying on it).
Le mer. 20 nov. 2019 à 07:52, Grzegorz Grzybek a
écrit :
> Hello
>
> IMO, alias would be better. But how about child containers?
> (instance:create)?
>
> regards
> Grzegorz Grzybek
>
> śr., 20 lis 2019 o 07:50 Jean-Baptiste Onofré
> napisał(a):
>
> > Hi guys,
> >
> > I'm working on adding JMXMP connector on Karaf JMX layer (in addition of
> > the RMI connector we already have).
> >
> > I was thinking about the default JMX context we are using.
> >
> > Right now, our context contains the Karaf instance name. For users, it
> > means they have to use service URL like
> > service:jmx:rmi:///jndi/rmi://localhost:1099/karaf-foo
> >
> > It's not very convenient/predictable: for instance, in jconsole, the
> > users have to use the full service URL.
> > Of course, they can change the URL to use /jmxrmi in
> > etc/org.apache.karaf.management.cfg but it's not the default.
> >
> > I propose to either:
> > 1. Use /jmxrmi context instead of /karaf-${karaf.name}
> > 2. Keep the default /karaf-${karaf.name} context and add an "alias" on
> > /jmxrmi
> >
> > Thoughts ?
> >
> > Regards
> > JB
> > --
> > Jean-Baptiste Onofré
> > jbono...@apache.org
> > http://blog.nanthrax.net
> > Talend - http://www.talend.com
> >
>
Re: [DISCUSS] Donate Vineyard as new Apache Karaf subproject
+1 makes sense to give it a try, in particular on an OSGi runtime Le dim. 17 nov. 2019 à 06:59, Jean-Baptiste Onofré a écrit : > Ping ? > > Regards > JB > > On 07/11/2019 09:34, Jean-Baptiste Onofré wrote: > > Hi guys, > > > > As Thanksgiving and Christmas times are coming, we have a new "gift" for > > the Karaf community ;) > > > > For several weeks now, François and I worked on Vineyard. > > > > Vineyard is a API management platform powered by Apache Karaf. > > > > It provides two modules: > > > > - API Registry where users can create API/Resources, via shell commands > > or REST API. A API is a generic model in Vineyard. For now, we support > > REST typed API, but we plan to support other kind of API (GraphQL, etc). > > - API Gateway is the definition from the registry to actually bootstrap > > the API in the gateway. The gateway exposes the API and proxy the actual > > API calls to a target endpoint. The target endpoint can be any kind of > > endpoint (REST itself, SOAP, JMS, Kafka, whatever). It's also where the > > policies are located (the policies are describe and configured in the > > registry). > > > > The current codebase is there: > > > > https://github.com/jbonofre/karaf-vineyard > > > > We have bunch of ideas about improvements/new features/enhancement, and > > we are convinced that the community and you guys will also have ideas > > and contributions. > > > > Thoughts ? > > > > Regards > > JB > > > > -- > Jean-Baptiste Onofré > jbono...@apache.org > http://blog.nanthrax.net > Talend - http://www.talend.com >
Re: [PR/DISCUSS] Interceptor module?
+1 Le jeu. 14 nov. 2019 à 16:06, Jean-Baptiste Onofré a écrit : > It sounds good to me ;) > > Regards > JB > > On 14/11/2019 15:53, Loven, Hans CTR (FAA) wrote: > > "Karaf Greffer" to keep with the plant theme? > > > > H > > > > -Original Message- > > From: Jean-Baptiste Onofré > > Sent: Thursday, November 14, 2019 8:50 AM > > To: dev@karaf.apache.org > > Subject: Re: [PR/DISCUSS] Interceptor module? > > > > Good point ;) And I agree. > > > > Let's find another name ;) > > > > Regards > > JB > > > > On 14/11/2019 15:46, Loven, Hans CTR (FAA) wrote: > >> Respectfully, > >> > >> Karaf Secateur _sounds_ like a great name for something, but I think it > is contrary to what this does. Secateurs are pruning shears. Unless I > have missed something, this project adds annotation-based interceptor > capability. That seems the opposite of pruning, imho. > >> > >> > >> Cheers, > >> Hans > >> > >> -Original Message- > >> From: Jean-Baptiste Onofré > >> Sent: Thursday, November 14, 2019 6:38 AM > >> To: dev@karaf.apache.org > >> Subject: Re: [PR/DISCUSS] Interceptor module? > >> > >> I think we have two options: > >> > >> 1. Explicit name: Karaf IoC > >> 2. Fancy name: Karaf Secateur > >> > >> Either way is fine for me ;) > >> > >> Regards > >> JB > >> > >> On 14/11/2019 13:32, Christian Schneider wrote: > >>> In that case I am fine with the ioc name. > >>> > >>> Christian > >>> > >>> Am Do., 14. Nov. 2019 um 13:17 Uhr schrieb Romain Manni-Bucau < > >>> rmannibu...@gmail.com>: > >>> > >>>> Im fine whatever works the most. > >>>> > >>>> Ioc proposal comes from the hope to fill the gap between spring/CDI > >>>> and OSGi ecosystem without going directly to osgi-cdi which has some > >>>> pitfalls for cdi guys. > >>>> Interceptors were just the first step but it can be more after so > >>>> having interceptor in the name sounded limited to me. > >>>> Hope it clarifies where Im coming from. > >>>> > >>>> Le jeu. 14 nov. 2019 à 13:05, Christian Schneider > >>>> >>>>> > >>>> a écrit : > >>>> > >>>>> Sounds good .. for the name I propose karaf-interceptor. > >>>>> The name karaf-ioc ( I guess it should mean inversion of control) > >>>>> does > >>>> not > >>>>> seem to match well what it does. > >>>>> > >>>>> Christian > >>>>> > >>>>> Am Do., 14. Nov. 2019 um 12:51 Uhr schrieb Jean-Baptiste Onofré < > >>>>> j...@nanthrax.net>: > >>>>> > >>>>>> Agree, my point is that technically possible. > >>>>>> > >>>>>> And also agree to create a karaf-ioc repo (it takes me 2 minutes > ;)). > >>>>>> > >>>>>> We can start a formal vote about that. Let's just wait Romain's > >>>> feedback. > >>>>>> > >>>>>> Regards > >>>>>> JB > >>>>>> > >>>>>> On 14/11/2019 12:44, Christian Schneider wrote: > >>>>>>> Of course it technically works but it would be the only case in > >>>>>>> the > >>>>> karaf > >>>>>>> main repo. It would confuse people a lot. I think we should not > >>>>>>> start > >>>>>> this. > >>>>>>> Creating a new karaf repo is no big issue. > >>>>>>> > >>>>>>> Christian > >>>>>>> > >>>>>>> Am Do., 14. Nov. 2019 um 11:54 Uhr schrieb Jean-Baptiste Onofré < > >>>>>>> j...@nanthrax.net>: > >>>>>>> > >>>>>>>> Hi, > >>>>>>>> > >>>>>>>> It can be released in its own cycle in the main repo. > >>>>>>>> > >>>>>>>> For instance, ServiceMix Bundles are on an unique git repo, but > >>>>>>>> I do release of each independently from the others. > >>>>>>>> &g
Re: [PR/DISCUSS] Interceptor module?
Im fine whatever works the most. Ioc proposal comes from the hope to fill the gap between spring/CDI and OSGi ecosystem without going directly to osgi-cdi which has some pitfalls for cdi guys. Interceptors were just the first step but it can be more after so having interceptor in the name sounded limited to me. Hope it clarifies where Im coming from. Le jeu. 14 nov. 2019 à 13:05, Christian Schneider a écrit : > Sounds good .. for the name I propose karaf-interceptor. > The name karaf-ioc ( I guess it should mean inversion of control) does not > seem to match well what it does. > > Christian > > Am Do., 14. Nov. 2019 um 12:51 Uhr schrieb Jean-Baptiste Onofré < > j...@nanthrax.net>: > > > Agree, my point is that technically possible. > > > > And also agree to create a karaf-ioc repo (it takes me 2 minutes ;)). > > > > We can start a formal vote about that. Let's just wait Romain's feedback. > > > > Regards > > JB > > > > On 14/11/2019 12:44, Christian Schneider wrote: > > > Of course it technically works but it would be the only case in the > karaf > > > main repo. It would confuse people a lot. I think we should not start > > this. > > > Creating a new karaf repo is no big issue. > > > > > > Christian > > > > > > Am Do., 14. Nov. 2019 um 11:54 Uhr schrieb Jean-Baptiste Onofré < > > > j...@nanthrax.net>: > > > > > >> Hi, > > >> > > >> It can be released in its own cycle in the main repo. > > >> > > >> For instance, ServiceMix Bundles are on an unique git repo, but I do > > >> release of each independently from the others. > > >> > > >> I think we can start like this. > > >> > > >> Regards > > >> JB > > >> > > >> On 14/11/2019 11:09, Christian Schneider wrote: > > >>> The fact that it evolves a lot at the start is even another argument > to > > >>> keep it out of the karaf main repo as there you can only release > > together > > >>> with karaf. > > >>> > > >>> I think in the end it is your decision - either a new karaf repo (I > can > > >>> create it for you) or a new aries repo (again I can create it) or the > > >> aries > > >>> main repo. So all options should be pretty quick to do. > > >>> (Of course if you decide for aries we need an approval from the pmc > of > > >>> aries but I guess that is rather a formality as most are also in this > > >> list > > >>> and would have objected if they did not want it at aries). > > >>> > > >>> Christian > > >>> > > >>> Am Mi., 13. Nov. 2019 um 09:39 Uhr schrieb Romain Manni-Bucau < > > >>> rmannibu...@gmail.com>: > > >>> > > >>>> I kind of share the fact code will likely be stable - that said, > > >> depending > > >>>> the adoption it can evolve quite a lot for ~1 year I think (adding > > >> method > > >>>> binding support is the one I have in mind if the module works great > > >> without > > >>>> this feature). > > >>>> Where I'm a bit less "easy" is cause karaf has jms, jpa, jdbc etc > > >> modules > > >>>> so it sounds it is on the same plan to me, no? > > >>>> That said, once again any home will be fine for me while it exists > ;) > > >>>> > > >>>> Le mer. 13 nov. 2019 à 09:29, Christian Schneider < > > >> ch...@die-schneider.net > > >>>>> > > >>>> a écrit : > > >>>> > > >>>>> I would not put the new code into an existing Aries subproject. > > Instead > > >>>> we > > >>>>> could add a new one. > > >>>>> Either in its own git repo or in the shared one (depends on how we > > want > > >>>> to > > >>>>> release). > > >>>>> > > >>>>> @Romain .. do you plan to version by bundle or the whole > interceptor > > >>>>> subproject? > > >>>>> If you plan to release by bundle then the aries main git would be a > > >> great > > >>>>> fit as the modules there are released in the same fashion. > > >>>>> If you plan to always release the whole interceptor tree then a new > > g
Re: [PR/DISCUSS] Interceptor module?
I kind of share the fact code will likely be stable - that said, depending the adoption it can evolve quite a lot for ~1 year I think (adding method binding support is the one I have in mind if the module works great without this feature). Where I'm a bit less "easy" is cause karaf has jms, jpa, jdbc etc modules so it sounds it is on the same plan to me, no? That said, once again any home will be fine for me while it exists ;) Le mer. 13 nov. 2019 à 09:29, Christian Schneider a écrit : > I would not put the new code into an existing Aries subproject. Instead we > could add a new one. > Either in its own git repo or in the shared one (depends on how we want to > release). > > @Romain .. do you plan to version by bundle or the whole interceptor > subproject? > If you plan to release by bundle then the aries main git would be a great > fit as the modules there are released in the same fashion. > If you plan to always release the whole interceptor tree then a new git > repo in aries or karaf would work great. > > The karaf main repo would be a bad choice as I think the interceptor code > will be quite stable after some time while karaf will always be changing. > > Christian > > Am Di., 12. Nov. 2019 um 11:23 Uhr schrieb Romain Manni-Bucau < > rmannibu...@gmail.com>: > > > Updated the code, last changes are mainly: > > > > 1. moving the module in the right parent (I put it in service instead of > > service*s* originally) > > 2. added an E2E test using pax-exam > > 3. make it work :) > > > > I added a doc page ([1]) to try to share more what it tries to achieve. > > > > About aries, the proxy module looks almost 100% bound to blueprint so > > didn't see it as an option but I don't have a really strong blocker > there, > > I'll fully trust the OSGi@apache community on that. > > > > [1] > > > > > https://github.com/apache/karaf/pull/993/files#diff-6aaf055d932f602b06135e6446ee6c2eR15 > > > > Romain Manni-Bucau > > @rmannibucau <https://twitter.com/rmannibucau> | Blog > > <https://rmannibucau.metawerx.net/> | Old Blog > > <http://rmannibucau.wordpress.com> | Github < > > https://github.com/rmannibucau> | > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book > > < > > > https://www.packtpub.com/application-development/java-ee-8-high-performance > > > > > > > > > Le mar. 12 nov. 2019 à 08:15, Grzegorz Grzybek a > > écrit : > > > > > Hello > > > > > > pon., 11 lis 2019 o 20:45 Christian Schneider > > > > napisał(a): > > > > > > > Great to hear that you already considered aspecio. > > > > If we want to put this into apache then I rather would suggest Apache > > > > Felix, Apache Aries or a Karaf submodule. > > > > > > > > > > Yes, IMO it'd fit more into Apache Aries Proxy. > > > > > > regards > > > Grzegorz Grzybek > > > > > > > > > > The interceptor support is a small standalone module that should have > > its > > > > own lifecycle. > > > > Putting it in the main karaf tree would mean it is released for every > > > karaf > > > > version. > > > > > > > > Christian > > > > > > > > Am Mo., 11. Nov. 2019 um 20:38 Uhr schrieb Romain Manni-Bucau < > > > > rmannibu...@gmail.com>: > > > > > > > > > @Christian yes and no. Ray pointed out aspecio to me but I had a > few > > > > issues > > > > > with it: > > > > > > > > > > 1. it brings its own stack - and yes I care about each single dep > my > > > app > > > > > brings cause, a) network usage the size can implies with modern > > > > > deployments, b) security vulnerabilities the stack can hide. > > > > > 2. it is not at asf or asf influenced (as part of codehaus projects > > had > > > > > been in early times for exapple) with all it implies in terms of > > > > governance > > > > > and legal quality. > > > > > 3. the API is reinvented compared to the final step of my proposal > > > which > > > > > would be aligned on the standard. Current version of code is almost > > > > aligned > > > > > on interceptor API (you just sed the package for the mainstream > > usage) > > > > but > > > > > the consumer side is a bit different, I must refine it to be closer > > to > > > > C
Re: [PR/DISCUSS] Interceptor module?
Updated the code, last changes are mainly: 1. moving the module in the right parent (I put it in service instead of service*s* originally) 2. added an E2E test using pax-exam 3. make it work :) I added a doc page ([1]) to try to share more what it tries to achieve. About aries, the proxy module looks almost 100% bound to blueprint so didn't see it as an option but I don't have a really strong blocker there, I'll fully trust the OSGi@apache community on that. [1] https://github.com/apache/karaf/pull/993/files#diff-6aaf055d932f602b06135e6446ee6c2eR15 Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le mar. 12 nov. 2019 à 08:15, Grzegorz Grzybek a écrit : > Hello > > pon., 11 lis 2019 o 20:45 Christian Schneider > napisał(a): > > > Great to hear that you already considered aspecio. > > If we want to put this into apache then I rather would suggest Apache > > Felix, Apache Aries or a Karaf submodule. > > > > Yes, IMO it'd fit more into Apache Aries Proxy. > > regards > Grzegorz Grzybek > > > > The interceptor support is a small standalone module that should have its > > own lifecycle. > > Putting it in the main karaf tree would mean it is released for every > karaf > > version. > > > > Christian > > > > Am Mo., 11. Nov. 2019 um 20:38 Uhr schrieb Romain Manni-Bucau < > > rmannibu...@gmail.com>: > > > > > @Christian yes and no. Ray pointed out aspecio to me but I had a few > > issues > > > with it: > > > > > > 1. it brings its own stack - and yes I care about each single dep my > app > > > brings cause, a) network usage the size can implies with modern > > > deployments, b) security vulnerabilities the stack can hide. > > > 2. it is not at asf or asf influenced (as part of codehaus projects had > > > been in early times for exapple) with all it implies in terms of > > governance > > > and legal quality. > > > 3. the API is reinvented compared to the final step of my proposal > which > > > would be aligned on the standard. Current version of code is almost > > aligned > > > on interceptor API (you just sed the package for the mainstream usage) > > but > > > the consumer side is a bit different, I must refine it to be closer to > > CDI > > > but it is just a matter of handling RUNTIME interceptor annotations and > > > just using @Interceptors as a component property type of type boolean > and > > > not a value holder which breaks interceptor simplicity. > > > 4. it is a one guy github project (even if code quality is not bad) so > > not > > > something you can reliably use in a professional project (we > don't > > > code in javascript ;)) > > > 5. no commit since > 1 year? > > > > > > Hope it clarifies a bit how I ended up on that proposal. > > > > > > Romain Manni-Bucau > > > @rmannibucau <https://twitter.com/rmannibucau> | Blog > > > <https://rmannibucau.metawerx.net/> | Old Blog > > > <http://rmannibucau.wordpress.com> | Github < > > > https://github.com/rmannibucau> | > > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book > > > < > > > > > > https://www.packtpub.com/application-development/java-ee-8-high-performance > > > > > > > > > > > > > Le lun. 11 nov. 2019 à 20:22, Jean-Baptiste Onofré a > > > écrit : > > > > > > > Hi Romain, > > > > > > > > that sounds great to me ! Thanks for that. > > > > > > > > First, you did well in terms of modules organization: it makes sense > to > > > > have interceptor in service (like staticcm). > > > > > > > > About the use case, it makes sense as well. I will take a deeper look > > > soon. > > > > > > > > Thanks again ! > > > > Regards > > > > JB > > > > > > > > > > > > On 11/11/2019 19:37, Romain Manni-Bucau wrote: > > > > > Hi all, > > > > > > > > > > I took some time this week-end to draft an interceptor module in > > Karaf. > > > > > I tried to describe it in the related PR ([1]) - in WIP mode so > don't > >
Re: [PR/DISCUSS] Interceptor module?
Ok so let's: 1. Finish the PoC 2. Review the API (and impl but rhis part can evolve faster ;)) 3. Validate where we put it and move forward with integrations :) Le mar. 12 nov. 2019 à 06:14, Jean-Baptiste Onofré a écrit : > It depends of the scope. I don't mind to start in Karaf and move to > Karaf IoC later. Up to you. > > Regards > JB > > On 11/11/2019 20:49, Romain Manni-Bucau wrote: > > Guess it is true for all project and I assume "submodule" means > > "subproject" right? > > Not sure what it means in practise (new git?) but it is not shocking. Any > > proposal karaf-ioc (we could add more feature later this way)? Is it what > > you meant? > > > > Romain Manni-Bucau > > @rmannibucau <https://twitter.com/rmannibucau> | Blog > > <https://rmannibucau.metawerx.net/> | Old Blog > > <http://rmannibucau.wordpress.com> | Github < > https://github.com/rmannibucau> | > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book > > < > https://www.packtpub.com/application-development/java-ee-8-high-performance > > > > > > > > Le lun. 11 nov. 2019 à 20:45, Christian Schneider < > ch...@die-schneider.net> > > a écrit : > > > >> Great to hear that you already considered aspecio. > >> If we want to put this into apache then I rather would suggest Apache > >> Felix, Apache Aries or a Karaf submodule. > >> The interceptor support is a small standalone module that should have > its > >> own lifecycle. > >> Putting it in the main karaf tree would mean it is released for every > karaf > >> version. > >> > >> Christian > >> > >> Am Mo., 11. Nov. 2019 um 20:38 Uhr schrieb Romain Manni-Bucau < > >> rmannibu...@gmail.com>: > >> > >>> @Christian yes and no. Ray pointed out aspecio to me but I had a few > >> issues > >>> with it: > >>> > >>> 1. it brings its own stack - and yes I care about each single dep my > app > >>> brings cause, a) network usage the size can implies with modern > >>> deployments, b) security vulnerabilities the stack can hide. > >>> 2. it is not at asf or asf influenced (as part of codehaus projects had > >>> been in early times for exapple) with all it implies in terms of > >> governance > >>> and legal quality. > >>> 3. the API is reinvented compared to the final step of my proposal > which > >>> would be aligned on the standard. Current version of code is almost > >> aligned > >>> on interceptor API (you just sed the package for the mainstream usage) > >> but > >>> the consumer side is a bit different, I must refine it to be closer to > >> CDI > >>> but it is just a matter of handling RUNTIME interceptor annotations and > >>> just using @Interceptors as a component property type of type boolean > and > >>> not a value holder which breaks interceptor simplicity. > >>> 4. it is a one guy github project (even if code quality is not bad) so > >> not > >>> something you can reliably use in a professional project (we > don't > >>> code in javascript ;)) > >>> 5. no commit since > 1 year? > >>> > >>> Hope it clarifies a bit how I ended up on that proposal. > >>> > >>> Romain Manni-Bucau > >>> @rmannibucau <https://twitter.com/rmannibucau> | Blog > >>> <https://rmannibucau.metawerx.net/> | Old Blog > >>> <http://rmannibucau.wordpress.com> | Github < > >>> https://github.com/rmannibucau> | > >>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book > >>> < > >>> > >> > https://www.packtpub.com/application-development/java-ee-8-high-performance > >>>> > >>> > >>> > >>> Le lun. 11 nov. 2019 à 20:22, Jean-Baptiste Onofré a > >>> écrit : > >>> > >>>> Hi Romain, > >>>> > >>>> that sounds great to me ! Thanks for that. > >>>> > >>>> First, you did well in terms of modules organization: it makes sense > to > >>>> have interceptor in service (like staticcm). > >>>> > >>>> About the use case, it makes sense as well. I will take a deeper look > >>> soon. > >>>> > >>>> Thanks again ! > >>>> Regards > >>>> JB > >>>> > >&g
Re: [PR/DISCUSS] Interceptor module?
Guess it is true for all project and I assume "submodule" means "subproject" right? Not sure what it means in practise (new git?) but it is not shocking. Any proposal karaf-ioc (we could add more feature later this way)? Is it what you meant? Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le lun. 11 nov. 2019 à 20:45, Christian Schneider a écrit : > Great to hear that you already considered aspecio. > If we want to put this into apache then I rather would suggest Apache > Felix, Apache Aries or a Karaf submodule. > The interceptor support is a small standalone module that should have its > own lifecycle. > Putting it in the main karaf tree would mean it is released for every karaf > version. > > Christian > > Am Mo., 11. Nov. 2019 um 20:38 Uhr schrieb Romain Manni-Bucau < > rmannibu...@gmail.com>: > > > @Christian yes and no. Ray pointed out aspecio to me but I had a few > issues > > with it: > > > > 1. it brings its own stack - and yes I care about each single dep my app > > brings cause, a) network usage the size can implies with modern > > deployments, b) security vulnerabilities the stack can hide. > > 2. it is not at asf or asf influenced (as part of codehaus projects had > > been in early times for exapple) with all it implies in terms of > governance > > and legal quality. > > 3. the API is reinvented compared to the final step of my proposal which > > would be aligned on the standard. Current version of code is almost > aligned > > on interceptor API (you just sed the package for the mainstream usage) > but > > the consumer side is a bit different, I must refine it to be closer to > CDI > > but it is just a matter of handling RUNTIME interceptor annotations and > > just using @Interceptors as a component property type of type boolean and > > not a value holder which breaks interceptor simplicity. > > 4. it is a one guy github project (even if code quality is not bad) so > not > > something you can reliably use in a professional project (we don't > > code in javascript ;)) > > 5. no commit since > 1 year? > > > > Hope it clarifies a bit how I ended up on that proposal. > > > > Romain Manni-Bucau > > @rmannibucau <https://twitter.com/rmannibucau> | Blog > > <https://rmannibucau.metawerx.net/> | Old Blog > > <http://rmannibucau.wordpress.com> | Github < > > https://github.com/rmannibucau> | > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book > > < > > > https://www.packtpub.com/application-development/java-ee-8-high-performance > > > > > > > > > Le lun. 11 nov. 2019 à 20:22, Jean-Baptiste Onofré a > > écrit : > > > > > Hi Romain, > > > > > > that sounds great to me ! Thanks for that. > > > > > > First, you did well in terms of modules organization: it makes sense to > > > have interceptor in service (like staticcm). > > > > > > About the use case, it makes sense as well. I will take a deeper look > > soon. > > > > > > Thanks again ! > > > Regards > > > JB > > > > > > > > > On 11/11/2019 19:37, Romain Manni-Bucau wrote: > > > > Hi all, > > > > > > > > I took some time this week-end to draft an interceptor module in > Karaf. > > > > I tried to describe it in the related PR ([1]) - in WIP mode so don't > > > jump > > > > on me yet cause tests are not there please ;). > > > > > > > > High level, I missed a lot interceptors (from javax.) when starting > to > > > use > > > > SCR. > > > > It mainly change the way to add transversal features (metrics, > > security, > > > > tracing, circuit-breaker, asynchronism to cite a few). > > > > > > > > I still have some API refinement to do but high level it would > enable a > > > > service to be marked as intercepted ([2]) and implement interceptors > > "as > > > > usual" ([3]) and link them with a marker (in the PoC it is an > > > annotation). > > > > > > > > It is in very early stages but before investing way more time, I'd > like > > > to > > > > know if it sounds like a module
