Re: [PROPOSAL] Apache Karaf runtime releases and roadmap
Thanks for clarification JB! Just one more comment about: Tomcat for the Karaf Web service yes (not strong opinion here, it > would be Jetty). And as state earlier, only Servlet/Filter service > registration package will be supported. That's quite arbitrary distinction TBH :) You know - we rarely write servlets these days and rather have some kind of dispatcher servlet (yes, this is spring...) which delegates to different views/controllers/handlers etc. However the point is that even if you DO write servlets, then: - servlets have access to ServletContext - ServletContext gives you access to context attributes - context attributes are either taken from web.xml () or are setup in ServletContextListeners - ServletContextListeners are 3rd "big thing" (next to servlets and filters) that constitute web applications - so you have to allow them too - but ServletContextListeners allow you to dynamically register additional servlets (that's what most SCIs do too - JSF, JSP, ...) dynamically with dynamic mapping - also servlets and filters may be protected - in web.xml you can have and elements... I could continue (I've already mentioned JSPs, SCIs, ...) getting closer and closer to full Servlet API specification... The point is that if you want servlets + filters only, you'd need full implementation based on particular runtime (whether Tomcat, Jetty or Undertow) to deal with its specifics (like Jetty's ServletContextHandler, Tomcat's StandardContext or Undertow's DeploymentInfo). You also have to deal with contexts (implementations of jakarta.servlet.ServletContext interface) to separate servlets. Though Felix-Http has one "dispatcher servlet" registered in single context and moves "context" concept from the runtime to this servlet... Anyway - a lot of work ;) regards Grzegorz Grzybek czw., 20 cze 2024 o 08:51 Jean-Baptiste Onofré napisał(a): > Hi Grzegorz > > Thanks for your message, it's highly appreciated. > > See my comments inline: > > > 1. What exactly are "Karaf services"? Are these OSGi services? > (registered > > with BundleContext.registerService(iface, object, properties)?) If not > then > > what are the aspects that make them "services" - discoverability, > > interface, registration method (through annotations and build time > > processing? /META-INF/services? other?)? > > It's OSGi services. > > > > > 2. Removing Pax + hiding OSGi seems complementary, but is OSGi going to > be > > implementation detail of Karaf 5? or just deployment method (Minho / > Felix > > Atomos?) If you say that pax-web will still be available, it means it > needs > > full OSGi runtime (Felix, Equinox) underneath. Mind that the biggest > > obstacle when refactoring Pax Web 7 into Pax Web 8 was this entire > > "discoverability" mechanism, which allows you to scan > > bundles/fragments/wires looking for annotated web elements, SCIs and > > web-fragment.xml files... So if you hide OSGi under "Karaf services" and > at > > the same time keep OSGi for those who want it, it'd be (sorry for > analogy) > > like hiding an elephant under a napkin... :) > > Fair comment. The purpose of Karaf Services is to simplify and focus > only on what matters for the users in the Karaf context. > For instance, why not just supporting Servlet OSGi services listening, > not need to support annotation web elements or web-fragments.xml. > If a user wants these features, then it will use Pax Web. > But, if the user just need a simple webcontainer for servlet and Karaf > webconsole, then Karaf Web service would be enough. > > > > > 3. Pax URL and Pax Web accept configuration via ConfigAdmin. So again - > you > > can't remove, you have to hide it (see #2). > > I'm not too concerned about ConfigAdmin: it will stay there. > > > > > 4. Also for Pax Web - it required a lot of effort to make it > "restartable". > > I mean even Tomcat/Jetty/Undertow itself keep each webapp in separate > > classloader, so you can kind of get rid of the webapp (undeploy) if you > > like. Pax Web pushes this to the extreme with whiteboard, where you can > > have filters from different bundles filtering access to servlets from > > different bundles and sending events to listeners from yet different > > bundles and everything is (should be) classloader-safe. Hinding it under > > non-hierarchical classloader may not be possible... > > Same here: restartable could be Pax Web feature. > > > > > 5. You've mentioned "main focus on Tomcat", but roughly speaking, Tomcat > > operates on entire webapps. It's only Pax Web (or Felix HTTP with Jetty) > > that make i
Re: [PROPOSAL] Apache Karaf runtime releases and roadmap
Hello Sorry for late response, I'm stuck in savage and obscure world of JavaScript right now (webpack module federation). Looking back at OSGi, it's seen as clear, pleasant and predictable environment ;) anyway - here are my comments to JB's proposal: Be opinionated means that I propose to remove PAX * dependencies, > and provide Karaf services instead, very simple and opinionated (for > instance, instead of PAX Web, a simple Tomcat based service, instead > of PAX Logging, a simple slf4j/log4j only service, Pax Exam replaced > by JUnit 5 simple extensions, etc). > The main proposed change is to simplify the services in Karaf mostly for > the pax * parts. > There are two main reasons about that : > - having Karaf provided services would simplify the releases, dependency > management and security due diligence > - some pax components are very complex and we can have a simpler impl (and > maintainable) with Karaf opiniated service > > Specifically about pax web, it doesn’t mean necessary to not super OSGi web > spec. It’s mainly to focus on tomcat and Karaf impl as part of the Karaf > project. > For instance, pax-web will still be available (if people want to use > it), but Karaf will provide a web feature (as alternative). > > For URL and logging, Karaf will provide simplified mvn and wrap url > handlers, and opinionated Karaf logging service (only supporting slf4j > and log4j2). If users still want to use Pax URL and Pax Logging, they > will still be able to do so via custom distribution. > I have few questions, concerns about the above... 1. What exactly are "Karaf services"? Are these OSGi services? (registered with BundleContext.registerService(iface, object, properties)?) If not then what are the aspects that make them "services" - discoverability, interface, registration method (through annotations and build time processing? /META-INF/services? other?)? 2. Removing Pax + hiding OSGi seems complementary, but is OSGi going to be implementation detail of Karaf 5? or just deployment method (Minho / Felix Atomos?) If you say that pax-web will still be available, it means it needs full OSGi runtime (Felix, Equinox) underneath. Mind that the biggest obstacle when refactoring Pax Web 7 into Pax Web 8 was this entire "discoverability" mechanism, which allows you to scan bundles/fragments/wires looking for annotated web elements, SCIs and web-fragment.xml files... So if you hide OSGi under "Karaf services" and at the same time keep OSGi for those who want it, it'd be (sorry for analogy) like hiding an elephant under a napkin... :) 3. Pax URL and Pax Web accept configuration via ConfigAdmin. So again - you can't remove, you have to hide it (see #2). 4. Also for Pax Web - it required a lot of effort to make it "restartable". I mean even Tomcat/Jetty/Undertow itself keep each webapp in separate classloader, so you can kind of get rid of the webapp (undeploy) if you like. Pax Web pushes this to the extreme with whiteboard, where you can have filters from different bundles filtering access to servlets from different bundles and sending events to listeners from yet different bundles and everything is (should be) classloader-safe. Hinding it under non-hierarchical classloader may not be possible... 5. You've mentioned "main focus on Tomcat", but roughly speaking, Tomcat operates on entire webapps. It's only Pax Web (or Felix HTTP with Jetty) that make it possible to operate on the level of single servlet/filter/listener/SCI/... - how could such "Karaf web service for Tomcat" look like if you, say, wanted to register a servlet + filter? How would you package and register such servlet + filter? Not that I don't approve the plans (I like how you think about the future), or maybe simply my mind went numb after working for few weeks with rollup.js and typescript, but I don't feel like I can provide any constructive feedback besides asking for clarification... kind regards Grzegorz Grzybek wt., 11 cze 2024 o 16:20 Matt Pavlovich napisał(a): > Hi JB- > > Makes sense, I figured I’d make the pitch for the pax-* merger in that > there is a lot of good use cases, stability and performance scenarios > already handled there. > > I look forward to assisting with the new karaf-* services. > > Thanks, > Matt Pavlovich > > > On Jun 11, 2024, at 3:45 AM, Jean-Baptiste Onofré > wrote: > > > > Hi all, > > > > I would like to clarify the PAX * questions. It would be still > > possible to use PAX * projects in Karaf 5.x, via the features (as > > today), but optional (not boot features anymore). > > > > As an alternative, we will have opinionated Karaf services features. > > > > For instance, pax-web will still be available (if people want to use > > it), but Karaf will pro
Re: [PROPOSAL] Apache Karaf runtime releases and roadmap
Hello I'll try to comment in general topic a bit later, but for now, one inline response (below): niedz., 9 cze 2024 o 20:45 Matt Pavlovich napisał(a): > I think this summarizes a core maintenance issue with pax+karaf today > > > I am not sure how many people travel between PAX and Karaf and vice > versa, but lets be honest - contribution criteria for PAX is lower than for > Karaf. > > I suggest we take a look at migrating pax-* (pax-logging. pax-url, > pax-web, etc) into karaf for a couple of practical benefits (perhaps for > Karaf 4.5?): > We had such discussion in 2022: https://lists.apache.org/thread/7oc4opjbplxps9gt8jnr5lxlmtwx0lzh Some time ago, I've moved OPS4J Jira issues to GitHub and I think it improved the release process and community feedback greatly (much easier to create issues and link them with commits). I don't want to sound like an "owner" of Pax Web or Pax Logging, because I only maintain great projects standing on the shoulders of giants. > > 1. Less repositories to manage and preform releases > 2. Artifacts (jars, configs, services) are less confusing to users (ie. > org.apache.karaf.web makes more sense vs org.ops4j.pax.web .. etc) > > This would also give us an opportunity to see how this gels before > finalizing what is supported in Karaf 5 (jetty, tomcat, etc). > Pax Web and Pax Logging would be direct "competitor" to Felix Web and Felix Log and I'm not sure it's good for ASF... But I'm just a plain and simple code maintainer ;) regards Grzegorz Grzybek > > Thoughts? > > Matt Pavlovich
Re: [VOTE] Apache Karaf OSGi runtime 4.4.6 release
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 >
[ANN] Pax JDBC 1.5.7 released
Hello I'd like to announce the release of Pax JDBC 1.5.7 which is version-update only release. The relevant changelog is: https://github.com/ops4j/org.ops4j.pax.jdbc/milestone/33?closed=1 The version changes are: - MS SQL driver upgraded to 12.6.1 - Oracle driver upgraded to 23.3.0.23.09 - MariaDB driver upgraded to 3.3.3 - MySQL driver upgraded to 8.3.0 - SQLite driver upgraded to 3.45.2.0 - PostgreSQL driver upgraded to 42.7.3 - H2 driver upgraded to 2.2.224 - Commons DBCP2 and Commons Pool2 upgraded to 2.12.0 kind regards Grzegorz Grzybek
[ANN] Pax Web 8.0.27 and 9.0.16 released
Hello I'd like to announce new releases of Pax Web: 8.0.27 and 9.0.16. Only runtimes are upgraded (Tomcat and Undertow) Current runtime versions are: - Jetty 9.4.54.v20240208 (8.0.x) and 10.0.20 (9.0.x) - Tomcat 9.0.87 - Undertow 2.2.31.Final For completeness, the changelogs are available for 8.0.27[1] and 9.0.16[2]. kind regards Grzegorz Grzybek === [1]: https://github.com/ops4j/org.ops4j.pax.web/milestone/260?closed=1 [2]: https://github.com/ops4j/org.ops4j.pax.web/milestone/261?closed=1
Re: [HEADS UP] Apache Karaf runtime 4.4.5 release
Hello I've recently released Pax Web versions with runtime upgrades (and one fix), but I see there's already new Undertow and Tomcat. I'll release new version of Pax Web today - WDYT? regards Grzegorz Grzybek niedz., 24 mar 2024 o 19:04 Jean-Baptiste Onofré napisał(a): > Hi guys, > > New update about 4.4.5 and 4.5.0 releases. > > I think I fixed all found issues (and dependency updates). > I'm now opening the PRs, and I will submit the releases to vote in the > coming days. > > Thanks for your patience, > > Regards > JB > > On Mon, Feb 19, 2024 at 8:21 AM Jean-Baptiste Onofré > wrote: > > > > Hi guys, > > > > While working on Camel 4.x support (4.4.0) in Karaf 4.x, I identified > > some issues and required improvements. > > > > I'm working on this: I would like to include this in the Karaf 4.5.0 > > release as it will be a better experience for our users (with a > > cleaner Camel 4.x and ActiveMQ 6.x support). > > > > I will keep you posted. > > > > Regards > > JB > > > > On Mon, Dec 18, 2023 at 1:54 PM Jean-Baptiste Onofré > wrote: > > > > > > Hi guys, > > > > > > I'm finalizing Karaf runtime 4.4.5 release preparation. > > > I should be able to submit the release to vote just around Christmas. > > > > > > I will keep you posted. > > > > > > Regards > > > JB >
Re: Board report for March 2024
+1 regards Grzegorz Grzybek czw., 29 lut 2024 o 14:22 Francois Papon napisał(a): > LGTM, thanks JB! > > regards, > > François > > On 29/02/2024 13:45, Jean-Baptiste Onofré wrote: > > Hi guys, > > > > I prepared the board report for March 2024: > > > > https://cwiki.apache.org/confluence/display/KARAF/Board+Reports > > > > Please take a look and feel free to update. > > > > I would like to send the report asap. > > > > Thanks ! > > Regards > > JB >
[ANN] Pax Web 8.0.26 and 9.0.15 released
Hello I'd like to announce new bugfix releases of Pax Web: 8.0.26 and 9.0.15. Current runtime versions are: - Jetty 9.4.54.v20240208 (8.0.x) and 10.0.20 (9.0.x) - Tomcat 9.0.86 - Undertow 2.2.30.Final There's also one fix for a problem reported by Ivaylo Milev about non-working "org.ops4j.pax.web.session.cookie.secure" option. For completeness, the changelogs are available for 8.0.26[1] and 9.0.15[2]. kind regards Grzegorz Grzybek === [1]: https://github.com/ops4j/org.ops4j.pax.web/milestone/258?closed=1 [2]: https://github.com/ops4j/org.ops4j.pax.web/milestone/259?closed=1
Re: [PROPOSAL] Migrate to GitHub Issues/Actions
Hello JBO - we can discuss on slack later if you decide to migrate - we can use the scripts I used to migrate Pax projects. regards Grzegorz Grzybek sob., 3 lut 2024 o 06:39 Jean-Baptiste Onofré napisał(a): > Hi guys, > > it seems we have a consensus here. > > I propose to complete Karaf 4.5.0 release first and then I will move > forward on the switch to GH Issues (and also GH Actions). > > Thanks, > Regards > JB > > On Tue, Oct 31, 2023 at 9:27 AM Jean-Baptiste Onofré > wrote: > > > > Hi guys, > > > > I would like to propose to move from Jira to GH Issues and from > > Jenkins to GH Actions. > > > > As we have several sub-projects, each sub-project will have its own > > space, like we do for Karaf Minho > > (https://github.com/apache/karaf-minho). > > > > The migration should be "smooth" and I will work on it if you agree. > > > > Thoughts ? > > > > Regards > > JB >
[ANN] Pax Web 8.0.25 and 9.0.14 released
Hello I'd like to announce new bugfix releases of Pax Web: 8.0.25 and 9.0.14. Current runtime versions are: - Jetty 9.4.53.v20231009 (8.0.x) and 10.0.19 (9.0.x) - Tomcat 9.0.85 - Undertow 2.2.28.Final There's one fix for a problem reported by @liao-qing-hua that "org.ops4j.pax.web.session.timeout" option was ignored. For completeness, the changelogs are available for 8.0.25[1] and 9.0.14[2]. kind regards Grzegorz Grzybek === [1]: https://github.com/ops4j/org.ops4j.pax.web/milestone/256?closed=1 [2]: https://github.com/ops4j/org.ops4j.pax.web/milestone/257?closed=1
[ANN] Pax Logging 2.2.7 and 1.12.10 released
Hello I'd like to announce minor releases of Pax Logging 1.12.10 (OSGi R6) and 2.2.7 (OSGi R8). The single upgrade Logback 1.3.14. The release notes can be found using the following links: - 2.2.7: https://github.com/ops4j/org.ops4j.pax.logging/milestone/117?closed=1 - 1.12.10: https://github.com/ops4j/org.ops4j.pax.logging/milestone/118?closed=1 kind regards Grzegorz Grzybek
Re: [VOTE] Apache Karaf OSGi runtime 4.4.5 release
+1 regards Grzegorz Grzybek pon., 8 sty 2024 o 00:42 Jamie G. napisał(a): > +1 > > Cheers, > Jamie > > On Sun, Jan 7, 2024 at 2:34 PM Jean-Baptiste Onofré > wrote: > > > > Hi guys, > > > > I submit Apache Karaf OSGi runtime 4.4.5 release to your vote. > > > > This release is a maintenance release bringing fixes and dependency > > updates, especially: > > - isolate config shell commands in a dedicated bundle to avoid refresh > > and race condition at startup > > - better JDK21 support with new ASM version (9.6) > > - upgrade to Jetty 9.4.53.v20231009 and Pax Web 8.0.24 > > - fix webconsole plugins loading > > - upgrade to sshd 2.11.0 fixing ecdsa key support > > > > You can take a look on the Release Notes for details: > > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12353604 > > > > Maven Staging Repository: > > https://repository.apache.org/content/repositories/orgapachekaraf-1190/ > > > > Dist Staging Repository: > > https://dist.apache.org/repos/dist/dev/karaf/4.4.5/ > > > > Git tag: > > karaf-4.4.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: Board report for December 2023
+1 regards Grzegorz Grzybek pt., 15 gru 2023 o 13:43 Jean-Baptiste Onofré napisał(a): > Hi guys, > > I'm sorry, we are late for the board report this month (I didn't > receive a reminder and forgot to create one). > So I quickly created a board report here: > > https://cwiki.apache.org/confluence/display/KARAF/Board+Reports > > Please take a look, I would like to send it asap (if possible tonight). > > Thanks ! > Regards > JB >
Re: [PROPOSAL] Migrate to GitHub Issues/Actions
Hello Please check https://github.com/ops4j/org.ops4j.tools/blob/main/jira2github/data/readme.adoc - I can perform the migration. The tool is a bit low level, but it worked during OPS4J migration to GH. This readme describes multi-stage procedure which includes generation of properties files containing the mapping of various jira items (versions, components, milestones, ...). The point is that there may be cross links between JIRAs, so GH issues should also contain links - that's handled by the tool as well. In first pass I create the issues, collect the JIRA (KARAF-xxx) to GH # mapping, which then is used in second pass to recreate the links. regards Grzegorz Grzybek wt., 21 lis 2023 o 10:15 Jean-Baptiste Onofré napisał(a): > Hi guys > > Any comments on that one ? > > If there are no objections, I will move forward with that. > > Regards > JB > > On Tue, Oct 31, 2023 at 9:27 AM Jean-Baptiste Onofré > wrote: > > > > Hi guys, > > > > I would like to propose to move from Jira to GH Issues and from > > Jenkins to GH Actions. > > > > As we have several sub-projects, each sub-project will have its own > > space, like we do for Karaf Minho > > (https://github.com/apache/karaf-minho). > > > > The migration should be "smooth" and I will work on it if you agree. > > > > Thoughts ? > > > > Regards > > JB >
Re: Karaf + SOAP + JDK 21
Thanks for the feedback!
In my custom distro (Fuse), I'm still stuck with javax.* packages. This is
what I have in lib/jdk9plus:
istack-commons-runtime-3.0.10.redhat-3.jar
jakarta.jws-api-2.1.0.redhat-3.jar
jakarta.xml.bind-api-2.3.3.redhat-3.jar
jakarta.xml.soap-api-1.4.2.redhat-1.jar
jakarta.xml.ws-api-2.3.3.redhat-1.jar
jaxb-runtime-2.3.4.jar
txw2-2.3.4.jar
so yes - there's also jakarta.jws-api (but the one with javax packages).
regards
Grzegorz Grzybek
śr., 15 lis 2023 o 10:11 Mark Derricutt napisał(a):
> Unfortunately that didn't quite work as I fell into the trap of then
> needing javax.jws.
>
> However - I do now have it working, tho I did have to end up updating
> the bundle that included the WSDL generation. In my custom distribution
> I now have:
>
> version="${project.version}">
> mvn:jakarta.activation/jakarta.activation-api/2.1.2
> mvn:jakarta.jws/jakarta.jws-api/3.0.0
> mvn:jakarta.xml.bind/jakarta.xml.bind-api/4.0.0
> mvn:jakarta.xml.ws/jakarta.xml.ws-api/4.0.1
> mvn:jakarta.xml.soap/jakarta.xml.soap-api/3.0.1
> cxf-core
> cxf-jaxws
> cxf-http
> cxf-specs
> cxf-wsdl
> cxf-databinding-jaxb
> cxf-bindings-soap
>
>
> It's possible I could trim some of the included 's there as
> they're transcluded by the others, but for now this works. This switches
> to the jakarta.xml version of packages, which avoids the default export
> of javax.xml. In the karaf-maven-plugin configuration, I had to set
> 11 tho as it was a requirement for one of those bundles
> (I forget which off hand), and for some reason I couldn't use
> 21 as it claimed it wasn't a valid Java version.
>
> On the service side, I had to add the following dependencies:
>
>
>jakarta.jws
>jakarta.jws-api
>3.0.0
>
>
>jakarta.xml.bind
>jakarta.xml.bind-api
>4.0.0
>
>
>jakarta.xml.ws
>jakarta.xml.ws-api
>4.0.1
>
>
>javax.xml.bind
>jaxb-api
>[2.3.1]
>
>
>*
>*
>
>
>
>
>javax.xml.ws
>jaxws-api
>[2.3.1]
>
>
>*
>*
>
>
>
>
> and updated cxf-codegen-plugin to 4.0.3. Interestingly, I couldn't find
> any suitable replacements/updates for
> org.jvnet.jaxb2_commons:jaxb2-fluent-api it's sibling XCJ extensions so
> had to rewrite one wrapper service to match the changed code-gen.
>
> But it seems to be working now. At least - the custom image
> builds/verifies and starts up - I've not yet tried calling any of the
> services yet. Tomorrows job.
>
>
> Mark
>
> On 6/11/23 8:44 pm, Grzegorz Grzybek wrote:
> > I think you should simply drop jakarta.xml.ws-api-2.3.3.jar
> > <
> https://repo1.maven.org/maven2/jakarta/xml/ws/jakarta.xml.ws-api/2.3.3/jakarta.xml.ws-api-2.3.3.jar
> >
> > into KARAF_HOME/lib/jdk9plus
Re: Karaf + SOAP + JDK 21
Also mind that Karaf exports "javax.xml.ws.soap" system package in etc/jre.properties, so adding a bundle which exports the same could be confusing... In the version of CXF I use, "cxf-specs" features has: mvn:org.apache.servicemix.specs/org.apache.servicemix.specs.jaxws-api-2.2/2.9.0 which means this bundle WON'T be installed if the package is available in different, already installed bundle. And etc/jre.properties says that javax.xml.ws.soap package is exported by bundle 0. And it is only declaratively, but the package is physically not available. regards Grzegorz Grzybek pon., 6 lis 2023 o 08:42 Steven Huypens napisał(a): > Hi Mark, > > It looks like my bundles import the package "javax.xml.ws.soap" from > > 'mvn:org.apache.servicemix.specs/org.apache.servicemix.specs.jaxws-api-2.3/2.3_2' > which is in the feature "cxf-specs". > > Kind regards, > Steven > > On Mon, Nov 6, 2023 at 7:44 AM Mark Derricutt wrote: > > > On 6/11/23 7:21 pm, Grzegorz Grzybek wrote: > > > But "smx3.system" bundle looks like something from you, not from > Karaf... > > > > It is, but there's a wiring dependency on > > osgi.wiring.package=javax.xml.ws.soap>=0.0.0 there, which is no longer > > being satisfied. > > > > Note I've not currently moved out individual bundles to be built under > > Java 21 or anything yet, as I'd rather get a distribution working first > > (if possible). > > > > Also, when running a stock Karaf 4.4.4 with the soap sample project jars > > copied into the ./deploy directory, I got the same issue running the > > newer (non 8) JDKs. > > >
Re: Karaf + SOAP + JDK 21
Hmm I see KARAF_HOME/lib/endorsed/org.apache.karaf.specs.java.xml.ws-4.4.4.jar library, but it contains only javax.xml.ws.spi package (and javax.xml.soap) In my work I maintain custom Karaf distro (Fuse Karaf), which in addition has this library: FUSE_HOME/lib/jdk9plus/jakarta.xml.ws-api-2.3.3.jar - and this library (Maven Central: https://repo1.maven.org/maven2/jakarta/xml/ws/jakarta.xml.ws-api/2.3.3/) and THIS library contains javax.xml.ws.soap (and javax.xml.ws.handler.soap) packages... I think you should simply drop jakarta.xml.ws-api-2.3.3.jar <https://repo1.maven.org/maven2/jakarta/xml/ws/jakarta.xml.ws-api/2.3.3/jakarta.xml.ws-api-2.3.3.jar> into KARAF_HOME/lib/jdk9plus regards Grzegorz Grzybek pon., 6 lis 2023 o 07:44 Mark Derricutt napisał(a): > On 6/11/23 7:21 pm, Grzegorz Grzybek wrote: > > But "smx3.system" bundle looks like something from you, not from Karaf... > > It is, but there's a wiring dependency on > osgi.wiring.package=javax.xml.ws.soap>=0.0.0 there, which is no longer > being satisfied. > > Note I've not currently moved out individual bundles to be built under > Java 21 or anything yet, as I'd rather get a distribution working first > (if possible). > > Also, when running a stock Karaf 4.4.4 with the soap sample project jars > copied into the ./deploy directory, I got the same issue running the > newer (non 8) JDKs. >
Re: Karaf + SOAP + JDK 21
Hello
But "smx3.system" bundle looks like something from you, not from Karaf...
regards
Grzegorz Grzybek
pon., 6 lis 2023 o 07:17 Mark Derricutt napisał(a):
> Hi Jean-Baptiste,
>
> This is what I have in my feature file:
>
> mvn:org.apache.cxf.karaf/apache-cxf/3.5.5/xml/features
>
> version="${project.version}"> version="3.5.5">cxf-core
>cxf-jaxws
>cxf-databinding-jaxb
>
>
> This gives me the following outputL
>
> smx3 | org.osgi.framework.BundleException: Unable to resolve smx3.system
> [118](R 118.0):
> missing requirement[smx3.system [118](R 118.0)] osgi.wiring.package;
> (&(osgi.wiring.package=smx3.mailproducts.api)(version>=21.1.0)(!(version>=22.0.0)))
> [caused by: Unable to resolve smx3.mailproducts [145](R 145.0):
> missing requirement [smx3.mailproducts [145](R 145.0)]
> osgi.wiring.package;
> (&(osgi.wiring.package=javax.xml.ws.soap)(version>=0.0.0))] Unresolved
> requirements: [[smx3.system [118](R 118.0)] osgi.wiring.package;
>
> (&(osgi.wiring.package=smx3.mailproducts.api)(version>=21.1.0)(!(version>=22.0.0)))]
>
> Interestingly, I was trying to figure out where I found the version from
> (I may have just been trying any modern version), but I note the
> /examples/pom.xml in the binary zip refers to a parent ../pom.xml which
> doesn't exist (it's there in the -src.zip tho, and at 3.5.5.
>
> Mark
>
>
> On 6/11/23 6:37 pm, Jean-Baptiste Onofré wrote:
> > Hi
> >
> > Which CXF version are you using ?
> > I guess it’s about CXF support.
> >
> > I will check on main.
> >
> > Regards
> > JB
> >
> > Le dim. 5 nov. 2023 à 20:31, Mark Derricutt a écrit :
> >
> >> Anyone got Karaf 4.4.4 and SOAP working under JDk 21?
> >>
> >> I've been trying to update our project from Java 8, and just getting hit
> >> with the lack of javax.ws.* classes being a part of the JDK from 9
> onward.
> >>
> >> Even the stock Karaf SOAP example doesn't seem to work for me - I'm
> >> guessing I just need to add an extra dependency which provides those
> >> classes, but haven't been able to find a recommended/standard
> >> implementation to use...
> >>
> >> Any pointers?
> >>
> >>
> >>
> >>
Re: [PROPOSAL] Migrate to GitHub Issues/Actions
Thanks JBO for explanation So +1 from me ;) and I offer to migrate Jiras using org.ops4j.tools/jira2github ! regards Grzegorz wt., 31 paź 2023 o 09:53 Jean-Baptiste Onofré napisał(a): > There's no problem from ASF standpoint: > - INFRA delegated the settings to .asf.yml > - several ASF projects already use GH Issues/Actions (Iceberg, ...) > - we already have Karaf Minho using it > > https://infra.apache.org/github-actions-policy.html > > Regards > JB > > On Tue, Oct 31, 2023 at 9:31 AM Grzegorz Grzybek > wrote: > > > > Hello > > > > Technically it's easy - I wrote and successfully used > > https://github.com/ops4j/org.ops4j.tools/tree/main/jira2github to > migrate > > Pax projects from Jira to GitHub. > > > > But how does it relate to ASF governance? > > > > regards > > Grzegorz Grzybek > > > > wt., 31 paź 2023 o 09:27 Jean-Baptiste Onofré > napisał(a): > > > > > Hi guys, > > > > > > I would like to propose to move from Jira to GH Issues and from > > > Jenkins to GH Actions. > > > > > > As we have several sub-projects, each sub-project will have its own > > > space, like we do for Karaf Minho > > > (https://github.com/apache/karaf-minho). > > > > > > The migration should be "smooth" and I will work on it if you agree. > > > > > > Thoughts ? > > > > > > Regards > > > JB > > > >
Re: [PROPOSAL] Migrate to GitHub Issues/Actions
Hello Technically it's easy - I wrote and successfully used https://github.com/ops4j/org.ops4j.tools/tree/main/jira2github to migrate Pax projects from Jira to GitHub. But how does it relate to ASF governance? regards Grzegorz Grzybek wt., 31 paź 2023 o 09:27 Jean-Baptiste Onofré napisał(a): > Hi guys, > > I would like to propose to move from Jira to GH Issues and from > Jenkins to GH Actions. > > As we have several sub-projects, each sub-project will have its own > space, like we do for Karaf Minho > (https://github.com/apache/karaf-minho). > > The migration should be "smooth" and I will work on it if you agree. > > Thoughts ? > > Regards > JB >
[ANN] Pax Web 8.0.24 and 9.0.13 released
Hello I'd like to announce new bugfix releases of Pax Web: 8.0.24 and 9.0.13. Current runtime versions are: - Jetty 9.4.53.v20231009 (8.0.x) and 10.0.17 (9.0.x) - Tomcat 9.0.82 - Undertow 2.2.28.Final There's one fix for a problem reported by Amichai Rothman as https://issues.apache.org/jira/browse/KARAF-7773. It is a case where - dynamic filters registered by ServletContextListeners are not destroyed by Jetty - ServletContextListeners are not removed during WAB undeployment For completeness, the changelogs are available for 8.0.24[1] and 9.0.13[2]. kind regards Grzegorz Grzybek === [1]: https://github.com/ops4j/org.ops4j.pax.web/milestone/254?closed=1 [2]: https://github.com/ops4j/org.ops4j.pax.web/milestone/255?closed=1
[ANN] Pax Web 8.0.23 and 9.0.12 released
Hello I'd like to announce new minor releases of Pax Web: 8.0.23 and 9.0.12. Current runtime versions are: - Jetty 9.4.53.v20231009 (8.0.x) and 10.0.17 (9.0.x) - Tomcat 9.0.82 - Undertow 2.2.28.Final These are important fixes related to recent CVE-2023-44487: HTTP/2 Rapid Reset Attack <https://nvd.nist.gov/vuln/detail/CVE-2023-44487>. There's also a minor QoL improvements/fixes: - OSGi security (ServletContextHelper.handleSecurity()) - user was not visible in access log (thanks François de Parscau!) - Keycloak 19+ (up to 22) integration was not complete - Additional Tomcat valves (from context.xml) were removed on restart (thanks Stephan Siano!) - ServletContext.getServletContextName() returned wrong value for WABs (thanks Amichai Rothman!) For completeness, the changelogs are available for 8.0.23[1] and 9.0.12[2]. kind regards Grzegorz Grzybek === [1]: https://github.com/ops4j/org.ops4j.pax.web/milestone/252?closed=1 [2]: https://github.com/ops4j/org.ops4j.pax.web/milestone/253?closed=1
[ANN] Pax Logging 2.2.5 and 1.12.8 released
Hello I'd like to announce minor releases of Pax Logging 1.12.8 (OSGi R6) and 2.2.5 (OSGi R8). The upgrades are: - Log4j2 2.21.0 - Logback 1.3.11 And thanks to Wouter Born <https://github.com/wborn>, pax-logging-log4j2 and pax-logging-logback source jars include source code of related Log4j2 / Logback libraries. The release notes can be found using the following links: - 2.2.5: https://github.com/ops4j/org.ops4j.pax.logging/milestone/114?closed=1 - 1.12.8: https://github.com/ops4j/org.ops4j.pax.logging/milestone/113?closed=1 kind regards Grzegorz Grzybek
Re: [UPDATE] Karaf WebConsole has issues with Karaf 4.4.4
Hello A little updated - because of CVE-2023-44487 (HTTP/2 rapid reset attack) I was waiting for updates to Undertow, Jetty and Tomcat. Undertow has been released few hours ago, so I'm releasing new Pax Web today. But I found new version of Log4j2 (2.21.0) and I'm releasing Pax Logging first. kind regards Grzegorz Grzybek śr., 18 paź 2023 o 07:43 Jean-Baptiste Onofré napisał(a): > Hey guys > > As we have new pax web releases now, I’m resuming fixes and upgrade in > preparation for releases. > > Regards > JB > > Le dim. 1 oct. 2023 à 18:39, Jean-Baptiste Onofré a > écrit : > >> Hi Robert >> >> Sure, I will (I have other stuff to include anyway :)). >> >> Regards >> JB >> >> On Sun, Oct 1, 2023 at 8:32 AM Robert Varga wrote: >> > >> > Hey JB,Can you also look at including aries-proxy-1.1.14? It needs the >> usual ASM bump to not fail when run on Java 21.Thanks,Robert Sent from my >> Galaxy >> > Original message From: Jean-Baptiste Onofré < >> j...@nanthrax.net> Date: 10/1/23 07:33 (GMT+01:00) To: dev < >> dev@karaf.apache.org>, user Subject: [UPDATE] >> Karaf WebConsole has issues with Karaf 4.4.4 Hi guys,I created >> https://issues.apache.org/jira/browse/KARAF-7769Since the Felix >> WebConsole update, the Karaf WebConsole plugins(features, gogo, ...) don't >> load correctly.I'm fixing that and I will quickly submit Karaf 4.4.5 to >> vote.Sorry for the inconvenience;RegardsJB >> >
Re: [UPDATE] Karaf WebConsole has issues with Karaf 4.4.4
I'll check it tomorrow, as Pax Web has itests related to WebConsole - I'll update the version in Pax Web itself and check. regards Grzegorz Grzybek niedz., 1 paź 2023 o 07:32 Jean-Baptiste Onofré napisał(a): > Hi guys, > > I created https://issues.apache.org/jira/browse/KARAF-7769 > > Since the Felix WebConsole update, the Karaf WebConsole plugins > (features, gogo, ...) don't load correctly. > I'm fixing that and I will quickly submit Karaf 4.4.5 to vote. > > Sorry for the inconvenience; > Regards > JB >
Re: [INFO] main branch has been updated to 4.5.0-SNAPSHOT
Hello Few years ago, when I started thinking about javax → jakarta move (IMO one of the biggest mistakes in Java history), I thought that it'll be a tough problem for OSGi... However it turns out that https://docs.osgi.org/specification/osgi.cmpn/8.1.0/ somehow tries to live with this (wrt web stuff): - chapter 102 (HttpService with direct API to `registerServlet()`) is gone - chapter 128 (Web Applications) is not touched a lot and still refers to javax, but only for "loose" dependencies, as it's not an API chapter, only high level chapter about WARs and WABs. So if underlying web technology moves to jakarta, it's straightforward to migrate - chapter 140 (Whiteboard) is renamed to from "Http Whiteboard Specification" to "Whiteboard Specification for Jakarta™ Servlet" and it's the most important change Mind that I have no idea about other javax stuff (JPA? JTA?): - 123 JTA Transaction Services Specification - is still about javax.transaction (mind that javax.transaction.xa is NOT going to be Jakartified, as it's part of JavaSE - another reason it's a silly move) - 127 JPA Service Specification is still about javax.persistence - 147 Transaction Control Service Specification still mentions javax.transaction and javax.persistence - 151 Whiteboard Specification for Jakarta™ RESTful Web Services is moved to jakarta - 152 CDI Integration Specification is still about javax.enterprise So while I really work on Pax Web 10 (see https://github.com/ops4j/org.ops4j.pax.web/issues/1802), I'm not sure who (if anyone) will deal with JPA, JTA and CDI stuff... Also FYI, there are proposals: - https://github.com/osgi/osgi/issues/575 - jakarta websockets (at OSGi WG meeting I mentioned that Pax Web already supports WebSocket whiteboard pattern) - https://github.com/osgi/osgi/issues/587 - Jakarta WS (SOAP) Yes this SOAP. And about Karaf 5 - I fully agree that if it arrives, it should be like Spring Boot 3 - get rid of javax (where possible) and move to jakarta. And yes - it's OSGi, so we can have 13 Guava versions installed (yep - I've seen it) and we can have 4 Servlet API versions too. However Pax Web 10 will NOT support both javax and jakarta runtimes - it _may_ do whiteboarding of javax.servlet.http.HttpServlet services, but only to wrap them and register in (as of 2023-09): - Jetty 12 - Tomcat 10.1 (Tomcat 11 is for Servlet API 6.1 and JDK 21) - Undertow 2.3 I hope you'll find this summary useful. regards Grzegorz Grzybek czw., 21 wrz 2023 o 23:05 Łukasz Dywicki napisał(a): > I guess we could lift version, other projects (ie. ActiveMQ) aim jakarta > in next major version. For them its more of the JMS API change, for us > its more of other dependencies. > However, it is not entirely clear to me how the osgi specs will go, > cause we have there some to follow. I know pax stuff is going to > deliver, its just a question of "compatibility". > I wouldn't hold a breath on spec alignment, but having some clear guide > of how 5.0 will work with new/old stuff can help us evangelizing > community about possible troubles or further work ahead of them. > > Cheers, > Łukasz > > On 21.09.2023 19:52, Matt Pavlovich wrote: > > Hi JB- > > > > For Jakarta-based Karaf, should we go ahead and call it Karaf 5.0.0? > > > > -Matt > > > >> On Sep 21, 2023, at 10:45 AM, Jean-Baptiste Onofré > wrote: > >> > >> Hi guys, > >> > >> now that we released Karaf OSGi runtime 4.4.4 and 4.3.10: > >> - I updated main branch to use 4.5.0-SNAPSHOT branch > >> - I created karaf-4.4.x branch > >> > >> As a reminder, karaf-4.3.x will move "not active" when the first 4.5.0 > >> version will be released. > >> > >> Regards > >> JB > > >
[ANN] Pax Logging 2.2.4 and 1.12.7 released
Hello I'd like to announce minor releases of Pax Logging 1.12.7 (OSGi R6) and 2.2.4 (OSGi R8). There's only one NPE fix in pax-logging-api bundle. The short release notes can be found using the following links: - 2.2.4: https://github.com/ops4j/org.ops4j.pax.logging/milestone/112?closed=1 - 1.12.7: https://github.com/ops4j/org.ops4j.pax.logging/milestone/111?closed=1 kind regards Grzegorz Grzybek
Re: [VOTE] Apache Karaf OSGi runtime 4.3.10 release
+1 regards Grzegorz Grzybek czw., 14 wrz 2023 o 20:44 Serge Huber napisał(a): > Thanks JB, > > +1 (non-binding) > > from me ! > > cheers, > Serge... > > On Thu, Sep 14, 2023 at 6:34 PM Jean-Baptiste Onofré > wrote: > > > Hi guys, > > > > I submit Apache Karaf OSGi runtime 4.3.10 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) > > > > You can take a look on the Release Notes for details: > > > > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12352694 > > > > Maven Staging Repository: > > https://repository.apache.org/content/repositories/orgapachekaraf-1188/ > > > > Dist Staging Repository: > > https://dist.apache.org/repos/dist/dev/karaf/4.3.10/ > > > > Git tag: > > karaf-4.3.10 > > > > 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 OSGi runtime 4.4.4 release
+1 Thanks! regards Grzegorz Grzybek wt., 12 wrz 2023 o 17:06 Jean-Baptiste Onofré napisał(a): > 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 >
[ANN] Pax Web 8.0.22 and 9.0.11 released
Hello I'd like to announce new minor releases of Pax Web: 8.0.22 and 9.0.11. Current runtime versions are: - Jetty 9.4.52.v20230823 (8.0.x) and 10.0.16 (9.0.x) - Tomcat 9.0.80 - Undertow 2.2.26.Final There's also a minor fix related to "secure" flag for a connector (connector WAS secure, but it was displayed as normal). For completeness, the changelogs are available for 8.0.22[1] and 9.0.11[2]. kind regards Grzegorz Grzybek === [1]: https://github.com/ops4j/org.ops4j.pax.web/milestone/249?closed=1 [2]: https://github.com/ops4j/org.ops4j.pax.web/milestone/250?closed=1
[ANN] Pax Web 8.0.21 and 9.0.10 released (was: [ANN] Pax Web 8.0.20 and 9.0.9 released)
Sorry for wrong subject line (forward of previous ANN email...) śr., 26 lip 2023 o 16:48 Grzegorz Grzybek napisał(a): > Hello > > I'd like to announce new minor releases of Pax Web: 8.0.21 and 9.0.10. > > Current runtime versions are: > >- Jetty 9.4.51.v20230217 (8.0.x) and 10.0.15 (9.0.x) >- Tomcat 9.0.78 >- Undertow 2.2.25.Final > > For completeness, the changelogs are available for 8.0.21[1] and 9.0.10[2]. > > kind regards > Grzegorz Grzybek > === > [1]: https://github.com/ops4j/org.ops4j.pax.web/milestone/247?closed=1 > [2]: https://github.com/ops4j/org.ops4j.pax.web/milestone/248?closed=1 > >
Fwd: [ANN] Pax Web 8.0.20 and 9.0.9 released
Hello I'd like to announce new minor releases of Pax Web: 8.0.21 and 9.0.10. Current runtime versions are: - Jetty 9.4.51.v20230217 (8.0.x) and 10.0.15 (9.0.x) - Tomcat 9.0.78 - Undertow 2.2.25.Final For completeness, the changelogs are available for 8.0.21[1] and 9.0.10[2]. kind regards Grzegorz Grzybek === [1]: https://github.com/ops4j/org.ops4j.pax.web/milestone/247?closed=1 [2]: https://github.com/ops4j/org.ops4j.pax.web/milestone/248?closed=1
Re: Towards releases
Hello Pax Logging 1.12.6 + 2.2.3, Pax Transx 0.5.4, Pax JMS 1.1.3 and Pax JDBC 1.5.6 are already in Maven Central. I'm just running integration tests on Pax Web 8.0.21 and 9.0.10 and these releases should be in Maven Central in <1 hour. Thanks for the patience and sorry for delay! regards Grzegorz Grzybek wt., 25 lip 2023 o 07:52 Jean-Baptiste Onofré napisał(a): > OK great. I will update in Karaf (we can wait one more day for the > release, no problem at all). > > Regards > JB > > On Tue, Jul 25, 2023 at 7:40 AM Grzegorz Grzybek > wrote: > > > > Hello > > > > From Pax side, there are two driver updates in Pax JDBC and one issue I > want to investigate for Pax JMS. > > If I can't do it today (hoping to have releases for next Karaf), I'll > let you know to now wait ;) > > > > For Pax Web, I also have 8.0.21 waiting with Undertow and Tomcat > upgrades so I can prepare the releases today. > > > > regards > > Grzegorz Grzybek > > > > wt., 25 lip 2023 o 06:59 Jean-Baptiste Onofré > napisał(a): > >> > >> Hi, > >> > >> The release preparation is almost done. I'm just doing a triage on > >> Jira and I will cut the release and I will send the vote email. > >> > >> Stay tuned! > >> > >> Regards > >> JB > >> > >> On Fri, Jul 21, 2023 at 6:36 AM Jean-Baptiste Onofré > wrote: > >> > > >> > Hi guys, > >> > > >> > I know I'm super late about these releases :/ > >> > > >> > The Karaf releases (especially 4.4.4) will be in vote next week (I > >> > merged the final touches during the weekend). > >> > > >> > Regards > >> > JB > >> > > >> > On Thu, Jun 15, 2023 at 5:08 PM Jean-Baptiste Onofré > wrote: > >> > > > >> > > Hi guys, > >> > > > >> > > even if I'm a bit late on the original releases schedule, it's > almost there :) > >> > > > >> > > So stay tuned, the votes will start soon. > >> > > > >> > > Regards > >> > > JB > >> > > > >> > > On Mon, May 29, 2023 at 7:45 AM Jean-Baptiste Onofré < > j...@nanthrax.net> wrote: > >> > > > > >> > > > Hi guys, > >> > > > > >> > > > I'm doing the final touches on releases preparation. We should be > good > >> > > > for a vote this week. > >> > > > > >> > > > I will keep you posted. > >> > > > > >> > > > Regards > >> > > > JB > >> > > > > >> > > > On Mon, May 22, 2023 at 9:22 AM Jean-Baptiste Onofré < > j...@nanthrax.net> wrote: > >> > > > > > >> > > > > Hi guys, > >> > > > > > >> > > > > I made good progress on releases preparation. I will create a > bunch of > >> > > > > PR soon (starting from today). > >> > > > > > >> > > > > I should be able to submit releases to vote by the end of the > week. > >> > > > > > >> > > > > I will keep you posted. > >> > > > > > >> > > > > Regards > >> > > > > JB > >> > > > > > >> > > > > On Thu, May 4, 2023 at 4:57 PM Jean-Baptiste Onofré < > j...@nanthrax.net> wrote: > >> > > > > > > >> > > > > > Sorry guys, I'm late on the release pace. I'm now working on > releases > >> > > > > > preparation, starting from Karaf runtime. > >> > > > > > > >> > > > > > I should be able to submit a first batch of releases by the > end of this week. > >> > > > > > > >> > > > > > Regards > >> > > > > > JB > >> > > > > > > >> > > > > > On Thu, Jan 26, 2023 at 8:31 AM Jean-Baptiste Onofré < > j...@nanthrax.net> 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 >
Fwd: [ANN] Pax Transx 0.5.0, Pax JMS 1.1.0 and Pax JDBC 1.5.0 released
Hello I'd like to announce the release of three Pax projects - Pax Transx 0.5.4, Pax JMS 1.1.3 and Pax JDBC 1.5.6. This is a simultaneous release with mutual version alignment and certain amount of refreshment. The relevant changelogs are here: - Pax Transx: https://github.com/ops4j/org.ops4j.pax.transx/milestone/10?closed=1 - Pax JMS: https://github.com/ops4j/org.ops4j.pax.jms/milestone/11?closed=1 - Pax JDBC: https://github.com/ops4j/org.ops4j.pax.jdbc/milestone/32?closed=1 The notable changes are: *Pax Transx:* - Atomikos TM upgraded to 5.0.9 - Narayana TM upgraded to 5.12.7 *Pax JMS:* - Netty (tests) upgraded to 4.1.95 - pooled-jms upgraded to 1.2.4 - Narayana TM upgraded to 5.12.7 - ActiveMQ upgraded to 5.16.6 mind that Pax JMS works with newer versions of Artemis and ActiveMQ. Simply we want to keep JDK8 compatibility *Pax JDBC:* - MS SQL driver upgraded to 12.3.1 - Oracle driver upgraded to 23.2.0.0 - MariaDB driver upgraded to 3.1.4 - MySQL driver upgraded to 8.1.0 - SQLite driver upgraded to 3.42.0.0 - PostgreSQL driver upgraded to 42.6.0 - HSQLDB driver upgraded to 2.7.2 - H2 driver upgraded to 2.2.220 - Narayana TM upgraded to 5.12.7 kind regards Grzegorz Grzybek
Fwd: [ANN] Pax Logging 2.2.2 and 1.12.5 released
Hello
I'd like to announce minor releases of Pax Logging 1.12.6 (OSGi R6) and
2.2.3 (OSGi R8). These releases include minor version upgrades:
- reload4j 1.2.25
- Tomcat JULI 9.0.78
- Logback 1.3.8
Also Pax Logging 2.2.3 contains a fix related to duplicate "{}" placeholder
replacement (thanks Rastislav Papp for the report!)
The short release notes can be found using the following links:
- 2.2.3:
https://github.com/ops4j/org.ops4j.pax.logging/milestone/108?closed=1
- 1.12.6:
https://github.com/ops4j/org.ops4j.pax.logging/milestone/109?closed=1
kind regards
Grzegorz Grzybek
Re: Towards releases
Hello >From Pax side, there are two driver updates in Pax JDBC and one issue I want to investigate for Pax JMS. If I can't do it today (hoping to have releases for next Karaf), I'll let you know to now wait ;) For Pax Web, I also have 8.0.21 waiting with Undertow and Tomcat upgrades so I can prepare the releases today. regards Grzegorz Grzybek wt., 25 lip 2023 o 06:59 Jean-Baptiste Onofré napisał(a): > Hi, > > The release preparation is almost done. I'm just doing a triage on > Jira and I will cut the release and I will send the vote email. > > Stay tuned! > > Regards > JB > > On Fri, Jul 21, 2023 at 6:36 AM Jean-Baptiste Onofré > wrote: > > > > Hi guys, > > > > I know I'm super late about these releases :/ > > > > The Karaf releases (especially 4.4.4) will be in vote next week (I > > merged the final touches during the weekend). > > > > Regards > > JB > > > > On Thu, Jun 15, 2023 at 5:08 PM Jean-Baptiste Onofré > wrote: > > > > > > Hi guys, > > > > > > even if I'm a bit late on the original releases schedule, it's almost > there :) > > > > > > So stay tuned, the votes will start soon. > > > > > > Regards > > > JB > > > > > > On Mon, May 29, 2023 at 7:45 AM Jean-Baptiste Onofré > wrote: > > > > > > > > Hi guys, > > > > > > > > I'm doing the final touches on releases preparation. We should be > good > > > > for a vote this week. > > > > > > > > I will keep you posted. > > > > > > > > Regards > > > > JB > > > > > > > > On Mon, May 22, 2023 at 9:22 AM Jean-Baptiste Onofré < > j...@nanthrax.net> wrote: > > > > > > > > > > Hi guys, > > > > > > > > > > I made good progress on releases preparation. I will create a > bunch of > > > > > PR soon (starting from today). > > > > > > > > > > I should be able to submit releases to vote by the end of the week. > > > > > > > > > > I will keep you posted. > > > > > > > > > > Regards > > > > > JB > > > > > > > > > > On Thu, May 4, 2023 at 4:57 PM Jean-Baptiste Onofré < > j...@nanthrax.net> wrote: > > > > > > > > > > > > Sorry guys, I'm late on the release pace. I'm now working on > releases > > > > > > preparation, starting from Karaf runtime. > > > > > > > > > > > > I should be able to submit a first batch of releases by the end > of this week. > > > > > > > > > > > > Regards > > > > > > JB > > > > > > > > > > > > On Thu, Jan 26, 2023 at 8:31 AM Jean-Baptiste Onofré < > j...@nanthrax.net> 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: karaf-4.5.x?
Hello For 2.2.x, Pax Logging 2.2.1 was the version where SLF4J 2.0 packages are exported (see: #504 <https://github.com/ops4j/org.ops4j.pax.logging/issues/504>[1]). Mind that the API for SLF4J didn't really change and the "big" thing is different discovery of logging implementation (that's why outside of OSGi, SLF4J 2.0 has to be combined with Logback 1.3+ or dedicated log4j-slf4j2-impl). It doesn't really impact Pax Logging users. regards Grzegorz Grzybek === [1]: https://github.com/ops4j/org.ops4j.pax.logging/issues/504 pt., 21 lip 2023 o 06:35 Jean-Baptiste Onofré napisał(a): > Hi > > I'm working on Karaf releases and plan to create 4.5.x after 4.4.4, > I'm a bit late in the preparation but the releases votes are planned > for next week. > > However, regarding slf4j 2, Pax Logging already exports the packages > so I have to check the Pax Logging versions used in Karaf. > > Regards > JB > > On Thu, Jul 20, 2023 at 7:54 PM Łukasz Dywicki > wrote: > > > > I am reactivating this thread because I just ran into issue with > > dependency which pulls slf4j 2.0.x API. > > Given it is already 6 months since last message in this topic, is it > > right time to start 4.5.x branch? > > > > Cheers, > > Łukasz > > > > On 13.01.2023 07:23, Jean-Baptiste Onofré wrote: > > > Hi Robert, > > > > > > It makes sense. I will prepare 4.5.x on Jira and I will create the > > > 4.4.x branch and move main on the 4.5.x version. > > > > > > Let me first complete the 4.3.9 release and other Decanter/Cellar > > > releases first. > > > > > > Thanks ! > > > Regards > > > JB > > > > > > On Thu, Jan 12, 2023 at 9:45 PM Robert Varga wrote: > > >> > > >> On 08/01/2023 08:33, Mark Derricutt wrote: > > >>> On 8 Jan 2023, at 20:14, Jean-Baptiste Onofré wrote: > > >>> > > >>>> Java 11 is not a point as it's already used on Karaf 4.4.x. > > >>> > > >>> Altho it seems we can run Karaf 4.4.x under JDK 8 - so now I'm > curious. > > >>> I assume nothings being targeting JDK 9+ byte code then. > > >> > > >> Right, the karaf-4.4 contract is "YMMV". My proposal here is to switch > > >> to "./bin/karaf will refuse to run unless you have a JAVA_HOME that > > >> points to Java 11+". > > >> > > >> Regards, > > >> Robert >
Re: Board Report for June 2023
+1 regards Grzegorz Grzybek śr., 7 cze 2023 o 17:13 Francois Papon napisał(a): > Look good to me! > > Thanks JB! > > regards, > > On 06/06/2023 10:53, Jean-Baptiste Onofré wrote: > > Hi guys, > > > > I prepared the board report for this month: > > > > https://cwiki.apache.org/confluence/display/KARAF/Board+Reports > > > > Please take a look and update if needed. I would like to send the report > asap. > > > > Thanks ! > > Regards > > JB >
Re: which is the right way to use Spring MVC and Spring Security in Karaf?
Hello If you are new to Spring and know a bit more about OSGi then there's some explanation required. - spring-mvc (and spring-web) helps you a lot with standard JavaEE web applications (where you have a WAR application with WEB-INF/web.xml). With Spring you need only one Servlet - the "dispatcher servlet" and the rest is handled by Spring, including various (better than JSP) view technologies like Thymeleaf) - Spring DM (a.k.a. Spring OSGi) is ancient Spring project from the golden age of OSGi around the time of Spring 2.5/3.0 and is no longer maintained, which means Spring has no interest in integration Spring's application context's lifecycle to OSGi lifecycle - OSGi on the other hand always promoted separation of deployments (bundles / packages) where your applications are sets of bundles working together (or not being aware of each other if needed) Karaf itself, for web purposes uses Pax Web project. And with Karaf 4.4 it's Pax Web 8 which is complete refactor of previous versions. Most of the functionality is not changed, just polished and made consistent across different runtimes (Jetty, Tomcat, Undertow). The easiest way to use Spring MVC application is to use pure WAB installed using webbundle: URI. Pax Web has two samples: - https://github.com/ops4j/org.ops4j.pax.web/tree/web-8.0.20/samples/samples-war/war-spring - https://github.com/ops4j/org.ops4j.pax.web/tree/web-8.0.20/samples/samples-war/war-spring-wired The first one is full WAR with Spring libraries packaged in WEB-INF/lib and it has to be installed using webbundle:mvn:org.ops4j.pax.web.samples/war-spring/8.0.20/war?Web-ContextPath=/path-of-your-choice The second one is a WAB (Web Application Bundle) which can be installed with mvn:org.ops4j.pax.web.samples/war-spring-wired/8.0.20/war, but the dependencies (Spring libraries) have to be installed separately - for example using Karaf's "spring" and "spring-web" features. The first approach is easier, but less in the spirit of OSGi. Please have a look at the samples (available directly from Maven Central: https://repo1.maven.org/maven2/org/ops4j/pax/web/samples/ and if you have more questions, do not hesitate to ask here. regards Grzegorz Grzybek śr., 19 kwi 2023 o 21:52 z8...@yahoo.com.ar.INVALID napisał(a): > Hi, I'm tyring to use Spring MVC to expose some business logic already > coded in bundles through @Controller endpoints and secure them using Spring > Security. > > In 4.2.15, when installing spring-security feature, the following > dependencies are added: > karaf@root()> feature:install spring-securitykaraf@root()> la | grep -i > spring 69 | Active | 30 | 5.3.9.1 | Apache ServiceMix :: Bundles :: > spring-aop 70 | Active | 30 | 5.3.9.1 | Apache ServiceMix :: Bundles :: > spring-beans 71 | Active | 30 | 5.3.9.1 | Apache ServiceMix :: Bundles > :: spring-context 72 | Active | 30 | 5.3.9.1 | Apache ServiceMix :: > Bundles :: spring-context-support 73 | Active | 30 | 5.3.9.1 | Apache > ServiceMix :: Bundles :: spring-core 74 | Active | 30 | 5.3.9.1 | > Apache ServiceMix :: Bundles :: spring-expression 75 | Active | 30 | > 5.3.9.1 | Apache ServiceMix :: Bundles :: spring-jdbc 76 | Active | 30 > | 5.4.6.1 | Apache ServiceMix :: Bundles :: spring-security-acl 77 | > Active | 30 | 5.4.6.1 | Apache ServiceMix :: Bundles :: > spring-security-config 78 | Active | 30 | 5.4.6.1 | Apache ServiceMix > :: Bundles :: spring-security-core 79 | Active | 30 | 5.4.6.1 | Apache > ServiceMix :: Bundles :: spring-security-taglibs 80 | Active | 30 | > 5.4.6.1 | Apache ServiceMix :: Bundles :: spring-security-web 81 | Active > | 30 | 5.3.9.1 | Apache ServiceMix :: Bundles :: spring-tx 82 | Active > | 30 | 5.3.9.1 | Apache ServiceMix :: Bundles :: spring-web 83 | Active > | 30 | 5.3.9.1 | Apache ServiceMix :: Bundles :: spring-webmvc > > As far as I understand (I'm very new to Spring) if there's a > spring-security feature, It can be use, more, you could use Spring to code > your bundles, but I'm very confused.Since the feature adds spring-web > and spring-webmvc dependencies, It means that I will be using Spring MVC, > which is "programatically" different from Spring Boot. Also, I found that > there's something called Spring Dynamic Modules which google/stackoverflow > says it's already dead (or almost). > > How should I use Spring MVC in Karaf? How could a bundle activator starts > a Spring app? Does anyonw have an example on using Spring MVC and Spring > Security in Karaf? > Thank you very much in advanced.Nick. > >
[ANN] Pax Web 8.0.20 and 9.0.9 released
Hello I'd like to announce new minor releases of Pax Web: 8.0.20 and 9.0.9. Current runtime versions are: - Jetty 9.4.51.v20230217 (8.0.x) and 10.0.15 (9.0.x) - Tomcat 9.0.74 - Undertow 2.2.24.Final There's one important change. Johannes Utzig reported slow deployment times in real-world, complex Karaf installation. He found that WAB deployment involved "scanning" of all transitive bundles, while in fact the proper way to scan a WAB is to scan: - /WEB-INF/classes and /WEB-INF/*.jar of the WAB - or generally - all WAB's entries from Bundle-ClassPath manifest - all attached WAB OSGi bundle fragments - all bundles "wired" to the WAB (and its fragments) using Import-Package, Require-Bundle and "osgi.extender" namespace The scanning however should NOT be transitive (because otherwise we can reach thousands of bundles). Also, this release, together with Pax URL 2.6.14 *fully passes official OSGi CMPN TCK for Web Applications specification!* (OSGi CMPN chapter 128). For completeness, the changelogs is available for 8.0.20[1] and 9.0.9[2]. kind regards Grzegorz Grzybek === [1]: https://github.com/ops4j/org.ops4j.pax.web/milestone/245?closed=1 [2]: https://github.com/ops4j/org.ops4j.pax.web/milestone/246?closed=1
[ANN] Pax URL 2.6.14 released
Hello I'd like to announce the release of Pax URL 2.6.14. This is a minor release that adds two small changes related to OSGi CMPN TCK. With these changes, Pax Web 8 (released later today) *passes entire official TCK for OSGi CMPN Web Applications specification* Also thanks Tamas Cservenak for polishing the build/plugin versions. Full changelog can be found here[1]. kind regards Grzegorz Grzybek === [1]: https://github.com/ops4j/org.ops4j.pax.url/milestone/79?closed=1
Re: [ANN] Pax URL 2.6.13 released
Hello pt., 14 kwi 2023 o 22:35 Mark Derricutt napisał(a): > On 7 Apr 2023, at 1:08, Grzegorz Grzybek wrote: > > This is a minor release fixing Aether session memory leak (thanks to > > Does this update Aether/maven-resolver to the current version, that > supports the new split-repositories? > > I raised a ticket for Karaf itself, but forgot I meant to raised it on > pax-url - see my blog post on it: > > > https://www.theoryinpractice.net/post/708585430266855424/healing-the-poisoned-repository > > Mark > There's a similar issue created for Pax URL: https://github.com/ops4j/org.ops4j.pax.url/issues/417 Feel free to add your comments there. regards Grzegorz Grzybek > -- > "Great artists are extremely selfish and arrogant things" — Steven Wilson, > Porcupine Tree > > On Fri, Apr 7, 2023 at 1:09 AM Grzegorz Grzybek > wrote: > > Hello > > I'd like to announce the release of Pax URL 2.6.13. > > This is a minor release fixing Aether session memory leak (thanks to > GH@bhe-talendbj). > Also there are some changes to "webbundle:" handler to greatly improve Pax > Web's TCK coverage. > > Full changelog can be found here[1]. > > kind regards > Grzegorz Grzybek > === > [1]: https://github.com/ops4j/org.ops4j.pax.url/milestone/78?closed=1 > >
[ANN] Pax Web 8.0.19 and 9.0.8 released
Hello I'd like to announce new minor releases of Pax Web: 8.0.19 and 9.0.8. Current runtime versions are: - Jetty 9.4.51.v20230217 (8.0.x) and 10.0.14 (9.0.x) - Tomcat 9.0.73 - Undertow 2.2.23.Final Besides single improvement (allow custom Tomcat Server implementation - thanks Mathias Schwaninger!), this release is a step toward OSGi CMPN TCK compliance. I was experimenting with public TCK tests from https://github.com/osgi/osgi/ project (only CPMN Web Applications specification for now) and 136 tests pass out of 138 (I've created osgi/osgi issues for the two remaining tests). I'm going to check Whiteboard and HttpService TCK tests soon. For completeness, the changelogs is available for 8.0.19[1] and 9.0.8[2]. kind regards Grzegorz Grzybek === [1]: https://github.com/ops4j/org.ops4j.pax.web/milestone/243?closed=1 [2]: https://github.com/ops4j/org.ops4j.pax.web/milestone/244?closed=1
[ANN] Pax URL 2.6.13 released
Hello I'd like to announce the release of Pax URL 2.6.13. This is a minor release fixing Aether session memory leak (thanks to GH@bhe-talendbj). Also there are some changes to "webbundle:" handler to greatly improve Pax Web's TCK coverage. Full changelog can be found here[1]. kind regards Grzegorz Grzybek === [1]: https://github.com/ops4j/org.ops4j.pax.url/milestone/78?closed=1
Re: Towards releases
Hello Traditional hijacking to mention Pax Web. I've played a bit with OSGi CMPN TCK and out of 3 CMPN "chapters" (102 - HttpService, 128 - Web Applications, 140 - Whiteboard Service), here are the results of running Pax Web 8.0.18 and Pax URL 2.6.12 with tiny fixes for "web container tests" (Chapter 128): Test run finished after 211979 ms [16 containers found ] [ 0 containers skipped] [16 containers started] [ 0 containers aborted] [16 containers successful ] [ 0 containers failed ] [ 138 tests found ] [ 0 tests skipped ] [ 138 tests started ] [ 0 tests aborted ] [ 136 tests successful ] [ 2 tests failed ] Those two failing tests are related to: - https://github.com/osgi/osgi/issues/577 - https://github.com/osgi/osgi/issues/578 So far, OSGi TCK for CMPN 128 was based on Eclipse Virgo + Eclipse Gemini servers. The point is that I want to release Pax Web 8.0.19 and Pax URL 2.6.13 today or tomorrow. +Jean-Baptiste Onofré - do I have few days? regards Grzegorz Grzybek czw., 6 kwi 2023 o 09:57 Romain Manni-Bucau napisał(a): > +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 > > >
[ANN] Pax Web 8.0.18 and 9.0.7 released
Hello I'd like to announce new minor releases of Pax Web: 8.0.18 and 9.0.7. Current runtime versions are: - Jetty 9.4.51.v20230217 (8.0.x) and 10.0.14 (9.0.x) - Tomcat 9.0.73 - Undertow 2.2.23.Final There's new Karaf feature called "pax-web-jetty-http2-extras" which includes additional, client-side http2 Jetty bundles. And existing "pax-web-jetty-extras" feature contains two additional Jetty bundles. For completeness, the changelogs is available for 8.0.18[1] and 9.0.7[2]. kind regards Grzegorz Grzybek === [1]: https://github.com/ops4j/org.ops4j.pax.web/milestone/241?closed=1 [2]: https://github.com/ops4j/org.ops4j.pax.web/milestone/242?closed=1
Re: Board Report for March 2023
+1 Thanks! regards Grzegorz Grzybek pon., 6 mar 2023 o 14:10 Jean-Baptiste Onofré napisał(a): > Hi guys, > > I prepared the board report for this month: > > https://cwiki.apache.org/confluence/display/KARAF/Board+Reports > > Please take a look if it's OK for you. I would like to submit the report > asap. > > Thanks ! > Regards > JB >
[ANN] Pax Web 8.0.17 and 9.0.6 released
Hello I'd like to announce new minor releases of Pax Web: 8.0.17 and 9.0.6. These versions are tiny improvements over previous 8.0.16 and 9.0.5 releases. Thanks to Maurice Betzel <https://github.com/Maurice-Betzel> we've repackaged Keycloak 21 which has just been released too. So Pax Web will support / package: - Keycloak 18.0.x which still contains something called "Fuse Adapters" (a.k.a. Pax Web Adapters) - Current major upstream Keycloak upgrade which is now 21.0.0 Current runtime versions are still: - Jetty 9.4.50.v20221201 (8.0.x) and 10.0.13 (9.0.x) - Tomcat 9.0.72 - Undertow 2.2.23.Final For completeness, the changelogs is available for 8.0.17[1] and 9.0.6[2]. kind regards Grzegorz Grzybek === [1]: https://github.com/ops4j/org.ops4j.pax.web/milestone/239?closed=1 [2]: https://github.com/ops4j/org.ops4j.pax.web/milestone/240?closed=1
[ANN] Pax Web 8.0.16 and 9.0.5 released
Hello I'd like to announce new minor releases of Pax Web: 8.0.16 and 9.0.5. Current runtime versions are: - Jetty 9.4.50.v20221201 (8.0.x) and 10.0.13 (9.0.x) - Tomcat 9.0.72 - Undertow 2.2.23.Final Another corner case was solved when WAB, Whiteboard and HttpService registered web elements were registered into the same target context (a case originally called "Where is JSF Support?"). A feature from Pax Web 7 is back - now both WebContainer (an extension to standard HttpService) and Whiteboard (this is new - there was no such option in Pax Web 7) can be used to register security configuration: - login config - security constraints - security roles A new whiteboard-security sample was added here: https://github.com/ops4j/org.ops4j.pax.web/tree/web-8.0.16/samples/samples-whiteboard/whiteboard-security And finally I've reviewed Pax Web 7 support for Keycloak. In Pax Web 7 it worked only in Undertow runtime (mostly due to problems on Keycloak side). Now there are new Karaf features that ensure that Pax Web 8/9 can integrate with Keycloak 18 (which contains something called "Fuse Adapters") and Keycloak 20 (where "Fuse Adapters" were removed). These features are: - pax-web-jetty-keycloak18 - pax-web-tomcat-keycloak18 - pax-web-undertow-keycloak18 - pax-web-jetty-keycloak20 - pax-web-tomcat-keycloak20 - pax-web-undertow-keycloak20 The "keycloak18" features are designed to work with Keycloak 18.0.x and require this feature repository: "mvn:org.keycloak/keycloak-osgi-features/18.0.3/xml/features" The "keycloak20" features do NOT require Keycloak features (because Keycloak 19 has them removed) and Pax Web itself repackages proper Keycloak libraries (because not all of them are proper OSGi bundles). If you want to know more about how I tested Pax Web with Keycloak, please look at the readme files: - https://github.com/ops4j/org.ops4j.pax.web/blob/web-8.0.16/pax-web-keycloak18/readme.adoc - https://github.com/ops4j/org.ops4j.pax.web/blob/web-8.0.16/pax-web-keycloak20/readme.adoc For completeness, the changelogs is available for 8.0.16[1] and 9.0.5[2]. kind regards Grzegorz Grzybek === [1]: https://github.com/ops4j/org.ops4j.pax.web/milestone/238?closed=1 [2]: https://github.com/ops4j/org.ops4j.pax.web/milestone/237?closed=1
[ANN] Pax Logging 2.2.2 and 1.12.5 released
Hello After previous more important release of Pax Logging 2.2.1 and 1.12.4 where SLF4J 2.0 support was added, I'd like to announce minor releases where only Log4j2 version was upgraded to 2.20.0. The short release notes can be found using the following links: - 2.2.2: https://github.com/ops4j/org.ops4j.pax.logging/milestone/104?closed=1 - 1.12.5: https://github.com/ops4j/org.ops4j.pax.logging/milestone/106?closed=1 kind regards Grzegorz Grzybek
Re: [PROPOSAL] Create integration (ServiceMix like) distribution in Karaf OSGi runtime
Hello I don't know much about SMX distributions (except SMX bundles), but having a Karaf distro with ready-to-use Camel + CXF + ActiveMQ sounds like a good idea. regards Grzegorz Grzybek śr., 18 sty 2023 o 13:44 Jean-Baptiste Onofré napisał(a): > 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: Unable to start Pax-Web 8.0.6 by using PFX Certificate.
Hello
Having just:
in KARAF_HOME/etc/jetty.xml is not enough to have proper SSL configuration.
In Karaf, when you install "pax-web-http-jetty" you'll get
KARAF_HOME/etc/org.ops4j.pax.web.cfg template with this section:
# secure connector configuration
org.osgi.service.http.secure.enabled = false
#org.osgi.service.http.port.secure = 8443
#org.ops4j.pax.web.ssl.truststore = ${karaf.etc}/server.keystore
#org.ops4j.pax.web.ssl.truststore.password = passw0rd
#org.ops4j.pax.web.ssl.truststore.type = JKS
#org.ops4j.pax.web.ssl.keystore = ${karaf.etc}/server.keystore
#org.ops4j.pax.web.ssl.keystore.password = passw0rd
#org.ops4j.pax.web.ssl.keystore.type = JKS
#org.ops4j.pax.web.ssl.key.password = passw0rd
#org.ops4j.pax.web.ssl.key.alias = server
#org.ops4j.pax.web.ssl.clientauth.needed = false
#org.ops4j.pax.web.ssl.protocols.included = TLSv1.3
#org.ops4j.pax.web.ssl.protocol = TLSv1.3
#org.ops4j.pax.web.ssl.protocols.included = TLSv1.2 TLSv1.3
#org.ops4j.pax.web.ssl.ciphersuites.included =
TLS_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_256_GCM_SHA384
#org.ops4j.pax.web.ssl.secureRandom.algorithm = NativePRNGNonBlocking
#org.ops4j.pax.web.ssl.renegotiationAllowed = true
#org.ops4j.pax.web.ssl.session.enabled = true
so you can use it for SSL configuration. Next week I'll check what's the
actual problem with your config - see here for follow-up:
https://github.com/ops4j/org.ops4j.pax.web/issues/1821
regards
Grzegorz Grzybek
pt., 13 sty 2023 o 15:31 Vamsikrishna Koka
napisał(a):
> + dev@karaf.apache.org<mailto:dev@karaf.apache.org>
>
> From: Vamsikrishna Koka
> Sent: 13 January 2023 19:16
> To: u...@karaf.apache.org; iss...@karaf.apache.org
> Subject: RE: Unable to start Pax-Web 8.0.6 by using PFX Certificate.
>
> Thank you so much for looking into this @Grzegorz Grzybek.
>
> What is you $KARAF_HOME/etc/org.ops4j.pax.web.cfg configuration?
>
> There is no password in org.ops4j.pax.web.cfg file. It was reading
> external configuration file. Which is jetty xml file.
>
> $KARAF_HOME/etc/org.ops4j.pax.web.cfg file :-
>
> org.osgi.service.http.port=8181
> org.osgi.service.http.secure.enabled=true
> org.osgi.service.http.port.secure=8443
> org.ops4j.pax.web.listening.addresses=127.0.0.1
> org.ops4j.pax.web.config.file = ${karaf.home}/etc/jetty.xml
> org.ops4j.pax.web.session.timeout=30
>
> $KARAF_HOME/etc/jetty.xml file :-
>
> id="sslContextFactory">
>
>name="jetty.home"/>/etc/keystores/bems.pfx
>
>name="jetty.home"/>/etc/keystores/bems.pfx
>
> OBF: password will generate after
> compilation
> OBF: : password will generate after
> compilation
> OBF: : password will generate after
> compilation
> PKCS12
> PKCS12
>
>
>
> TLSv1.1
> TLSv1
> SSL
> SSLv2
> SSLv2Hello
> SSLv3
>
>
>
> Thanks,
> Vamsi Krishna.
>
> From: Vamsikrishna Koka
> Sent: Friday, January 13, 2023 12:42 AM
> To: 'u...@karaf.apache.org' u...@karaf.apache.org>>; 'iss...@karaf.apache.org' <
> iss...@karaf.apache.org<mailto:iss...@karaf.apache.org>>;
> dev@karaf.apache.org<mailto:dev@karaf.apache.org>
> Subject: RE: Unable to start Pax-Web 8.0.6 by using PFX Certificate.
>
> Hi Team,
>
> I have migrated karaf version 4.4.1 and OpenJDK 11 also. Tried to using
> PFX file but it was failed due to given below stack trace.
>
> Please can anyone take look at once.
>
> 2023-01-12T12:53:03.265-0500 CEF:1 | org.eclipse.jetty.util |
> 9.4.48.v20220622 | WARN | ID=245 THR=ange controller)
> CAT=AbstractLifeCycleMSG=FAILED Server@21d6680d
> {FAILED}[9.4.48.v20220622<mailto:Server@21d6680d%7bFAILED%7d[9.4.48.v20220622>]:
> java.lang.NullPointerException
> java.lang.NullPointerException: null
> at
> org.eclipse.jetty.util.ssl.SslContextFactory.getKeyManagers(SslContextFactory.java:1249)
> ~[?:?]
> at
> org.eclipse.jetty.util.ssl.SslContextFactory$Server.getKeyManagers(SslContextFactory.java:2364)
> ~[?:?]
> at
> org.eclipse.jetty.util.ssl.SslContextFactory.load(SslContextFactory.java:373)
> ~[?:?]
> at
> org.eclipse.jetty.util.ssl.SslContextFactory.doStart(SslContextFactory.java:244)
> ~[?:?]
> at
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:73)
> ~[?:?]
> at
> org.eclipse.jetty.util.component.ContainerLifeCycle.start(C
Re: Unable to start Pax-Web 8.0.6 by using PFX Certificate.
Hello
What is you $KARAF_HOME/etc/org.ops4j.pax.web.cfg configuration? (please
remove the password values).
regards
Grzegorz Grzybek
czw., 12 sty 2023 o 20:14 Vamsikrishna Koka
napisał(a):
> Hi Team,
>
> I have migrated karaf version 4.4.1 and OpenJDK 11 also. Tried to using
> PFX file but it was failed due to given below stack trace.
>
> Please can anyone take look at once.
>
> 2023-01-12T12:53:03.265-0500 CEF:1 | org.eclipse.jetty.util |
> 9.4.48.v20220622 | WARN | ID=245 THR=ange controller)
> CAT=AbstractLifeCycleMSG=FAILED Server@21d6680d
> {FAILED}[9.4.48.v20220622<mailto:Server@21d6680d%7bFAILED%7d[9.4.48.v20220622>]:
> java.lang.NullPointerException
> java.lang.NullPointerException: null
> at
> org.eclipse.jetty.util.ssl.SslContextFactory.getKeyManagers(SslContextFactory.java:1249)
> ~[?:?]
> at
> org.eclipse.jetty.util.ssl.SslContextFactory$Server.getKeyManagers(SslContextFactory.java:2364)
> ~[?:?]
> at
> org.eclipse.jetty.util.ssl.SslContextFactory.load(SslContextFactory.java:373)
> ~[?:?]
> at
> org.eclipse.jetty.util.ssl.SslContextFactory.doStart(SslContextFactory.java:244)
> ~[?:?]
> at
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:73)
> ~[?:?]
> at
> org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:169)
> ~[?:?]
> at
> org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:117)
> ~[?:?]
> at
> org.eclipse.jetty.server.SslConnectionFactory.doStart(SslConnectionFactory.java:97)
> ~[?:?]
> at
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:73)
> ~[?:?]
> at
> org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:169)
> ~[?:?]
> at
> org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:117)
> ~[?:?]
> at
> org.eclipse.jetty.server.AbstractConnector.doStart(AbstractConnector.java:323)
> ~[?:?]
> at
> org.eclipse.jetty.server.AbstractNetworkConnector.doStart(AbstractNetworkConnector.java:81)
> ~[?:?]
> at
> org.eclipse.jetty.server.ServerConnector.doStart(ServerConnector.java:234)
> ~[?:?]
> at
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:73)
> ~[?:?]
> at org.eclipse.jetty.server.Server.doStart(Server.java:401) ~[?:?]
> at
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:73)
> ~[?:?]
> at
> org.ops4j.pax.web.service.jetty.internal.JettyServerWrapper.start(JettyServerWrapper.java:623)
> ~[?:?]
> at
> org.ops4j.pax.web.service.jetty.internal.JettyServerController.start(JettyServerController.java:109)
> ~[?:?]
> at
> org.ops4j.pax.web.service.internal.Activator.performConfiguration(Activator.java:551)
> ~[?:?]
> at
> org.ops4j.pax.web.service.internal.Activator.updateController(Activator.java:441)
> ~[?:?]
> at
> org.ops4j.pax.web.service.internal.Activator.lambda$updateServerControllerFactory$1(Activator.java:347)
> ~[?:?]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> ~[?:?]
> at java.util.concurrent.FutureTask.run(FutureTask.java:264) ~[?:?]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304)
> ~[?:?]
> 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) ~[?:?]
> 2023-01-12T12:53:03.281-0500 CEF:1 | org.ops4j.pax.web.pax-web-runtime |
> 8.0.6 | ERROR | ID=274 THR=ange controller) CAT=Activator
> MSG=Unable to start Pax Web server: null
> java.lang.NullPointerException: null
> at
> org.eclipse.jetty.util.ssl.SslContextFactory.getKeyManagers(SslContextFactory.java:1249)
> ~[?:?]
> at
> org.eclipse.jetty.util.ssl.SslContextFactory$Server.getKeyManagers(SslContextFactory.java:2364)
> ~[?:?]
> at
> org.eclipse.jetty.util.ssl.SslContextFactory.load(SslContextFactory.java:373)
> ~[?:?]
> at
> org.eclipse.jetty.util.ssl.SslContextFactory.doStart(SslContextFactory.java:244)
> ~[?:?]
> at
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:73)
> ~[?:?]
> at
> org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycl
Re: [VOTE] Apache Karaf OSGi runtime 4.3.9 release
+1 (binding) regards Grzegorz Grzybek śr., 11 sty 2023 o 21:02 Jean-Baptiste Onofré napisał(a): > +1 (binding) > > Regards > JB > > On Tue, Jan 10, 2023 at 6:41 PM Jean-Baptiste Onofré > wrote: > > > > Hi guys, > > > > I submit Apache Karaf OSGi runtime 4.3.9 release to your vote. > > > > This release is a maintenance release bringing a lot of dependency > > updates and fixes. > > Especially, this release includes: > > - fix threads leak in karaf-maven-plugin (in verify feature goal) > > - fix on JMX stub IP address assignation (especially on different > > docker networks) > > - re-add shell:alias command > > - fix ssh client on Windows > > - and several dependency updates ! > > > > You can take a look on the Release Notes for details: > > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12352383 > > > > Maven Staging Repository: > > https://repository.apache.org/content/repositories/orgapachekaraf-1183/ > > > > Dist Staging Repository: > > https://dist.apache.org/repos/dist/dev/karaf/4.3.9/ > > > > Git tag: > > karaf-4.3.9 > > > > Please vote to approve this release: > > [ ] +1 Approve the release > > [ ] -1 Don't approve the release (please provide specific comments) > > > > This vote will be open for at least 72 hours. > > > > Regards > > JB >
Re: [DISCUSS] Apache Karaf subprojects Roadmap
Hello I'd like to ask about: For SMX bundles, the objective is not to move as it is. The > objective it's to use the new bundle descriptor I started in Pax URL. > Karaf "Bundles" will host just the descriptor to create the bundle on > the fly (and eventually cached). The other part of SMX (assembly + > spec) can be moved in Karaf subproject. > I know that providing OSGi metadata to external 3rd party libs which do not care about OSGi is a bit PITA... (I remember back in theserverside.com days I suggested using external metadata instead of one kept in META-INF/MANIFEST.MF...) How do you imagine this on the fly generation? kind of like wrap: protocol? regards Grzegorz Grzybek pon., 9 sty 2023 o 10:20 fpapon napisał(a): > Hi JB, > > Make sense for Cave and Winegrower. > > About Camel-Karaf, as it was announced by the Camel team in the roadmap > to Camel 4, I was thinking that it was already acted: > > https://camel.apache.org/blog/2023/01/camel4roadmap/ > > I asked the question about the OSGi bundle still provide or not by Camel > team but no clear decision, Camel team don't want to provide OSGi bundle > for Camel core anymore. > > regards, > > François > > On 09/01/2023 10:13, Jean-Baptiste Onofré wrote: > > Hi François, > > > > Thanks for bringing this discussion. > > > > Here's my personal standpoint: > > 1. Decanter: I started to work on Decanter 3.x (refactoring). I think > > we can do a release now with just updates on the collectors/appenders > > before moving forward on decanter 3.x. I propose to cut new Decanter > > release asap. > > 2. Cellar: quite the same as Decanter. I plan a refactoring, but it is > > worth doing an updated version (new hazelcast, kubernetes client, > > karaf version). Same: I propose to cut new Cellar release asp. > > 3. Cave: I think we don't have many users on Cave, maybe it's worth to > > move the project to "attic" ? > > 4. Winegrower: same as Cave, I don't think we have a lot of users, > > maybe it's worth to move the project to "attic" ? > > 5. Minho: > > 6. For SMX bundles, the objective is not to move as it is. The > > objective it's to use the new bundle descriptor I started in Pax URL. > > Karaf "Bundles" will host just the descriptor to create the bundle on > > the fly (and eventually cached). The other part of SMX (assembly + > > spec) can be moved in Karaf subproject. > > 7. For camel-karaf, I'm open to community proposals. If it's better to > > have it in Karaf, I'm OK with it (same question about jclouds-karaf). > > > > Regards > > JB > > > > On Mon, Jan 9, 2023 at 10:07 AM fpapon wrote: > >> Hi, > >> > >> I want to start a thread about Apache Karaf subprojects roadmap and > >> maintainability. > >> > >> Today we have: > >> > >> - Decanter: last release on Feb. 2022 > >> > >> - Cellar: last release on Aug. 2020 > >> > >> - Cave: last release on Nov. 2019 > >> > >> We also have: > >> > >> - Winegrower: last release on Nov. 2020 > >> > >> - Minho: last release on Jan. 2023 (but plan to move to dedicated TLP > >> project) > >> > >> There is also some discussion about moving SMX bundle and Camel-Karaf as > >> Karaf subprojects so I think it will be nice to see what we would/could > >> maintain. > >> > >> regards, > >> > >> -- > >> -- > >> François > >> > -- > -- > François > >
[ANN] Pax Logging 2.2.1 and 1.12.4 released
Hello First - I've updated https://github.com/ops4j/org.ops4j.pax.logging#versions page which now marks only 2 versions as active. Here's more detailed explanation: - versions 1.9.x and 1.10.x are pre-refactoring versions without any real integration tests - version 1.11.x and 1.12.x are both based on OSGi CMPN Log service 1.3, but version 1.11.x includes Log4j1 backend. I've decided to keep and maintain only version 1.12.x, because we don't want to use Log4j1 backend anymore. The Log4j1 API is still available though. So please use 1.12.x for Felix 5.6 / Karaf 4.2 - version 2.0.x (with Log4j1 backend) and 2.1.x (without Log4j1 backend) are based on OSGi CMPN Log service 1.4 and because Log service 1.5 is identical, I've decided to keep and maintain only version 2.2.x The most important change in 1.12.4 and 2.2.1 is related to SLF4J 2.x API support. Actually the interfaces didn't change since version 1.7.x, but there was a change with discovery of logging backend. Instead of static org.slf4j.impl.StaticLoggerBinder, SLF4J 2 now relies on /META-INF/services/org.slf4j.spi.SLF4JServiceProvider which is now providing org.ops4j.pax.logging.slf4j.PaxLoggingSLF4JServiceProvider service. >From the API point of view nothing has changed except that pax-logging-api now exports `org.slf4j` package with version 2.0.6 (in addition to version 1.4, 1.5, 1.6 and 1.7). That's important for OSGi bundles compiled with maven-bundle-plugin (or bnd-maven-plugin) with default configuration which would generate this import header: Import-Package: org.slf4j;version="[2.0,3.0)". This would cause problems before Pax Logging 2.2.1 and 1.12.4. All the release notes can be found using the following links: - 2.2.1: https://github.com/ops4j/org.ops4j.pax.logging/milestone/98?closed=1 - 1.12.4: https://github.com/ops4j/org.ops4j.pax.logging/milestone/105?closed=1 kind regards Grzegorz Grzybek
Re: pax-web-8: handling security for non-existent resources?
Hello Robert!
Right, and this I think is actually a bug in Jolokia. I think it should
> set its context path to /jolokia and use urlPatterns=/*, right?
>
It's not a bug in Jolokia, but a limitation of the method to register a
servlet...
If you `git blame` related lines, you'll see:
https://github.com/rhuss/jolokia/blame/v1.7.2/agent/osgi/src/main/java/org/jolokia/osgi/JolokiaActivator.java#L322-L325
This code was added ... 12 years ago and the only method back then was to
use OSGi CMPN HttpService specification, which allowed to do these:
- register a servlet
- register resources
That's all. No filters, *no contexts other than "/"!*, no listeners, no
nothing...
Whiteboard specification is more flexible and I think this is what should
be done:
- please create a rhuss/jolokia GH issue with your problem, let me know
and I'll add my comments there (and PR to turn it into whiteboard)
- for now, you have to live with what we have. I agree that Jolokia
"takes over" the "/" context, but is it possible that you use different
context? and register a servlet to "/" that redirects all (but
"/jolokia/*") URIs to your context?
regards
Grzegorz Grzybek
niedz., 8 sty 2023 o 01:04 Robert Varga napisał(a):
> On 17/08/2022 08:31, Grzegorz Grzybek wrote:
> > Hello
>
> Hello Grzegorz,
>
> sorry for the late reply. I needed some time to get into this entire
> business.
>
> > Is this expected behaviour? I would have expected to hit
> >> ServiceAuthenticationHttpContext only when servicing /jolokia...
> >>
> >
> > /jolokia/* mapping (actually a one-element array of URL patterns) is a
> > mapping for org.jolokia.osgi.servlet.JolokiaServlet registered into "/"
> > (default), ROOT) context. See this in logs:
> >
> > Adding servlet
> >>
> ServletModel{id=ServletModel-3,name='org.jolokia.osgi.servlet.JolokiaServlet',alias='/jolokia',urlPatterns=[/jolokia/*],servlet=org.jolokia.osgi.servlet.JolokiaServlet@2d7892f6
> >> ,contexts=[{HS,OCM-4,context:570736934,/}]}
> >>
>
> Right, and this I think is actually a bug in Jolokia. I think it should
> set its context path to /jolokia and use urlPatterns=/*, right?
>
> That way...
>
> >
> > toString() method for ServletModel shows the associated (as in Whiteboard
> > specification) _contexts_. The single associated context is:
> >
> > {HS,OCM-4,context:570736934,/}
> >>
> >
> > HS means "Http Service", OCM-4 is an internal ID of the context and
> > "context:570736934" is generated name, because Jolokia's provided
> > "ServiceAuthenticationHttpContext"
> > is wrapped to match the API consistency internally. This
> > "ServiceAuthenticationHttpContext" is used by Jolokia to register the
> > servlet:
> >
> > service.registerServlet(getServletAlias(),
> > new
> > JolokiaServlet(context,restrictor),
> > getConfiguration(),
> > getHttpContext());
> >
> > (see 4th parameter - result of getHttpContext()).
> >
> > What's more important is that such context replaces default "/" context
> > from Whiteboard specification:
>
> it would just not do this...
>
> >> 2022-08-16T08:09:51,804 | INFO | paxweb-config-1-thread-1 |
> >> JettyServerWrapper | 474 -
> org.ops4j.pax.web.pax-web-jetty -
> >> 8.0.2 | Changing default OSGi context model for
> >> o.o.p.w.s.j.i.PaxWebServletContextHandler@14729e2e{/,null,STOPPED}
> >>> 2022-08-16T08:09:51,804 | INFO | paxweb-config-1-thread-1 |
> >> OsgiServletContext | 477 - org.ops4j.pax.web.pax-web-spi -
> >> 8.0.2 | Unegistering
> >>
> OsgiServletContext{model=OsgiContextModel{WB,id=OCM-1,name='default',path='/',bundle=org.ops4j.pax.web.pax-web-extender-whiteboard,context=(supplier)}}
> >> as OSGi service for "/" context path
> >>> 2022-08-16T08:09:51,804 | INFO | paxweb-config-1-thread-1 |
> >> OsgiServletContext | 477 - org.ops4j.pax.web.pax-web-spi -
> >> 8.0.2 | Registering
> >>
> OsgiServletContext{model=OsgiContextModel{HS,id=OCM-4,name='context:570736934',path='/',bundle=org.jolokia.osgi,context=WebContainerContextWrapper{bundle=org.jolokia.osgi_1.7.1
> >>
> [166],contextId='context:570736934',delegate=org.jolokia.osgi.security.ServiceAuthenticationHttpContext@2204c126
> }}}
> >> as OSGi service for "/" context path
> >
> >
> > See
> >
> {WB,id=O
Re: [VOTE] Apache Karaf OSGi runtime 4.4.3 release (take #2)
+1 Thanks and sorry for previous cancellation due to Pax Web upgrade ;) regards Grzegorz Grzybek sob., 7 sty 2023 o 06:44 Jean-Baptiste Onofré napisał(a): > Hi guys, > > I submit Apache Karaf OSGi runtime 4.4.3 release to your vote (take #2). > > This release is a maintenance release bringing a lot of dependency > updates and fixes. > Especially, this release includes: > - fix threads leak in karaf-maven-plugin (in verify feature goal) > - fix on JMX stub IP address assignation (especially on different > docker networks) > - re-add shell:alias command > - fix ssh client on Windows > - upgrade to Aries JAX RS Whiteboard 2.0.2 > - upgrade to Pax Web 8.0.15 > - and several dependency updates ! > > You can take a look on the Release Notes for details: > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12352267 > > Maven Staging Repository: > https://repository.apache.org/content/repositories/orgapachekaraf-1182/ > > Dist Staging Repository: > https://dist.apache.org/repos/dist/dev/karaf/4.4.3/ > > Git tag: > karaf-4.4.3 > > Please vote to approve this release: > [ ] +1 Approve the release > [ ] -1 Don't approve the release (please provide specific comments) > > This vote will be open for at least 72 hours. > > Regards > JB >
Re: karaf-4.5.x?
Hello Of course JBO has to answer, but I can give you some good news too ;) (sorry for top-posting). First - Karaf 4.4.x is already JDK11 only (kind of) - because it _can't_ be compiled using JDK8 - see https://issues.apache.org/jira/browse/KARAF-7312 and https://github.com/apache/karaf/blob/karaf-4.4.2/management/server/src/main/java/org/apache/karaf/management/internal/Activator.java#L115 - this constant is JDK9+ only. About Jetty 11 - it's kept in line with 10.x and the only difference is Servlet API used (4 with `javax.servlet` packages vs. 5 with `jakarta.servlet` package). Usage in OSGi however is far from ready, because OSGi CMPN 8.1 is just being released, however: - there's no HttpService chapter *at all* - there's only Whiteboard left and Web Apps (WABs) chapter is not updated to `jakarta`. See https://github.com/osgi/osgi/issues/499 - Pax Web 10 (yes, 10) is work in progress, because there are lot of changes enforced by javax → jakarta migration. See https://github.com/ops4j/org.ops4j.pax.web/issues/1802 About Pax Web 9 - actually, it should be a matter of replacing version 8 with 9 without _any problems_ - the release is compatible and because Pax Web 9 is JDK 11 only, it could switch (with minor changes related to websocket handling from Jetty 9 to Jetty 10. I think some Karaf 4.4.x soon could use Pax Web 9 and Jetty 10 - and that's where @Jean-Baptiste Onofré comment is needed ;) About SLF4J2 - I just can't help but share an insight into how I work ;) See: - I was working on Pax Web 10 and decided to run OSGi TCKs over it, so - I started checking https://github.com/osgi/osgi/ where the TCKs are stored, but I saw it's a `bnd` workspace, so - I started learning `bnd` and `bndtools`, because I'm pure Maven engineer, so - I got back to osgi/osgi project to check how they use `bnd` and saw that they run TCKs using Github Actions, so - I started learning Github Actions, because I never learned them because I always have this subconscious angst about exceed free plan, so - I decided to take simpler project and add Github Actions support there - I chose... Pax Logging, so - I got back to Pax Logging and recalled that it's about time to finish (created by me) https://github.com/ops4j/org.ops4j.pax.logging/issues/504 - upgrade to SLF4J 2 with Logback 1.3 Whew - summarizing, SLF4J2 is already supported in `main` branch (2.2.x) of Pax Logging and all the tests pass - the only issue I found was https://jira.qos.ch/browse/LOGBACK-1716 So soon (maybe even today) I'm going to release Pax Logging 2.2.1 with: - Log4j2 2.19.0 ( https://github.com/ops4j/org.ops4j.pax.logging/issues/505) - Reload4J 1.2.24 ( https://github.com/ops4j/org.ops4j.pax.logging/issues/509) - just an update, no CVEs, no breaking changes - SLF4J2 2.0.6 - and I committed a heresy, but pax-logging-api will export two major versions (and more minor versions) of `org.slf4j` package: 1.4.3, 1.5.11, 1.6.6, 1.7.36 and 2.0.6 - the first 4 versions were exported for long time, but I've never exported two different major versions before - fortunately OSGi can do it ;) - Logback 1.3.5 (upgrade from 1.2.11 for SLF4J 1.7.x), because Logback 1.4.5 is to be used with `jakarta` packages and we don't do it (OSGi CMPN) yet. I hope this long explanation answer is helpful ;) regards Grzegorz Grzybek niedz., 8 sty 2023 o 00:17 Robert Varga napisał(a): > Hello everyone, > > are there any plans for a karaf-4.5.x release? > > I think there is a number of breaking changes out there to warrant a > rather major step: > > - Java 11+ > - slf4j-2.0.x > - logback-1.4.x (Java 11, slf4j-2) > - pax-web-9.0.x (Java 11, jetty-10.x) > > Also, I think it is time to plan for jetty-11, i.e. jakarta.ee > namespace, as it is invariably coming down the pike, but that is a thing > of its own. > > Key drivers here for me are slf4j-2 (finally out) and jetty-10 (9.4 is > EOSL). Most of my projects are already on Java 17, all are on Java 11, > so yeah, I am biased :) > > Thanks, > Robert >
[ANN] Pax Web 8.0.15 released
Hello I'd like to announce new minor release of Pax Web: 8.0.15. It will be part of Karaf 4.4.3. - Kevin Schmidt helped to fix pax-web-jetty - org.eclipse.jetty.rewrite import package was missing - Kevan Jahanshahi found a problem with missing org.apache.xpath import package for pax-web-jsp All runtimes are updated: - Jetty 9.4.50.v20221201 - Tomcat 9.0.70 - Undertow 2.2.22.Final For completeness, the changelog is available for 8.0.15[1]. kind regards Grzegorz Grzybek === [1]: https://github.com/ops4j/org.ops4j.pax.web/milestone/236?closed=1 >
Re: [VOTE] Apache Karaf Minho 0.1 release
+1 regards Grzegorz Grzybek czw., 5 sty 2023 o 18:51 Romain Manni-Bucau napisał(a): > +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 jeu. 5 janv. 2023 à 17:56, Jean-Baptiste Onofré a > écrit : > > > +1 (binding) > > > > Regards > > JB > > > > On Wed, Jan 4, 2023 at 11:38 AM Jean-Baptiste Onofré > > wrote: > > > > > > Hi all, > > > > > > as discussed on the mailing list, I submit Apache Karaf Minho 0.1 to > > your vote. > > > > > > This is the first Minho release. > > > > > > You can find details of the release content here: > > > https://github.com/apache/karaf-minho/milestone/1?closed=1 > > > > > > Maven Staging Repository: > > > > https://repository.apache.org/content/repositories/orgapachekaraf-1180/ > > > > > > Dist Staging Repository: > > > https://dist.apache.org/repos/dist/dev/karaf/minho/0.1/ > > > > > > Git tag: > > > minho-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: [VOTE] Apache Karaf OSGi runtime 4.4.3 release
Hello I have several updates to Pax Web 8.0.15 including 2 bug fixes: https://github.com/ops4j/org.ops4j.pax.web/milestone/236?closed=1 but Pax Web 8.0.15 is not released yet (I can do it tomorrow). What's important (at least for some people) is that all 3 runtimes are updated: - tomcat to 9.0.70 - jetty to 9.4.50 - undertow to 2.2.22 if you could wait a bit, we can have the fixes available. Also I see that currently Karaf 4.4 uses Pax Web 8.0.11, but there were few more important fixes after 8.0.11 - https://github.com/ops4j/org.ops4j.pax.web/issues/1800 - a nasty deadlock - https://github.com/ops4j/org.ops4j.pax.web/issues/1792 - global jetty-web.xml not being processed - https://github.com/ops4j/org.ops4j.pax.web/issues/1794 - problem getting "default" dispatcher when the "/" servlet is overriden - https://github.com/ops4j/org.ops4j.pax.web/issues/1798 - another timing issue between whiteboard and httpservice - https://github.com/ops4j/org.ops4j.pax.web/issues/1784 - custom HttpContext (felix.webconsole) issues kind regards Grzegorz Grzybek czw., 5 sty 2023 o 15:35 Jean-Baptiste Onofré napisał(a): > Hi guys, > > I submit Apache Karaf OSGi runtime 4.4.3 release to your vote. > > This release is a maintenance release bringing a lot of dependency > updates and fixes. > Especially, this release includes: > - fix threads leak in karaf-maven-plugin (in verify feature goal) > - fix on JMX stub IP address assignation (especially on different > docker networks) > - re-add shell:alias command > - fix ssh client on Windows > - upgrade to Aries JAX RS Whiteboard 2.0.2 > - several dependency updates ! > > You can take a look on the Release Notes for details: > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12352267 > > Maven Staging Repository: > https://repository.apache.org/content/repositories/orgapachekaraf-1181/ > > Dist Staging Repository: > https://dist.apache.org/repos/dist/dev/karaf/4.4.3/ > > Git tag: > karaf-4.4.3 > > Please vote to approve this release: > [ ] +1 Approve the release > [ ] -1 Don't approve the release (please provide specific comments) > > This vote will be open for at least 72 hours. > > Regards > JB >
Re: Happy new year 2023!
Happy New Year everyone! I wish you all new inspirations, new hopes and new achievements in coming 2023. kind regards Grzegorz Grzybek niedz., 1 sty 2023 o 06:41 Jean-Baptiste Onofré napisał(a): > Hi everyone, > > On behalf of the Apache Karaf team, I wish you all a very happy new year > 2023! > > Regards > JB >
Re: [HEADSUP] Apache Karaf OSGi runtime 4.4.3 and 4.3.9 on vote this weekend
Thanks JBO If you didn't update Pax Web yet (in 4.4.x to 8.0.14), I'll check it. regards Grzegorz Grzybek czw., 1 gru 2022 o 07:18 Jean-Baptiste Onofré napisał(a): > Hi guys > > I’m working on issues and Jira triage for 4.4.3 and 4.3.9 releases. > > I plan to submit both releases to vote during the weekend. > > I will keep you posted. > > Regards > JB >
Re: [PROPOSAL] Create new Apache project proposal with Minho
Hello +1 for separation. Why? I started an experiment - Pax Web 10 can quite easily run on latest JakartaEE 10+ servers (Jetty 11, Tomcat 10, Undertow 2.3), because there's continued work on OSGi CMPN 8.1 - Karaf (and OSGi in general) became quite "conservative" project (in strict, good sense of what "conservatism" is - preservation of working, stable institutions, looking at incoming changes and absorbing them in evolutionary way). In this spirit, I imagine that some (considerable number of) people, enterprises use Karaf/OSGi and are happy with it. These groups react only when something is removed/deprecated/no longer supported. So if we were to slowly transition "Karaf on OSGi" to "Karaf/Minho on anything, with less emphasis on OSGi", we could have more and more voices that we should keep what's working. In other words - Minho is a good project where the underlying philosophy is less relevant (Spring, OSGi, ...), but I think it's better to keep Karaf as is - "application server running on OSGi kernel - Felix/Equinox". kind regards Grzegorz Grzybek wt., 29 lis 2022 o 07:14 fpapon napisał(a): > Hi, > > The more we are moving forward, the move we are moving away from Karaf > so +1 to make a proposal for a new project. > > Regards, > > François > > On 28/11/2022 11:26, Jean-Baptiste Onofré wrote: > > 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 > > -- > -- > FrançoisT > >
[ANN] Pax Web 8.0.14 and 9.0.4 released
Hello I'd like to announce new minor releases of Pax Web: 8.0.14 and 9.0.4. There's one, quite tricky problem resolved (thanks Oliver F. for your great analysis!): - there was an issue when WAB was wired to a service (backend) bundle and this bundle was updated. This bundle had to register (Whiteboard or HttpService) servlets into the same context as the WAB. It was possible to detect it, because the WAB used "/" context path and CXF (cxf-rt-transports-http) registers "/cxf" servlet into "/" path. Current versions of runtimes are: - Jetty 9.4.49.v20220914 (8.0.x) and 10.0.12 (9.0.x) - Tomcat 9.0.69 - Undertow 2.2.21.Final For completeness, the changelogs is available for 8.0.14[1] and 9.0.4[2]. kind regards Grzegorz Grzybek === [1]: https://github.com/ops4j/org.ops4j.pax.web/milestone/233?closed=1 [2]: https://github.com/ops4j/org.ops4j.pax.web/milestone/234?closed=1
[ANN] Pax Web 8.0.13 and 9.0.3 released
Hello
I'd like to announce new minor releases of Pax Web: 8.0.12 and 9.0.2.
There are three problems resolved:
- there was a little timing issue if a web element targeting default
whiteboard context was processed before the actual context was processed by
target runtime
- there was a problem getting named dispatcher for "default" name, when
a custom servlet from web.xml was using "/" mapping (thanks Prashanth
Ettaboina for the report!)
- ${karaf.etc}/jetty-web.xml was actually not processed even if declared
in ${karaf.etc}/org.ops4j.pax.web.cfg (thanks Oliver F. for the report!)
Tomcat runtime is upgraded and the current versions are:
- Jetty 9.4.49.v20220914 (8.0.x) and 10.0.12 (9.0.x)
- Tomcat 9.0.69
- Undertow 2.2.21.Final
For completeness, the changelogs is available for 8.0.13[1] and 9.0.3[2].
kind regards
Grzegorz Grzybek
===
[1]: https://github.com/ops4j/org.ops4j.pax.web/milestone/231?closed=1
[2]: https://github.com/ops4j/org.ops4j.pax.web/milestone/232?closed=1
Re: Unable to create default RequestDispatcher
Hi
Part of the fix is this example:
https://github.com/ops4j/org.ops4j.pax.web/tree/pax-web-8.0.x/samples/samples-war/war-dispatcher
with this web.xml:
http://xmlns.jcp.org/xml/ns/javaee; xmlns:xsi="
http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee
http://xmlns.jcp.org/xml/ns/javaee/web-app_4_0.xsd;
version="4.0">
dispatch-servlet
org.ops4j.pax.web.samples.war.osgi.JustDispatchServlet
dispatch-servlet
/
and this org.ops4j.pax.web.samples.war.osgi.JustDispatchServlet:
public class JustDispatchServlet extends HttpServlet {
@Override
protected void service(HttpServletRequest req, HttpServletResponse resp)
throws ServletException, IOException {
// https://github.com/ops4j/org.ops4j.pax.web/issues/1794:
// we want to delegate to "default" servlet hoping to use it's
functionality
getServletContext().getNamedDispatcher("default").include(req, resp);
}
}
the test checks the behavior on three runtimes (Jetty, Tomcat, Undertow).
regards
Grzegorz Grzybek
śr., 16 lis 2022 o 14:57 Prashanth Ettaboina
napisał(a):
> Hi Grzegorz,
>
> I hope the latest version(8.0.13) should solve the issue.
> Thank you for taking up the issue and being supportive, your responses are
> deeply appreciated.
>
> Regards,
> Prashanth
>
> From: Prashanth Ettaboina
> Sent: 16 November 2022 15:33
> To: 'iss...@karaf.apache.org' ; '
> dev@karaf.apache.org' ; 'u...@karaf.apache.org' <
> u...@karaf.apache.org>
> Subject: RE: Unable to create default RequestDispatcher
>
> Hi Grzegorz,
>
> Thank you for your response.
> I have gone through your explanation; I have seen that "/" is overriding
> the default servlet. Thank you for letting me know.
> But we had that web.xml configuration from last several years below is the
> web.xml which was being used from older karaf versions (before 4.4.1).
>
>
> helloboard
> com.console.helloboard.HelloboardServlet
>
>
> helloboard
> /
>
>
> Previously HelloboardServlet used to take in all the requests and process
> them, below is the code block which is used to be executed.
>
> public class HelloboardServlet extends HttpServlet {
>
>protected void doGet(HttpServletRequest request,
> HttpServletResponse response) throws ServletException, IOException {
> if (request.getServletPath().equals("/")) {
> response.sendRedirect("views/welcome.jsp");
> } else if (request.getServletPath().startsWith("/resources/")){
> if(request.getServletPath().endsWith(".css")) {
> response.setContentType("text/css");
> } else if (request.getServletPath().endsWith(".js")) {
>response.setContentType("text/javascript");
> }
> RequestDispatcher rd =
> getServletContext().getNamedDispatcher("default");
> rd.include(request, response);
> }
>}
> }
>
> I want to know why it was able to create a default RequestDispatcher back
> then and why not now? are there any changes in the implementation as part
> of the upgrades, if yes can I get some information of what has been
> modified.
>
> As per your directions I have changed the web.xml servlet mapping from /
> to /*, now I'm able to create the default servlet but the above code block
> will not be working because I have changed the url-pattern from / to /* all
> the request objects are containing servletPath as "" (empty string). Which
> will break the existing flow.
>
> I'm sorry that I cannot share the WAB and can give any further inputs
> regarding this issue.
>
> Thanks,
> Prashanth Ettaboina.
>
>
> From: Prashanth Ettaboina
> Sent: 16 November 2022 14:02
> To: 'iss...@karaf.apache.org' iss...@karaf.apache.org>>; 'dev@karaf.apache.org' <mailto:dev@karaf.apache.org>>; 'u...@karaf.apache.org' <
> u...@karaf.apache.org<mailto:u...@karaf.apache.org>>
> Subject: RE: Unable to create default RequestDispatcher
>
> Hi Grzegorz,
>
> Thank you for your response.
> I have gone through your explanation; I have seen that "/" is overriding
> the default servlet. Thank you for letting me know.
> But we had that web.xml configuration from last several years below is the
> web.xml which was being used from older karaf versions (before 4.4.1).
>
>
> helloboard
> com.console.helloboard.HelloboardServlet
>
>
> helloboard
> /
>
>
> Previously HelloboardServlet
Re: Unable to create default RequestDispatcher
Hello
I've fixed the problem here:
https://github.com/ops4j/org.ops4j.pax.web/commit/19696d4dcabe8b5663d33f894a8d40fc2b742c88
The problem was that during WAR scanning, if there was any servlet mapped
to "/", "default" servlet was removed entirely - now it's still registered,
but with empty mapping - so you can't invoke it, but you can get a named
dispatcher for it.
I'm going to release Pax Web 8.0.13 today.
Thanks Prashanth for the report!
regards
Grzegorz Grzybek
śr., 16 lis 2022 o 12:21 Grzegorz Grzybek napisał(a):
> Hello Prashanth
>
> I've added some findings to
> https://github.com/ops4j/org.ops4j.pax.web/issues/1794 and I see there's
> a problem in Tomcat and Jetty runtimes for Pax Web.
> I've just checked it in pure standalone Tomcat and indeed - the "default"
> dispatcher should NEVER be removed - I'm working on a fix.
>
> regards
> Grzegorz Grzybek
>
> śr., 16 lis 2022 o 12:02 Prashanth Ettaboina
> napisał(a):
>
>> Hi Grzegorz,
>>
>> Thank you for your response.
>> I have gone through your explanation; I have seen that "/" is overriding
>> the default servlet. Thank you for letting me know.
>> But we had that web.xml configuration from last several years below is
>> the web.xml which was being used from older karaf versions (before 4.4.1).
>>
>>
>> helloboard
>>
>> com.console.helloboard.HelloboardServlet
>>
>>
>> helloboard
>> /
>>
>>
>> Previously HelloboardServlet used to take in all the requests and process
>> them, below is the code block which is used to be executed.
>>
>> public class HelloboardServlet extends HttpServlet {
>>
>>protected void doGet(HttpServletRequest request,
>> HttpServletResponse response) throws ServletException, IOException {
>> if (request.getServletPath().equals("/")) {
>> response.sendRedirect("views/welcome.jsp");
>> } else if
>> (request.getServletPath().startsWith("/resources/")){
>> if(request.getServletPath().endsWith(".css")) {
>> response.setContentType("text/css");
>> } else if (request.getServletPath().endsWith(".js")) {
>>response.setContentType("text/javascript");
>> }
>> RequestDispatcher rd =
>> getServletContext().getNamedDispatcher("default");
>> rd.include(request, response);
>> }
>>}
>> }
>>
>> I want to know why it was able to create a default RequestDispatcher back
>> then and why not now? are there any changes in the implementation as part
>> of the upgrades, if yes can I get some information of what has been
>> modified.
>>
>> As per your directions I have changed the web.xml servlet mapping from /
>> to /*, now I'm able to create the default servlet but the above code block
>> will not be working because I have changed the url-pattern from / to /* all
>> the request objects are containing servletPath as "" (empty string). Which
>> will break the existing flow.
>>
>> I'm sorry that I cannot share the WAB and can give any further inputs
>> regarding this issue.
>>
>> Thanks,
>> Prashanth Ettaboina.
>>
>>
>> From: Prashanth Ettaboina
>> Sent: 16 November 2022 14:02
>> To: 'iss...@karaf.apache.org' ; '
>> dev@karaf.apache.org' ; 'u...@karaf.apache.org' <
>> u...@karaf.apache.org>
>> Subject: RE: Unable to create default RequestDispatcher
>>
>> Hi Grzegorz,
>>
>> Thank you for your response.
>> I have gone through your explanation; I have seen that "/" is overriding
>> the default servlet. Thank you for letting me know.
>> But we had that web.xml configuration from last several years below is
>> the web.xml which was being used from older karaf versions (before 4.4.1).
>>
>>
>> helloboard
>>
>> com.console.helloboard.HelloboardServlet
>>
>>
>> helloboard
>> /
>>
>>
>> Previously HelloboardServlet used to take in all the requests and process
>> them, below is the code block which is used to be executed.
>>
>> public class HelloboardServlet extends HttpServlet {
>>
>>protected void doGet(HttpServletRequest request,
>> HttpServletResponse response) throws ServletException, IOException {
>> if (request.getServletPath().equals(&quo
Re: Unable to create default RequestDispatcher
Hello Prashanth
I've added some findings to
https://github.com/ops4j/org.ops4j.pax.web/issues/1794 and I see there's a
problem in Tomcat and Jetty runtimes for Pax Web.
I've just checked it in pure standalone Tomcat and indeed - the "default"
dispatcher should NEVER be removed - I'm working on a fix.
regards
Grzegorz Grzybek
śr., 16 lis 2022 o 12:02 Prashanth Ettaboina
napisał(a):
> Hi Grzegorz,
>
> Thank you for your response.
> I have gone through your explanation; I have seen that "/" is overriding
> the default servlet. Thank you for letting me know.
> But we had that web.xml configuration from last several years below is the
> web.xml which was being used from older karaf versions (before 4.4.1).
>
>
> helloboard
> com.console.helloboard.HelloboardServlet
>
>
> helloboard
> /
>
>
> Previously HelloboardServlet used to take in all the requests and process
> them, below is the code block which is used to be executed.
>
> public class HelloboardServlet extends HttpServlet {
>
>protected void doGet(HttpServletRequest request,
> HttpServletResponse response) throws ServletException, IOException {
> if (request.getServletPath().equals("/")) {
> response.sendRedirect("views/welcome.jsp");
> } else if (request.getServletPath().startsWith("/resources/")){
> if(request.getServletPath().endsWith(".css")) {
> response.setContentType("text/css");
> } else if (request.getServletPath().endsWith(".js")) {
>response.setContentType("text/javascript");
> }
> RequestDispatcher rd =
> getServletContext().getNamedDispatcher("default");
> rd.include(request, response);
> }
>}
> }
>
> I want to know why it was able to create a default RequestDispatcher back
> then and why not now? are there any changes in the implementation as part
> of the upgrades, if yes can I get some information of what has been
> modified.
>
> As per your directions I have changed the web.xml servlet mapping from /
> to /*, now I'm able to create the default servlet but the above code block
> will not be working because I have changed the url-pattern from / to /* all
> the request objects are containing servletPath as "" (empty string). Which
> will break the existing flow.
>
> I'm sorry that I cannot share the WAB and can give any further inputs
> regarding this issue.
>
> Thanks,
> Prashanth Ettaboina.
>
>
> From: Prashanth Ettaboina
> Sent: 16 November 2022 14:02
> To: 'iss...@karaf.apache.org' ; '
> dev@karaf.apache.org' ; 'u...@karaf.apache.org' <
> u...@karaf.apache.org>
> Subject: RE: Unable to create default RequestDispatcher
>
> Hi Grzegorz,
>
> Thank you for your response.
> I have gone through your explanation; I have seen that "/" is overriding
> the default servlet. Thank you for letting me know.
> But we had that web.xml configuration from last several years below is the
> web.xml which was being used from older karaf versions (before 4.4.1).
>
>
> helloboard
> com.console.helloboard.HelloboardServlet
>
>
> helloboard
> /
>
>
> Previously HelloboardServlet used to take in all the requests and process
> them, below is the code block which is used to be executed.
>
> public class HelloboardServlet extends HttpServlet {
>
>protected void doGet(HttpServletRequest request,
> HttpServletResponse response) throws ServletException, IOException {
> if (request.getServletPath().equals("/")) {
> response.sendRedirect("views/welcome.jsp");
> } else if (request.getServletPath().startsWith("/resources/")){
> if(request.getServletPath().endsWith(".css")) {
> response.setContentType("text/css");
> } else if (request.getServletPath().endsWith(".js")) {
>response.setContentType("text/javascript");
> }
> RequestDispatcher rd =
> getServletContext().getNamedDispatcher("default");
> rd.include(request, response);
> }
>}
> }
>
> I want to know why it was able to create a default RequestDispatcher back
> then and why not now? are there any changes in the implementation as part
> of the upgrades, if yes can I get some information of what has been
> modified.
>
Re: [VOTE] Adopt new Apache Karaf "generic" logo
Hello I like it as generic Karaf logo - I have no idea about the font replacements, alignments and other design-related things. Simply +1 ;) regards Grzegorz Grzybek wt., 15 lis 2022 o 09:57 Jean-Baptiste Onofré napisał(a): > Hi guys, > > As discussed on the other thread, here's a vote for the new Karaf logo > proposal. > > As a reminder, this logo is the generic one, used on the main > karaf.apache.org website. Each Karaf subproject (Minho, OSGi, etc) > will have its own "sub-website", with dedicated content and eventually > its own logo. > > Please vote: > +1 to adopt Karaf generic logo > 0 I don't care > -1 for Karaf generic logo and work on a new one > > NB: I would like to move forward pretty fast on the logo just to > promote the new website and announce Karaf Minho. > > Thanks, > Regards > JB >
Re: Unable to create default RequestDispatcher
Hello
You have this message:
Adding servlet
ServletModel{id=ServletModel-239,name='helloboard',urlPatterns=[/],servletClass=class
com..gcs.console.helloboard.HelloboardServlet,contexts=null}
With this, you're overriding the "default" servlet normally mapped to "/"
with your "helloboard" servlet mapped to "/".
I'll check in Servlets specification how this should behave, but for now
this looks like this is the reason. If you don't add this servlet, named
dispatcher should work.
regards
Grzegorz Grzybek
wt., 15 lis 2022 o 15:38 Prashanth Ettaboina
napisał(a):
> Hi Grzegorz,
>
> I'm generating a WAR file of the bundle(which will have the web
> application).
>
> Adding the war file in the feature.xml and installing it in the karaf as a
> kar file.
>
>
> start-level="95">mvn:com.server.console/helloboard/${project.version}/war
>
> karaf@root()> kar: install file :filepath*** snapshot.kar
>
> below are the logs from karaf which are generated while I installed the
> kar file.
>
> 2022-11-15T19:19:11.401+0530 CEF:1 | org.apache.karaf.kar.core | 4.4.1 |
> INFO | ID=168 THR=0.0-SNAPSHOT.kar CAT=KarServiceImpl
> MSG=Added feature repository
> 'mvn:com.server.kars/example-console/51.0.0-SNAPSHOT/xml/features'
> 2022-11-15T19:19:11.403+0530 CEF:1 | org.apache.karaf.features.core |
> 4.4.1 | INFO | ID=19 THR=0.0-SNAPSHOT.kar CAT=FeaturesServiceImpl
> MSG=Adding features: example-console/[51.0.0.SNAPSHOT,51.0.0.SNAPSHOT]
> 2022-11-15T19:19:15.041+0530 CEF:1 | org.apache.karaf.features.core |
> 4.4.1 | INFO | ID=19 THR=tures-3-thread-1 CAT=FeaturesServiceImpl
> MSG=Changes to perform:
> 2022-11-15T19:19:15.041+0530 CEF:1 | org.apache.karaf.features.core |
> 4.4.1 | INFO | ID=19 THR=tures-3-thread-1 CAT=FeaturesServiceImpl
> MSG= Region: root
> 2022-11-15T19:19:15.042+0530 CEF:1 | org.apache.karaf.features.core |
> 4.4.1 | INFO | ID=19 THR=tures-3-thread-1 CAT=FeaturesServiceImpl
> MSG=Bundles to install:
> 2022-11-15T19:19:15.042+0530 CEF:1 | org.apache.karaf.features.core |
> 4.4.1 | INFO | ID=19 THR=tures-3-thread-1 CAT=FeaturesServiceImpl
> MSG= mvn:com.server.console/helloboard/51.0.0-SNAPSHOT/war
> 2022-11-15T19:19:20.621+0530 CEF:1 | org.apache.karaf.features.core |
> 4.4.1 | INFO | ID=19 THR=tures-3-thread-1 CAT=FeaturesServiceImpl
> MSG= helloboard/51.0.0.SNAPSHOT
> 2022-11-15T19:19:20.634+0530 CEF:1 |
> org.ops4j.pax.web.pax-web-extender-war | 8.0.6 | INFO | ID=269
> THR=ender-1-thread-1 CAT=BundleWebApplication MSG=Configuring
> Web Application "/helloboard" for bundle helloboard/51.0.0.SNAPSHOT
> 2022-11-15T19:19:20.635+0530 CEF:1 | org.apache.karaf.features.core |
> 4.4.1 | INFO | ID=19 THR=tures-3-thread-1 CAT=FeaturesServiceImpl
> MSG=Done.
> 2022-11-15T19:19:32.512+0530 CEF:1 | org.ops4j.pax.web.pax-web-runtime |
> 8.0.6 | INFO | ID=272 THR=ender-1-thread-1
> CAT=StoppableHttpServiceFactory MSG=Binding HTTP Service for bundle:
> [helloboard [318]]
> 2022-11-15T19:19:32.514+0530 CEF:1 |
> org.ops4j.pax.web.pax-web-extender-war | 8.0.6 | INFO | ID=269
> THR=ender-1-thread-1 CAT=BundleWebApplication MSG=Allocated
> context for /helloboard:
> OsgiContextModel{WAB,id=OCM-233,name='/helloboard',path='/helloboard',bundle=helloboard,}
> 2022-11-15T19:19:32.520+0530 CEF:1 | org.ops4j.pax.web.pax-web-jetty |
> 8.0.6 | INFO | ID=270 THR=ploy /helloboard) CAT=JettyServerController
> MSG=Receiving Batch{"Deployment of Web Application "/helloboard" for
> bundle helloboard/51.0.0.SNAPSHOT", size=24}
> 2022-11-15T19:19:32.520+0530 CEF:1 | org.ops4j.pax.web.pax-web-jetty |
> 8.0.6 | INFO | ID=270 THR=ploy /helloboard) CAT=JettyServerWrapper
>MSG=Creating new Jetty context for
> ServletContextModel{id=ServletContextModel-234,contextPath='/helloboard'}
> 2022-11-15T19:19:32.521+0530 CEF:1 | org.ops4j.pax.web.pax-web-jetty |
> 8.0.6 | INFO | ID=270 THR=ploy /helloboard) CAT=JettyServerWrapper
>MSG=Adding
> OsgiContextModel{WAB,id=OCM-233,name='/helloboard',path='/helloboard',bundle=helloboard,context=WebContainerContextWrapper{bundle=helloboard
> [318],contextId='/helloboard',delegate=org.ops4j.pax.web.extender.war.internal.WebApplicationHelper@1641e385}}
> to o.o.p.w.s.j.i.PaxWebServletContextHandler@6ae38bdd
> {/helloboard,null,STOPPED} o.o.p.w.s.j.i.PaxWebServletContextHandler@6ae38bdd
> %7b/dashboard,null,STOPPED%7d>
> 2022-11-15T19:19:32.522+0530 CEF:1 | org.ops4j.pax.web.pax-web-jetty |
> 8.0.6 | INFO | ID=270 THR=ploy /helloboard) CAT=JettyServerWrapper
>MSG=Changing default OSGi context model for
> o.o.p.w.s.j.i.PaxWebServletContextHandler@6ae38bdd
> {/helloboard,null,ST
Re: Unable to create default RequestDispatcher
Hello Prashanth
I've added a link to Github issue to your
https://stackoverflow.com/questions/74432966/unable-to-create-default-requestdispatcher
I checked simplest web.xml with a servlet mapped to `/*` (so I can grab all
the requests) and getNamedDispatcher("default") simply worked.
Please share your entire WAB if possible.
regards
Grzegorz Grzybek
wt., 15 lis 2022 o 13:56 Grzegorz Grzybek napisał(a):
> Ah - so you're installing a WAR/WAB? Can you give some details under
> https://github.com/ops4j/org.ops4j.pax.web/issues/1794 ?
>
> Or if you don't use Github, please share:
> - information about the WAR you're installing
> - some logs from Karaf when you install the WAR
>
> regards
> Grzegorz Grzybek
>
> wt., 15 lis 2022 o 12:04 Prashanth Ettaboina
> napisał(a):
>
>> Hi Grzegorz,
>>
>> I'm not registering the ExampleServlet anywhere, I'm configuring them in
>> web.xml.
>> In the web.xml we are giving the servlet and servlet mapping with
>> url-pattern and class path.
>>
>> Thanks,
>> Prashanth Ettaboina.
>>
>> From: Prashanth Ettaboina
>> Sent: 14 November 2022 19:11
>> To: iss...@karaf.apache.org; dev@karaf.apache.org; u...@karaf.apache.org
>> Subject: Unable to create default RequestDispatcher
>>
>> Hi Team,
>>
>> I have updated my KARAF version from 4.2.15 to 4.4.1 and Java from 8 to
>> 11 in my application.
>> Gone through the official Release notes and updated some dependencies as
>> well.
>>
>> Upgraded OSGI-Core from 6.0.0 to 8.0.0.
>> Upgraded osgi.compendium 5.0.0 to osgi.cmpn 7.0.0
>> Upgraded Jetty from 9.4.43.v20210629 to 9.4.46.v20220331.
>> Upgraded pax-web-spi from 4.3.4 to 7.2.11.
>> I'm using javax.servlet-api 3.1.0 version in my application.
>>
>> I'm unable to create default RequestDispatcher.
>> Please check the below code lines.
>>
>> public class ExampleServlet extends HttpServlet {
>> protected void doGet(HttpServletRequest request,
>> HttpServletResponse response) throws ServletException, IOException {
>> RequestDispatcher requestDispatcher =
>> getServletContext().getNamedDispatcher("default"); // get
>> getServletContext() is calling the method in GenericServlet.
>> requestDispatcher.include(request, response);
>> }
>> }
>>
>> the above code used to work fine before the version upgrades but now I'm
>> getting the requestDispatcher as null.
>>
>> Can anyone please look at it, let me know if I'm missing something.
>>
>> Thanks,
>> Prashanth Ettaboina
>>
>>
>>
>>
Re: Unable to create default RequestDispatcher
Ah - so you're installing a WAR/WAB? Can you give some details under
https://github.com/ops4j/org.ops4j.pax.web/issues/1794 ?
Or if you don't use Github, please share:
- information about the WAR you're installing
- some logs from Karaf when you install the WAR
regards
Grzegorz Grzybek
wt., 15 lis 2022 o 12:04 Prashanth Ettaboina
napisał(a):
> Hi Grzegorz,
>
> I'm not registering the ExampleServlet anywhere, I'm configuring them in
> web.xml.
> In the web.xml we are giving the servlet and servlet mapping with
> url-pattern and class path.
>
> Thanks,
> Prashanth Ettaboina.
>
> From: Prashanth Ettaboina
> Sent: 14 November 2022 19:11
> To: iss...@karaf.apache.org; dev@karaf.apache.org; u...@karaf.apache.org
> Subject: Unable to create default RequestDispatcher
>
> Hi Team,
>
> I have updated my KARAF version from 4.2.15 to 4.4.1 and Java from 8 to 11
> in my application.
> Gone through the official Release notes and updated some dependencies as
> well.
>
> Upgraded OSGI-Core from 6.0.0 to 8.0.0.
> Upgraded osgi.compendium 5.0.0 to osgi.cmpn 7.0.0
> Upgraded Jetty from 9.4.43.v20210629 to 9.4.46.v20220331.
> Upgraded pax-web-spi from 4.3.4 to 7.2.11.
> I'm using javax.servlet-api 3.1.0 version in my application.
>
> I'm unable to create default RequestDispatcher.
> Please check the below code lines.
>
> public class ExampleServlet extends HttpServlet {
> protected void doGet(HttpServletRequest request, HttpServletResponse
> response) throws ServletException, IOException {
> RequestDispatcher requestDispatcher =
> getServletContext().getNamedDispatcher("default"); // get
> getServletContext() is calling the method in GenericServlet.
> requestDispatcher.include(request, response);
> }
> }
>
> the above code used to work fine before the version upgrades but now I'm
> getting the requestDispatcher as null.
>
> Can anyone please look at it, let me know if I'm missing something.
>
> Thanks,
> Prashanth Ettaboina
>
>
>
>
Re: Unable to create default RequestDispatcher
Prashanth - just one thing - what's the method you're using to register
ExampleServlet?
Because according to HttpService and Whiteboard specifications, there's no
"default" servlet registered.
See - in Karaf 4.4.2, I've installed hawtio application
(mvn:io.hawt/hawtio-osgi/2.15.0/war) and this "showcase" bundle from Pax
Web:
karaf@root()> install mvn:org.ops4j.pax.web.samples/showcase/8.0.11
Bundle ID: 79
karaf@root()> start 79
karaf@root()> sample:whiteboard servlet s1 /s1/*
>> Using context for bundle org.ops4j.pax.web.samples.showcase [79]
>> Registering a servlet with "s1" name, "/s1/*" pattern, "(
osgi.http.whiteboard.context.name=default)" context selector and for
org.ops4j.pax.web.samples.showcase [79].
>>>> Registered successfully. You can test it using `curl -i
http://127.0.0.1:8181/s1/anything`
karaf@root()> web:servlet-list
Bundle ID │ Name │ Class
│ Context Path(s) │ URLs │ Type │ Context
Filter
──┼───┼───┼─┼──┼┼
75│ default │
org.ops4j.pax.web.service.jetty.internal.web.JettyResourceServlet │ /hawtio
│ /│ WAB│ -
75│ jolokia-agent │
io.hawt.web.servlets.JolokiaConfiguredAgentServlet│ /hawtio
│ /jolokia/* │ WAB│ -
75│ jolokia-proxy │ io.hawt.web.proxy.ProxyServlet
│ /hawtio │ /proxy/* │ WAB│ -
75│ keycloak │ io.hawt.web.auth.keycloak.KeycloakServlet
│ /hawtio │ /keycloak/* │ WAB│ -
75│ login │ io.hawt.web.auth.LoginServlet
│ /hawtio │ /auth/login │ WAB│ -
75│ logout│ io.hawt.web.auth.LogoutServlet
│ /hawtio │ /auth/logout │ WAB│ -
75│ plugin│ io.hawt.web.plugin.PluginServlet
│ /hawtio │ /plugin/*│ WAB│ -
75│ user │ io.hawt.web.auth.keycloak.KeycloakUserServlet
│ /hawtio │ /user/* │ WAB│ -
79│ s1│
org.ops4j.pax.web.samples.config.commands.web.TestServlet │ /
│ /s1/*│ Whiteboard │ (osgi.http.whiteboard.context.name
=default)
And there's no "defaul" servlet in "/" context.
"default" servlet is installed by default only for WAB scenarios (WAR).
regards
Grzegorz Grzybek
pon., 14 lis 2022 o 15:05 Grzegorz Grzybek
napisał(a):
> Hello
>
> There were a lot of changes in Pax Web 8 and in previous versions,
> getNamedDispatch() was simply delegated to underlying web server. Now the
> servlet context is always OSGi-specific and there indeed may be something
> missing.
>
> I've created https://github.com/ops4j/org.ops4j.pax.web/issues/1794 to
> track this problem - please give me ~1 day to find the reason of the
> problem.
>
> kind regards
> Grzegorz Grzybek
>
> pon., 14 lis 2022 o 14:56 Prashanth Ettaboina
> napisał(a):
>
>> Hi Team,
>>
>> I have updated my KARAF version from 4.2.15 to 4.4.1 and Java from 8 to
>> 11 in my application.
>> Gone through the official Release notes and updated some dependencies as
>> well.
>>
>> Upgraded OSGI-Core from 6.0.0 to 8.0.0.
>> Upgraded osgi.compendium 5.0.0 to osgi.cmpn 7.0.0
>> Upgraded Jetty from 9.4.43.v20210629 to 9.4.46.v20220331.
>> Upgraded pax-web-spi from 4.3.4 to 7.2.11.
>> I'm using javax.servlet-api 3.1.0 version in my application.
>>
>> I'm unable to create default RequestDispatcher.
>> Please check the below code lines.
>>
>> public class ExampleServlet extends HttpServlet {
>> protected void doGet(HttpServletRequest request,
>> HttpServletResponse response) throws ServletException, IOException {
>> RequestDispatcher requestDispatcher =
>> getServletContext().getNamedDispatcher("default"); // get
>> getServletContext() is calling the method in GenericServlet.
>> requestDispatcher.include(request, response);
>> }
>> }
>>
>> the above code used to work fine before the version upgrades but now I'm
>> getting the requestDispatcher as null.
>>
>> Can anyone please look at it, let me know if I'm missing something.
>>
>> Thanks,
>> Prashanth Ettaboina
>>
>>
>>
>>
Re: Unable to create default RequestDispatcher
Hello
There were a lot of changes in Pax Web 8 and in previous versions,
getNamedDispatch() was simply delegated to underlying web server. Now the
servlet context is always OSGi-specific and there indeed may be something
missing.
I've created https://github.com/ops4j/org.ops4j.pax.web/issues/1794 to
track this problem - please give me ~1 day to find the reason of the
problem.
kind regards
Grzegorz Grzybek
pon., 14 lis 2022 o 14:56 Prashanth Ettaboina
napisał(a):
> Hi Team,
>
> I have updated my KARAF version from 4.2.15 to 4.4.1 and Java from 8 to 11
> in my application.
> Gone through the official Release notes and updated some dependencies as
> well.
>
> Upgraded OSGI-Core from 6.0.0 to 8.0.0.
> Upgraded osgi.compendium 5.0.0 to osgi.cmpn 7.0.0
> Upgraded Jetty from 9.4.43.v20210629 to 9.4.46.v20220331.
> Upgraded pax-web-spi from 4.3.4 to 7.2.11.
> I'm using javax.servlet-api 3.1.0 version in my application.
>
> I'm unable to create default RequestDispatcher.
> Please check the below code lines.
>
> public class ExampleServlet extends HttpServlet {
> protected void doGet(HttpServletRequest request, HttpServletResponse
> response) throws ServletException, IOException {
> RequestDispatcher requestDispatcher =
> getServletContext().getNamedDispatcher("default"); // get
> getServletContext() is calling the method in GenericServlet.
> requestDispatcher.include(request, response);
> }
> }
>
> the above code used to work fine before the version upgrades but now I'm
> getting the requestDispatcher as null.
>
> Can anyone please look at it, let me know if I'm missing something.
>
> Thanks,
> Prashanth Ettaboina
>
>
>
>
Re: Unable to load custom web.xml for Pax Web in Karaf (4.4.1)
Hi
OK - please then change "helloboard" to "/helloboard" in your
Web-ContextPath manifest header. context path without slash is wrong
according to specification.
regards
Grzegorz Grzybek
czw., 10 lis 2022 o 15:25 Prashanth Ettaboina
napisał(a):
> Hi Grzybek,
>
> Thank you for your response.
>
> I do not have any jars in my /WEB-INF/lib, I do not have lib folder in my
> WEB-INF folder.
>
> In my module I have a web.xml (/src/main/webapp/WEB-INF/web.xml) I'm
> building this module as a kar file and installing it into the karaf console.
> I'm able to see my bundle getting started and getting active without any
> issue.
> But I'm able to see the below log lines after installing the kar file.
>
> 2022-11-10T19:09:05.486+0530 CEF:1 | org.apache.karaf.features.core |
> 4.4.1 | INFO | ID=19 THR=tures-3-thread-1 CAT=FeaturesServiceImpl
> MSG= helloboard/51.0.0.SNAPSHOT
> 2022-11-10T19:09:05.506+0530 CEF:1 |
> org.ops4j.pax.web.pax-web-extender-war | 8.0.6 | WARN | ID=269
> THR=tures-3-thread-1 CAT=WarExtenderContext
> MSG=Web-ContextPath manifest header of helloboard [312] specifies invalid
> context path: helloboard. This bundle will not be processed.
> 2022-11-10T19:09:05.506+0530 CEF:1 | org.apache.karaf.features.core |
> 4.4.1 | INFO | ID=19 THR=tures-3-thread-1 CAT=FeaturesServiceImpl
> MSG=Done.
>
> When I try to access https://localhost:8443/helloboard/ server responded
> back with 404.
>
> Below are the jetty logs when I try to access the above endpoint.
>
> 2022-11-10T19:39:46.391+0530 CEF:1 | org.eclipse.jetty.util |
> 9.4.48.v20220622 | DEBUG | ID=243 THR=qtp501056700-863 CAT=HttpChannel
> MSG=REQUEST for //localhost:8443/helloboard on
> HttpChannelOverHttp@62fa25b0{s=HttpChannelState@2f46c6d1{s=IDLE
> rs=BLOCKING os=OPEN is=IDLE awp=false se=false i=true
> al=0},r=2,c=false/false,a=IDLE,uri=//localhost:8443/helloboard,age=0}
> GET //localhost:8443/helloboard HTTP/1.1
> Host: localhost:8443
>
>
> 2022-11-10T19:39:46.392+0530 CEF:1 | org.eclipse.jetty.util |
> 9.4.48.v20220622 | DEBUG | ID=243 THR=qtp501056700-863 CAT=HttpChannel
> MSG=handle //localhost:8443/helloboard
> HttpChannelOverHttp@62fa25b0{s=HttpChannelState@2f46c6d1{s=IDLE
> rs=BLOCKING os=OPEN is=IDLE awp=false se=false i=true
> al=0},r=2,c=false/false,a=IDLE,uri=//localhost:8443/helloboard,age=0}
> 2022-11-10T19:39:46.392+0530 CEF:1 | org.eclipse.jetty.util |
> 9.4.48.v20220622 | DEBUG | ID=243 THR=qtp501056700-863 CAT=HttpChannel
> MSG=action DISPATCH HttpChannelOverHttp@62fa25b0
> {s=HttpChannelState@2f46c6d1{s=HANDLING rs=BLOCKING os=OPEN is=IDLE
> awp=false se=false i=true
> al=0},r=2,c=false/false,a=HANDLING,uri=//localhost:8443/helloboard,age=1}
> 2022-11-10T19:39:46.392+0530 CEF:1 | org.eclipse.jetty.util |
> 9.4.48.v20220622 | DEBUG | ID=243 THR=qtp501056700-863
> CAT=SecureRequestCustomizer MSG=Host localhost with SNI null
> 2022-11-10T19:39:46.392+0530 CEF:1 | org.eclipse.jetty.util |
> 9.4.48.v20220622 | DEBUG | ID=243 THR=qtp501056700-863 CAT=Server
> MSG=REQUEST GET /helloboard on HttpChannelOverHttp@62fa25b0
> {s=HttpChannelState@2f46c6d1{s=HANDLING rs=BLOCKING os=OPEN is=IDLE
> awp=false se=false i=true al=0},r=2,c=false/false,a=HANDLING,uri=
> https://localhost:8443/helloboard,age=1}
> 2022-11-10T19:39:46.393+0530 CEF:1 | org.eclipse.jetty.util |
> 9.4.48.v20220622 | DEBUG | ID=243 THR=qtp501056700-863 CAT=ContextHandler
> MSG=scope null||/helloboard @
> o.o.p.w.s.j.i.PaxWebServletContextHandler@52ee63a5
> {/,null,AVAILABLE} o.o.p.w.s.j.i.PaxWebServletContextHandler@52ee63a5%7b/,null,AVAILABLE%7d>
> 2022-11-10T19:39:46.393+0530 CEF:1 | org.eclipse.jetty.util |
> 9.4.48.v20220622 | DEBUG | ID=243 THR=qtp501056700-863 CAT=ContextHandler
> MSG=context=||/helloboard @
> o.o.p.w.s.j.i.PaxWebServletContextHandler@52ee63a5
> {/,null,AVAILABLE} o.o.p.w.s.j.i.PaxWebServletContextHandler@52ee63a5%7b/,null,AVAILABLE%7d>
> 2022-11-10T19:39:46.393+0530 CEF:1 | org.eclipse.jetty.util |
> 9.4.48.v20220622 | DEBUG | ID=243 THR=qtp501056700-863 CAT=session
> MSG=Entering scope
> org.ops4j.pax.web.service.jetty.internal.PaxWebSessionHandler1209060588==dftMaxIdleSec=1800,
> dispatch=REQUEST asyncstarted=false
> 2022-11-10T19:39:46.393+0530 CEF:1 | org.eclipse.jetty.util |
> 9.4.48.v20220622 | DEBUG | ID=243 THR=qtp501056700-863 CAT=session
> MSG=Got Session ID node0153ccberdksh618rs5jxv328kq22.node0
> from cookie JSESSIONID
> 2022-11-10T19:39:46.393+0530 CEF:1 | org.eclipse.jetty.util |
> 9.4.48.v20220622 | DEBUG | ID=243 THR=qtp501056700-863 CAT=session
> MSG=Session node0153ccberdksh618rs5jxv328k
Re: Unable to load custom web.xml for Pax Web in Karaf (4.4.1)
Hello czw., 10 lis 2022 o 11:29 Prashanth Ettaboina napisał(a): > Hi Team, > > I have upgraded my Application from Karaf 4.2.15 to 4.4.1 version. > > As per release notes (4.4.0 and 4.4.1) I have updated Pax Web dependency > to 8.0.6 along with Jetty to 9.4.46.v20220331 > > The issue is Pax web is unable to load my web.xml, I have tried to find > the end points (list of servlets) which are running in the karaf using the > karaf commands (http:list & web:list) both commands are not supported by > latest karaf. > How are you "loading" your web.xml? Is it part of Web Application? How do you install it? Which jars do you have in /WEB-INF/lib? If you see some errors in logs, please create an issue under https://github.com/ops4j/org.ops4j.pax.web/issues. and the commands changed - if you install pax-web-karaf feature, you'll get new commands like "web:servlet-list", "web:wab-list" or "web:context-list". regards Grzegorz Grzybek > > Can anyone please look at it. > > Thanks, > Prashanth Ettaboina, >
Re: Issue with org.eclipse.jetty.server (9.4.46.v20220331) and Pax Web (8.0.6) in KARAF 4.4.1
Hello
I found a solution - Pax Web tries to validate whether
etc/org.ops4j.pax.web.cfg matches the runtime-specific configuration
In PID config you have:
org.osgi.service.http.secure.enabled = true
org.osgi.service.http.port.secure = 8443
org.ops4j.pax.web.listening.addresses=127.0.0.1
So Pax Web tries to find a connector in etc/jetty.xml which has 127.0.0.1
as bind address.
However your is not bound to
127.0.0.1, but to 0.0.0.0.
To fix this, change:
To:
Worked for me ;)
regards
Grzegorz Grzybek
pon., 7 lis 2022 o 14:35 Vamsikrishna Koka
napisał(a):
> Hi Grzegorz,
>
> Thank you so much for looking into this.
>
> Here is entire information for etc/org.ops4j.pax.web.cfg, etc/jetty.xml
> and logs.
>
>
>
> Entire org.ops4j.pax.web.cfg File :
>
> org.osgi.service.http.port=8181
>
> org.osgi.service.http.secure.enabled=true
>
> org.osgi.service.http.port.secure=8443
>
> org.ops4j.pax.web.listening.addresses=127.0.0.1
>
> org.ops4j.pax.web.config.file = ${karaf.home}/etc/jetty.xml
>
> org.ops4j.pax.web.session.timeout=30
>
>
>
> Entire Jetty.xml File :
>
>
>
> http://jetty.mortbay.org/configure.dtd>
>
>
>
>
>
>
>
>
>
>
>
>
>
> class="org.eclipse.jetty.util.thread.QueuedThreadPool">
>
> 300
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> karaf
>
> karaf
>
>
>
>
>
>
> org.apache.karaf.jaas.boot.principal.RolePrincipal
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> default
>
> karaf
>
>
>
>
>
>
> org.apache.karaf.jaas.boot.principal.RolePrincipal
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> adminGod
>
> adminGod
>
>
>
>
>
>
> org.apache.karaf.jaas.boot.principal.RolePrincipal
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> admincert
>
> admincert
>
> name="roleClassNames">
>
>
>
>
> org.apache.karaf.jaas.boot.principal.RolePrincipal
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> adminGodproperties
>
> adminGodproperties
>
>
>
>
>
>
> org.apache.karaf.jaas.boot.principal.RolePrincipal
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> admin-db
>
> admin-db
>
>
>
>
>
>
> org.apache.karaf.jaas.boot.principal.RolePrincipal
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> class="org.eclipse.jetty.util.ssl.SslContextFactory$Server">
>
> name="jetty.home"/>/etc/keystores/keystores.pfx
>
> name="jetty.home"/>/etc/keystores/keystores.pfx
>
>
>
> remove sensitive data
>
> remove sensitive data
>
> remove sensitive data
>
> PKCS12
>
> PKCS12
>
> false
>
> adminGodkey
>
>
>
>
>
>
>
> TLSv1.1
>
> TLSv1
>
> SSL
>
> SSLv2
>
> SSLv2Hello
>
Re: [DISCUSS] Adopt new Karaf logo
Hello I think I saw something similar... google-images searching, I found: Kaspersky: [image: image.png] PPC System: [image: image.png] Innolitics: [image: image.png] And I couldn't resist ;) [image: image.png] personally, I liked the previous one better, but I'm not an expert. regards Grzegorz Grzybek pon., 7 lis 2022 o 13:20 Jean-Baptiste Onofré napisał(a): > Hi guys, > > Thanks all for your feedback. > > Regarding your comments (it seems cloud logo doesn't convince > everyone), and to represent more the generic aspect of karaf (as > umbrella project), I created a new more abstract logo. > > Thoughts ? > > Regards > JB > > On Tue, Nov 1, 2022 at 2:11 PM Jean-Baptiste Onofré > wrote: > > > > Hi guys, > > > > as discussed on a previous thread, I'm working on a new website > > proposal with the following objectives: > > > > 1. Use docusaurus instead of jekyll to build. The good thing is that > > it supports md syntax, blog, etc. > > 2. Give the same space/visibility to the subprojects (Karaf Minho, > > Karaf OSGi, Karaf Decanter, Karaf Cellar, Karaf Cave, Karaf > > Winegrower) > > 3. Add blog feature to announce and provide details about Karaf projects > > > > Related to that, I created a new "generic" logo for Karaf (each > > project can have its own logo). > > > > You can see the logo proposal attached. > > > > Basically the idea is: > > - boxes populating the cloud represent Karaf projects > > - we can assembly Karaf projects to create a cloud solution > > > > Thoughts ? > > > > If we agree with this logo, I would like to prepare some goodies using > > it (probably on https://www.redbubble.com/en/). > > > > Regards > > JB >
[ANN] Pax Web 8.0.12 and 9.0.2 released
Hello I'd like to announce new minor releases of Pax Web: 8.0.12 and 9.0.2. There was one bug fixed related to non-default HttpContext and resource servlet registered in Tomcat runtime by felix.webconsole. Thanks +Martin Zukal for the report! Non runtime updates are ASM 9.4 and BouncyCastle 1.72 (test only). Jetty and Tomcat runtimes are upgraded and the current versions are: - Jetty 9.4.49.v20220914 (8.0.x) and 10.0.12 (9.0.x) - Tomcat 9.0.68 - Undertow 2.2.21.Final For completeness, the changelogs is available for 8.0.12[1] and 9.0.2[2]. kind regards Grzegorz Grzybek === [1]: https://github.com/ops4j/org.ops4j.pax.web/milestone/228?closed=1 [2]: https://github.com/ops4j/org.ops4j.pax.web/milestone/227?closed=1
Re: Issue with org.eclipse.jetty.server (9.4.46.v20220331) and Pax Web (8.0.6) in KARAF 4.4.1
Hello
Please show me your entire:
- etc/org.ops4j.pax.web.cfg
- etc/jetty.xml
- logs
I've just checked with Karaf 4.4.1 and this SSL configuration works fine:
org.osgi.service.http.secure.enabled = true
org.osgi.service.http.port.secure = 8443
org.ops4j.pax.web.ssl.truststore = ${karaf.etc}/server.keystore
org.ops4j.pax.web.ssl.truststore.password = xxx
org.ops4j.pax.web.ssl.truststore.type = JKS
org.ops4j.pax.web.ssl.keystore = ${karaf.etc}/server.keystore
org.ops4j.pax.web.ssl.keystore.password = xxx
org.ops4j.pax.web.ssl.keystore.type = JKS
org.ops4j.pax.web.ssl.key.password = xxx
org.ops4j.pax.web.ssl.key.alias = server
if you want SSL, you seem to be missing keystore configuration.
regards
Grzegorz Grzybek
pon., 7 lis 2022 o 11:31 Vamsikrishna Koka
napisał(a):
> Hi Team,
>
> I have migrated KARAF (from 4.2.15 to 4.4.1) and JDK (Open JDK 8 to
> OpenJDK 11) along with required dependency also. As per KARAF release NOTE.
>
> There is issue with jetty xml configuration and org.ops4j.pax.web.cfg.
>
>
>
> *Jetty.xml file*
>
>
>
>
>
>
> class="org.eclipse.jetty.server.ServerConnector">
>
>
>
> name="jetty.ssl.acceptors" deprecated="ssl.acceptors" default="-1"/>
>
> name="jetty.ssl.selectors" deprecated="ssl.selectors" default="-1"/>
>
>
>
> type="org.eclipse.jetty.server.ConnectionFactory">
>
>
>
>
>
>
>
> deprecated="jetty.host" />
>
> deprecated="ssl.port" default="8443"/>
>
> 127.0.0.1:8443
>
> name="jetty.ssl.idleTimeout" deprecated="ssl.timeout"
> default="3"/>
>
> name="jetty.ssl.soLingerTime" deprecated="ssl.soLingerTime"
> default="-1"/>
>
> name="jetty.ssl.acceptorPriorityDelta"
> deprecated="ssl.acceptorPriorityDelta" default="0"/>
>
> name="jetty.ssl.acceptQueueSize" deprecated="ssl.acceptQueueSize"
> default="0"/>
>
>
>
>
>
>
>
>
>
>
>
> *org.ops4j.pax.web.cfg*
>
>
>
> org.osgi.service.http.port=8181
>
> org.osgi.service.http.secure.enabled=true
>
> org.osgi.service.http.port.secure=8443
>
> org.ops4j.pax.web.listening.addresses=127.0.0.1
>
> org.ops4j.pax.web.config.file = ${karaf.home}/etc/jetty.xml
>
> org.ops4j.pax.web.session.timeout=30
>
>
>
>
>
> The above configuration *perfectly working* on KARAF 4.2.15 version both
> jetty *9.4.43* and pax web *7.2.29. *So, I have migrated jetty and Pax
> web dependency part of the KARAF upgrade 4.4.1 version.
>
>
>
> Tried to start KARAF 4.4.1 server on console logs, I have seen *More
> than one HttpConfiguration found in external Jetty configuration. Using
> HttpConfiguration and Failed to bind to /127.0.0.1:8443
> <http://127.0.0.1:8443>. *Understand some where latest PAX Web also
> started container with port 8443*. *If I change port my login page does
> not able to land on browser.
>
>
>
> *Difference b/w Pax-Web 7.2.29 and 8.0.6 version.*
>
> *Pax-Web 7.2.29*
>
>
>
> OPS4J Pax Web - APIorg.ops4j.pax.web.pax-web-api
>
>7.2.29 Active
>
> OPS4J Pax Web - Deployment Descriptor
> Modelorg.ops4j.pax.web.pax-web-descriptor 7.2.29
> Active
>
> OPS4J Pax Web - Extender -
> WARorg.ops4j.pax.web.pax-web-extender-war
> 7.2.29 Active
>
> OPS4J Pax Web - Extender -
> Whiteboardorg.ops4j.pax.web.pax-web-extender-whiteboard 7.2.29
> Active
>
> OPS4J Pax Web - FileInstall
> Deployerorg.ops4j.pax.web.pax-web-deployer
> 7.2.29 Active
>
> OPS4J Pax Web - Jettyorg.ops4j.pax.web.pax-web-jetty
>
> 7.2.29 Active
>
> OPS4J Pax Web - Jsp Supportorg.ops4j.pax.web.pax-web-jsp
> 7.2.29 Active
>
> OPS4J Pax Web - Runtimeorg.ops4j.pax.web.pax-web-runtime
> 7.2.29 Active
>
> OPS4J Pax Web - Service SPIorg.ops4j.pax.web.pax-web-spi
> 7.2.29 Active
>
>
>
>
>
> *karaf@root()> list -s -t 0 | grep "org.ops4j.pax.web"*
>
>
>
> 252 | Active | 30 | 8.0.6 |
> org.ops4j.pax.web.pax-web-api
>
> 253 | Resolved | 30 | 8.0.6
Re: Issue with org.eclipse.jetty.security.jaspi/9.4.46.v20220331 in KARAF 4.4.1
Hello czw., 3 lis 2022 o 12:37 Vamshi Krishna (External) < vamkris...@blackberry.com> napisał(a): > Hi Grzegorz Grzybek, > > > > Please review give below issue. > > > > *Server Core :: Login Module (85)* > > ** > > *Status: GracePeriod* > > *Blueprint* > > *11/3/22, 3:58 PM* > > *Missing dependencies:* > > *(&(objectClass=org.apache.aries.blueprint.NamespaceHandler)(osgi.service.blueprint.namespace=http://karaf.apache.org/xmlns/jaas/v1.0.0 > <http://karaf.apache.org/xmlns/jaas/v1.0.0>))* > > *Declarative Services* > > > "http://karaf.apache.org/xmlns/jaas/v1.0.0; namespace is handled by org.apache.karaf.jaas.blueprint.config.impl.NamespaceHandler which is part of org.apache.karaf.jaas.blueprint.config bundle which is available in "jaas-deployer" feature in Karaf 4.4.1 - please install this feature and the problem should be gone. regards Grzegorz Grzybek > Thanks, > > VamsiKrishna. > > > > *From:* Vamshi Krishna (External) > *Sent:* Thursday, November 3, 2022 4:01 PM > *To:* 'dev@karaf.apache.org' ; ' > iss...@karaf.apache.org' ; 'u...@karaf.apache.org' > > *Subject:* RE: Issue with > org.eclipse.jetty.security.jaspi/9.4.46.v20220331 in KARAF 4.4.1 > > > > Hi Grzegorz Grzybek, > > > > Thank you for looking into this. > > > > I have updated as per KARAF release notes (4.4.0 & 4.4.1 version) > https://github.com/apache/karaf/blob/main/RELEASE-NOTES.md > > > > In feature.xml of my product, I specifically activated "org.eclipse.jetty" > version. > > > > Simply comment out JASPI in feature.xml and try "org.eclipse.jetty" with > 9.4.48.v20220622 version. The GracePeriod status was one of the Login > Modules. > > > > Server Core :: Login Module (85) > > > > Status: GracePeriod > > Blueprint > > 11/3/22, 3:58 PM > > Missing dependencies: > > > (&(objectClass=org.apache.aries.blueprint.NamespaceHandler)(osgi.service.blueprint.namespace= > http://karaf.apache.org/xmlns/jaas/v1.0.0)) > > Declarative Services > > > > Thanks, > > VamsiKrishna. > > > > *From:* Vamshi Krishna (External) > *Sent:* Thursday, November 3, 2022 3:49 PM > *To:* 'dev@karaf.apache.org' ; ' > iss...@karaf.apache.org' ; u...@karaf.apache.org > *Subject:* RE: Issue with > org.eclipse.jetty.security.jaspi/9.4.46.v20220331 in KARAF 4.4.1 > > > > Hi Grzegorz Grzybek, > > > > Thank you for looking into this. > > > > I have updated as per KARAF release notes (4.4.0 & 4.4.1 version) > https://github.com/apache/karaf/blob/main/RELEASE-NOTES.md > > > > In feature.xml of my product, I specifically activated "org.eclipse.jetty" > version. > > > > Simply comment out JASPI in feature.xml and try "org.eclipse.jetty" with > 9.4.48.v20220622. The GracePeriod status was one of the Login Modules. > > > > > > Thanks, > > Vamsi Krishna. > > *From:* Vamshi Krishna (External) > *Sent:* Wednesday, November 2, 2022 11:09 PM > *To:* dev@karaf.apache.org; 'iss...@karaf.apache.org' < > iss...@karaf.apache.org> > *Subject:* Issue with org.eclipse.jetty.security.jaspi/9.4.46.v20220331 > in KARAF 4.4.1 > > > > Hi Team, > > > > I have migrating KARAF from 4.2.15 to 4.4.1 along with Eclipse jetty > server also from 9.4.42 to 9.4.46.v2022033. When I start KARAF having > wiring issue. > > > > Error: missing requirement > org.eclipse.jetty.security.jaspi/9.4.46.v20220331] osgi.extender; > osgi.extender=osgi.serviceloader.registrar). > > > > Please can you any take a look at once. > > > > Thanks > -- > This transmission (including any attachments) may contain confidential > information, privileged material (including material protected by the > solicitor-client or other applicable privileges), or constitute non-public > information. Any use of this information by anyone other than the intended > recipient is prohibited. If you have received this transmission in error, > please immediately reply to the sender and delete this information from > your system. Use, dissemination, distribution, or reproduction of this > transmission by unintended recipients is not authorized and may be unlawful. >
Re: Issue with org.eclipse.jetty.security.jaspi/9.4.46.v20220331 in KARAF 4.4.1
Hmm, did you attach something? I see like missing picture in your email... regards Grzegorz Grzybek czw., 3 lis 2022 o 11:25 Vamshi Krishna (External) < vamkris...@blackberry.com> napisał(a): > Hi Grzegorz Grzybek, > > > > Thank you for looking into this. > > > > I have updated as per KARAF release notes (4.4.0 & 4.4.1 version) > https://github.com/apache/karaf/blob/main/RELEASE-NOTES.md > > > > In feature.xml of my product, I specifically activated "org.eclipse.jetty" > version. > > > > Simply comment out JASPI in feature.xml and try "org.eclipse.jetty" with > 9.4.48.v20220622. The GracePeriod status was one of the Login Modules. > > > > > > Thanks, > > Vamsi Krishna. > > *From:* Vamshi Krishna (External) > *Sent:* Wednesday, November 2, 2022 11:09 PM > *To:* dev@karaf.apache.org; 'iss...@karaf.apache.org' < > iss...@karaf.apache.org> > *Subject:* Issue with org.eclipse.jetty.security.jaspi/9.4.46.v20220331 > in KARAF 4.4.1 > > > > Hi Team, > > > > I have migrating KARAF from 4.2.15 to 4.4.1 along with Eclipse jetty > server also from 9.4.42 to 9.4.46.v2022033. When I start KARAF having > wiring issue. > > > > Error: missing requirement > org.eclipse.jetty.security.jaspi/9.4.46.v20220331] osgi.extender; > osgi.extender=osgi.serviceloader.registrar). > > > > Please can you any take a look at once. > > > > Thanks > -- > This transmission (including any attachments) may contain confidential > information, privileged material (including material protected by the > solicitor-client or other applicable privileges), or constitute non-public > information. Any use of this information by anyone other than the intended > recipient is prohibited. If you have received this transmission in error, > please immediately reply to the sender and delete this information from > your system. Use, dissemination, distribution, or reproduction of this > transmission by unintended recipients is not authorized and may be unlawful. >
Re: Issue with org.eclipse.jetty.security.jaspi/9.4.46.v20220331 in KARAF 4.4.1
Hello Karaf 4.4.1 uses Pax web 8.0.6 which uses Jetty 9.4.48.v20220622 and jetty-jaspi bundle is no longer part of "jetty" and "pax-web-jetty" features. I'm not sure where did you get 9.4.46 from... See this feature from Karaf "standard" features: pax-web-jetty Looks like some of your existing features use hardcoded Jetty version and you reference jetty-jaspi somewhere. jetty-jaspi is removed from Pax Web 8 because JASPIC is quite inactive specification and there are OSGi problems getting proper implementation to work in OSGi. kind regards Grzegorz Grzybek śr., 2 lis 2022 o 19:05 Vamshi Krishna (External) napisał(a): > Hi Team, > > I have migrating KARAF from 4.2.15 to 4.4.1 along with Eclipse jetty > server also from 9.4.42 to 9.4.46.v2022033. When I start KARAF having > wiring issue. > > Error: missing requirement > org.eclipse.jetty.security.jaspi/9.4.46.v20220331] osgi.extender; > osgi.extender=osgi.serviceloader.registrar). > > Please can you any take a look at once. > > Thanks > > -- > This transmission (including any attachments) may contain confidential > information, privileged material (including material protected by the > solicitor-client or other applicable privileges), or constitute non-public > information. Any use of this information by anyone other than the intended > recipient is prohibited. If you have received this transmission in error, > please immediately reply to the sender and delete this information from > your system. Use, dissemination, distribution, or reproduction of this > transmission by unintended recipients is not authorized and may be unlawful. >
Re: [VOTE] Apache Karaf OSGi runtime 4.3.8 release
+1 regards Grzegorz Grzybek śr., 19 paź 2022 o 15:05 Jamie G. napisał(a): > +1 > > Cheers, > Jamie > > On Wed, Oct 19, 2022 at 9:33 AM Jean-Baptiste Onofré > wrote: > > > > Hi guys, > > > > I submit Apache Karaf OSGi runtime 4.3.8 release to your vote. > > > > This release is a maintenance release bringing a lot of dependency > > updates and fixes. > > Especially, this release includes: > > - new feature:status command > > - new --repository option on feature:list command > > - improved Kar service about bundles refresh > > - a bunch of dependencies updates > > > > You can take a look on the Release Notes for details: > > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12351577 > > > > Maven Staging Repository: > > https://repository.apache.org/content/repositories/orgapachekaraf-1178/ > > > > Dist Staging Repository: > > https://dist.apache.org/repos/dist/dev/karaf/4.3.8/ > > > > Git tag: > > karaf-4.3.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. > > > > Regards > > JB >
Re: [VOTE] Apache Karaf OSGi runtime 4.4.2 release
+1 regards Grzegorz Grzybek śr., 19 paź 2022 o 08:17 Mark Derricutt napisał(a): > +2 from me and our app which is a custom static distro in a container. > > -- > "Great artists are extremely selfish and arrogant things" — Steven Wilson, > Porcupine Tree > > On 19/10/2022 at 5:04:18 PM, Jean-Baptiste Onofré wrote: > > > Hi guys, > > > > I submit Apache Karaf OSGi runtime 4.4.2 release to your vote. > > > > This release is a maintenance release bringing a lot of dependency > > updates and fixes. > > Especially, this release includes: > > - new feature:status command > > - new --repository option on feature:list command > > - improved Kar service about bundles refresh > > - a bunch of dependencies updates > > > > You can take a look on the Release Notes for details: > > > > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12352048 > > > > Maven Staging Repository: > > https://repository.apache.org/content/repositories/orgapachekaraf-1177/ > > > > Dist Staging Repository: > > https://dist.apache.org/repos/dist/dev/karaf/4.4.2/ > > > > Git tag: > > karaf-4.4.2 > > > > Please vote to approve this release: > > [ ] +1 Approve the release > > [ ] -1 Don't approve the release (please provide specific comments) > > > > This vote will be open for at least 72 hours. > > > > Regards > > JB > > >
Re: [VOTE] Accept Apache Karaf Minho in Apache Karaf
+1 regards Grzegorz Grzybek czw., 13 paź 2022 o 09:12 fpapon napisał(a): > +1 (binding) > > regards, > > Francois > > On 13/10/2022 08:46, Jean-Baptiste Onofré wrote: > > Hi guys, > > > > As discussed on the mailing list, I would like to start a formal vote > > to accept Apache Karaf Minho in Apache Karaf. > > > > The proposal is: > > - create karaf-minho repository on github > > - use github issues/actions for Minho > > - rework the website to have all projects at the same level, Karaf > > runtime becoming Karaf OSGi. Each project will have its own > > subwebsite, like https://jbonofre.github.io/karaf5/. > > > > In the meantime, I will change all resources to use > > org.apache.karaf.minho namespace on my github before donation. > > > > Please vote to approve this donation/change: > > > > [ ] +1 Approve Minho donation and proposed plan > > [ ] -1 Don't approve the donation/changes (please provide specific > comments) > > > > This vote will be open for at least 72 hours. > > > > Regards > > JB > > -- > -- > François > >
Re: [DISCUSS] Accepting K5 in the Karaf ecosystem
Hello (also a bit late) niedz., 9 paź 2022 o 12:46 Achim Nierbeck napisał(a): > a bit late to the party, nevertheless I'm also in favor of making it > crystal clear that Karaf is for OSGi and Karaf Minho is the new kid in > town. > I agree. Same as with Camel - there's "Camel", "Camel-K" and "Camel-Quarkus". Original Camel wasn't renamed ;) regards Grzegorz Grzybek > besides that I'm also in favor of accepting this new runtime into the karaf > community. > > regards, Achim > > Am So., 9. Okt. 2022 um 09:13 Uhr schrieb Serge Huber : > > > Sounds good to me. > > > > On Sun, Oct 9, 2022 at 7:50 AM Jean-Baptiste Onofré > > wrote: > > > > > That's correct. > > > > > > My proposal is really more for the website and "marketing". > > > > > > If you go there: https://karaf.apache.org/projects.html > > > > > > You can see we have: > > > - Karaf runtime > > > - Karaf cellar > > > - Karaf cave > > > - Karaf decanter > > > > > > So, basically, nothing change so much with my proposal. We would have: > > > - Karaf OSGi runtime > > > - Karaf Minho runtime > > > - Karaf Cellar > > > - Karaf Cave > > > - Karaf Decanter > > > - Karaf Winegrower > > > > > > Each subproject will have a dedicated subsite (with their own > > > documentation, etc, ...). > > > > > > Regards > > > JB > > > > > > On Sat, Oct 8, 2022 at 4:20 PM Steinar Bang wrote: > > > > > > > > >>>>> Eric Lilja : > > > > > > > > > Because it's shedding its OSGi core, making it optional. It's a > > > different > > > > > product stack. > > > > > > > > What I meant: K5 is something different so call it something > different, > > > > but leave the karaf 4.x line with the name "karaf". > > > > > > > > (And in a different place in the thread it seems like this is the > > > > current plan...?) > > > > > > > > > > > > -- > > Apache Member > Apache Karaf <http://karaf.apache.org/> Committer & PMC > OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer & > Project Lead > blog <http://notizblog.nierbeck.de/> > Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS> >
Re: Issue karaf 4.4.1 with org.eclipse.jetty.security.jaspi
Hello Karaf 4.4.1 uses Pax Web 8.0.6 which defines several features - the ones related to Jetty use Jetty version 9.4.48.v20220622. And because jetty-jaspi is problematic (requires actual JASPIC implementation), we no longer use it in Pax Web. Please try installing Jetty using "pax-web-jetty" feature from Pax Web or "jetty" feature from Karaf itself (which actually includes Pax Web's "pax-web-jetty" feature). kind regards Grzegorz Grzybek czw., 6 paź 2022 o 13:39 Vamsikrishna Koka napisał(a): > > Hi Team, > > I have tried with plain KARAF 4.4.1 binary with > "org.eclipse.jetty/jetty-server/9.4.46.v20220331" along with required > dependency also deployed into deploy folder (*\apache-karaf-4.4.1\deploy). > Now my question is all the bundles or jar's up and running except this > "org.eclipse.jetty.security.jaspi" bundle or jar. > > The ERROR message showing on karaf-shell-console. > > 00:28:17.230 [FelixDispatchQueue] ERROR Events.Framework - FrameworkEvent > ERROR > org.osgi.framework.BundleException: Unable to resolve > org.eclipse.jetty.security.jaspi [68](R 68.0): missing requirement > [org.eclipse.jetty.security.jaspi [68](R 68.0)] osgi.extender; > (osgi.extender=osgi.serviceloader.registrar) Unresolved requirements: > [[org.eclipse.jetty.security.jaspi [68](R 68.0)] osgi.extender; > (osgi.extender=osgi.serviceloader.registrar)] > > Please any take a look at once and suggest me. > > > Thanks, > VamsiKrishna >
[ANN] Pax Web 8.0.10 and 9.0.1 released
Hello I'd like to announce new minor releases of Pax Web: 8.0.10 and 9.0.1. There were quite a few actual bug fixes related to how TCCL is configured and how default context can be overriden. Jetty and Tomcat runtimes are upgraded and the current versions are: - Jetty 9.4.49.v20220914 - Tomcat 9.0.67 - Undertow 2.2.19.Final There's a new PID configuration option called "org.ops4j.pax.web.tccl.type" introduced with this issue <https://github.com/ops4j/org.ops4j.pax.web/issues/1760>[1]. It accepts two options: - "servlet" (which is the default) - TCCL inside service methods (like servlet.doGet()) is set to an OsgiServletContextClassLoader which delegates to all the bundles that are reachable for the context - this is perfect setting for a WAB scenario, however in Whiteboard scenario, TCCL doesn't delegate to bundles of the dynamically registered servlets! The problem is that each time a servlet is whiteboard-registered into a context, servlet's bundle would have to be added to the underlying list of bundles, but it causes classloader leaks due to the very JVM specification - "whiteboard" - TCCL is set for each service method (separately for each filter and target servlet in invocation chain) to a bundle classloader of the actual filter/servlet The problem with TCCL is that no OSGi CMPN specification mentions TCCL at all and I simply followed the "principle of least surprise <https://en.wikipedia.org/wiki/Principle_of_least_astonishment>"[2]. For completeness, the changelogs is available for 8.0.10[3] and 9.0.1[4]. kind regards Grzegorz Grzybek === [1]: https://github.com/ops4j/org.ops4j.pax.web/issues/1760 [2]: https://en.wikipedia.org/wiki/Principle_of_least_astonishment [3]: https://github.com/ops4j/org.ops4j.pax.web/milestone/224?closed=1 [4]: https://github.com/ops4j/org.ops4j.pax.web/milestone/225?closed=1
Re: [HEADSUP] Apache Karaf runtime 4.3.8 and 4.4.2 releases in preparation, Decanter 3.0.0 on the way
Hello Thanks JBO for your hard work! Hijacking (a bit) the thread, I work on one outstanding Pax Web 8+ issue related to race condition in special scenario, where all bundles have the same start level and whiteboard services are registered before pax-web-extender-whiteboard starts[1]. I'm almost ready. Also there's https://issues.apache.org/jira/browse/KARAF-7544 where I've prepared a branch where Karaf switches to Jetty 10 (JDK11+) and Pax Web 9 (which also switched to Jetty 10) - there are few tests failing (CamelExampleTest because of asm 5.0.4, PaxCdiFeaturesTest because it's no longer valid and WebSocketExampleTest because Jetty 10 doesn't support this API anymore). No need to upgrade Karaf 4.4.x to Jetty 10 + Pax Web 9, but everything is ready. kind regards Grzegorz Grzybek === [1]: https://github.com/ops4j/org.ops4j.pax.web/issues/1769 wt., 20 wrz 2022 o 17:14 Jean-Baptiste Onofré napisał(a): > Hey guys > > Quick update : I did good progress on K5 (TOOL branch). I gonna merge the > tooling. I’m working on docusaurus based doc. Then I will start the formal > discussion for donation. > > Regarding K4 releases, I’m resuming the investigations on couple of issues. > It should be ready by the end of the week. > > I will keep you posted. > > Regards > JB > > Le sam. 10 sept. 2022 à 07:46, Jean-Baptiste Onofré a > écrit : > > > Hi Mark, > > > > That's a good point. I will add this. > > > > Regards > > JB > > > > On Sat, Sep 10, 2022 at 6:31 AM Mark Derricutt wrote: > > > > > > Given JDK 19 is just around the corner, is worth adding that to the > > export > > > list in jre.properties at all for this release? > > > > > > Mark > > > > > > -- > > > "Great artists are extremely selfish and arrogant things" — Steven > > Wilson, > > > Porcupine Tree > > > > > > > > > On 8/09/2022 at 6:31:41 PM, Jean-Baptiste Onofré > > wrote: > > > > > > > Hi guys, > > > > > > > > I started to prepare Karaf runtime 4.3.8 and 4.4.2 releases. > > > > I will do a new Jira triage and I hope to submit these releases to > > > > vote end of next week/beginning of the following one. > > > > > > > > > > >
[ANN] Pax Web 9.0.0 released
Hello I'd like to announce the release of new major version of Pax Web - version 9! It's supposed to be a long term release being maintained in parallel with Pax Web 8.0.x, the ONLY difference is: - Pax Web 9 is JDK 11+ only - Jetty 10.x is used instead of Jetty 9.4.x All other fixes will always go to Pax Web 8 and Pax Web 9 at the same time. The changelog is available here <https://github.com/ops4j/org.ops4j.pax.web/milestone/221?closed=1>[1]. kind regards Grzegorz Grzybek === [1]: https://github.com/ops4j/org.ops4j.pax.web/milestone/221?closed=1
[ANN] Pax Web 8.0.9 released
Hello Just one day after 8.0.8, I'd like to announce the release of Pax Web 8.0.9 with a fix to a problem found by Qian Weichun (thanks!) - TCCL in service methods of servlets/filters/websockets should be able to find classes of the bundle which registered given web element. The fix for https://github.com/ops4j/org.ops4j.pax.web/issues/1759 is the only fix in Pax Web 8.0.9. For completeness, the changelog is available here[1]. kind regards Grzegorz Grzybek === [1]: https://github.com/ops4j/org.ops4j.pax.web/milestone/223?closed=1
[ANN] Pax Web 8.0.8 released
Hello
I'd like to announce the release of Pax Web 8.0.8 with two fixes:
- proper TCCL configuration when starting servlets and filters added to
started context[1]
- fixed Provide-Capability header for
pax-web-{jetty,tomcat,undertow}-bundle[2]
The changelog can be found here[3].
kind regards
Grzegorz Grzybek
===
[1]: https://github.com/ops4j/org.ops4j.pax.web/issues/1753
[2]: https://github.com/ops4j/org.ops4j.pax.web/issues/1755
[3]: https://github.com/ops4j/org.ops4j.pax.web/milestone/222?closed=1
>
Re: Board report for September 22
+1 regards Grzegorz Grzybek pon., 12 wrz 2022 o 00:36 Matt Pavlovich napisał(a): > +1 looks good > > > On Sep 11, 2022, at 12:23 AM, Jean-Baptiste Onofré > wrote: > > > > Hi guys, > > > > I prepared the board report for September 22: > > > > https://cwiki.apache.org/confluence/display/KARAF/Board+Reports > > > > Please take a look and let me know if I missed anything. > > I would like to send the board report asap. > > > > Thanks ! > > Regards > > JB > >
[ANN] Pax Web 8.0.7 released
Hello I'd like to announce the release of Pax Web 8.0.7 - with few fixes, improvements and runtime upgrades. The runtime versions are: - Jetty 9.4.48.v20220622 - Tomcat 9.0.65 - Undertow 2.2.19.Final The fixes are: - Fixing problem where pax-web-tomcat-common bundle has higher bundle id than pax-web-jsp (NoClassDefFoundError) - Optimized scanning of huge WABs - Fix a problem with session cookie name configuration Additionally there are two more examples added (without any special tests): - samples/samples-whiteboard/whiteboard-annotated <https://github.com/ops4j/org.ops4j.pax.web/tree/main/samples/samples-whiteboard/whiteboard-annotated>[1] - using build-time whiteboard annotations (to register resources and welcome files) - samples/samples-whiteboard/whiteboard-blueprint-jaxrs <https://github.com/ops4j/org.ops4j.pax.web/tree/main/samples/samples-whiteboard/whiteboard-blueprint-jaxrs>[2] - a CXF REST endpoint with Swagger annotations, where http://localhost:8181/cxf/ URI contains a link to Swagger UI application Full changelog can be found here[3]. kind regards Grzegorz Grzybek === [1]: https://github.com/ops4j/org.ops4j.pax.web/tree/main/samples/samples-whiteboard/whiteboard-annotated [2]: https://github.com/ops4j/org.ops4j.pax.web/tree/main/samples/samples-whiteboard/whiteboard-blueprint-jaxrs [3]: https://github.com/ops4j/org.ops4j.pax.web/milestone/218?closed=1 >
Re: [ANN] Pax Logging 2.2.0, 2.1.4, 2.0.19, 1.12.3, 1.11.17 released (5 versions)
Hello TL;DR: I've created https://github.com/ops4j/org.ops4j.pax.logging/issues/504 to track this. I saw yesterday that Logback has finally released (two days ago) versions 1.3.0 and 1.4.0 (simultaneously) which are working with SLF4J 2.0 (released <2 weeks ago). Sure, it'd be good to have Pax Logging using SLF4J2, but with two restrictions: - it has to be compatible with SLF4J 1.7.x (thus exporting `org.slf4j` package with older versions too) - it won't happen in all the branches I've released yesterday (1.11.x, 1.12.x, 2.0.x, 2.1.x and 2.2.x). Probably it'll be Pax Logging 2.3.x, but maybe (because it's not breaking API change) 2.2.x. WDYT @jbono...@apache.org ? kind regards Grzegorz Grzybek wt., 30 sie 2022 o 10:47 Mark Derricutt napisał(a): > Awesome! > > I was wondering the other day about support for the new SLFJ 2.0 that’s > just come out, is there any Pax Logging that supports that yet (along with > the 1.x SLF4j) ? ( or maybe the next version ) > > Mark > > On 29/08/2022 at 11:00:13 PM, Grzegorz Grzybek > wrote: > > > Hello > > > > First - to lower some confusion about Pax Logging versions, I've created > a > > handy (I hope) https://github.com/ops4j/org.ops4j.pax.logging#versions > > page. > > > > Just to refresh some dependencies, I've released 4 versions of minor > > releases with reload4j dependency upgrade: > > > > - 2.1.4 - R7 without Log4j1 backend > > - 2.0.19 - R7 with Log4j1 backend > > - 1.12.3 - R6 without Log4j1 backend > > - 1.11.17 - R6 with Log4j1 backend > > > > Additionally, there's a new release 2.2.0, which exports > > "org.osgi.service.log" package with version 1.5 (OSGi R8). > > > > All the release notes can be found using the following links: > > > > - 2.2.0: > > https://github.com/ops4j/org.ops4j.pax.logging/milestone/84?closed=1 > > - 2.1.4: > > https://github.com/ops4j/org.ops4j.pax.logging/milestone/96?closed=1 > > - 2.0.19: > > https://github.com/ops4j/org.ops4j.pax.logging/milestone/99?closed=1 > > <https://github.com/ops4j/org.ops4j.pax.logging/milestone/80?closed=1> > > - 1.12.3: > > https://github.com/ops4j/org.ops4j.pax.logging/milestone/100?closed=1 > > - 1.11.17: > > https://github.com/ops4j/org.ops4j.pax.logging/milestone/101?closed=1 > > > > kind regards > > Grzegorz Grzybek > > >
[ANN] Pax Logging 2.2.0, 2.1.4, 2.0.19, 1.12.3, 1.11.17 released (5 versions)
Hello First - to lower some confusion about Pax Logging versions, I've created a handy (I hope) https://github.com/ops4j/org.ops4j.pax.logging#versions page. Just to refresh some dependencies, I've released 4 versions of minor releases with reload4j dependency upgrade: - 2.1.4 - R7 without Log4j1 backend - 2.0.19 - R7 with Log4j1 backend - 1.12.3 - R6 without Log4j1 backend - 1.11.17 - R6 with Log4j1 backend Additionally, there's a new release 2.2.0, which exports "org.osgi.service.log" package with version 1.5 (OSGi R8). All the release notes can be found using the following links: - 2.2.0: https://github.com/ops4j/org.ops4j.pax.logging/milestone/84?closed=1 - 2.1.4: https://github.com/ops4j/org.ops4j.pax.logging/milestone/96?closed=1 - 2.0.19: https://github.com/ops4j/org.ops4j.pax.logging/milestone/99?closed=1 <https://github.com/ops4j/org.ops4j.pax.logging/milestone/80?closed=1> - 1.12.3: https://github.com/ops4j/org.ops4j.pax.logging/milestone/100?closed=1 - 1.11.17: https://github.com/ops4j/org.ops4j.pax.logging/milestone/101?closed=1 kind regards Grzegorz Grzybek
