Re: pax-web-8: handling security for non-existent resources?
Hello
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,/}]}
>
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:
> 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=OCM-1,name='default',path='/',bundle=org.ops4j.pax.web.pax-web-extender-whiteboard,context=(supplier)}}
was replaced b:
{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}}}
So the context (in terms of org.osgi.service.http.HttpContext and
org.osgi.service.http.context.ServletContextHelper) was switched from the
one provided (by default) by org.ops4j.pax.web.pax-web-extender-whiteboard
bundle to the one provided by Jolokia.
And now the final part of the explanation - what is used to handle
/restconf/operational/network-topology:network-topology/topology/example-ipv4-topology
URL? Pax Web delegates to the underlying container (Jetty, Tomcat and
Undertow) to handle the mapping - and according to Servlets specification,
first, the context is chosen using the longest possible path.
>From the logs you've provided, I see that in addition to "/" context (now
managed by Jolokia) you have two more contexts:
- /auth - {WB,id=OCM-8,name='/auth.id
',path='/auth',bundle=org.opendaylight.aaa.shiro,ref={org.osgi.service.http.context.ServletContextHelper}={
service.id=464, osgi.http.whiteboard.context.name=/auth.id,
service.bundleid=181, service.scope=singleton,
osgi.http.whiteboard.context.path=/auth}}
- /yanglib - {WB,id=OCM-13,name='/yanglib.id
',path='/yanglib',bundle=org.opendaylight.netconf.yanglib,ref={org.osgi.service.http.context.ServletContextHelper}={
service.id=472, osgi.http.whiteboard.context.name=/yanglib.id,
service.bundleid=370, service.scope=singleton,
osgi.http.whiteboard.context.path=/yanglib}}
There are no contexts with paths like:
- /restconf/operational/network-topology:network-topology
- /restconf/operational
- /restconf
(at least I don't see them). So the context that handles
/restconf/operational/network-topology:network-topology/topology/example-ipv4-topology
is simply "/" with Jolokia's provided security handled by
org.jolokia.osgi.security.ServiceAuthenticationHttpContext.handleSecurity().
Can you check Karaf's web:context-list command?
regards
Gr
Re: Circular feature dependency?
Hello Pax Web 8 features use a kind of "loose coupling" to Karaf features. It doesn't use `` element in https://github.com/ops4j/org.ops4j.pax.web/blob/main/pax-web-features/src/main/resources/features.xml, just this: ... shell And Karaf should provide "shell" feature - in any version. The fact that Pax Web 8 POM have concrete version of Karaf isn't relevant from features point of view. kind regards Grzegorz Grzybek pon., 11 lip 2022 o 16:26 Paul Stanley napisał(a): > Hello, > > Just a quick observation. There appears to be a circular dependency > between the karaf standard feature and the pax-web feature. To deal with > the problem the pax-web-service references an old version of karaf. e.g > pax-web-8.0.6 references Karaf version 4.7.3. > Is this going to cause any issues going forward? > > Thanks > Paul > > Get TypeApp for Android<http://www.typeapp.com/r> >
Re: [VOTE] Apache Karaf runtime 4.4.1 release
+1 regards Grzegorz Grzybek pon., 11 lip 2022 o 09:31 fpapon napisał(a): > +1 (binding) > > regards, > > On 10/07/2022 19:24, Jean-Baptiste Onofré wrote: > > Hi guys, > > > > I submit Apache Karaf runtime 4.4.1 release to your vote. > > > > This release is a maintenance release bringing a lot of dependency > > updates and fixes. > > Especially, this release includes: > > - fix on the exported system packages > > - fix on the config management in features service > > - upgrade to Pax Web 8.0.6, Pax URL 2.6.11, Pax Logging 2.1.3 > > - upgrade to OSGi frameworks (both Felix Framework 7.0.5 and Equinox > 3.18.0) > > - upgrade to Spring 5.3.21 and 5.2.22.RELEASE > > > > You can take a look on the Release Notes for details: > > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12351548 > > > > Maven Staging Repository: > > https://repository.apache.org/content/repositories/orgapachekaraf-1176/ > > > > Dist Staging Repository: > > https://dist.apache.org/repos/dist/dev/karaf/4.4.1/ > > > > Git tag: > > karaf-4.4.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 > > -- > -- > François > >
[ANN] Pax Logging 2.0.18 released
Hello I'd like to announce the release of Pax Logging 2.0.18 with just one update: - Log4j2 2.18.0 This is simply a follow up of Pax Logging 2.1.3 release. Pax Logging 2.0.x is exactly the same as 2.1.x, but includes legacy log4j1 backend. The release notes can be found here: - 2.0.18: https://github.com/ops4j/org.ops4j.pax.logging/milestone/97?closed=1 kind regards Grzegorz Grzybek
Re: [ANN] Pax Logging 2.1.3 released
Hello wt., 5 lip 2022 o 15:23 Eric Lilja napisał(a): > Great, thanks! > > Question: Will Pax Exam be updated to use this version, it uses an ancient > version doesn't it? > I think it does. I never released Pax Exam versions (though I did one deadlock fix I guess). In all other Pax projects I worked, I used Pax Exam in "custom mode", which allowed me to use any Pax Logging version I wanted :) (check Pax Web, Pax JDBC, Pax JMS, Pax Transx). Pax Logging itself is also tested using Pax Exam ;) But answering your question, I think there should be no problem upgrading Pax Exam itself. regards Grzegorz Grzybek > > - Eric L > > On Tue, Jul 5, 2022 at 3:18 PM Grzegorz Grzybek > wrote: > > > Hello > > > > I'd like to announce the release of Pax Logging 2.1.3 with just one > update: > > > >- Log4j2 2.18.0 > > > > Updating to 2.18.0 helped with one CCE problem related to JeroMqAppender. > > > > I'd like to mention that lines 2.0.x and 1.11.x are no longer a priority > > because they include log4j1 "backend". > > And line 1.12.x without log4j1 backend is based on OSGi CMPN R6 which is > > already quite old. > > > > So if you can, please migrate to 2.1.x. If you can't, please let us know > ;) > > > > The release notes can be found here: > > > >- 2.1.3: > >https://github.com/ops4j/org.ops4j.pax.logging/milestone/95?closed=1 > > > > kind regards > > Grzegorz Grzybek > > >
[ANN] Pax Logging 2.1.3 released
Hello I'd like to announce the release of Pax Logging 2.1.3 with just one update: - Log4j2 2.18.0 Updating to 2.18.0 helped with one CCE problem related to JeroMqAppender. I'd like to mention that lines 2.0.x and 1.11.x are no longer a priority because they include log4j1 "backend". And line 1.12.x without log4j1 backend is based on OSGi CMPN R6 which is already quite old. So if you can, please migrate to 2.1.x. If you can't, please let us know ;) The release notes can be found here: - 2.1.3: https://github.com/ops4j/org.ops4j.pax.logging/milestone/95?closed=1 kind regards Grzegorz Grzybek
[ANN] Pax Web 8.0.5 released
Hello I'd like to announce the release of Pax Web 8.0.5 - with few fixes, improvements and runtime upgrades. The runtime versions are: - Jetty 9.4.48.v20220622 - Tomcat 9.0.64 - Undertow 2.2.18.Final The changes are: - there's now new option in org.ops4j.pax.web PID called "org.ops4j.pax.web.session.cookie.sameSite", which allows to add SameSite attribute to session cookie. The accepted values are: unset (default), none, lax, strict - There's a fix for NPE when starting Jetty without any configured connector - There's a fix for the problem where truststore is not set with SSL configuration - When using external context.xml configuration for Tomcat, authentication valve is added only once. Full changelog can be found here[1]. kind regards Grzegorz Grzybek === [1]: https://github.com/ops4j/org.ops4j.pax.web/milestone/215?closed=1 >
Re: Karaf 4.4/Pax-Web 8.0.4 Tomcat login valve handling
Hello
I didn't spot the change embedded in the move ;) But anyway - thanks for
the PR and the improvement! The tests passed and I've merged your PR.
Tomorrow I'll release 8.0.5.
regards
Grzegorz Grzybek
wt., 28 cze 2022 o 15:08 Siano, Stephan
napisał(a):
> Hi Grzegorz,
>
> The change is actually simpler than it looks, I just moved some code
> further down. The only code that is actually new is
> // Has an authenticator been configured
> already?
> authenticationValve = (Valve)
> context.getAuthenticator();
> if (authenticationValve == null) {
> (and the closing bracket for the if statement).
>
> I did run the tests (with -Ptomcat, so I didn't run the integration tests
> for jetty and undertow). In my (Windows) environment a few tests failed
> (three in the non-OSGi integration test and two Tomcat integration tests,
> but I got the same errors before the change).
>
> Tests are always a bit difficult or run in foreign environments for
> projects as big as pax-web, but it worked relatively smooth for me.
>
> Thanks for the quick response. I really appreciate this!
>
> Best regards
> Stephan
>
>
> -Original Message-
> From: Grzegorz Grzybek
> Sent: Tuesday, 28 June 2022 14:32
> To: dev@karaf.apache.org
> Subject: Re: Karaf 4.4/Pax-Web 8.0.4 Tomcat login valve handling
>
> Hello
>
> The process is perfectly fine ;) Just create a GH issue and/or PR and we
> can include it in the next release.
> By simply looking at
>
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fops4j%2Forg.ops4j.pax.web%2Fpull%2F1734%2Ffilesdata=05%7C01%7Cstephan.siano%40sap.com%7Ce41771998d754338a7b808da59024236%7C42f7676cf455423c82f6dc2d99791af7%7C0%7C0%7C637920163477527906%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=SZoEfSn3A64QznDxAt3B9pXmI0keapseqpj344a2S54%3Dreserved=0
> I can't _feel_ the change, let me just run all the tests (btw - did you run
> it? I'd be happy to get a feedback about how easy/hard it is to run the
> tests :).
>
> I plan to release 8.0.5 to be included in Karaf 4.4.1 and we should be
> ready this week (with Pax Web 8.0.5).
>
> thanks for the issue+PR!
> regards
> Grzegorz Grzybek
>
> wt., 28 cze 2022 o 14:04 Siano, Stephan
> napisał(a):
>
> > Hi,
> >
> > I have a meta-question concerning extensions in pax-web.
> >
> > With pax-web 8.0.4 (which is the latest version of the pax-web in the
> > karaf 4.4 release) thanks to Grzegorz parsing of global and war
> > specific context.xml files works in pax-web-tomcat.
> >
> > However there is still one limitation: If the context configuration
> > contains a login valve unlike in plain Tomcat the default login valve
> > will be added in addition to the one from the context configuration.
> >
> > The resolution is a rather easy change in the
> > org.ops4j.pax.web.service.tomcat.internal.OsgiContextConfiguration class.
> >
> > What is the process for this? I created
> > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> > ub.com%2Fops4j%2Forg.ops4j.pax.web%2Fissues%2F1733data=05%7C01%7C
> > stephan.siano%40sap.com%7Ce41771998d754338a7b808da59024236%7C42f7676cf455423c82f6dc2d99791af7%7C0%7C0%7C637920163477527906%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=PJw3NcjWkWFmjPBaWTo23TaoyuVFPRI9Vri6UcIQyI4%3Dreserved=0
> for this topic and I can also contribute a pull request to pax-web for it.
> Is this the way to go, or did I do something wrong there?
> >
> > Best regards
> > Stephan
> >
>
Re: Karaf 4.4/Pax-Web 8.0.4 Tomcat login valve handling
Hello The process is perfectly fine ;) Just create a GH issue and/or PR and we can include it in the next release. By simply looking at https://github.com/ops4j/org.ops4j.pax.web/pull/1734/files I can't _feel_ the change, let me just run all the tests (btw - did you run it? I'd be happy to get a feedback about how easy/hard it is to run the tests :). I plan to release 8.0.5 to be included in Karaf 4.4.1 and we should be ready this week (with Pax Web 8.0.5). thanks for the issue+PR! regards Grzegorz Grzybek wt., 28 cze 2022 o 14:04 Siano, Stephan napisał(a): > Hi, > > I have a meta-question concerning extensions in pax-web. > > With pax-web 8.0.4 (which is the latest version of the pax-web in the > karaf 4.4 release) thanks to Grzegorz parsing of global and war specific > context.xml files works in pax-web-tomcat. > > However there is still one limitation: If the context configuration > contains a login valve unlike in plain Tomcat the default login valve will > be added in addition to the one from the context configuration. > > The resolution is a rather easy change in the > org.ops4j.pax.web.service.tomcat.internal.OsgiContextConfiguration class. > > What is the process for this? I created > https://github.com/ops4j/org.ops4j.pax.web/issues/1733 for this topic and > I can also contribute a pull request to pax-web for it. Is this the way to > go, or did I do something wrong there? > > Best regards > Stephan >
Re: [VOTE] Apache Karaf runtime 4.2.16 release
+1 regards Grzegorz Grzybek pon., 13 cze 2022 o 14:17 Jamie G. napisał(a): > +1 > > Cheers, > Jamie > > On Mon, Jun 13, 2022 at 9:40 AM Jean-Baptiste Onofré > wrote: > > > > +1 (binding) > > > > Regards > > JB > > > > On Fri, Jun 10, 2022 at 3:11 PM Jean-Baptiste Onofré > wrote: > > > > > > Hi guys, > > > > > > As requested by some users, I submit Apache Karaf runtime 4.2.16 > > > release to your vote. > > > > > > This release includes important updates, especially Pax URL 1.11.15. > > > > > > NB: 4.2.16 should be the last release on the 4.2.x series. Again, we > > > strongly encourage users to upgrade to 4.3.x or 4.4.x series. > > > > > > Release Notes: > > > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12351218 > > > > > > Maven Staging Repository: > > > > https://repository.apache.org/content/repositories/orgapachekaraf-1175/ > > > > > > Dist Staging Repository: > > > https://dist.apache.org/repos/dist/dev/karaf/4.2.16/ > > > > > > Git tag: > > > karaf-4.2.16 > > > > > > 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: [UPDATE] Apache Karaf runtime 4.2.16 and 4.4.1 releases planned next week
Hello I've created https://issues.apache.org/jira/browse/KARAF-7449 to upgrade to Pax Web 8.0.4 (with some recent fixes to context processing and "/" WAB fixes) and I'll upgrade today. regards Grzegorz Grzybek wt., 7 cze 2022 o 05:32 Jean-Baptiste Onofré napisał(a): > Hi guys > > Just to let you know that I finished the preparation of 4.2.16 release. I > will submit to vote soon. > > Regarding 4.4.1 and 4.3.8, I’m still working on it. I hope to submit to > vote by the end of this week. > > Regards > JB > > Le ven. 27 mai 2022 à 09:31, Jean-Baptiste Onofré a > écrit : > > > Hi guys, > > > > I'm working on Karaf runtime 4.2.16 (last one on the 4.2.x series) and > > 4.4.1 releases. > > > > I hope to submit those releases to vote during the weekend or > > beginning of next week. > > > > On the other hand, I'm moving forward on Karaf 5.x preparation. I'm > > working on tooling (an important part) and demo. Stay tuned, I should > > be able to provide an update soon (and push to Apache repo). > > > > Regards > > JB > > >
[ANN] Pax Web 8.0.4 released
Hello
I'd like to announce the release of Pax Web 8.0.4 - with few fixes and
quite important improvements.
The changes are:
- there's now new option in org.ops4j.pax.web PID called (thanks Stephan
Siano!) "org.ops4j.pax.web.context.file", which can be used for Tomcat and
Jetty to point to a global context configuration file. Standalone Tomcat
has $CATALINA_HOME/conf/context.xml file and Pax Web now allows to point to
similar file that's used to configure ALL contexts (whether these are
created from WABs, HttpService or Whiteboard):
- with pax-web-tomcat, it points to (commented out by default)
${karaf.etc}/tomcat-context.xml
- with pax-web-jetty, it points to (commented out by default)
${karaf.etc}/jetty-web.xml
- There's a fix to WABs with Web-ContextPath=/ (thanks Jakub Herkel!) -
to prevent conflicts with servlets registered in standard way to "/"
context. So now it's really safe to have a WAB deployed to "/" and at the
same time, a popular CXF's /cxf servlet registered by
cxf-rt-transports-http bundle
- There's a fix to how multiple "context processing" configurations
affect a context (thanks Gerald Kallas!) - so you can have external
security constraints defined in multiple files (and fragments)
The runtime versions are:
- Jetty 9.4.46.v20220331
- Tomcat 9.0.63
- Undertow 2.2.17.Final
Full changelog can be found here[1].
kind regards
Grzegorz Grzybek
===
[1]: https://github.com/ops4j/org.ops4j.pax.web/milestone/214?closed=1
>
Re: Karaf 4.4.0/Pax-Web 8.0.2 Tomcat context handling
Hello!
pon., 30 maj 2022 o 11:26 Siano, Stephan
napisał(a):
> Hi Grzegorz,
>
> Thanks a lot, this looks great. I will try to test that as soon as I find
> the time for it.
>
If it's fine, then I'll do a 8.0.4 release.
regards
Grzegorz Grzybek
>
> Best regards
> Stephan
>
> -Original Message-
> From: Grzegorz Grzybek
> Sent: Wednesday, 25 May 2022 13:05
> To: dev@karaf.apache.org
> Subject: Re: Karaf 4.4.0/Pax-Web 8.0.2 Tomcat context handling
>
> Hello
>
> wt., 24 maj 2022 o 15:28 Siano, Stephan
> napisał(a):
>
> > Hi Grzegorz,
> >
> > > These are kind of inline dev notes. I can imagine that they may blur
> > > the
> > code, but I really tried to ensure that everything is consistent, so I
> > spent a lot of time reading the
> > > original Tomcat/Jetty/Undertow code and writing down some observations.
> > > This note just states what Tomcat itself is doing and it uses it for
> > $CATALINA_HOME/conf/context.xml file which is common to ALL web
> > applications. That's definitely
> > > something we DON'T want in Pax Web.
> >
> > Well, this global context.xml in Tomcat is for customizing all web
> > applications to the environment. This might as well be a use case for
> > the karaf container. Currently some of the stuff like authentication
> > configuration is hard-coded in the pax-web-tomcat coding, however we
> > need to find a way to customize this somehow...
> >
>
> I've created and fixed
>
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fops4j%2Forg.ops4j.pax.web%2Fissues%2F1723data=05%7C01%7Cstephan.siano%40sap.com%7C617076115dd54a790a2708da3e3e63d6%7C42f7676cf455423c82f6dc2d99791af7%7C0%7C0%7C637890734929332755%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=%2FvdjG0ax56a7L2t7pa07zB4Mj1knwRiM79L3CCgjc4A%3Dreserved=0
>
> I found i indeed useful, so I've added support for another PID
> configuration option - `org.ops4j.pax.web.context.file` If you install
> pax-web-http-jetty or pax-web-http-tomcat (no support for Undertow), you
> can configure a global "context configuration file" which
> matches:
>
>- for Jetty, the jetty-web.xml file documented in
>
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.eclipse.org%2Fjetty%2Fdocumentation%2Fjetty-9%2Findex.html%23using-basic-descriptor-filesdata=05%7C01%7Cstephan.siano%40sap.com%7C617076115dd54a790a2708da3e3e63d6%7C42f7676cf455423c82f6dc2d99791af7%7C0%7C0%7C637890734929332755%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=sssbzXtw3aykNaWivNHMTmj7BYEzUT8i3CpPpIVRvDs%3Dreserved=0
>- it was already handled from /WEB-INF/jetty-web.xml
>- for Tomcat, the tomcat-context.xml file documented in
>
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftomcat.apache.org%2Ftomcat-9.0-doc%2Fconfig%2Fcontext.htmldata=05%7C01%7Cstephan.siano%40sap.com%7C617076115dd54a790a2708da3e3e63d6%7C42f7676cf455423c82f6dc2d99791af7%7C0%7C0%7C637890734929332755%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=0t4Ey84q3NKm0AAXkwx3f1q1nbXTzR%2BDvyFG4941HMg%3Dreserved=0
> - it was
>already handled from META-INF/context.xml - Tomcat reads it from
>$CATALINA_HOME/conf/context.xml
>
> These options are disabled by default, but I provide template versions of
> jetty-web.xml and tomcat-context.xml
>
> For example, tomcat-context.xml contains:
>
>
>
>
>
> If you uncomment the valve and "org.ops4j.pax.web.context.file =
> ${karaf.etc}/tomcat-context.xml" option, the valve rejects request from non
> local addresses - I hope that's what you're looking for.
>
> kind regards
> Grzegorz Grzybek
>
>
> >
> > Best regards
> > Stephan
> >
> > -Original Message-
> > From: Grzegorz Grzybek
> > Sent: Tuesday, 24 May 2022 11:44
> > To: dev@karaf.apache.org
> > Subject: Re: Karaf 4.4.0/Pax-Web 8.0.2 Tomcat context handling
> >
> > Hello
> >
> > wt., 24 maj 2022 o 09:59 Siano, Stephan
> >
> > napisał(a):
> >
> > > Hi,
> > >
> > > I have been trying around with Karaf 4.4.0 with the pax-web-tomcat
> > > webcontainer in the last days. First of all I want to state that
> > > Grzegorz did a fantastic job with the Pax-Web refactoring!
> > >
> >
> > It was my pleasure refactoring ;) I'd never have written/designed
> > anything as complex as Pax Web in the first place, so big thanks to
> original authors!
> >
> &g
Re: Karaf 4.4.0/Pax-Web 8.0.2 Tomcat context handling
Hello
wt., 24 maj 2022 o 15:28 Siano, Stephan
napisał(a):
> Hi Grzegorz,
>
> > These are kind of inline dev notes. I can imagine that they may blur the
> code, but I really tried to ensure that everything is consistent, so I
> spent a lot of time reading the
> > original Tomcat/Jetty/Undertow code and writing down some observations.
> > This note just states what Tomcat itself is doing and it uses it for
> $CATALINA_HOME/conf/context.xml file which is common to ALL web
> applications. That's definitely
> > something we DON'T want in Pax Web.
>
> Well, this global context.xml in Tomcat is for customizing all web
> applications to the environment. This might as well be a use case for the
> karaf container. Currently some of the stuff like authentication
> configuration is hard-coded in the pax-web-tomcat coding, however we need
> to find a way to customize this somehow...
>
I've created and fixed
https://github.com/ops4j/org.ops4j.pax.web/issues/1723
I found i indeed useful, so I've added support for another PID
configuration option - `org.ops4j.pax.web.context.file`
If you install pax-web-http-jetty or pax-web-http-tomcat (no support for
Undertow), you can configure a global "context configuration file" which
matches:
- for Jetty, the jetty-web.xml file documented in
https://www.eclipse.org/jetty/documentation/jetty-9/index.html#using-basic-descriptor-files
- it was already handled from /WEB-INF/jetty-web.xml
- for Tomcat, the tomcat-context.xml file documented in
https://tomcat.apache.org/tomcat-9.0-doc/config/context.html - it was
already handled from META-INF/context.xml - Tomcat reads it from
$CATALINA_HOME/conf/context.xml
These options are disabled by default, but I provide template versions of
jetty-web.xml and tomcat-context.xml
For example, tomcat-context.xml contains:
If you uncomment the valve and "org.ops4j.pax.web.context.file =
${karaf.etc}/tomcat-context.xml" option, the valve rejects request from non
local addresses - I hope that's what you're looking for.
kind regards
Grzegorz Grzybek
>
> Best regards
> Stephan
>
> -Original Message-
> From: Grzegorz Grzybek
> Sent: Tuesday, 24 May 2022 11:44
> To: dev@karaf.apache.org
> Subject: Re: Karaf 4.4.0/Pax-Web 8.0.2 Tomcat context handling
>
> Hello
>
> wt., 24 maj 2022 o 09:59 Siano, Stephan
> napisał(a):
>
> > Hi,
> >
> > I have been trying around with Karaf 4.4.0 with the pax-web-tomcat
> > webcontainer in the last days. First of all I want to state that
> > Grzegorz did a fantastic job with the Pax-Web refactoring!
> >
>
> It was my pleasure refactoring ;) I'd never have written/designed anything
> as complex as Pax Web in the first place, so big thanks to original authors!
>
>
> > Nevertheless, I encountered a few issues with tomcat context.xml
> handling.
> >
> > First of all prior versions of pax-web-tomcat were able to load a
> > default context.xml from the same directory as the tomcat-server.xml.
> > I am not sure how to proceed with this.
> > The BundleWebApplication class in the pax-web-extender-war bundle
> > contains the following comment:
> > // additionally:
> > // - Tomcat handles context.xml files
> > set by org.apache.catalina.core.StandardContext.setDefaultContextXml()
> >
>
> These are kind of inline dev notes. I can imagine that they may blur the
> code, but I really tried to ensure that everything is consistent, so I
> spent a lot of time reading the original Tomcat/Jetty/Undertow code and
> writing down some observations.
> This note just states what Tomcat itself is doing and it uses it for
> $CATALINA_HOME/conf/context.xml file which is common to ALL web
> applications. That's definitely something we DON'T want in Pax Web.
>
>
> > However, as far as I understand, the defaultContextXml in
> > StandardContext is not used in the embedded Tomcat. The only uses I
> > could find was in the
> > org.apache.catalina.startup.ContextConfig.contextConfig() method which
> > does not seem to get called by the embedded tomcat startup. This
> > method is normally called with a
> > ContextConfig.lifecycleEvent(Lifecycle.AFTER_INIT_EVENT), but it seems
> > that this ContextConfig lifecycle is not called. I am not sure what is
> > the way to go here, either to try to include this ContextConfig
> > lifecycle, try to exeute the contextConfig method with the digester we
> > get in the
> > TomcatFactory.createContextDigester() method, or try to funnel this
> > default context.xml somehow into the serverSpecificDescriptors and
> > parse it in the tomcat specific OsgiCon
Re: Karaf 4.4.0/Pax-Web 8.0.2 Tomcat context handling
ght - I've explicitly searched for context.xml in
multiple locations, but didn't use it when actually applying the
configuration. The check is needed to not include for example Jetty's
WEB-INF/jetty-web.xml when using Tomcat, but simple change from:
if (path.equals("/META-INF/context.xml")) {
to:
if (path.endsWith("/META-INF/context.xml")) {
is probably what we need.
>
> I am willing to contribute to this, but I would prefer to discuss the
> correct way to go first.
>
I've created https://github.com/ops4j/org.ops4j.pax.web/issues/1721 to
track this issue - thanks!
And while I've checked, I can immediately fix it ;)
kind regards
Grzegorz Grzybek
> Best regards
> Stephan
>
Re: The state of Pax Web
pt., 29 kwi 2022 o 16:44 Matt Pavlovich napisał(a): > Hi Grzegorz- > > > > Great work on this refactor, it was quite an undertaking! Saying “much > appreciated” seems like not enough =). > It was my pleasure - another reason to admire internal OSGi design :) I had really good time working with the code written greatly by others. I hope my goal to only polish things and to make them more stable and spec compliant as achieved - not many classes were removed. And not many were added. I hoped to make things work as similar as possible between Jetty, Tomcat and Undertow and I think the structure of pax-web-jetty, pax-web-tomcat and pax-web-undertow is really similar, so anyone can work on it without getting lost ;) > > > We have a JMeter test suite that we’ll run against Karaf + Pax Web v8.0.3 > and report back in the few couple weeks for functionality and performance > —covers REST and Web app servlet functionality. > Great! I'd love to see the results! regards Grzegorz Grzybek > > > Thank you, > > Matt Pavlovich > > > > *From: *op...@googlegroups.com on behalf of > Grzegorz Grzybek > *Date: *Friday, April 29, 2022 at 4:36 AM > *To: *OPS4J , Karaf Dev > *Subject: *The state of Pax Web > > Hello > > > > I'm planning to release Pax Web 8.0.3 with 6 issues fixed, including: > >- Keycloak integration tweaks (see >https://issues.redhat.com/browse/KEYCLOAK-19939) >- refined session management (session per Osgi Context with single >JSESSIONID cookie per Servlet Context) >- two deadlocks fixes (Aries CDI) >- gzip encoding configuration and Jetty RewriteHandler support > > With the above fixes, *I think my long term plan to refactor Pax Web ends*. > It doesn't mean I quit, it simply means I don't plan anything new to add to > Pax Web if there's no request to do so. > > > > IMO, the compliance with chapters 102 (Http Service), 128 (Web > Applications) and 140 (Whiteboard Service) of OSGi CMPN specification (R7, > but should be the same for R8) is sufficiently complete. I didn't run the > TCKs, because I didn't have much time to understand how to run it in proper > way ;) > > > > There's one obvious violation of Whiteboard specification wrt to context > handling. See 140.2 The Servlet Context > <https://docs.osgi.org/specification/osgi.cmpn/7.0.0/service.http.whiteboard.html#service.http.whiteboard.servletcontext> > [1]: > > > > For example, if two ServletContextHelper services are registered as follows > > osgi.http.whiteboard.context.path = /foo > osgi.http.whiteboard.context.path = /foo/bar > > Then a request for http://localhost/foo/bar/someServlet is looked up in > the following order: > >1. /foo/bar context looking for a pattern to match /someServlet >2. /foo context looking for a pattern to match /bar/someServlet > > According to JavaServlet specification, context selection happens first > and further resolution of servlets is performed within the found context. > The above Whiteboard requirement mandates searching for servlets in other > contexts. I've consciously NOT implemented the Whiteboard behavior, > sticking to JavaServlet recommendation. > > > > Anyway - I hope Pax Web 8 is stable and fast enough to be used in > production. There are much more tests than we had in Pax Web 7 and I've > added complex WAR scenarios involving CDI, JSF and complex > ServletContainerInitializer scenarios, including web-fragment.xml > integration tests. > > > > I'll of course be releasing new versions if there's new Jetty, Tomcat or > Undertow release - in Pax Web 8 we no longer require TIPI releases for > Tomcat. > > > > If you see any problems or have nice feature requests, please create a > GitHub issue at usual place > <https://github.com/ops4j/org.ops4j.pax.web/issues>[2]. > > > > kind regards > > Grzegorz Grzybek > > === > > [1]: > https://docs.osgi.org/specification/osgi.cmpn/7.0.0/service.http.whiteboard.html#service.http.whiteboard.servletcontext > > [2]: https://github.com/ops4j/org.ops4j.pax.web/issues > > -- > -- > -- > OPS4J - http://www.ops4j.org - op...@googlegroups.com > > --- > You received this message because you are subscribed to the Google Groups > "OPS4J" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to ops4j+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/ops4j/CAAdXmhobbxcXUFnNQ_AiK-b04MCQR_QAXdMRG47MbmKKakNjpg%40mail.gmail.com > <https://groups.google.com/d/msgid/ops4j/CAAdXmhobbxcXUFnNQ_AiK-b04MCQR_QAXdMRG47MbmKKakNjpg%40mail.gmail.com?ut
[ANN] Pax Web 8.0.3 released
Hello I'd like to announce the release of Pax Web 8.0.3 - the feature complete version of Pax Web 8. Since now, new 8.0.x release should be mostly bug-fix only and jetty/tomcat/underdow-update only (and of course CVE fix only). All features I planned to include (like Keycloak support) are in place. This is a minor release but adds several new features: - Keycloak WAR example works - Sessions are handled a bit differently (one per OSGi Context with single JSESSION ID cookie) The runtime versions are: - Jetty 9.4.46.v20220331 - Tomcat 9.0.62 - Undertow 2.2.17.Final Full changelog can be found here[1]. kind regards Grzegorz Grzybek === [1]: https://github.com/ops4j/org.ops4j.pax.web/milestone/212?closed=1 >
The state of Pax Web
Hello I'm planning to release Pax Web 8.0.3 with 6 issues fixed, including: - Keycloak integration tweaks (see https://issues.redhat.com/browse/KEYCLOAK-19939) - refined session management (session per Osgi Context with single JSESSIONID cookie per Servlet Context) - two deadlocks fixes (Aries CDI) - gzip encoding configuration and Jetty RewriteHandler support With the above fixes, *I think my long term plan to refactor Pax Web ends*. It doesn't mean I quit, it simply means I don't plan anything new to add to Pax Web if there's no request to do so. IMO, the compliance with chapters 102 (Http Service), 128 (Web Applications) and 140 (Whiteboard Service) of OSGi CMPN specification (R7, but should be the same for R8) is sufficiently complete. I didn't run the TCKs, because I didn't have much time to understand how to run it in proper way ;) There's one obvious violation of Whiteboard specification wrt to context handling. See 140.2 The Servlet Context <https://docs.osgi.org/specification/osgi.cmpn/7.0.0/service.http.whiteboard.html#service.http.whiteboard.servletcontext> [1]: For example, if two ServletContextHelper services are registered as follows > > osgi.http.whiteboard.context.path = /foo > osgi.http.whiteboard.context.path = /foo/bar > > Then a request for http://localhost/foo/bar/someServlet is looked up in > the following order: > >1. /foo/bar context looking for a pattern to match /someServlet >2. /foo context looking for a pattern to match /bar/someServlet > > According to JavaServlet specification, context selection happens first and further resolution of servlets is performed within the found context. The above Whiteboard requirement mandates searching for servlets in other contexts. I've consciously NOT implemented the Whiteboard behavior, sticking to JavaServlet recommendation. Anyway - I hope Pax Web 8 is stable and fast enough to be used in production. There are much more tests than we had in Pax Web 7 and I've added complex WAR scenarios involving CDI, JSF and complex ServletContainerInitializer scenarios, including web-fragment.xml integration tests. I'll of course be releasing new versions if there's new Jetty, Tomcat or Undertow release - in Pax Web 8 we no longer require TIPI releases for Tomcat. If you see any problems or have nice feature requests, please create a GitHub issue at usual place <https://github.com/ops4j/org.ops4j.pax.web/issues>[2]. kind regards Grzegorz Grzybek === [1]: https://docs.osgi.org/specification/osgi.cmpn/7.0.0/service.http.whiteboard.html#service.http.whiteboard.servletcontext [2]: https://github.com/ops4j/org.ops4j.pax.web/issues
Re: [VOTE] Apache Karaf runtime 4.4.0 release
+1 Thanks for your work JBO! regards Grzegorz Grzybek wt., 19 kwi 2022 o 08:24 Jean-Baptiste Onofré napisał(a): > Hi guys, > > I submit Apache Karaf runtime 4.4.0 release to your vote. > This release is a new milestone, starting the 4.4.x series. > > This release includes: > - OSGi R8 support > - Pax Web 8.x upgrade > - Pax Logging 2.1.x upgrade > - and much much more ! > > You can take a look on the Release Notes for details: > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12349243 > > Maven Staging Repository: > https://repository.apache.org/content/repositories/orgapachekaraf-1173/ > > Dist Staging Repository: > https://dist.apache.org/repos/dist/dev/karaf/4.4.0/ > > Git tag: > karaf-4.4.0 > > Please vote to approve this release: > [ ] +1 Approve the release > [ ] -1 Don't approve the release (please provide specific comments) > > This vote will be open for at least 72 hours. > > Regards > JB >
[ANN] Pax Web 8.0.2 released
Hello I'd like to announce the release of Pax Web 8.0.2. This is a minor release but adds several new features: - HTTP Context Processing (reimplementation of this feature from Pax Web 7 - this time it's possible to alter existing context using external web-fragment.xml <https://github.com/ops4j/org.ops4j.pax.web/blob/main/pax-web-itest/pax-web-itest-container/pax-web-itest-jetty/src/test/java/org/ops4j/pax/web/itest/jetty/httpservice/HttpServiceProcessingWithWebFragmentIntegrationTest.java> [1]) - Fixes allowing Aries-CDI <https://github.com/ops4j/org.ops4j.pax.web/blob/main/pax-web-itest/pax-web-itest-karaf/src/test/java/org/ops4j/pax/web/itest/karaf/CdiJSFBaseKarafTest.java>[2] and Aries-JAX-RS <https://github.com/ops4j/org.ops4j.pax.web/blob/561a4408f048c8bc02a83f8e2a1044e974381376/pax-web-itest/pax-web-itest-container/pax-web-itest-container-common/src/main/java/org/ops4j/pax/web/itest/container/whiteboard/AbstractWhiteboardR7JaxRsIntegrationTest.java>[3] Whiteboard examples to run well in Pax Web - Added HTTP/2 support (Clear Text/h2c and ALPN/JDK9+ based) with tests The new runtime versions are: - Jetty 9.4.46.v20220331 - Tomcat 9.0.62 - Undertow 2.2.17.Final Full changelog can be found here[4]. kind regards Grzegorz Grzybek === [1]: https://github.com/ops4j/org.ops4j.pax.web/blob/main/pax-web-itest/pax-web-itest-container/pax-web-itest-jetty/src/test/java/org/ops4j/pax/web/itest/jetty/httpservice/HttpServiceProcessingWithWebFragmentIntegrationTest.java [2]: https://github.com/ops4j/org.ops4j.pax.web/blob/main/pax-web-itest/pax-web-itest-karaf/src/test/java/org/ops4j/pax/web/itest/karaf/CdiJSFBaseKarafTest.java [3]: https://github.com/ops4j/org.ops4j.pax.web/blob/561a4408f048c8bc02a83f8e2a1044e974381376/pax-web-itest/pax-web-itest-container/pax-web-itest-container-common/src/main/java/org/ops4j/pax/web/itest/container/whiteboard/AbstractWhiteboardR7JaxRsIntegrationTest.java [4]: https://github.com/ops4j/org.ops4j.pax.web/milestone/210?closed=1
[ANN] Pax Logging 2.1.2, 2.0.17, 1.12.2 and 1.11.16 released (4 versions)
Hello I'd like to announce the release of 4 Pax Logging versions with one version update: - Logback 1.2.11 One improvement: - "org.ops4j.pax.logging.logReaderEnabled" system/context property that allows disabling of org.osgi.service.log.LogReaderService registration. While it's a bit against the specification, it speeds up logging process (no more synchronized access to shared LinkedList. And one bug fix: - NPE when MDC contains null value and EventAdmin integration is enabled All the release notes can be found using the following links: - 2.1.2: https://github.com/ops4j/org.ops4j.pax.logging/milestone/94?closed=1 - 2.0.17: https://github.com/ops4j/org.ops4j.pax.logging/milestone/93?closed=1 - 1.12.2: https://github.com/ops4j/org.ops4j.pax.logging/milestone/92?closed=1 - 1.11.16: https://github.com/ops4j/org.ops4j.pax.logging/milestone/91?closed=1 kind regards Grzegorz Grzybek
Re: Apache Karaf board report for March 22
+1 Thanks! regards Grzegorz Grzybek wt., 1 mar 2022 o 16:41 Matt Pavlovich napisał(a): > +1 looks good. > > I see you have the note about all CVE’s are clear. Maybe add a specific > line item to mention log4shell related issues have been addressed? (Log2j, > reload4j, etc) > > Matt Pavlovich > > > On Mar 1, 2022, at 4:43 AM, Jean-Baptiste Onofré > wrote: > > > > Hi guys, > > > > I prepared the board report for this month: > > > > https://cwiki.apache.org/confluence/display/KARAF/Board+Reports > > > > Can you please take a look ? > > I would like to send the report to board asap. > > > > Thanks ! > > Regards > > JB > >
Re: [DISCUSSION] Move PAX projects to Apache Karaf ?
Hello I don't have clear opinion about which "home" is better (ASF or github.com/ops4j). I was thinking about this idea and here are my random thoughts: – [+1] for staying at GH: Not that long ago, I've migrated most of the projects (18) from https://ops4j1.jira.com/ to https://github.com/ops4j/*/issues - it required some effort, but IMO it was worth it - it's really much faster and the "turnaround" is shorter. The only (little) drawback is that we can't set more than one "fixed version" values for an issue. So going back to Jira would be (IMO) stepping back. – [+1] for ASF: at ASF we'd get nice CI infra to build the projects – [+1] for staying at GH: I'm aware that Pax Logging is quite often used outside of Karaf, so making it Karaf subproject could be confusing – [-1] for ASF: Felix already provides OSGi Logging, OSGi Http Service and OSGi Whiteboard implementations. – [-1] for ASF: 3 day vote - while totally great practice, for know we enjoy the flexibility to release Pax Logging the day the Log4j CVEs disasters happened (10th December 2021) – [+1] for ASF: as JBO said, ASF is a brand and it'd benefit OPS4J projects – [+1] for staying at GH: the "spirit" of Open Participation would be preserved. Mind that while I spent considerable amount of time refactoring Pax Logging and Pax Web, I still didn't find a time to work on proper, upgraded manual... Simply not that many people work on the projects. Bonus thought (but probably impossible) TLP Apache project... It'd however conflict (?) too much with Felix and its reference implementations of OSGi specs. kind regards, have a good weekend and prayers for peace Grzegorz Grzybek pt., 25 lut 2022 o 11:39 Jean-Baptiste Onofré napisał(a): > Thanks all for your comment. > > Fair discussion. I agree with you, just wanted to have this open > discussion and share some messages I received. > > Let's keep PAX as it is, at OPS4J. > > Thanks > Regards > JB > > On Fri, Feb 25, 2022 at 11:34 AM Łukasz Dywicki > wrote: > > > > I see problem similar to Achim. We still didn't hear anything about > > solving a community trouble. We definitely do not solve a trouble of > > ops4j community which probably do not overlap 100% with Karaf. We may be > > solving some trouble for Karaf community, however we probably ask about > > shifting even more work on already small set of people working on it. > > We hear concerns, which might or might not be justified. I don't think > > they are since there is no record of any malicious activities made by > > people contributing to ops4j/pax. > > People which are mainly contributing to these project are well known > > (Grzegorz, JB, Achim), externals contributions are coming over pull > > requests, just like they would come to the ASF, so why we should be > > moving around sources? As far I remember ASF does not scan IDs of their > > contributors so it can't guarantee identity of people behind > > contributions as well. Back at the times I was signing my agreement I > > was sending it by online fax service, so verification was very mild. > > While the GPG keys is some kind of resort, a lot of people (including > > myself) have self signed key which is as good as my ssh key I use to > > push things to git. > > > > The big customers can become part of community if they wish, no matter > > where project is hosted - at github or at ASF. So far it seems to me > > that they are asking for favor without giving anything back to > > communities which will be affected. > > > > Best, > > Łukasz > > > > On 25.02.2022 08:43, Achim Nierbeck wrote: > > > Hi, > > > > > > I'm sorry to be a PITA :) > > > What I've read so far has been feelings, one concern of perception by > "big" > > > customers. > > > I would really like to know, which problem we are trying to solve by > moving > > > the pax projects under the umbrella of Karaf. > > > Or what I personally would favor under their own tlp of the ASF. > > > > > > Just to clarify, I'm trying the 5 W's here ... > > > Why do you think it's a good idea to move the Pax Projects under the > karaf > > > umbrella? > > > Why do you think customers have a wrong perception of the Pax Projects > ... > > > and so on ... > > > > > > > > > What is the core issue we are trying to solve here? > > > As long as I don't get down to the core thing that needs to be solved > I'm > > > not in favor of moving the pax projects anywhere. > > > > > > Again sorry if I'm PITA. > > > > > > regards, Achim > > > > > > > > > >
[ANN] Pax Logging 2.1.1, 2.0.16, 1.12.1 and 1.11.15 released (4 versions)
Hello I'd like to announce the release of 4 Pax Logging versions with two version updates: - SLF4J 1.7.36 (not much affecting Pax Logging - just a version update) - Reload4J 1.2.19 (aligning to latest upstream version) in 1.11.15 and 2.0.16 (the 1.12.x and 2.1.x branches do not contain log4j1 backend) And two improvements: - Allowing Log4j2's JsonTemplateLayout (JSON without Jackson) - "org.ops4j.pax.logging.eventAdminEnabled" system/context property that allows disabling of EventAdmin integration - even if EventAdmin is mandatory in org.osgi.service.log specification (if available), it greatly affects performance (even on async logging), so this property should increase performance. See the github issue[1] All the release notes can be found using the following links: - 2.1.1: https://github.com/ops4j/org.ops4j.pax.logging/milestone/85?closed=1 - 2.0.16: https://github.com/ops4j/org.ops4j.pax.logging/milestone/88?closed=1 - 1.12.1: https://github.com/ops4j/org.ops4j.pax.logging/milestone/90?closed=1 - 1.11.15: https://github.com/ops4j/org.ops4j.pax.logging/milestone/89?closed=1 kind regards Grzegorz Grzybek === [1]: https://github.com/ops4j/org.ops4j.pax.logging/issues/480 <https://reload4j.qos.ch/>
[ANN] Pax Web 8.0.1 released
Hello I'd like to announce the release of Pax Web 8.0.1. Initial version 8.0.0 was released after roughly 2 years of interrupted refactoring. Version 8.0.1 adds missing pieces which didn't make it into 8.0.0.GA. This is a minor release but adds lot of new features besides normal version upgrades. The new runtime versions are: - Jetty 9.4.45.v20220203 - Tomcat 9.0.58 - Undertow 2.2.15 The additions comparing to initial release of Pax Web 8 are: - Web-VirtualHosts and Web-Connectors headers are handled correctly in all runtimes (in Pax Web 7 only Jetty handled them) - for Jetty, full tracking of org.eclipse.jetty.server.Handler and org.eclipse.jetty.server.HttpConfiguration.Customizer OSGi services. - pax-web-undertow no longer uses JAXB to parse XML configuration - "skipped JARs" property (as in Tomcat) is handled, so it's possible to configure which WEB-INF/lib/*.jar (and reachable bundles) are scanned for TLDs, web-fragment.xmls and annotated web elements - Karaf commands are now provided by Pax Web itself providing much more information - see my blog post about it <https://ggrzybek.blogspot.com/2021/11/pax-web-8-whiteboard-services-and-karaf.html> [2] - EventAdmin notifications are added - there are three "bundles bundles" (all-in-one) - pax-web-jetty-bundle, pax-web-tomcat-bundle and pax-web-undertow-bundle - @ServletSecurity, @RunAs, @DeclareRoles annotations are now correctly handled Full changelog can be found here[1]. kind regards Grzegorz Grzybek === [1]: https://github.com/ops4j/org.ops4j.pax.web/milestone/201?closed=1 [2]: https://ggrzybek.blogspot.com/2021/11/pax-web-8-whiteboard-services-and-karaf.html
Re: [PROPOSAL] Karaf 5
Hello Great to hear about Karaf5 progress. Do I understand correctly that you think about `K5` branch in apache/karaf repo? If there's no common history, why simply not https://github.com/apache/karaf5 ? regards Grzegorz Grzybek pon., 7 lut 2022 o 08:25 Francois Papon napisał(a): > Of course ;) > > On 07/02/2022 08:22, JB Onofré wrote: > > Let’s wait for others feedback on the mailing list. > > > >> Le 7 févr. 2022 à 08:08, Francois Papon > a écrit : > >> > >> I can manage the creation of the branch and move the code source. > >> > >> regards, > >> > >> François > >> > >>> On 07/02/2022 08:05, Francois Papon wrote: > >>> +1, we can use a dedicated branch :) > >>> > >>> regards, > >>> > >>> Francois > >>> > >>>> On 07/02/2022 08:02, Jean-Baptiste Onofre wrote: > >>>> Hi, > >>>> > >>>> It sounds good to me. > >>>> > >>>> The K5 repo is currently on my GitHub: > >>>> > >>>> https://github.com/jbonofre/karaf5 > >>>> > >>>> I propose: > >>>> > >>>> 1. To keep main for karaf-4.4.x for now > >>>> 2. Fix K4 like assembly on K5 (just have to push some new services) > >>>> 3. Push Karaf 5 on K5 branch > >>>> 4. Improve documentation on K5 branch to show what’s a service, and > so, allow anyone to contribute service/distribution > >>>> > >>>> ETA: end of this week if no objection. > >>>> > >>>> Regards > >>>> JB > >>>> > >>>> > >>>>> Le 7 févr. 2022 à 07:56, Francois Papon < > francois.pa...@openobject.fr> a écrit : > >>>>> > >>>>> Hi, > >>>>> > >>>>> As we have some users that asking questions about Karaf 5 the next > Karaf generation, I think it would be nice to move the current repo to > master. > >>>>> > >>>>> It could be a good booster if we want to move forward on this for a > first RC. > >>>>> > >>>>> Thoughts? > >>>>> > >>>>> Regards, > >>>>> > >>>>> François > >>>>> >
Re: [PROPOSAL] Apache Karaf 4.4.0 release
Hello Pax Web 8.0.1 is almost ready (20 issues closed[1]) and I wanted to fix one more thing - "Unify handling of TRACE + OPTIONS methods across runtimes"[2], but this can wait. You can check pax-web's todo.txt[3]. The biggest addition to 8.0.1 is a set of Karaf commands I wrote a blog about[4], where you can see some nice additions to Karaf web commands - and also I wanted (at least to check) to move the commands from Karaf (as they rely on Pax Web SPI anyway) to Pax Web itself - I hope with good result. I'd definitely like to include Pax Web 8.0.1 starting with first Karaf 4.4.0 release - what do you think? I was super busy (still am) with log4j CVEs, that's why Pax Web 8.0.1 is not yet ready ;( kind regards Grzegorz Grzybek === [1]: https://github.com/ops4j/org.ops4j.pax.web/milestone/201?closed=1 [2]: https://github.com/ops4j/org.ops4j.pax.web/issues/1664 [3]: https://github.com/ops4j/org.ops4j.pax.web/blob/main/todo.txt [4]: https://ggrzybek.blogspot.com/2021/11/pax-web-8-whiteboard-services-and-karaf.html czw., 3 lut 2022 o 17:24 Jean-Baptiste Onofré napisał(a): > Hi guys, > > I would like to release Apache Karaf 4.4.0 (currently main branch). > > I'm doing a pass on Jira right now. I would like to submit this release > to vote probably during the weekend. > > No objection ? > > Regards > JB >
Pax Logging and recent Log4j1 CVEs (and one note about JMSAppender in Logj42)
Hello Let me describe the idea for 3 recent and 3 older Log41 CVEs: - CVE-2022-23302:Deserialization of untrusted data in JMSSink (org.apache.log4j.net.JMSSink#main()) - CVE-2022-23305: SQL injection in JDBC Appender - CVE-2022-23307: A deserialization flaw in the Chainsaw component - CVE-2021-4104: JMSAppender in Log4j 1.2 is vulnerable to deserialization of untrusted data when the attacker has write access to the Log4j configuration - CVE-2020-9488: Improper validation of certificate with host mismatch in Apache Log4j SMTP appender - CVE-2019-17571: Included in Log4j 1.2 is a SocketServer class that is vulnerable to deserialization of untrusted data Let me categorize these: - Chainsaw and JMSSink ones are kind of "external" and are not used in anyway at runtime. To use them, it'd be required to create a pax-logging-service OSGi fragment - JMSAppender, SocketAppender, SMTPAppender (if configured of course) require attacker to have write access to configuration file (config admin) - JDBCAppender (if configured of course) is indeed prone to SQL Injection https://reload4j.qos.ch/ is a fork created by Ceki Gulcu (original author of Log4j1 and Logback) where he wants to tackle all these problems and partially it's ok. The problem is with his approach to: - JDBCAppender - he's removed it - JMSAppender - he allowed JNDI name to be looked up only if the name is without schema part or has "java:" schema (JavaEE / JNDI spec) - this effectively prevents configuration like the one from https://activemq.apache.org/how-do-i-use-log4j-jms-appender-with-activemq if the ConnectionFactory is stored in LDAP (same for Artemis) When checking JMSAppender in reload4j, I checked how it's "fixed" in Log4j2 - and also there we can only use schema-less or "java:" schema topic names, so JMSConnectionFactory can only be configured when manually and locally configuring the JNDI binding for ActiveMQ. Now about mitigation - I had to take security scanners into account - these scanners usually don't bother if you (especially in OSGi environment) use the classes from available jars (like from KARAF_HOME/system repo) or not - these just mark your installation as vulnerable. So here's my plan: - users of Pax Logging 1.11.x will get two options: - new 1.11.x release without Chainsaw, JMSSink and with Socket/SMTPAppender backports from reload4j in pax-logging-service bundle - new 1.12.0 release based completely on 1.11.x, but simply without pax-logging-service - you'll have option to use Log4j2 or Logback implementations *ONLY* - users of Pax Logging 2.0.x will get two options: - new 2.0.x release without Chainsaw, JMSSink and with Socket/SMTPAppender backports from reload4j in pax-logging-log4j1 bundle - new 2.1.0 release based completely on 2.0.x, but simply without pax-logging-log4j1 - users of Pax Logging 1.10.x will get one option: - new 1.10.x release without Chainsaw, JMSSink and with Socket/SMTPAppender backports from reload4j - without ANY changes to JMSAppender I also want to suggest JDBCAppender fix different than its removal and send it to https://github.com/qos-ch/reload4j What do you think? kind regards Grzegorz Grzybek
Re: [VOTE] Apache Karaf runtime 4.3.6 release
+1 (binding) regards Grzegorz Grzybek wt., 11 sty 2022 o 12:17 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 mar. 11 janv. 2022 à 12:06, Roedl Lukas a > écrit : > > > +1 (non-binding) > > > > regards, > > Lukas > > > > -Ursprüngliche Nachricht- > > Von: Jean-Baptiste Onofre > > Gesendet: Montag, 10. Januar 2022 21:09 > > An: dev@karaf.apache.org > > Betreff: [VOTE] Apache Karaf runtime 4.3.6 release > > > > Hi everyone, > > > > I submit Apache Karaf runtime 4.3.6 to your vote. > > > > This release includes: > > - upgrade to Pax Logging 2.0.14 with log4j 2.17.1 (fixing CVE-2021-44832) > > - prepare support for JDK 18 > > - fix issue on Apache Felix FileInstall 3.7.4 fixing deployment issue > > - and much more! > > > > Please take a look on Release Notes for details ! > > > > Release Notes: > > > > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12351123 > > > > Staging Maven Repository: > > https://repository.apache.org/content/repositories/orgapachekaraf-1170/ > > > > Staging Dist Repository: > > https://dist.apache.org/repos/dist/dev/karaf/4.3.6/ > > > > Git tag: > > karaf-4.3.6 > > > > Please vote to approve this release: > > > > [ ] +1 Approve the release > > [ ] -1 Don't approve the release (please provide specific comments) > > > > This vote will be open for at least 72 hours. > > > > Regards > > JB > > >
Re: [VOTE] Apache Karaf runtime 4.2.15 release
Hello I saw the 4.2.15 tag even before your email and I've already checked it with Fuse. +1 (binding) regards Grzegorz Grzybek wt., 11 sty 2022 o 09:59 Jean-Baptiste Onofré napisał(a): > Hi all, > > I submit Apache Karaf 4.2.15 to your vote. > > This version includes: > - upgrade to Pax Logging 1.11.13 upgrading to log4j 2.17.1 (fixing > CVE-2021-44832) > - upgrade to Apache Felix FileInstall 3.7.4 fixing deployment issue > - and other improvements/fixes! > > Please take a look on Release Notes for details. > > Release Notes: > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12351124 > > Staging Maven Repository: > https://repository.apache.org/content/repositories/orgapachekaraf-1171/ > > Staging Dist Repository: > https://dist.apache.org/repos/dist/dev/karaf/4.2.15/ > > Git tag: > karaf-4.2.15 > > > 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 Logging 2.0.14, 1.11.13 and 1.10.9 released
Hello Pax Logging 2.0.14, 1.11.13 and 1.10.9 have been released with two upgrades: - Log4j2 2.17.1 - Logback 1.2.10 These are the latest versions of the dependencies as of December 30th 2021. Additionally, 2.0.14 and 1.11.13 contain new configuration property: "org.ops4j.pax.logging.syncJULFormatter" (defaults to "true") which controls the usage of `java.util.logging.SimpleFormatter` inside Pax Logging's JUL Handler. By default, there's a single formatter with synchronization. When this property is set to "false", new instance is created for each event being handled - this is special system/context property to be used in Payara server where some deadlocks were observed. The changelogs are: - 2.0.14: https://github.com/ops4j/org.ops4j.pax.logging/milestone/78?closed=1 - 1.11.13: https://github.com/ops4j/org.ops4j.pax.logging/milestone/79?closed=1 - 1.10.9: https://github.com/ops4j/org.ops4j.pax.logging/milestone/81?closed=1 kind regards Grzegorz Grzybek
Re: [VOTE] Apache Karaf runtime 4.3.5 release
+1 regards Grzegorz Grzybek pon., 20 gru 2021 o 08:19 Romain Manni-Bucau napisał(a): > +1 > > Le dim. 19 déc. 2021 à 22:34, Jean-Baptiste Onofré a > écrit : > > > Hi everyone, > > > > I submit Apache Karaf runtime 4.3.5 to your vote. > > This release includes Pax Logging 2.0.13 update: > > - with logback 1.2.9 upgrade, fixing CVE-2021-42550 > > - with log4j 2.17.0 upgrade, fixing CVE-2021-45105 > > > > Please take a look on Release Notes for details ! > > > > Release Notes: > > > > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12350856 > > > > Staging Maven Repository: > > https://repository.apache.org/content/repositories/orgapachekaraf-1167/ > > > > Staging Dist Repository: > > https://dist.apache.org/repos/dist/dev/karaf/4.3.5/ > > > > Git tag: > > karaf-4.3.5 > > > > Please vote to approve this release: > > > > [ ] +1 Approve the release > > [ ] -1 Don't approve the release (please provide specific comments) > > > > This vote will be open for at least 72 hours. > > > > Regards > > JB > > > > >
Re: Logback CVE-2021-42550
Hello Done - I've released Pax Logging 1.11.12 and 2.0.13 with the Logback update. Thanks Matt for the initial PR - I've checked that no other changes are required. regards Grzegorz Grzybek sob., 18 gru 2021 o 05:42 Jean-Baptiste Onofre napisał(a): > Thanks, > > However, the PR is not correct. > > We (Greg and I) will create a right PR and move forward on Pax Logging > release. > > However, just a note for the users: this issue is largely less critical > than log4j one. > Anyway, I will cut maintenance release quickly. > > Regards > JB > > > Le 17 déc. 2021 à 16:35, Matt Pavlovich a écrit : > > > > PR created for pax-logging against main: > https://github.com/ops4j/org.ops4j.pax.logging/pull/425 < > https://github.com/ops4j/org.ops4j.pax.logging/pull/425> > > > > > >> On Dec 17, 2021, at 9:23 AM, Matt Pavlovich wrote: > >> > >> I summarized notes on the Logback CVE-2021-42550 . While significantly > less critical, we probably need to consider another round of releases to > address and bring in logback 1.2.9. > >> > >> notes here: https://issues.apache.org/jira/browse/KARAF-7299 < > https://issues.apache.org/jira/browse/KARAF-7299> > >> > >> Thoughts? > > > >
[ANN] Pax Logging 2.0.13 and 1.11.12 released
Hello Pax Logging 2.0.13 and 1.11.12 have been released with two upgrades: - Log4j2 2.17.0 - Logback 1.2.9 These are the latest versions of the dependencies as of December 18th 2021. The changelogs are: - 2.0.13: https://github.com/ops4j/org.ops4j.pax.logging/milestone/75?closed=1 - 1.11.12: https://github.com/ops4j/org.ops4j.pax.logging/milestone/76?closed=1 kind regards Grzegorz Grzybek
[ANN] Pax Logging 1.10.8 released
Hello Pax Logging 1.10.8 has been released with Log4j2 upgrade to version 2.12.2. This is the version with CVE-2021-44228 fixed for people that still use JDK 7. Normally, Pax Logging 1.10.x is no longer maintaned (only 1.11.x and 2.0.x branches are for now), but for this CVE we've made an exception ;) The changelog is available at GitHub: https://github.com/ops4j/org.ops4j.pax.logging/milestone/77?closed=1 kind regards Grzegorz Grzybek
Re: [VOTE] Apache Karaf runtime 4.3.4 release (take #3)
+1 (binding) regards Grzegorz Grzybek śr., 15 gru 2021 o 09:44 Achim Nierbeck napisał(a): > +1 (binding) > > regards, Achim > > > Am Mi., 15. Dez. 2021 um 08:34 Uhr schrieb Romain Manni-Bucau < > rmannibu...@gmail.com>: > > > +1 > > > > Romain Manni-Bucau > > @rmannibucau <https://twitter.com/rmannibucau> | Blog > > <https://rmannibucau.metawerx.net/> | Old Blog > > <http://rmannibucau.wordpress.com> | Github < > > https://github.com/rmannibucau> | > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book > > < > > > https://www.packtpub.com/application-development/java-ee-8-high-performance > > > > > > > > > Le mer. 15 déc. 2021 à 08:21, Roedl Lukas a > écrit > > : > > > > > +1 (non-binding) > > > > > > regards, > > > Lukas > > > > > > -Ursprüngliche Nachricht- > > > Von: JB Onofré > > > Gesendet: Mittwoch, 15. Dezember 2021 05:44 > > > An: dev@karaf.apache.org > > > Betreff: [VOTE] Apache Karaf runtime 4.3.4 release (take #3) > > > > > > Hi everyone, > > > > > > I submit Apache Karaf runtime 4.3.4 to your vote (take #3). > > > > > > This release includes dependency upgrades, fixes, and improvements, > > > especially: > > > > > > - upgrade to Pax Logging 2.0.12, upgrading to log4j2 2.0.15, fixing > > > important security issue (CVE-2021-44228) and fixing JNDI issue > > > - align dependencies versions between Karaf and Pax * > > > - fix missing system export packages > > > - fix on Karaf features json support > > > - fix features autoRefresh configuration handling > > > - fix on sshd session handling > > > - update to sshd 2.8.0 > > > - lot of pax * updates > > > - and much more ! > > > > > > Please take a look on Release Notes for details ! > > > > > > Release Notes: > > > > > > > > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12350547 > > > > > > Staging Maven Repository: > > > > https://repository.apache.org/content/repositories/orgapachekaraf-1165/ > > > > > > Staging Dist Repository: > > > https://dist.apache.org/repos/dist/dev/karaf/4.3.4/ > > > > > > Git tag: > > > karaf-4.3.4 > > > > > > Please vote to approve this release: > > > > > > [ ] +1 Approve the release > > > [ ] -1 Don't approve the release (please provide specific comments) > > > > > > This vote will be open for at least 72 hours. > > > > > > Regards > > > JB > > > > > > > > > > > -- > > 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: [VOTE] Apache Karaf runtime 4.3.4 release (take #3)
Hello With https://github.com/ops4j/org.ops4j.pax.logging/issues/416, Pax Logging 2.0.12 and 1.11.11 already use Log4j2 2.16.0. regards Grzegorz Grzybek śr., 15 gru 2021 o 07:36 Serge Huber napisał(a): > Given that log2j 2.15.0 has been found to have a Denial of service should > we re-release with 2.16.0 ? > > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45046 > > Note that previous mitigations involving configuration such as to set the > system property `log4j2.noFormatMsgLookup` to `true` do NOT mitigate this > specific vulnerability. Log4j 2.16.0 fixes this issue by removing support > for message lookup patterns and disabling JNDI functionality by default. > This issue can be mitigated in prior releases (<2.16.0) by removing the > JndiLookup class from the classpath (example: zip -q -d log4j-core-*.jar > org/apache/logging/log4j/core/lookup/JndiLookup.class). > > Regards, > Serge... > > Serge Huber > CTO & Co-Founder > T +41 22 361 3424 > 9 route des Jeunes | 1227 Acacias | Switzerland > jahia.com <http://www.jahia.com/> > SKYPE | LINKEDIN <https://www.linkedin.com/in/sergehuber> | TWITTER > <https://twitter.com/sergehuber> | VCARD > <http://www.jahia.com/vcard/HuberSerge.vcf> > > > > JOIN OUR COMMUNITY <http://www.jahia.com/> to evaluate, get trained and > to discover why Jahia is a leading User Experience Platform (UXP) for > Digital Transformation. > > > On Wed, Dec 15, 2021 at 7:28 AM Francois Papon < > francois.pa...@openobject.fr> > wrote: > > > +1 (binding) > > > > Thanks JB! > > > > regards, > > > > Francois > > > > On 15/12/2021 05:43, JB Onofré wrote: > > > Hi everyone, > > > > > > I submit Apache Karaf runtime 4.3.4 to your vote (take #3). > > > > > > This release includes dependency upgrades, fixes, and improvements, > > especially: > > > > > > - upgrade to Pax Logging 2.0.12, upgrading to log4j2 2.0.15, fixing > > important security issue (CVE-2021-44228) and fixing JNDI issue > > > - align dependencies versions between Karaf and Pax * > > > - fix missing system export packages > > > - fix on Karaf features json support > > > - fix features autoRefresh configuration handling > > > - fix on sshd session handling > > > - update to sshd 2.8.0 > > > - lot of pax * updates > > > - and much more ! > > > > > > Please take a look on Release Notes for details ! > > > > > > Release Notes: > > > > > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12350547 > > > > > > Staging Maven Repository: > > > > https://repository.apache.org/content/repositories/orgapachekaraf-1165/ > > > > > > Staging Dist Repository: > > > https://dist.apache.org/repos/dist/dev/karaf/4.3.4/ > > > > > > Git tag: > > > karaf-4.3.4 > > > > > > Please vote to approve this release: > > > > > > [ ] +1 Approve the release > > > [ ] -1 Don't approve the release (please provide specific comments) > > > > > > This vote will be open for at least 72 hours. > > > > > > Regards > > > JB > > > > > >
[ANN] Pax Logging 2.0.12 and 1.11.11 released
Hello Pax Logging 2.0.12 and 1.11.11 have been released with Log4j2 upgrade. The Log4j2 version used is 2.16.0, which is a follow-up release related to recent world-shaking CVE-2021-44228. Version 2.16.0 polishes some corner cases related to message interpolation and is NOT a required upgrade for this CVE. The changelog is available at GitHub: https://github.com/ops4j/org.ops4j.pax.logging/milestone/74?closed=1 kind regards Grzegorz Grzybek
Re: [VOTE] Apache Karaf runtime 4.3.4 release (take #2)
+1 regards Grzegorz Grzybek pon., 13 gru 2021 o 17:17 Freeman Fang napisał(a): > +1(binding) > > Thanks! > Freeman > > On Mon, Dec 13, 2021 at 10:24 AM Jean-Baptiste Onofré > wrote: > > > Hi everyone, > > > > I submit Apache Karaf runtime 4.3.4 to your vote (take #2). > > > > This release includes dependency upgrades, fixes, and improvements, > > especially: > > > > - upgrade to Pax Logging 2.0.11, upgrading to log4j2 2.0.15, fixing > > important security issue (CVE-2021-44228) > > - align dependencies versions between Karaf and Pax * > > - fix missing system export packages > > - fix on Karaf features json support > > - fix features autoRefresh configuration handling > > - fix on sshd session handling > > - update to sshd 2.8.0 > > - lot of pax * updates > > - and much more ! > > > > Please take a look on Release Notes for details ! > > > > Release Notes: > > > > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12350547 > > > > Staging Maven Repository: > > https://repository.apache.org/content/repositories/orgapachekaraf-1164/ > > > > Staging Dist Repository: > > https://dist.apache.org/repos/dist/dev/karaf/4.3.4/ > > > > Git tag: > > karaf-4.3.4 > > > > Please vote to approve this release: > > > > [ ] +1 Approve the release > > [ ] -1 Don't approve the release (please provide specific comments) > > > > This vote will be open for at least 72 hours. > > > > Regards > > JB > > >
Re: [ANN][CVE-2021-44228] Pax Logging 2.0.11 and 1.11.10 released
@Steven Huypens
In order to fix in current installation, you have to change the version in
etc/startup.properties and at runtime, do `update
mvn:org.ops4j.pax.logging/pax-logging-log4j2/2.0.11`
regards
Grzegorz Grzybek
pon., 13 gru 2021 o 13:18 Jean-Baptiste Onofré napisał(a):
> Hi,
>
> you can upgrade to Karaf 4.3.4 (vote will start in a hour or so).
>
> It will include Pax Logging 2.0.11.
>
> If you can't wait, then, you have to create your own distro (mimic what
> we do at Karaf).
>
> Regards
> JB
>
> On 13/12/2021 13:10, Steven Huypens wrote:
> > Hi Grzegorz,
> >
> > Thanks, that's clear now.
> >
> > Another question: what is the simplest way of upgrading pax logging to
> > 2.0.11 in my current Karaf 4.3.2 distro ? Should I blacklist the 2.0.9
> > dependencies and add the 2.0.11 ones to my features.xml, or is there a
> > better option ?
> >
> > Kind regards,
> > Steven
> >
> > On Mon, Dec 13, 2021 at 11:57 AM Grzegorz Grzybek
> > wrote:
> >
> >> Hello
> >>
> >> The multiple export trick/hack/improvement/convenience is to make it
> easier
> >> to upgrade pax logging itself without affecting the OSGi users.
> >> Pax Logging *has to* export Log4j2 packages at version of the ONLY
> Log4j2
> >> library it uses (private-packages + re-exports), but it also declares
> that
> >> the exports match earlier versions.
> >> So if your application has:
> >>
> >> Import-Package: org.apache.logging.log4j; version="[2.13,2.14)"
> >>
> >> Just because it was built by maven-bundle-plugin that for some reasons
> used
> >> more strict version range policy, the multiple versions exported by Pax
> >> Logging bundles won't break your application.
> >> It's a way of telling - if you're using our API at given version, we
> >> provide compatible interfaces. But the underlying implementation is (for
> >> pax logging 2.0.11) is log4j2 2.15.0 (so with the CVE fix).
> >>
> >> regards
> >> Grzegorz Grzybek
> >>
> >> pon., 13 gru 2021 o 11:42 Steven Huypens
> >> napisał(a):
> >>
> >>> Hi all,
> >>>
> >>> We are using pax logging 2.0.9, but I can see it exports log4j2
> packages
> >>> for different versions: 2.9.1, 2.13.3 & 2.14.1
> >>>
> >>> Since one of those versions is not higher than 2.10, it's not clear to
> me
> >>> if the system property log4j.formatMsgNoLookup will fix the issue for
> our
> >>> application. Anyone knows ?
> >>>
> >>> Kind regards,
> >>> Steven
> >>>
> >>> On Fri, Dec 10, 2021 at 11:26 PM Bernd Eckenfels <
> e...@zusammenkunft.net
> >>>
> >>> wrote:
> >>>
> >>>> I am currently working on a description for a work around (specifying
> >> the
> >>>> system property) but I can’t get it to work.
> >>>>
> >>>> It still expands ${java:version}. I checked that it shows with
> >>>> “system:property log4j.formatMsgNoLookup” true and there seems to be
> no
> >>>> %m{lookup} setting.
> >>>>
> >>>> I am using pax logging 2.0.8 which is containing log4j 2.14.1 (I.e a
> >>>> version newer than 2.10).
> >>>>
> >>>> Any idea?
> >>>>
> >>>> Is it possible that the shaded pax-logging-log4j does not honor the
> >>> system
> >>>> property of log4j?
> >>>>
> >>>>
> >>>> --
> >>>> https://bernd.eckenfels.net
> >>>>
> >>>> From: Grzegorz Grzybek
> >>>> Sent: Friday, December 10, 2021 1:43:00 PM
> >>>> To: dev@karaf.apache.org
> >>>> Subject: Re: [ANN][CVE-2021-44228] Pax Logging 2.0.11 and 1.11.10
> >>> released
> >>>>
> >>>> Hello
> >>>>
> >>>> Actually, https://issues.apache.org/jira/browse/LOG4J2-3198 describes
> >> it
> >>>> in
> >>>> details.
> >>>>
> >>>> I was a bit surprised too - I knew about e.g., `${java:version}` if
> you
> >>>> used it in pattern layout configuration - I didn't expect Log4j2 to
> >>>> interpolate the messages passed to log() methods as well!
> >>>>
> >>>> But you can try (in Karaf):
> >>>>
> >>>> karaf@r
Re: [ANN][CVE-2021-44228] Pax Logging 2.0.11 and 1.11.10 released
Hello
The multiple export trick/hack/improvement/convenience is to make it easier
to upgrade pax logging itself without affecting the OSGi users.
Pax Logging *has to* export Log4j2 packages at version of the ONLY Log4j2
library it uses (private-packages + re-exports), but it also declares that
the exports match earlier versions.
So if your application has:
Import-Package: org.apache.logging.log4j; version="[2.13,2.14)"
Just because it was built by maven-bundle-plugin that for some reasons used
more strict version range policy, the multiple versions exported by Pax
Logging bundles won't break your application.
It's a way of telling - if you're using our API at given version, we
provide compatible interfaces. But the underlying implementation is (for
pax logging 2.0.11) is log4j2 2.15.0 (so with the CVE fix).
regards
Grzegorz Grzybek
pon., 13 gru 2021 o 11:42 Steven Huypens
napisał(a):
> Hi all,
>
> We are using pax logging 2.0.9, but I can see it exports log4j2 packages
> for different versions: 2.9.1, 2.13.3 & 2.14.1
>
> Since one of those versions is not higher than 2.10, it's not clear to me
> if the system property log4j.formatMsgNoLookup will fix the issue for our
> application. Anyone knows ?
>
> Kind regards,
> Steven
>
> On Fri, Dec 10, 2021 at 11:26 PM Bernd Eckenfels
> wrote:
>
> > I am currently working on a description for a work around (specifying the
> > system property) but I can’t get it to work.
> >
> > It still expands ${java:version}. I checked that it shows with
> > “system:property log4j.formatMsgNoLookup” true and there seems to be no
> > %m{lookup} setting.
> >
> > I am using pax logging 2.0.8 which is containing log4j 2.14.1 (I.e a
> > version newer than 2.10).
> >
> > Any idea?
> >
> > Is it possible that the shaded pax-logging-log4j does not honor the
> system
> > property of log4j?
> >
> >
> > --
> > https://bernd.eckenfels.net
> >
> > From: Grzegorz Grzybek
> > Sent: Friday, December 10, 2021 1:43:00 PM
> > To: dev@karaf.apache.org
> > Subject: Re: [ANN][CVE-2021-44228] Pax Logging 2.0.11 and 1.11.10
> released
> >
> > Hello
> >
> > Actually, https://issues.apache.org/jira/browse/LOG4J2-3198 describes it
> > in
> > details.
> >
> > I was a bit surprised too - I knew about e.g., `${java:version}` if you
> > used it in pattern layout configuration - I didn't expect Log4j2 to
> > interpolate the messages passed to log() methods as well!
> >
> > But you can try (in Karaf):
> >
> > karaf@root()> log:log 'xxx ${java:version} xxx'
> >
> > And you'll see (in the logs):
> >
> > 2021-12-10 13:39:25,243 INFO {pipe-log:log 'xxx ${java:version} xxx'}
> > [org.apache.karaf.log.command.LogEntry.execute()] (LogEntry.java:57) :
> xxx
> > Java version 1.8.0_312 xxx
> >
> > so a message has been interpolated.
> >
> > What's worse, I could add an entry to my OpenLDAP with:
> >
> > javaClassName: java.lang.String
> > javaSerializedData:: rO0ABXQAF2h0dHA6Ly9sb2NhbGhvc3QvYXR0YWNr
> >
> > And then:
> >
> > karaf@root()> log:log '${jndi:ldap://
> 10.39.192.99/cn=boom,dc=k8s,dc=forest
> > }'
> >
> > gave me this in logs:
> >
> > 2021-12-10 13:40:38,181 INFO {pipe-log:log '${jndi:ldap://
> > 10.39.192.99/cn=boom,dc=k8s,dc=forest}
> > <http://10.39.192.99/cn=boom,dc=k8s,dc=forest%7D>'}
> > [org.apache.karaf.log.command.LogEntry.execute()] (LogEntry.java:57) :
> > http://localhost/attack
> >
> > "http://localhost/attack; is the deserialized value from
> > "rO0ABXQAF2h0dHA6Ly9sb2NhbGhvc3QvYXR0YWNr" LDAP attribute.
> >
> > While you can't use "javaCodeBase" LDAP attribute to point to malicius
> URL
> > code base (thanks to "com.sun.jndi.ldap.object.trustURLCodebase" system
> > property that defaults to "false" since 2009), you still have a remote
> > request being performed when logging messages with ${jndi:ldap://
> > example.com
> > }.
> >
> > regards
> > Grzegorz Grzybek
> >
> > pt., 10 gru 2021 o 13:28 Bernd Eckenfels
> > napisał(a):
> >
> > > Hello Grzegorz,
> > >
> > > Thanks a lot for the super quick reaction.
> > >
> > > I was rather confused to see that log messages can trigger a JNDI
> lookup
> > > anyway. Do you think there should be hardened something here?
> > >
> > > Do you know if that is triggered by malicious log config or by
> malicious
> > > log messages an
Re: [ANN][CVE-2021-44228] Pax Logging 2.0.11 and 1.11.10 released
Thanks for sharing the information Bernd!
regards
Grzegorz Grzybek
sob., 11 gru 2021 o 03:25 Bernd Eckenfels
napisał(a):
> Hello,
>
> Found no problem was using the wrong property prefix. It works now to turn
> it off.
>
> I also noticed that JNDI lookups will fail on our karaf distribution
> because the JNDIManager has some DelegateContextLookup (OSGiDelegating
> something) which fails the lookup. It’s too late to find out why but that
> means at least the POC vectors don’t harm me.
>
> --
> https://bernd.eckenfels.net
>
> From: Bernd Eckenfels
> Sent: Friday, December 10, 2021 11:26:19 PM
> To: dev@karaf.apache.org
> Subject: Re: [ANN][CVE-2021-44228] Pax Logging 2.0.11 and 1.11.10 released
>
> I am currently working on a description for a work around (specifying the
> system property) but I can’t get it to work.
>
> It still expands ${java:version}. I checked that it shows with
> “system:property log4j.formatMsgNoLookup” true and there seems to be no
> %m{lookup} setting.
>
> I am using pax logging 2.0.8 which is containing log4j 2.14.1 (I.e a
> version newer than 2.10).
>
> Any idea?
>
> Is it possible that the shaded pax-logging-log4j does not honor the system
> property of log4j?
>
>
> --
> https://bernd.eckenfels.net
>
> From: Grzegorz Grzybek
> Sent: Friday, December 10, 2021 1:43:00 PM
> To: dev@karaf.apache.org
> Subject: Re: [ANN][CVE-2021-44228] Pax Logging 2.0.11 and 1.11.10 released
>
> Hello
>
> Actually, https://issues.apache.org/jira/browse/LOG4J2-3198 describes it
> in
> details.
>
> I was a bit surprised too - I knew about e.g., `${java:version}` if you
> used it in pattern layout configuration - I didn't expect Log4j2 to
> interpolate the messages passed to log() methods as well!
>
> But you can try (in Karaf):
>
> karaf@root()> log:log 'xxx ${java:version} xxx'
>
> And you'll see (in the logs):
>
> 2021-12-10 13:39:25,243 INFO {pipe-log:log 'xxx ${java:version} xxx'}
> [org.apache.karaf.log.command.LogEntry.execute()] (LogEntry.java:57) : xxx
> Java version 1.8.0_312 xxx
>
> so a message has been interpolated.
>
> What's worse, I could add an entry to my OpenLDAP with:
>
> javaClassName: java.lang.String
> javaSerializedData:: rO0ABXQAF2h0dHA6Ly9sb2NhbGhvc3QvYXR0YWNr
>
> And then:
>
> karaf@root()> log:log '${jndi:ldap://10.39.192.99/cn=boom,dc=k8s,dc=forest
> }'
>
> gave me this in logs:
>
> 2021-12-10 13:40:38,181 INFO {pipe-log:log '${jndi:ldap://
> 10.39.192.99/cn=boom,dc=k8s,dc=forest}
> <http://10.39.192.99/cn=boom,dc=k8s,dc=forest%7D>'}
> [org.apache.karaf.log.command.LogEntry.execute()] (LogEntry.java:57) :
> http://localhost/attack
>
> "http://localhost/attack; is the deserialized value from
> "rO0ABXQAF2h0dHA6Ly9sb2NhbGhvc3QvYXR0YWNr" LDAP attribute.
>
> While you can't use "javaCodeBase" LDAP attribute to point to malicius URL
> code base (thanks to "com.sun.jndi.ldap.object.trustURLCodebase" system
> property that defaults to "false" since 2009), you still have a remote
> request being performed when logging messages with ${jndi:ldap://
> example.com
> }.
>
> regards
> Grzegorz Grzybek
>
> pt., 10 gru 2021 o 13:28 Bernd Eckenfels
> napisał(a):
>
> > Hello Grzegorz,
> >
> > Thanks a lot for the super quick reaction.
> >
> > I was rather confused to see that log messages can trigger a JNDI lookup
> > anyway. Do you think there should be hardened something here?
> >
> > Do you know if that is triggered by malicious log config or by malicious
> > log messages and does it only affect systems where the JMSAppender is
> > actually used?
> >
> > Gruss
> > Bernd
> >
> >
> > --
> > http://bernd.eckenfels.net
> >
> > Von: Grzegorz Grzybek
> > Gesendet: Friday, December 10, 2021 12:20:02 PM
> > An: ops4j-announcem...@googlegroups.com <
> > ops4j-announcem...@googlegroups.com>; Karaf Dev ;
> > d...@felix.apache.org
> > Betreff: [ANN][CVE-2021-44228] Pax Logging 2.0.11 and 1.11.10 released
> >
> > Hello
> >
> > Pax Logging 2.0.11 and 1.11.10 have been released with CVE-2021-44228
> fix.
> >
> > *Log4j2 has been updated to version 2.15.0.*
> >
> > The changelog is available at GitHub:
> > https://github.com/ops4j/org.ops4j.pax.logging/milestone/72?closed=1
> >
> > kind regards
> > Grzegorz Grzybek
> >
>
Re: [ANN][CVE-2021-44228] Pax Logging 2.0.11 and 1.11.10 released
Hello
Actually, https://issues.apache.org/jira/browse/LOG4J2-3198 describes it in
details.
I was a bit surprised too - I knew about e.g., `${java:version}` if you
used it in pattern layout configuration - I didn't expect Log4j2 to
interpolate the messages passed to log() methods as well!
But you can try (in Karaf):
karaf@root()> log:log 'xxx ${java:version} xxx'
And you'll see (in the logs):
2021-12-10 13:39:25,243 INFO {pipe-log:log 'xxx ${java:version} xxx'}
[org.apache.karaf.log.command.LogEntry.execute()] (LogEntry.java:57) : xxx
Java version 1.8.0_312 xxx
so a message has been interpolated.
What's worse, I could add an entry to my OpenLDAP with:
javaClassName: java.lang.String
javaSerializedData:: rO0ABXQAF2h0dHA6Ly9sb2NhbGhvc3QvYXR0YWNr
And then:
karaf@root()> log:log '${jndi:ldap://10.39.192.99/cn=boom,dc=k8s,dc=forest}'
gave me this in logs:
2021-12-10 13:40:38,181 INFO {pipe-log:log '${jndi:ldap://
10.39.192.99/cn=boom,dc=k8s,dc=forest}'}
[org.apache.karaf.log.command.LogEntry.execute()] (LogEntry.java:57) :
http://localhost/attack
"http://localhost/attack; is the deserialized value from
"rO0ABXQAF2h0dHA6Ly9sb2NhbGhvc3QvYXR0YWNr" LDAP attribute.
While you can't use "javaCodeBase" LDAP attribute to point to malicius URL
code base (thanks to "com.sun.jndi.ldap.object.trustURLCodebase" system
property that defaults to "false" since 2009), you still have a remote
request being performed when logging messages with ${jndi:ldap://example.com
}.
regards
Grzegorz Grzybek
pt., 10 gru 2021 o 13:28 Bernd Eckenfels
napisał(a):
> Hello Grzegorz,
>
> Thanks a lot for the super quick reaction.
>
> I was rather confused to see that log messages can trigger a JNDI lookup
> anyway. Do you think there should be hardened something here?
>
> Do you know if that is triggered by malicious log config or by malicious
> log messages and does it only affect systems where the JMSAppender is
> actually used?
>
> Gruss
> Bernd
>
>
> --
> http://bernd.eckenfels.net
>
> Von: Grzegorz Grzybek
> Gesendet: Friday, December 10, 2021 12:20:02 PM
> An: ops4j-announcem...@googlegroups.com <
> ops4j-announcem...@googlegroups.com>; Karaf Dev ;
> d...@felix.apache.org
> Betreff: [ANN][CVE-2021-44228] Pax Logging 2.0.11 and 1.11.10 released
>
> Hello
>
> Pax Logging 2.0.11 and 1.11.10 have been released with CVE-2021-44228 fix.
>
> *Log4j2 has been updated to version 2.15.0.*
>
> The changelog is available at GitHub:
> https://github.com/ops4j/org.ops4j.pax.logging/milestone/72?closed=1
>
> kind regards
> Grzegorz Grzybek
>
[ANN][CVE-2021-44228] Pax Logging 2.0.11 and 1.11.10 released
Hello Pax Logging 2.0.11 and 1.11.10 have been released with CVE-2021-44228 fix. *Log4j2 has been updated to version 2.15.0.* The changelog is available at GitHub: https://github.com/ops4j/org.ops4j.pax.logging/milestone/72?closed=1 kind regards Grzegorz Grzybek
Re: [VOTE] Apache Karaf runtime 4.3.4 release
Hello +1 (binding) BTW - here’s how Karaf 4.3.4 works with Pax Web 8 (soon in Karaf 4.4): karaf@root()> install -s mvn:io.hawt/hawtio-osgi/2.14.1/war Bundle ID: 76 karaf@root()> web:wab-list Context Path │ Bundle ID │ Symbolic Name │ State│ Base URL ─┼───┼─┼──┼─ /hawtio │ 76│ io.hawt.hawtio-osgi │ Deployed │ http://127.0.0.1:8181/hawtio karaf@root()> web:context-list Bundle ID │ Symbolic Name │ Context Path │ Context Name │ Rank │ Service ID │ Type │ Scope │ Registration Properties ──┼───┼──┼──┼──┼┼┼─┼── 70│ org.ops4j.pax.web.pax-web-extender-whiteboard │ / │ default │ 0│ 0 │ Whiteboard │ static* │ osgi.http.whiteboard.context.name=default │ │ │ │ │││ │ osgi.http.whiteboard.context.path=/ 76│ io.hawt.hawtio-osgi │ /hawtio │ /hawtio │ MAX │ 0 │ WAB│ static* │ osgi.http.whiteboard.context.path=/hawtio *) This context is using ServletContextHelper/HttpContext without resolving an org.osgi.framework.ServiceReference. karaf@root()> web:servlet-list Bundle ID │ Name │ Class │ Context Path(s) │ URLs │ Type │ Context Filter ──┼───┼───┼─┼──┼──┼─── 76│ default │ org.ops4j.pax.web.service.jetty.internal.web.JettyResourceServlet │ /hawtio │ /│ WAB │ - 76│ jolokia-agent │ io.hawt.web.servlets.JolokiaConfiguredAgentServlet │ /hawtio │ /jolokia/* │ WAB │ - 76│ jolokia-proxy │ io.hawt.web.proxy.ProxyServlet │ /hawtio │ /proxy/* │ WAB │ - 76│ keycloak │ io.hawt.web.auth.keycloak.KeycloakServlet │ /hawtio │ /keycloak/* │ WAB │ - 76│ login │ io.hawt.web.auth.LoginServlet │ /hawtio │ /auth/login │ WAB │ - 76│ logout│ io.hawt.web.auth.LogoutServlet │ /hawtio │ /auth/logout │ WAB │ - 76│ plugin│ io.hawt.web.plugin.PluginServlet │ /hawtio │ /plugin/*│ WAB │ - 76│ user │ io.hawt.web.auth.keycloak.KeycloakUserServlet │ /hawtio │ /user/* │ WAB │ - regards Grzegorz Grzybek wt., 7 gru 2021 o 05:59 Jean-Baptiste Onofré napisał(a): > Hi everyone, > > I submit Apache Karaf runtime 4.3.4 to your vote. > > This release includes dependency upgrades, fixes, and improvements, > especially: > > - align dependencies versions between Karaf and Pax * > - fix missing system export packages > - fix on Karaf features json support > - fix features autoRefresh configuration handling > - fix on sshd session handling > - update to sshd 2.8.0 > - lot of pax * updates > - and much more ! > > Please take a look on Release Notes for details ! > > Release Notes: > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12350547 > > Staging Maven Repository: > https://repository.apache.org/content/repositories/orgapachekaraf-1162/ > > Staging Dist Repository: > https://dist.apache.org/repos/dist/dev/karaf/4.3.4/ > > Git tag: > karaf-4.3.4 > > Please vote to approve this release: > > [ ] +1 Approve the release > [ ] -1 Don't approve the release (please provide specific comments) > > This vote will be open for at least 72 hours. > > Regards > JB >
Re: Preparing Karaf runtime 4.3.4
Hi pon., 15 lis 2021 o 11:05 Jean-Baptiste Onofré napisał(a): > Hi Greg, > > No, it's not related to annotations: it's missing jaspi import in the > web bundle created on the fly by the war extender. > It looks like pax-url-war problem then... regards Grzegorz Grzybek > > I'm testing the fix right now and I will push a new Pax Web release. > > Regards > JB > > On 15/11/2021 07:02, Grzegorz Grzybek wrote: > > Hello > > > > niedz., 14 lis 2021 o 17:18 Jean-Baptiste Onofre > > napisał(a): > > > >> Hi guys, > >> > >> FYI, I just found an issue in Pax Web 7.3.21 (related to Jetty update, > in > >> the war extender). I’m fixing it now and I will cut a new Pax Web 7.3.x > >> release to update in Karaf. > >> > > > > Is it related to jetty 9.4.44 and annotations? Can I help? > > > > regards > > Grzegorz Grzybek > > > > > >> > >> I’m moving forward as quick as possible to submit Karaf 4.3.4 and > >> 4.4.0.RC1 to vote. > >> > >> Regards > >> JB > >> > >>> Le 12 nov. 2021 à 14:38, Jean-Baptiste Onofré a > écrit > >> : > >>> > >>> Hi Robert, > >>> > >>> From an user standpoint, you are right. > >>> > >>> I updated Karaf to use "individual" bundles. I think I sent a message > on > >> the mailing list about that. > >>> > >>> Regards > >>> JB > >>> > >>> On 12/11/2021 14:34, Robert Varga wrote: > >>>> On 12/11/2021 10:23, Paul Stanley wrote: > >>>>> Thanks JB. > >>>> Hello Paul, > >>>>> I would have though that OSGI R8 is backwards compatible with R7, as > I > >>>>> didn't see any breaking changes in the spec. > >>>> True, but the artifact packaging with R8 broken up to support JPMS -- > >> i.e. no osgi.cmpn anymore. That is a breaking change from build system > >> perspective. > >>>> Regards, > >>>> Robert > >> > >> > > >
Re: Preparing Karaf runtime 4.3.4
Hello niedz., 14 lis 2021 o 17:18 Jean-Baptiste Onofre napisał(a): > Hi guys, > > FYI, I just found an issue in Pax Web 7.3.21 (related to Jetty update, in > the war extender). I’m fixing it now and I will cut a new Pax Web 7.3.x > release to update in Karaf. > Is it related to jetty 9.4.44 and annotations? Can I help? regards Grzegorz Grzybek > > I’m moving forward as quick as possible to submit Karaf 4.3.4 and > 4.4.0.RC1 to vote. > > Regards > JB > > > Le 12 nov. 2021 à 14:38, Jean-Baptiste Onofré a écrit > : > > > > Hi Robert, > > > > From an user standpoint, you are right. > > > > I updated Karaf to use "individual" bundles. I think I sent a message on > the mailing list about that. > > > > Regards > > JB > > > > On 12/11/2021 14:34, Robert Varga wrote: > >> On 12/11/2021 10:23, Paul Stanley wrote: > >>> Thanks JB. > >> Hello Paul, > >>> I would have though that OSGI R8 is backwards compatible with R7, as I > >>> didn't see any breaking changes in the spec. > >> True, but the artifact packaging with R8 broken up to support JPMS -- > i.e. no osgi.cmpn anymore. That is a breaking change from build system > perspective. > >> Regards, > >> Robert > >
Re: Preparing Karaf runtime 4.3.4
pt., 12 lis 2021 o 09:15 Jean-Baptiste Onofré napisał(a): > Hi Greg, > > It's a RC1, so best effort. If we are not able to include Pax Web 8, we > will stay with 7.3 for RC1 and cut a RC2 with Pax Web 8. > > By the way, I'm about to release a new maven-bundle-plugin version, > including fixes that could be interested for any project using the plugin. > What are the changes? :) regards Grzegorz > > Regards > JB > > On 12/11/2021 08:51, Grzegorz Grzybek wrote: > > Hello > > > > Thanks JBO! > > > > I didn't yet add Pax Web 8 to 4.4.0-SNAPSHOT, but I'm going to do it > soon. > > > > regards > > Grzegorz Grzybek > > > > pt., 12 lis 2021 o 08:50 Jean-Baptiste Onofré > napisał(a): > > > >> Hi guys, > >> > >> I finally figured to move forward on release preparation. > >> > >> I will submit Karaf runtime 4.3.4 to vote soon (probably during the week > >> end). I will also work on new Decanter release for next week. > >> > >> Finally, I would like to propose a first Karaf runtime 4.4.0.RC1, just > >> to give a chance to everyone to test this new series before a GA. > >> > >> Regards > >> JB > >> > >> On 07/11/2021 07:02, JB Onofré wrote: > >>> Hi guys > >>> > >>> I gonna release pax web 7.3.21 to align version with Karaf. > >>> I’m working on other third party projects where a dependency alignement > >> is required. > >>> > >>> Karaf 4.3.4 will be on vote soon. > >>> > >>> Regards > >>> JB > >>> > >>>> Le 31 oct. 2021 à 07:30, Jean-Baptiste Onofre a > >> écrit : > >>>> > >>>> Hi guys, > >>>> > >>>> As said in my previous email I have a fix that I’m testing now. > >>>> > >>>> I will let you know when done. > >>>> > >>>> Regards > >>>> JB > >>>> > >>>>> Le 29 oct. 2021 à 15:28, Grzegorz Grzybek a > >> écrit : > >>>>> > >>>>> Now, when creating Pax Web 8 pax-web-jetty-bundle (all-in-one Jetty), > >> I'm > >>>>> getting: > >>>>> > >>>>> java.util.ServiceConfigurationError: > >>>>> org.eclipse.jetty.security.Authenticator$Factory: Provider > >>>>> org.eclipse.jetty.security.jaspi.JaspiAuthenticatorFactory not a > >> subtype > >>>>> at java.util.ServiceLoader.fail(ServiceLoader.java:239) > ~[?:1.8.0_312] > >>>>> at java.util.ServiceLoader.access$300(ServiceLoader.java:185) > >> ~[?:1.8.0_312] > >>>>> at > >> java.util.ServiceLoader$LazyIterator.nextService(ServiceLoader.java:376) > >>>>> ~[?:1.8.0_312] > >>>>> at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:404) > >>>>> ~[?:1.8.0_312] > >>>>> at java.util.ServiceLoader$1.next(ServiceLoader.java:480) > >> ~[?:1.8.0_312] > >>>>> at > >>>>> > >> > org.eclipse.jetty.security.SecurityHandler.(SecurityHandler.java:88) > >>>>> ~[pax-web-jetty-bundle-8.0.1-SNAPSHOT.jar:?] > >>>>> ... > >>>>> at > >>>>> > >> > org.eclipse.jetty.servlet.ServletContextHandler.(ServletContextHandler.java:131) > >>>>> ~[pax-web-jetty-bundle-8.0.1-SNAPSHOT.jar:?] > >>>>> at > >>>>> > >> > org.eclipse.jetty.servlet.ServletContextHandler.(ServletContextHandler.java:136) > >>>>> ~[pax-web-jetty-bundle-8.0.1-SNAPSHOT.jar:?] > >>>>> at > >>>>> > >> > org.ops4j.pax.web.service.jetty.internal.PaxWebServletContextHandler.(PaxWebServletContextHandler.java:97) > >>>>> ~[pax-web-jetty-8.0.1-SNAPSHOT.jar:?] > >>>>> > >>>>> Checking... > >>>>> regards > >>>>> Grzegorz Grzybek > >>>>> > >>>>> pt., 29 paź 2021 o 13:19 Grzegorz Grzybek > >> napisał(a): > >>>>> > >>>>>> Hi > >>>>>> > >>>>>> pax-web-jetty before Pax Web 8 used jetty-all, which has dependency > on > >>>>>> jetty-jaspic, which has dependency on javax.security.auth.message... > >>>>>> > >>>>>> Let me check it. > >>>>>> &
Re: Preparing Karaf runtime 4.3.4
Hello Thanks JBO! I didn't yet add Pax Web 8 to 4.4.0-SNAPSHOT, but I'm going to do it soon. regards Grzegorz Grzybek pt., 12 lis 2021 o 08:50 Jean-Baptiste Onofré napisał(a): > Hi guys, > > I finally figured to move forward on release preparation. > > I will submit Karaf runtime 4.3.4 to vote soon (probably during the week > end). I will also work on new Decanter release for next week. > > Finally, I would like to propose a first Karaf runtime 4.4.0.RC1, just > to give a chance to everyone to test this new series before a GA. > > Regards > JB > > On 07/11/2021 07:02, JB Onofré wrote: > > Hi guys > > > > I gonna release pax web 7.3.21 to align version with Karaf. > > I’m working on other third party projects where a dependency alignement > is required. > > > > Karaf 4.3.4 will be on vote soon. > > > > Regards > > JB > > > >> Le 31 oct. 2021 à 07:30, Jean-Baptiste Onofre a > écrit : > >> > >> Hi guys, > >> > >> As said in my previous email I have a fix that I’m testing now. > >> > >> I will let you know when done. > >> > >> Regards > >> JB > >> > >>> Le 29 oct. 2021 à 15:28, Grzegorz Grzybek a > écrit : > >>> > >>> Now, when creating Pax Web 8 pax-web-jetty-bundle (all-in-one Jetty), > I'm > >>> getting: > >>> > >>> java.util.ServiceConfigurationError: > >>> org.eclipse.jetty.security.Authenticator$Factory: Provider > >>> org.eclipse.jetty.security.jaspi.JaspiAuthenticatorFactory not a > subtype > >>> at java.util.ServiceLoader.fail(ServiceLoader.java:239) ~[?:1.8.0_312] > >>> at java.util.ServiceLoader.access$300(ServiceLoader.java:185) > ~[?:1.8.0_312] > >>> at > java.util.ServiceLoader$LazyIterator.nextService(ServiceLoader.java:376) > >>> ~[?:1.8.0_312] > >>> at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:404) > >>> ~[?:1.8.0_312] > >>> at java.util.ServiceLoader$1.next(ServiceLoader.java:480) > ~[?:1.8.0_312] > >>> at > >>> > org.eclipse.jetty.security.SecurityHandler.(SecurityHandler.java:88) > >>> ~[pax-web-jetty-bundle-8.0.1-SNAPSHOT.jar:?] > >>> ... > >>> at > >>> > org.eclipse.jetty.servlet.ServletContextHandler.(ServletContextHandler.java:131) > >>> ~[pax-web-jetty-bundle-8.0.1-SNAPSHOT.jar:?] > >>> at > >>> > org.eclipse.jetty.servlet.ServletContextHandler.(ServletContextHandler.java:136) > >>> ~[pax-web-jetty-bundle-8.0.1-SNAPSHOT.jar:?] > >>> at > >>> > org.ops4j.pax.web.service.jetty.internal.PaxWebServletContextHandler.(PaxWebServletContextHandler.java:97) > >>> ~[pax-web-jetty-8.0.1-SNAPSHOT.jar:?] > >>> > >>> Checking... > >>> regards > >>> Grzegorz Grzybek > >>> > >>> pt., 29 paź 2021 o 13:19 Grzegorz Grzybek > napisał(a): > >>> > >>>> Hi > >>>> > >>>> pax-web-jetty before Pax Web 8 used jetty-all, which has dependency on > >>>> jetty-jaspic, which has dependency on javax.security.auth.message... > >>>> > >>>> Let me check it. > >>>> > >>>> regards > >>>> Grzegorz Grzybek > >>>> > >>>> pt., 29 paź 2021 o 13:12 Paul Stanley < > paul.stan...@saaconsultants.com> > >>>> napisał(a): > >>>> > >>>>> The Jetty issue: > https://github.com/eclipse/jetty.project/issues/6554 > >>>>> resulted in pull request: > >>>>> > >>>>> > https://github.com/eclipse/jetty.project/commit/4fd1a4ea4b7a989ea16f40ba7c49dc553ae2ace1 > >>>>> This removed the check for the realm being set, thus always creating > a > >>>>> default identity service, even when one is not defined. > >>>>> As a result the geronimo JASPI spec (Java Authentication SPI), > Attempts > >>>>> to construct a default JASPI factory, resulting in a Class Not Found > >>>>> Exception. > >>>>> > >>>>> I've had a quick look at the pax-web-jetty project, but i can't see > any > >>>>> geronimo dependencies. As such one of the test modules must have the > api > >>>>> and implementation built in, or it's using a different Jetty Identity > >>>>> Service? > >>>>> > >>>>> Cheers > &
Re: Preparing Karaf runtime 4.3.4
Now, when creating Pax Web 8 pax-web-jetty-bundle (all-in-one Jetty), I'm getting: java.util.ServiceConfigurationError: org.eclipse.jetty.security.Authenticator$Factory: Provider org.eclipse.jetty.security.jaspi.JaspiAuthenticatorFactory not a subtype at java.util.ServiceLoader.fail(ServiceLoader.java:239) ~[?:1.8.0_312] at java.util.ServiceLoader.access$300(ServiceLoader.java:185) ~[?:1.8.0_312] at java.util.ServiceLoader$LazyIterator.nextService(ServiceLoader.java:376) ~[?:1.8.0_312] at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:404) ~[?:1.8.0_312] at java.util.ServiceLoader$1.next(ServiceLoader.java:480) ~[?:1.8.0_312] at org.eclipse.jetty.security.SecurityHandler.(SecurityHandler.java:88) ~[pax-web-jetty-bundle-8.0.1-SNAPSHOT.jar:?] ... at org.eclipse.jetty.servlet.ServletContextHandler.(ServletContextHandler.java:131) ~[pax-web-jetty-bundle-8.0.1-SNAPSHOT.jar:?] at org.eclipse.jetty.servlet.ServletContextHandler.(ServletContextHandler.java:136) ~[pax-web-jetty-bundle-8.0.1-SNAPSHOT.jar:?] at org.ops4j.pax.web.service.jetty.internal.PaxWebServletContextHandler.(PaxWebServletContextHandler.java:97) ~[pax-web-jetty-8.0.1-SNAPSHOT.jar:?] Checking... regards Grzegorz Grzybek pt., 29 paź 2021 o 13:19 Grzegorz Grzybek napisał(a): > Hi > > pax-web-jetty before Pax Web 8 used jetty-all, which has dependency on > jetty-jaspic, which has dependency on javax.security.auth.message... > > Let me check it. > > regards > Grzegorz Grzybek > > pt., 29 paź 2021 o 13:12 Paul Stanley > napisał(a): > >> The Jetty issue: https://github.com/eclipse/jetty.project/issues/6554 >> resulted in pull request: >> >> https://github.com/eclipse/jetty.project/commit/4fd1a4ea4b7a989ea16f40ba7c49dc553ae2ace1 >> This removed the check for the realm being set, thus always creating a >> default identity service, even when one is not defined. >> As a result the geronimo JASPI spec (Java Authentication SPI), Attempts >> to construct a default JASPI factory, resulting in a Class Not Found >> Exception. >> >> I've had a quick look at the pax-web-jetty project, but i can't see any >> geronimo dependencies. As such one of the test modules must have the api >> and implementation built in, or it's using a different Jetty Identity >> Service? >> >> Cheers >> Paul >> >> >> >> >> >> From: "Grzegorz Grzybek" >> To: "Karaf Dev" >> Date: 29/10/2021 11:36 >> Subject:Re: Preparing Karaf runtime 4.3.4 >> >> >> >> Hello >> >> What's the problem with Jetty 9.4.44? I checked with Pax Web 8 without any >> changes and I got: >> >> [INFO] Results: >> [INFO] >> [WARNING] Tests run: 201, Failures: 0, Errors: 0, Skipped: 2 >> ... >> [INFO] >> [INFO] --- maven-failsafe-plugin:2.22.2:verify (verify) @ >> pax-web-itest-jetty --- >> [INFO] >> >> [INFO] BUILD SUCCESS >> [INFO] >> >> [INFO] Total time: 05:34 min >> [INFO] Finished at: 2021-10-29T12:34:12+02:00 >> [INFO] >> >> >> The tests include authentication and TLS tests. >> >> regards >> Grzegorz Grzybek >> >> pt., 29 paź 2021 o 11:44 Paul Stanley >> napisał(a): >> >> > Hi JB, >> > >> > Jetty 9.4.44 now attempts to create the default instance of the jaspi, >> > even if it is not installed or used. >> > I've included the geronimo-jaspi implementation alongside the geronimo >> > -jaspic_1.0_spec to address the issue. >> > Note that ordering is important as there is static code begin used to >> > register the jaspic factories, thus the above packages need to loaded >> into >> > the runtime prior to the jetty bundles. >> > >> > Cheers >> > Paul >> > >> > >> > >> > >> > From: "Jean-Baptiste Onofre" >> > To: dev@karaf.apache.org >> > Date: 29/10/2021 09:58 >> > Subject:Re: Preparing Karaf runtime 4.3.4 >> > >> > >> > >> > Hi guys, >> > >> > I detected that Jetty 9.4.44 update breaks the authentication layer. >> > I’m fixing that and I will cut Pax Web 7.3.20 to integrate in Karaf >> 4.3.4. >> > >> > I will keep you posted, however, the plan is still to submit Karaf 4.3.4 >> > to vote during the week end. >> > >> > Regards >> > JB >> > >> > > Le 12 oct. 2021 à 14:43, JB Onofré a écrit : >> > > >> > > Hi guys >> > > >> > > I’m working on Felix FileInstall release fixing the first losing >> issue. >> > I will include couple of other important fixes. >> > > >> > > I would like to submit Karaf 4.3.4 to vote during the week end or >> early >> > next week. >> > > >> > > Thoughts ? >> > > >> > > Regards >> > > JB >> > >> > >> > >> > >> > >> >> >> >>
Re: Preparing Karaf runtime 4.3.4
Hi pax-web-jetty before Pax Web 8 used jetty-all, which has dependency on jetty-jaspic, which has dependency on javax.security.auth.message... Let me check it. regards Grzegorz Grzybek pt., 29 paź 2021 o 13:12 Paul Stanley napisał(a): > The Jetty issue: https://github.com/eclipse/jetty.project/issues/6554 > resulted in pull request: > > https://github.com/eclipse/jetty.project/commit/4fd1a4ea4b7a989ea16f40ba7c49dc553ae2ace1 > This removed the check for the realm being set, thus always creating a > default identity service, even when one is not defined. > As a result the geronimo JASPI spec (Java Authentication SPI), Attempts > to construct a default JASPI factory, resulting in a Class Not Found > Exception. > > I've had a quick look at the pax-web-jetty project, but i can't see any > geronimo dependencies. As such one of the test modules must have the api > and implementation built in, or it's using a different Jetty Identity > Service? > > Cheers > Paul > > > > > > From: "Grzegorz Grzybek" > To: "Karaf Dev" > Date: 29/10/2021 11:36 > Subject:Re: Preparing Karaf runtime 4.3.4 > > > > Hello > > What's the problem with Jetty 9.4.44? I checked with Pax Web 8 without any > changes and I got: > > [INFO] Results: > [INFO] > [WARNING] Tests run: 201, Failures: 0, Errors: 0, Skipped: 2 > ... > [INFO] > [INFO] --- maven-failsafe-plugin:2.22.2:verify (verify) @ > pax-web-itest-jetty --- > [INFO] > > [INFO] BUILD SUCCESS > [INFO] > > [INFO] Total time: 05:34 min > [INFO] Finished at: 2021-10-29T12:34:12+02:00 > [INFO] > > > The tests include authentication and TLS tests. > > regards > Grzegorz Grzybek > > pt., 29 paź 2021 o 11:44 Paul Stanley > napisał(a): > > > Hi JB, > > > > Jetty 9.4.44 now attempts to create the default instance of the jaspi, > > even if it is not installed or used. > > I've included the geronimo-jaspi implementation alongside the geronimo > > -jaspic_1.0_spec to address the issue. > > Note that ordering is important as there is static code begin used to > > register the jaspic factories, thus the above packages need to loaded > into > > the runtime prior to the jetty bundles. > > > > Cheers > > Paul > > > > > > > > > > From: "Jean-Baptiste Onofre" > > To: dev@karaf.apache.org > > Date: 29/10/2021 09:58 > > Subject:Re: Preparing Karaf runtime 4.3.4 > > > > > > > > Hi guys, > > > > I detected that Jetty 9.4.44 update breaks the authentication layer. > > I’m fixing that and I will cut Pax Web 7.3.20 to integrate in Karaf > 4.3.4. > > > > I will keep you posted, however, the plan is still to submit Karaf 4.3.4 > > to vote during the week end. > > > > Regards > > JB > > > > > Le 12 oct. 2021 à 14:43, JB Onofré a écrit : > > > > > > Hi guys > > > > > > I’m working on Felix FileInstall release fixing the first losing > issue. > > I will include couple of other important fixes. > > > > > > I would like to submit Karaf 4.3.4 to vote during the week end or > early > > next week. > > > > > > Thoughts ? > > > > > > Regards > > > JB > > > > > > > > > > > > > >
Re: Preparing Karaf runtime 4.3.4
Hello What's the problem with Jetty 9.4.44? I checked with Pax Web 8 without any changes and I got: [INFO] Results: [INFO] [WARNING] Tests run: 201, Failures: 0, Errors: 0, Skipped: 2 ... [INFO] [INFO] --- maven-failsafe-plugin:2.22.2:verify (verify) @ pax-web-itest-jetty --- [INFO] [INFO] BUILD SUCCESS [INFO] [INFO] Total time: 05:34 min [INFO] Finished at: 2021-10-29T12:34:12+02:00 [INFO] The tests include authentication and TLS tests. regards Grzegorz Grzybek pt., 29 paź 2021 o 11:44 Paul Stanley napisał(a): > Hi JB, > > Jetty 9.4.44 now attempts to create the default instance of the jaspi, > even if it is not installed or used. > I've included the geronimo-jaspi implementation alongside the geronimo > -jaspic_1.0_spec to address the issue. > Note that ordering is important as there is static code begin used to > register the jaspic factories, thus the above packages need to loaded into > the runtime prior to the jetty bundles. > > Cheers > Paul > > > > > From: "Jean-Baptiste Onofre" > To: dev@karaf.apache.org > Date: 29/10/2021 09:58 > Subject:Re: Preparing Karaf runtime 4.3.4 > > > > Hi guys, > > I detected that Jetty 9.4.44 update breaks the authentication layer. > I’m fixing that and I will cut Pax Web 7.3.20 to integrate in Karaf 4.3.4. > > I will keep you posted, however, the plan is still to submit Karaf 4.3.4 > to vote during the week end. > > Regards > JB > > > Le 12 oct. 2021 à 14:43, JB Onofré a écrit : > > > > Hi guys > > > > I’m working on Felix FileInstall release fixing the first losing issue. > I will include couple of other important fixes. > > > > I would like to submit Karaf 4.3.4 to vote during the week end or early > next week. > > > > Thoughts ? > > > > Regards > > JB > > > > >
Re: Preparing Karaf runtime 4.3.4
+1 Thanks! regards Grzegorz Grzybek wt., 12 paź 2021 o 14:43 JB Onofré napisał(a): > Hi guys > > I’m working on Felix FileInstall release fixing the first losing issue. I > will include couple of other important fixes. > > I would like to submit Karaf 4.3.4 to vote during the week end or early > next week. > > Thoughts ? > > Regards > JB >
Re: Main updated to 4.4.0-SNAPSHOT and karaf-4.3.x branch
Thanks JBO! I'll play with Karaf 4.4 + Pax Web 8 soon. regards Grzegorz Grzybek pon., 11 paź 2021 o 17:04 Jean-Baptiste Onofré napisał(a): > Hi guys, > > A quick update about this: > > - main branch has been updated to version 4.4.0-SNAPSHOT, R8 > spec/framework and single spec bundle are now used > - karaf-4.3.x branch has been created > > Both are built on Jenkins. > > Regards > JB > > On 21/09/2021 08:44, Jean-Baptiste Onofre wrote: > > Hi guys, > > > > I have almost finished the main branch update with: > > > > - OSGi R8 (Felix Framework 7.0.1) > > - remove of OSGi cmpn and use of single spec bundle now (recommended now) > > - update to Pax Web 8.0.0 > > > > You can take a look on the working branch here: > > > > https://github.com/jbonofre/karaf/tree/K44 > > > > I’m running several builds now to verify all tests are OK, etc. > > > > If there’s no objection, I would like to push: > > > > - create karaf-4.3.x branch with the current main HEAD > > - update main branch with K44 branch > > > > Thoughts ? > > > > Thanks > > Regards > > JB > > >
Re: Main updated to 4.4.0-SNAPSHOT and karaf-4.3.x branch
Hi Visibility has changed slightly, but the main problem is that: - http:* commands relied on stored "initial servlet events" which IMO is bad pattern - first, http:* commands (in Karaf with Pax Web 7) could investigate servlets only. But also it's better to check the current state of Pax Web runtime directly (in kind of HttpServiceRuntime DTO way) instead of relying on past events. - web:* commands relied on weird WarManager interface/service from Pax Web 7, which only exposed bundle IDs of web bundles - it doesn't give any insight into the WAB's content and also we couldn't observe contexts (context paths) created by Whiteboard and HttpService - like "/" context to which CXF registers it's /cxf servlet for example The above problems are easily fixable in Pax Web 8, just give me some time ;) regards Grzegorz Grzybek wt., 21 wrz 2021 o 08:52 Jean-Baptiste Onofre napisał(a): > Hi > > I have couple of issue with SPI visibility as some packages/classes are > not « public » anymore (I’m thinking about WebEvent). > > It’s especially true in the Karaf http commands, so, this should be > updated. > > Anyway, I propose to push main with 4.4.0-SNAPSHOT with Pax Web 7.3.x and > update to Pax Web 8.0.0 directly on main. > > Regards > JB > > > Le 21 sept. 2021 à 08:50, Grzegorz Grzybek a > écrit : > > > > Thanks JBO! > > > > I'll have a look at Pax Web 8 integration with Karaf - generally it > works, > > but I want something "special" here. > > Pax Web 8 (historically) re-exports org.osgi.service.http.* packages - > I'll > > think about moving the HttpService/Whiteboard APIs to external > > org.osgi/org.osgi.service.http bundle, but I have no clear opinion yet. > > > > regards > > Grzegorz Grzybek > > > > wt., 21 wrz 2021 o 08:44 Jean-Baptiste Onofre > napisał(a): > > > >> Hi guys, > >> > >> I have almost finished the main branch update with: > >> > >> - OSGi R8 (Felix Framework 7.0.1) > >> - remove of OSGi cmpn and use of single spec bundle now (recommended > now) > >> - update to Pax Web 8.0.0 > >> > >> You can take a look on the working branch here: > >> > >> https://github.com/jbonofre/karaf/tree/K44 > >> > >> I’m running several builds now to verify all tests are OK, etc. > >> > >> If there’s no objection, I would like to push: > >> > >> - create karaf-4.3.x branch with the current main HEAD > >> - update main branch with K44 branch > >> > >> Thoughts ? > >> > >> Thanks > >> Regards > >> JB > >
Re: Main updated to 4.4.0-SNAPSHOT and karaf-4.3.x branch
Thanks JBO! I'll have a look at Pax Web 8 integration with Karaf - generally it works, but I want something "special" here. Pax Web 8 (historically) re-exports org.osgi.service.http.* packages - I'll think about moving the HttpService/Whiteboard APIs to external org.osgi/org.osgi.service.http bundle, but I have no clear opinion yet. regards Grzegorz Grzybek wt., 21 wrz 2021 o 08:44 Jean-Baptiste Onofre napisał(a): > Hi guys, > > I have almost finished the main branch update with: > > - OSGi R8 (Felix Framework 7.0.1) > - remove of OSGi cmpn and use of single spec bundle now (recommended now) > - update to Pax Web 8.0.0 > > You can take a look on the working branch here: > > https://github.com/jbonofre/karaf/tree/K44 > > I’m running several builds now to verify all tests are OK, etc. > > If there’s no objection, I would like to push: > > - create karaf-4.3.x branch with the current main HEAD > - update main branch with K44 branch > > Thoughts ? > > Thanks > Regards > JB
Pax Web 8.0.0 is just one click away
Hello! I've just prepared Pax Web 8.0.0 release and the staging repository URL is https://oss.sonatype.org/content/repositories/orgops4j-1524/ How to test it in Karaf? Start fresh (with Karaf 4.3.3 for example), uncomment "karaf" user in etc/users.properties and: karaf@root()> repo-remove mvn:org.ops4j.pax.web/pax-web-features/7.3.19/xml/features karaf@root()> feature:install maven karaf@root()> maven:repository-add -id pax-web-8 https://oss.sonatype.org/content/repositories/orgops4j-1524/ karaf@root()> repo-add mvn:org.ops4j.pax.web/pax-web-features/8.0.0/xml/features karaf@root()> feature:install pax-web-http-jetty pax-web-war karaf@root()> bundle:install -s 'webbundle:mvn:io.hawt/hawtio-war/2.13.6/war?Web-ContextPath=/hawtio' Now you can navigate to http://localhost:8181/hawtio and see for example: [image: image.png] Now, I can click "Release" button any time soon and Pax Web 8 will be available in Maven Central. I just hope for a little feedback about the above steps ;) kind regards Grzegorz Grzybek
Re: [VOTE] Apache Karaf runtime 4.2.12 release
+1 (I checked the integration tests for Red Hat Fuse 7.x) regards Grzegorz Grzybek pon., 13 wrz 2021 o 14:50 Jean-Baptiste Onofré napisał(a): > Hi everyone, > > I submit Apache Karaf runtime 4.2.12 to your vote. > > This is a maintenance release on the karaf-4.2.x series, with bug fixes, > and dependency updates (for CVE and fixes): > > This release includes bunch of dependency upgrades, fixes, and > improvements, especially: > > - prevent NPE when creating shell session without in parameter > - fix on JMX connection with security manager > - fix on war deployment when the war contains module-info.class > - fix warning on the org.apache.karaf.specs.locator package > - bunch of dependency updates > - and much more! > > Please take a look on Release Notes for details ! > > Release Notes: > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12349962 > > Staging Maven Repository: > https://repository.apache.org/content/repositories/orgapachekaraf-1159/ > > Staging Dist Repository: > https://dist.apache.org/repos/dist/dev/karaf/4.2.12/ > > Git tag: > karaf-4.2.12 > > 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 >
Plan to release Pax Web 8 + some information
runtime) that: - keeps an instance of the "server" (org.eclipse.jetty.server.Server, org.apache.catalina.core.StandardServer or io.undertow.server.HttpHandler + collection of org.xnio.channels.AcceptingChannels) - Pax Web 8 DOESN'T use easy-to-use io.undertow.Undertow class! - implements org.ops4j.pax.web.service.spi.task.BatchVisitor interface that's used to react to state-changing operations (like registration of a servlet) - mind that a "batch" may be "transactional" - each runtime bundle contains some overriden runtime classes (like org.ops4j.pax.web.service.jetty.internal.PaxWebFilterHolder that extends org.eclipse.jetty.servlet.FilterHolder) - Knowing that we have 3 "ways into" the Pax Web (HttpService, Whiteboard, WABs), Pax Web 8 introduces the concept of "the view of the WebContainer" - each "way" uses specific "view" to interact with Pax Web runtime - The model is greatly simplified comparing to Pax Web 7: - there exist "model" classes (like org.ops4j.pax.web.service.spi.model.elements.ServletModel) which are held internall and passed around between whiteboard, war, runtime and target container bundles - from Whiteboard perspective, the "incoming" services, like "javax.servlet.Servlet" or "org.osgi.service.http.context.ServletContextHelper" are "tracked into" the model classes, so whether the servlet is registered by HttpService, Whiteboard or through a WAB, its processing is consistent and there's no problem mixing WABs, Whiteboard and HttpService approaches - the "model" classes are divided into "web elements" and "web contexts" and each "web element" may reference one or many "web contexts" and the relation is dynamic - ... *Pax Web 8 example:* The most important use-case is: - user/bundle registers (Whiteboard approach) a servlet without specifying a "context" and the servlet has mapping "/my-servlet" - this servlet should be available at URL http://localhost:8181/my-servlet - another user/bundle registers a org.osgi.service.http.context.ServletContextHelper service with "osgi.http.whiteboard.context.path=/my-context" and " osgi.http.whiteboard.context.name=default" properties - *immediately* (asap) the first servlet should be available at http://localhost:8181/my-context/my-servlet and *no longer* it should be available at the first URL Yes, it works. Also shadowing may happen, because when two servlets are registered with the same name and target context, only the one with higher ranking/lower service.id should be available. There are many integration tests that show what happens when conflicting services are registered across different contexts. *Summary*: If you have some time, please checkout https://github.com/ops4j/org.ops4j.pax.web/tree/main, `mvn clean -DskipTests` it and give it a try. For example in Karaf 4.3.3 (after uncommenting "karaf" user in `etc/users.properties`) we can do: karaf@root()> repo-remove org.ops4j.pax.web-7.3.19 > Removing features repository: > mvn:org.ops4j.pax.web/pax-web-features/7.3.19/xml/features > karaf@root()> repo-add > mvn:org.ops4j.pax.web/pax-web-features/8.0.0-SNAPSHOT/xml/features > Adding feature url > mvn:org.ops4j.pax.web/pax-web-features/8.0.0-SNAPSHOT/xml/features > karaf@root()> feature:install pax-web-http-tomcat > karaf@root()> feature:install pax-web-war > karaf@root()> bundle:install > 'webbundle:mvn:io.hawt/hawtio-war/2.13.6/war?Web-ContextPath=/hawtio' > Bundle ID: 68 > karaf@root()> start 68 > Then you can log in to http://localhost:8181/hawtio using karaf/karaf credentials (JAAS based authentication) and then navigate to http://localhost:8181/hawtio/jmx/attributes?nid=root-Catalina-WebResourceRoot-localhost-%2FServletContextModel-3-Cache which shows cache configuration for the default (resource) servlet used by /hawtio WAB. kind regards and thanks for the patience ;) Grzegorz Grzybek
Re: Pax Web 8 performance (different JDKs)
Hello JBO Pax Web 8 own "Karaf tests" work (since yesterday) on Karaf 4.3.3. Everything should work on all Osgi Core R6+ runtimes (pax-exam-container-native tests use osgi.core 6.0.0 / Felix 5.6.12) regards Grzegorz Grzybek niedz., 12 wrz 2021 o 21:10 Jean-Baptiste Onofre napisał(a): > Hi Greg > > Thanks for the update and great results ! > > I’m running a new build/pass and I will test in 4.3.x. > > What I have in mind is to prepare 4.4.x with Pax Web 8 and OSGi R8. > > So, I would create karaf-4.3.x branch and update main to OSGi R8/Pax Web 8. > > Thoughts ? > > Regards > JB > > > Le 12 sept. 2021 à 19:30, Grzegorz Grzybek a > écrit : > > > > Good evening! > > > > I've just pushed last commit before 8.0.0.GA. This commit fixed the > compilation and test problems under JDK17. > > > > Current state is: > > - all the tasks I've planned for 8.0.0.GA are finished > > - all the tests (unit, pax-exam-container-native, > pax-exam-container-karaf) work on JDK 8, JDK 11 and JDK 17 > > > > I expected that everything would work few percent slower on JDK 11 than > on JDK 8 (I observed this performance downgrade on several occasions). What > I didn't expect is that generally everything works faster on JDK 17 than on > JDK 8! > > > > Here's the table: > > > > > > > > I hope to write more about "what is Pax Web 8" soon and that the week of > Sep 13-17 will be the week of the release. > > > > kind regards > > Grzegorz Grzybek > >
Pax Web 8 performance (different JDKs)
Good evening! I've just pushed last commit before 8.0.0.GA. This commit fixed the compilation and test problems under JDK17. Current state is: - all the tasks I've planned for 8.0.0.GA are finished - all the tests (unit, pax-exam-container-native, pax-exam-container-karaf) work on JDK 8, JDK 11 and JDK 17 I expected that everything would work few percent slower on JDK 11 than on JDK 8 (I observed this performance downgrade on several occasions). What I didn't expect is that generally everything works faster on JDK 17 than on JDK 8! Here's the table: [image: image.png] I hope to write more about "what is Pax Web 8" soon and that the week of Sep 13-17 will be the week of the release. kind regards Grzegorz Grzybek
Pax Web 8 - WabAugmentingIntegrationTest works
Hello I'd like to share good news. The remaining task before GA seems to be DTOs only (I just have to review the work made initially Marc Schlegel to check how everything works with my changes). What "WAB Augmenting" means? the test: - installs a WAB with web.xml and single servlet - checks that it works - installs a Whiteboard filter targeting the WAB using osgi.http.whiteboard.context.select=(osgi.http.whiteboard.context.path=/war-bundle) selector - checks that it works - the filter should be used before the WAB's servlet - obtains a HttpService instance using bundle context of the WAB and calls plain old HttpService.registerServlet() - checks again that the Whiteboard filter can filter access both to the WAB's servlet AND to the HttpService servlet - stops the WAB - checks that nothing works (WAB's servlet, HttpService servlet and Whiteboard filter), but... - ... I register a `ServletContextHelper` with "osgi.http.whiteboard.context.path=/war-bundle", so the Filter which is NOT yet unregistered can be satisfied (based on its context selector) - checks that the filter works again! Actually this concludes the 3-way access to Pax Web, where underlying context can be manipulated easily (I hope) using standard OSGi CMPN methods. kind regards Grzegorz Grzybek
Re: [VOTE] Apache Karaf runtime 4.3.3 release
+1 regards Grzegorz Grzybek pt., 3 wrz 2021 o 19:52 Francois Papon napisał(a): > +1 (binding) > > Thanks JB! > > regards, > > François > fpa...@apache.org > francois.pa...@openobject.fr > > Le 02/09/2021 à 10:33, Jean-Baptiste Onofré a écrit : > > Hi everyone, > > > > I submit Apache Karaf runtime 4.3.3 to your vote. > > > > This release includes bunch of dependency upgrades, fixes, and > > improvements, especially: > > > > - first round of the specs features repository. This repository use > > will spread (in Karaf and third party projects) and we will improve > > it, but this first round introduces the skeleton we need. > > - ssh fix new closing socket cleanly > > - memory leak fix on the blueprint state service > > - fix on JMX exception push back to the client > > - bunch of dependency updates > > - and much more ! > > > > Please take a look on Release Notes for details ! > > > > Release Notes: > > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12350142 > > > > > > Staging Maven Repository: > > https://repository.apache.org/content/repositories/orgapachekaraf-1157/ > > > > Staging Dist Repository: > > https://dist.apache.org/repos/dist/dev/karaf/4.3.3/ > > > > Git tag: > > karaf-4.3.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 >
Pax Web 8 - 2 more tasks before GA
Hello I'd like to present the state of Pax Web 8. I hope to release Pax Web 8.0.0.GA in mid-September. I maintain a todo.txt[1] file where I present the issues I'd like to implement in given milestones. The priority is to have R7 compliance, though without running the TCK[2], because I didn't have time to find out an easy way to actually run the TCK :) However I'm glad it's public now. So summarizing, these R7 features were implemented recently: - Whiteboard preprocessors - RegEx filter mapping - Listener ordering according to ranking - Session per OsgiContextModel / OsgiServletContext (including proper javax.servlet.context.tempdir handling) - org.osgi.framework.ServiceObjects and proper service management (unget, prototype, singleton, bundle scopes) Also I've implemented (or ensured the stability and consistency between Jetty, Tomcat and Undertow) for these: - Whiteboard WebSockets - they work both through WABs, Whiteboard and even WebContainer (HttpService) - Karaf integration tests - all tests work for all three runtimes. In Pax Web 7 the tests were running mostly on Jetty The remaining *two* tasks are: - Mixing (in different order) WAB and Whiteboard contexts, so we can install a WAB and Whiteboard/HttpService alter it by registering for example Preprocessors - Whiteboard DTOs kind regards Grzegorz Grzybek === [1]: https://github.com/ops4j/org.ops4j.pax.web/blob/main/todo.txt [2]: https://github.com/osgi/osgi/
Important Pax Web 8 milestone achieved
Hello
I'd like to share great news about Pax Web 8 state.
For last few days I was working on tiny, single test related to
Whiteboard-registration of WebSockets...
Normally (WAR) websockets are registered by some
ServletContainerInitializer based ONLY on the classes passed to
SCI.onStartup() and scanned using (usually) the information like this:
@HandlesTypes({
ServerEndpoint.class,
ServerApplicationConfig.class,
Endpoint.class
})
WAR scenario in Pax Web 8 was easy - simply an existing SCI (or custom one
for Undertow) was sufficient.
The problem was the dynamics of Whiteboard approach. What should happen
when you simply "add a websocket"?
Pax Web 7, when registering a websocket was adding an SCI to be invoked at
(re)start time of the target (Jetty, Tomcat, Undertow) context. So easy
calculation - 10 websockets == 10 SCIs.
This fact made me think wider - how restarts and SCIs should be handled?
I got back to most trivial question - how many ways there are to register a
servlet? In Pax Web case there are FIVE:
1. webcontainer.registerServlet()
2. Whiteboard registration of javax.servlet.Servlet service
3. an SCI may invoke servletContext.addServlet()
4. a ServletContextListener may invoke servletContext.addServlet()
5. an Undertow extension may add additional servlets to DeploymentInfo
the same is for filters and listeners (except that a ServletContextListener
can't register more ServletContextListeners)
So when we register and SCI that registers a websocket we want it to be
run, right? so we effectively want to "restart a context". But (and that's
what I was working on during last 3 days):
- we *don't want* to lose servlets/filters/listeners registered
previously through Whiteboard/HttpService
- we *want* to lose the servlets/filters/listeners registered by SCIs
and ServletContextListeners, because if we call them again, we don't want
conflicts!
- we *want* to clear the context attributes that could've been set by
SCIs/ServletContextListeners before, because that's how SCis "mark" the
context as processed - leaving there some flags that prevents them from
doing some tasks more than once
And finally I have a working scenario:
- an SCI is Whiteboard registered and calls sc.addFilter() in onStartup()
- a ServletContextListener is Whiteboard registered and calls
sc.setAttribute() and sc.addServlet() in contextInitialized()
- a servlet is Whiteboard registered
- a filter is Whiteboard registered
- a WebSocket (1) is registered by instance
- a WebSocket (2) is registered by class
- a WebSocket (2) is unregistered
In between the registrations, GET requests are performed to check the
expected behavior - *and everything works consistently across all 3
container runtimes!*
And yes - I added the possibility to register actual WebSocket instance -
Pax Web 7, even if you've registered a @ServerEndpoint-annotated object as
WebSocket, was simply taking its getClass() and was using this class
(instantiated later by actual runtime).
And what's more - even if you register/unregister more WebSockets, single,
dedicated SCI is used to (re)register all needed WebSockets!
I hope the actual 8.0.0.GA is finally coming.
kind regards
Grzegorz Grzybek
State of Pax Web 8
Hello I'd just like to let you know that everything is under control and I didn't abandon the effort. I've added a todo.txt file[1] to Pax Web's main branch (I didn't create separate GH issues for the tasks yet, as the scope may change, but at some point I'll translate the remaining items to GH issues). So currently (and for some time already) I'm patiently making existing (Pax Web 7) integration tests work with Pax Web 8. The remaining integration tests cover (~10 tests): - HttpContext processing[2] (that's beyond CMPN specifications) - Whiteboard websockets (beyond CMPN specifications) - DTO tests - JAX-RS tests - Jetty/Tomcat/Undertow bundles tests - Jetty Handlers/Connectors OSGi services - VirtualHosts - CRLs - Jasypt The already working (much faster due to better listeners!) tests include (almost 200 per container runtime): - external jetty.xml/tomcat-server.xml/undertow.xml configuration - HttpService/WebContainer tests (CMPN chapter 102) - JSP tests (custom tags, directives, includes, ...) - WABs (including SCIs, WebSockets, scanning and fragments) - JSF - Vaadin (new!) - Whiteboard (much improved, including SCR and standard services) The most important aspects of chapters 102 (Http Service), 128 (Web Applications) and 140 (Whiteboard) are implemented including the most important one - 1:N mapping between web elements and _contexts_. The other most important aspect, not related to CMPN specifications is the consistency of behavior between Jetty, Tomcat and Undertow containers - only ONE integration test has container specific behavior - the test checking HTTP response when POST size (container-specific configuration) is exceeded. I roughly plan to release Pax Web 8 around mid of September. kind regards Grzegorz Grzybek === [1]: https://github.com/ops4j/org.ops4j.pax.web/blob/main/todo.txt [2]: https://ops4j1.jira.com/wiki/spaces/paxweb/pages/354025473/HTTP+Context+processing
Re: June '21 board report
+1 - thanks! regards Grzegorz Grzybek wt., 1 cze 2021 o 15:05 Jean-Baptiste Onofre napisał(a): > Hi guys, > > I prepared the board report for this month: > > https://cwiki.apache.org/confluence/display/KARAF/Board+Reports < > https://cwiki.apache.org/confluence/display/KARAF/Board+Reports> > > Can you please take a look and let me know if you want to add something ? > > Thanks ! > > Regards > JB
Re: Problem after install pax-trans-tm-narayana with Karaf 4.3.2
Hmm, but your remember this https://github.com/ops4j/org.ops4j.pax.transx/issues/50 issue? I ensured that pax-transx can run, build and test using JDK11... I'll check it again. Could you file a bug to https://github.com/ops4j/org.ops4j.pax.transx/issues ? regards Grzegorz Grzybek czw., 20 maj 2021 o 18:00 Benjamin Graf napisał(a): > Hi Grzegorz, > > the same error with pax-transx 0.5.1 > >- feature:repo-add pax-transx 0.5.1 >- feature:repo-add pax-transx 0.5.1 > > Regards > > Benjamin > On 20.05.2021 17:43, Grzegorz Grzybek wrote: > > Hi > > Did you try `mvn clean install` latest pax-transx release? > > regards > Grzegorz Grzybek > > czw., 20 maj 2021 o 17:40 Benjamin Graf > napisał(a): > > > Hi JB, > > I use JDK 11 as runtime environment. There is no code to compile to > reproduce this bug just plain Karaf and pax-trans-tm-narayana from Maven > central. > > Regards > > Benjamin > > On 20.05.2021 10:32, Jean-Baptiste Onofre wrote: > > Hi Ben, > > Are you using JDK 11 (for both compile and runtime) ? > > Regards > JB > > > Le 20 mai 2021 à 08:17, Benjamin Graf > a écrit : > > Hi, > > it seems there is a bug with embedded resources. I think it is caused > > by Felix and not Karaf itself. > > How to reproduce: > > - Clean start of plain Karaf 4.3.2 > > - feature:install pax-transx-tm-narayana > > Result: > > 2021-05-20T08:16:02,787 | WARN | paxtransx-config-1-thread-1 | > > pax-transx-tm-narayana | 60 - > org.ops4j.pax.transx.pax-transx-tm-narayana - 0.5.0 | Error starting service > > java.lang.reflect.InvocationTargetException: null > at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native > > Method) ~[?:?] > > at > > jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > ~[?:?] > > at > > jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > ~[?:?] > > at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?] > at > > org.jboss.narayana.osgi.jta.internal.Activator.doStart(Activator.java:49) > ~[?:?] > > at > > org.ops4j.pax.transx.tm.impl.AbstractActivator.run(AbstractActivator.java:115) > ~[?:?] > > at > > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) > [?:?] > > at java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?] > at > > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) > [?:?] > > at > > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > [?:?] > > at java.lang.Thread.run(Thread.java:829) [?:?] > Caused by: java.lang.IllegalStateException: Stream handler unavailable > > due to: null > > at > > org.apache.felix.framework.URLHandlersStreamHandlerProxy.openConnection(URLHandlersStreamHandlerProxy.java:311) > ~[?:?] > > at java.net.URL.openConnection(URL.java:1099) ~[?:?] > at > > jdk.internal.loader.URLClassPath$JarLoader.getJarFile(URLClassPath.java:815) > ~[?:?] > > at > > jdk.internal.loader.URLClassPath$JarLoader$1.run(URLClassPath.java:758) > ~[?:?] > > at > > jdk.internal.loader.URLClassPath$JarLoader$1.run(URLClassPath.java:751) > ~[?:?] > > at java.security.AccessController.doPrivileged(Native Method) > > ~[?:?] > > at > > jdk.internal.loader.URLClassPath$JarLoader.ensureOpen(URLClassPath.java:750) > ~[?:?] > > at > > jdk.internal.loader.URLClassPath$JarLoader.(URLClassPath.java:725) > ~[?:?] > > at jdk.internal.loader.URLClassPath$3.run(URLClassPath.java:493) > > ~[?:?] > > at jdk.internal.loader.URLClassPath$3.run(URLClassPath.java:476) > > ~[?:?] > > at java.security.AccessController.doPrivileged(Native Method) > > ~[?:?] > > at > > jdk.internal.loader.URLClassPath.getLoader(URLClassPath.java:475) ~[?:?] > > at > > jdk.internal.loader.URLClassPath.getLoader(URLClassPath.java:444) ~[?:?] > > at > > jdk.internal.loader.URLClassPath.getResource(URLClassPath.java:313) ~[?:?] > > at java.net.URLClassLoader$1.run(URLClassLoader.java:455) ~[?:?] > at java.net.URLClassLoader$1.run(URLClassLoader.java:452) ~[?:?] > at java.security.AccessController.doPrivileged(Native Method) > > ~[?:?] > > at java.net.URLClassLoader.findClass(URLClassLoader.java:451) > > ~[?:?] > > at java.lang.ClassLoader.loadClass(ClassLoader.java:589) ~[?:?] > at java.lang.ClassLoader.loadClass(ClassLoader.java:522) ~[?:?] &
Re: Problem after install pax-trans-tm-narayana with Karaf 4.3.2
Hi Did you try `mvn clean install` latest pax-transx release? regards Grzegorz Grzybek czw., 20 maj 2021 o 17:40 Benjamin Graf napisał(a): > Hi JB, > > I use JDK 11 as runtime environment. There is no code to compile to > reproduce this bug just plain Karaf and pax-trans-tm-narayana from Maven > central. > > Regards > > Benjamin > > On 20.05.2021 10:32, Jean-Baptiste Onofre wrote: > > Hi Ben, > > > > Are you using JDK 11 (for both compile and runtime) ? > > > > Regards > > JB > > > >> Le 20 mai 2021 à 08:17, Benjamin Graf a écrit : > >> > >> Hi, > >> > >> it seems there is a bug with embedded resources. I think it is caused > by Felix and not Karaf itself. > >> > >> How to reproduce: > >> > >> - Clean start of plain Karaf 4.3.2 > >> > >> - feature:install pax-transx-tm-narayana > >> > >> Result: > >> > >> 2021-05-20T08:16:02,787 | WARN | paxtransx-config-1-thread-1 | > pax-transx-tm-narayana | 60 - > org.ops4j.pax.transx.pax-transx-tm-narayana - 0.5.0 | Error starting service > >> java.lang.reflect.InvocationTargetException: null > >> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native > Method) ~[?:?] > >> at > jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > ~[?:?] > >> at > jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > ~[?:?] > >> at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?] > >> at > org.jboss.narayana.osgi.jta.internal.Activator.doStart(Activator.java:49) > ~[?:?] > >> at > org.ops4j.pax.transx.tm.impl.AbstractActivator.run(AbstractActivator.java:115) > ~[?:?] > >> at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) > [?:?] > >> at java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?] > >> at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) > [?:?] > >> at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > [?:?] > >> at java.lang.Thread.run(Thread.java:829) [?:?] > >> Caused by: java.lang.IllegalStateException: Stream handler unavailable > due to: null > >> at > org.apache.felix.framework.URLHandlersStreamHandlerProxy.openConnection(URLHandlersStreamHandlerProxy.java:311) > ~[?:?] > >> at java.net.URL.openConnection(URL.java:1099) ~[?:?] > >> at > jdk.internal.loader.URLClassPath$JarLoader.getJarFile(URLClassPath.java:815) > ~[?:?] > >> at > jdk.internal.loader.URLClassPath$JarLoader$1.run(URLClassPath.java:758) > ~[?:?] > >> at > jdk.internal.loader.URLClassPath$JarLoader$1.run(URLClassPath.java:751) > ~[?:?] > >> at java.security.AccessController.doPrivileged(Native Method) > ~[?:?] > >> at > jdk.internal.loader.URLClassPath$JarLoader.ensureOpen(URLClassPath.java:750) > ~[?:?] > >> at > jdk.internal.loader.URLClassPath$JarLoader.(URLClassPath.java:725) > ~[?:?] > >> at jdk.internal.loader.URLClassPath$3.run(URLClassPath.java:493) > ~[?:?] > >> at jdk.internal.loader.URLClassPath$3.run(URLClassPath.java:476) > ~[?:?] > >> at java.security.AccessController.doPrivileged(Native Method) > ~[?:?] > >> at > jdk.internal.loader.URLClassPath.getLoader(URLClassPath.java:475) ~[?:?] > >> at > jdk.internal.loader.URLClassPath.getLoader(URLClassPath.java:444) ~[?:?] > >> at > jdk.internal.loader.URLClassPath.getResource(URLClassPath.java:313) ~[?:?] > >> at java.net.URLClassLoader$1.run(URLClassLoader.java:455) ~[?:?] > >> at java.net.URLClassLoader$1.run(URLClassLoader.java:452) ~[?:?] > >> at java.security.AccessController.doPrivileged(Native Method) > ~[?:?] > >> at java.net.URLClassLoader.findClass(URLClassLoader.java:451) > ~[?:?] > >> at java.lang.ClassLoader.loadClass(ClassLoader.java:589) ~[?:?] > >> at java.lang.ClassLoader.loadClass(ClassLoader.java:522) ~[?:?] > >> at > org.jboss.narayana.osgi.jta.internal.OsgiServer.doStart(OsgiServer.java:73) > ~[?:?] > >> at > org.jboss.narayana.osgi.jta.internal.OsgiServer.start(OsgiServer.java:66) > ~[?:?] > >> ... 11 more > >> Caused by: java.lang.reflect.InvocationTargetException > >> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native > Method) ~[?:
Re: [PROPOSAL] Create karaf-4.3.x branch and update main to 4.4.0-SNAPSHOT
Hi Just a side note: I know almost nothing about R8 (core+cmpn), still trying to have full R6 (cmpn) Whiteboard implementation in Pax Web ;) Fortunately I see no changes in chapters 102 (HttpService), 128 (Web Applications) and 140 (Whiteboard). However I see that chapter 101 (Log Service) is moved (partially, the log.stream is now in chapter 158 of cmpn) to OSGi core and the version is bumped from 1.4 to 1.5 - looks like we'll need Pax Logging 2.1.x, but I hope I can make it quick as there are only minor changes. regards Grzegorz Grzybek czw., 20 maj 2021 o 13:51 Francois Papon napisał(a): > +1 > > François > fpa...@apache.org > > Le 20/05/2021 à 13:49, Jean-Baptiste Onofre a écrit : > > Hi guys, > > > > In order to prepare R8 support, I would like to create karaf-4.3.x > branch and update main to version 4.4.0-SNAPSHOT, and update to R8 and > corresponding frameworks version (Felix and equinox). > > > > No objection ? > > > > Regards > > JB >
Re: Problem after install pax-trans-tm-narayana with Karaf 4.3.2
Hello Mind that https://github.com/ops4j/org.ops4j.pax.transx/issues/50 was fixed recently, but it was about missing import package. regards Grzegorz Grzybek czw., 20 maj 2021 o 10:32 Jean-Baptiste Onofre napisał(a): > Hi Ben, > > Are you using JDK 11 (for both compile and runtime) ? > > Regards > JB > > > Le 20 mai 2021 à 08:17, Benjamin Graf a écrit : > > > > Hi, > > > > it seems there is a bug with embedded resources. I think it is caused by > Felix and not Karaf itself. > > > > How to reproduce: > > > > - Clean start of plain Karaf 4.3.2 > > > > - feature:install pax-transx-tm-narayana > > > > Result: > > > > 2021-05-20T08:16:02,787 | WARN | paxtransx-config-1-thread-1 | > pax-transx-tm-narayana | 60 - > org.ops4j.pax.transx.pax-transx-tm-narayana - 0.5.0 | Error starting service > > java.lang.reflect.InvocationTargetException: null > > at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native > Method) ~[?:?] > > at > jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > ~[?:?] > > at > jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > ~[?:?] > > at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?] > > at > org.jboss.narayana.osgi.jta.internal.Activator.doStart(Activator.java:49) > ~[?:?] > > at > org.ops4j.pax.transx.tm.impl.AbstractActivator.run(AbstractActivator.java:115) > ~[?:?] > > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) > [?:?] > > at java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?] > > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) > [?:?] > > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > [?:?] > > at java.lang.Thread.run(Thread.java:829) [?:?] > > Caused by: java.lang.IllegalStateException: Stream handler unavailable > due to: null > > at > org.apache.felix.framework.URLHandlersStreamHandlerProxy.openConnection(URLHandlersStreamHandlerProxy.java:311) > ~[?:?] > > at java.net.URL.openConnection(URL.java:1099) ~[?:?] > > at > jdk.internal.loader.URLClassPath$JarLoader.getJarFile(URLClassPath.java:815) > ~[?:?] > > at > jdk.internal.loader.URLClassPath$JarLoader$1.run(URLClassPath.java:758) > ~[?:?] > > at > jdk.internal.loader.URLClassPath$JarLoader$1.run(URLClassPath.java:751) > ~[?:?] > > at java.security.AccessController.doPrivileged(Native Method) ~[?:?] > > at > jdk.internal.loader.URLClassPath$JarLoader.ensureOpen(URLClassPath.java:750) > ~[?:?] > > at > jdk.internal.loader.URLClassPath$JarLoader.(URLClassPath.java:725) > ~[?:?] > > at jdk.internal.loader.URLClassPath$3.run(URLClassPath.java:493) > ~[?:?] > > at jdk.internal.loader.URLClassPath$3.run(URLClassPath.java:476) > ~[?:?] > > at java.security.AccessController.doPrivileged(Native Method) ~[?:?] > > at jdk.internal.loader.URLClassPath.getLoader(URLClassPath.java:475) > ~[?:?] > > at jdk.internal.loader.URLClassPath.getLoader(URLClassPath.java:444) > ~[?:?] > > at > jdk.internal.loader.URLClassPath.getResource(URLClassPath.java:313) ~[?:?] > > at java.net.URLClassLoader$1.run(URLClassLoader.java:455) ~[?:?] > > at java.net.URLClassLoader$1.run(URLClassLoader.java:452) ~[?:?] > > at java.security.AccessController.doPrivileged(Native Method) ~[?:?] > > at java.net.URLClassLoader.findClass(URLClassLoader.java:451) ~[?:?] > > at java.lang.ClassLoader.loadClass(ClassLoader.java:589) ~[?:?] > > at java.lang.ClassLoader.loadClass(ClassLoader.java:522) ~[?:?] > > at > org.jboss.narayana.osgi.jta.internal.OsgiServer.doStart(OsgiServer.java:73) > ~[?:?] > > at > org.jboss.narayana.osgi.jta.internal.OsgiServer.start(OsgiServer.java:66) > ~[?:?] > > ... 11 more > > Caused by: java.lang.reflect.InvocationTargetException > > at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native > Method) ~[?:?] > > at > jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > ~[?:?] > > at > jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > ~[?:?] > > at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?] > > at > org.apache.felix.framework.URLHandlersStreamHandlerProxy.openConnection(URLHandlersStreamHandlerProxy.java:303) > ~[?:?] > >
Re: [PROPOSAL] Disable autoRefresh on features service by default and simple optional features service
śr., 19 maj 2021 o 08:59 Jean-Baptiste Onofre napisał(a): > Yes, both are possible. > > Maybe keeping all in org.apache.karaf.features.core with a configuration > to use a different deploy/approach is better than a complete new features > bundle. > It’s not a problem to me to refactor what I did. > > Thoughts ? > Personally I'm 65% for keeping single features.core + configuration option and 35% for features.simple ;) regards Grzegorz Grzybek > > Regards > JB > > > Le 19 mai 2021 à 08:01, Grzegorz Grzybek a écrit > : > > > > śr., 19 maj 2021 o 07:53 Jean-Baptiste Onofre j...@nanthrax.net>> napisał(a): > > > >> Hi, > >> > >> Actually, it’s a complete separated bundle. > >> > >> So, in the Karaf standard distribution, you will have > >> org.apache.karaf.features.core in etc/startup.properties: that’s the > >> regular/current one with the resolver. > >> > >> Alternatively, you will have another distribution (I have to think about > >> the name), where you will have org.apache.karaf.features.simple in > >> etc/startup.properties: it doesn’t use the resolver, just loading the > >> features model and executing what’s in there. > >> > > > > Another, different, "non-canonical" distribution is fine ;) > > > > > >> > >> Another possible approach is a configuration in > >> etc/org.apache.karaf.features.cfg where we use a different/pluggable > >> deployer. > >> > > > > This can still be done in standard, "canonical" distro, but as > > commented-out configuration option. > > > > regards > > Grzegorz Grzybek > > > > > > > >> > >> Thoughts ? > >> > >> Regards > >> JB > >> > >>> Le 19 mai 2021 à 07:41, Grzegorz Grzybek a > écrit > >> : > >>> > >>> Hello > >>> > >>> śr., 19 maj 2021 o 07:35 Jean-Baptiste Onofre > >> napisał(a): > >>> > >>>> Hi, > >>>> > >>>> Regarding recent comments from users and lot of refresh > issues/questions > >>>> we have in the past, I moved forward with a new simple features > service > >>>> that doesn’t use the resolver. It basically reads the features repo > >>>> definition and just install what’s define in there statically. > >>>> > >>>> I will prepare a distribution using it by default. > >>>> > >>> > >>> Will it be configurable? I know about refresh problems - but the > resolver > >>> did a good job showing you what's wrong with the set of > features/bundles > >>> you're installing. > >>> Do you plan to switch to resolverless features service in micro release > >> of > >>> Karaf? Or will it be Karaf 4.4 / 5? > >>> > >>> regards > >>> Grzegorz Grzybek > >>> > >>> > >>>> > >>>> I will share some details soon. > >>>> > >>>> Regards > >>>> JB > >>>> > >>>>> Le 12 janv. 2021 à 06:07, Jean-Baptiste Onofre a > >>>> écrit : > >>>>> > >>>>> Hi, > >>>>> > >>>>> It doesn’t really break, it just don’t use it. > >>>>> > >>>>> It’s up to you to install all feature/bundle requirements. > >>>>> > >>>>> Regards > >>>>> JB > >>>>> > >>>>>> Le 11 janv. 2021 à 21:09, Markus Rathgeb a > >> écrit > >>>> : > >>>>>> > >>>>>> Hi, > >>>>>> > >>>>>>> - ignore requirement/capability (no resolver) > >>>>>> > >>>>>> did I get it right that this breaks the dependency=true feature that > >>>>>> installs bundles / features only if a requirement is not fullfilled > >> yet? > >>>>>> > >>>>>> Am Fr., 8. Jan. 2021 um 15:01 Uhr schrieb Patrique Legault < > >>>>>> patriquelega...@gmail.com>: > >>>>>> > >>>>>>> Same here, > >>>>>>> > >>>>>>> This is behaviour that has been expected for some time now, > reversing > >>>> it > >>>>>>> could cause damage to syste
Re: [PROPOSAL] Disable autoRefresh on features service by default and simple optional features service
śr., 19 maj 2021 o 07:53 Jean-Baptiste Onofre napisał(a): > Hi, > > Actually, it’s a complete separated bundle. > > So, in the Karaf standard distribution, you will have > org.apache.karaf.features.core in etc/startup.properties: that’s the > regular/current one with the resolver. > > Alternatively, you will have another distribution (I have to think about > the name), where you will have org.apache.karaf.features.simple in > etc/startup.properties: it doesn’t use the resolver, just loading the > features model and executing what’s in there. > Another, different, "non-canonical" distribution is fine ;) > > Another possible approach is a configuration in > etc/org.apache.karaf.features.cfg where we use a different/pluggable > deployer. > This can still be done in standard, "canonical" distro, but as commented-out configuration option. regards Grzegorz Grzybek > > Thoughts ? > > Regards > JB > > > Le 19 mai 2021 à 07:41, Grzegorz Grzybek a écrit > : > > > > Hello > > > > śr., 19 maj 2021 o 07:35 Jean-Baptiste Onofre > napisał(a): > > > >> Hi, > >> > >> Regarding recent comments from users and lot of refresh issues/questions > >> we have in the past, I moved forward with a new simple features service > >> that doesn’t use the resolver. It basically reads the features repo > >> definition and just install what’s define in there statically. > >> > >> I will prepare a distribution using it by default. > >> > > > > Will it be configurable? I know about refresh problems - but the resolver > > did a good job showing you what's wrong with the set of features/bundles > > you're installing. > > Do you plan to switch to resolverless features service in micro release > of > > Karaf? Or will it be Karaf 4.4 / 5? > > > > regards > > Grzegorz Grzybek > > > > > >> > >> I will share some details soon. > >> > >> Regards > >> JB > >> > >>> Le 12 janv. 2021 à 06:07, Jean-Baptiste Onofre a > >> écrit : > >>> > >>> Hi, > >>> > >>> It doesn’t really break, it just don’t use it. > >>> > >>> It’s up to you to install all feature/bundle requirements. > >>> > >>> Regards > >>> JB > >>> > >>>> Le 11 janv. 2021 à 21:09, Markus Rathgeb a > écrit > >> : > >>>> > >>>> Hi, > >>>> > >>>>> - ignore requirement/capability (no resolver) > >>>> > >>>> did I get it right that this breaks the dependency=true feature that > >>>> installs bundles / features only if a requirement is not fullfilled > yet? > >>>> > >>>> Am Fr., 8. Jan. 2021 um 15:01 Uhr schrieb Patrique Legault < > >>>> patriquelega...@gmail.com>: > >>>> > >>>>> Same here, > >>>>> > >>>>> This is behaviour that has been expected for some time now, reversing > >> it > >>>>> could cause damage to systems that upgrade to the latest Karaf. I > would > >>>>> make it something that users opt into vs having to opt-out of. > >>>>> > >>>>> On Fri, 8 Jan 2021 at 08:42, Daniel Las >> .invalid> > >>>>> wrote: > >>>>> > >>>>>> Hi, > >>>>>> > >>>>>> It looks like some kind of backward incompatible change introduced > >> within > >>>>>> patch version change. I personally would like to keep auto refresh > >> "on" > >>>>> by > >>>>>> default as this is expected/desired behavior for me. > >>>>>> > >>>>>> Regards > >>>>>> > >>>>>> pt., 8 sty 2021 o 07:31 Jean-Baptiste Onofre > >>>>> napisał(a): > >>>>>> > >>>>>>> Hi everyone, > >>>>>>> > >>>>>>> We got several user feedback, complaining about unexpected and > >> cascaded > >>>>>>> (unrelated) refresh while installing features. > >>>>>>> > >>>>>>> As reminder, a refresh can happen when: > >>>>>>> - bundle A imports package foo:1 and a bundle provides newer foo > >>>>> package > >>>>>>> version. In that ca
Re: [PROPOSAL] Disable autoRefresh on features service by default and simple optional features service
Hello śr., 19 maj 2021 o 07:35 Jean-Baptiste Onofre napisał(a): > Hi, > > Regarding recent comments from users and lot of refresh issues/questions > we have in the past, I moved forward with a new simple features service > that doesn’t use the resolver. It basically reads the features repo > definition and just install what’s define in there statically. > > I will prepare a distribution using it by default. > Will it be configurable? I know about refresh problems - but the resolver did a good job showing you what's wrong with the set of features/bundles you're installing. Do you plan to switch to resolverless features service in micro release of Karaf? Or will it be Karaf 4.4 / 5? regards Grzegorz Grzybek > > I will share some details soon. > > Regards > JB > > > Le 12 janv. 2021 à 06:07, Jean-Baptiste Onofre a > écrit : > > > > Hi, > > > > It doesn’t really break, it just don’t use it. > > > > It’s up to you to install all feature/bundle requirements. > > > > Regards > > JB > > > >> Le 11 janv. 2021 à 21:09, Markus Rathgeb a écrit > : > >> > >> Hi, > >> > >>> - ignore requirement/capability (no resolver) > >> > >> did I get it right that this breaks the dependency=true feature that > >> installs bundles / features only if a requirement is not fullfilled yet? > >> > >> Am Fr., 8. Jan. 2021 um 15:01 Uhr schrieb Patrique Legault < > >> patriquelega...@gmail.com>: > >> > >>> Same here, > >>> > >>> This is behaviour that has been expected for some time now, reversing > it > >>> could cause damage to systems that upgrade to the latest Karaf. I would > >>> make it something that users opt into vs having to opt-out of. > >>> > >>> On Fri, 8 Jan 2021 at 08:42, Daniel Las .invalid> > >>> wrote: > >>> > >>>> Hi, > >>>> > >>>> It looks like some kind of backward incompatible change introduced > within > >>>> patch version change. I personally would like to keep auto refresh > "on" > >>> by > >>>> default as this is expected/desired behavior for me. > >>>> > >>>> Regards > >>>> > >>>> pt., 8 sty 2021 o 07:31 Jean-Baptiste Onofre > >>> napisał(a): > >>>> > >>>>> Hi everyone, > >>>>> > >>>>> We got several user feedback, complaining about unexpected and > cascaded > >>>>> (unrelated) refresh while installing features. > >>>>> > >>>>> As reminder, a refresh can happen when: > >>>>> - bundle A imports package foo:1 and a bundle provides newer foo > >>> package > >>>>> version. In that case, the features service will refresh A to use the > >>>>> newest package version. > >>>>> - bundle A has an optional import to package foo and a bundle > provides > >>>>> this package. In that case, the features service will refresh A to > >>>> actually > >>>>> use the import as it’s a "resolved" optional. > >>>>> - bundle A is wired to bundle B (from a package perspective or > >>>>> requirement) and B is refreshed. In that case, the features service > >>> will > >>>>> refresh A as B is itself refreshed (for the previous reasons for > >>>> instance). > >>>>> This can cause "cascading" refresh. > >>>>> > >>>>> A refresh means that a bundle can be restarted (if the bundle > contains > >>> an > >>>>> activator or similar (DS component, blueprint bundle)). > >>>>> > >>>>> In this PR https://github.com/apache/karaf/pull/1287, I propose to > >>>>> introduce a new property autoRefresh in > >>> etc/org.apache.karaf.features.cfg > >>>>> to disable the auto refresh by the features service (and let the user > >>>>> decides when he wants to trigger refresh with bundle:refresh command > >>> for > >>>>> instance). > >>>>> I propose to keep autoRefresh=true on 4.2.x and turn > autoRefresh=false > >>> on > >>>>> 4.3.x. > >>>>> > >>>>> Thoughts ? > >>>>> > >>>>> On the other hand (and to prepare the "path" to Karaf5
Re: [VOTE] Apache Karaf runtime 4.3.2 release
+1 regards Grzegorz Grzybek pon., 10 maj 2021 o 18:14 Steinar Bang napisał(a): > >>>>> Jean-Baptiste Onofre : > > > Can you describe your test case ? > > 1. Download the tar.gz of the binary build > 2. Unpack into /tmp/apache-karaf-4.3.2/ > 3. Do "cd /tmp/apache-karaf-4.3.2/" > 4. Start karaf with "bin/karaf debug" > 5. From the karaf console add my own maven repo: > config:edit org.ops4j.pax.url.mvn > config:property-append org.ops4j.pax.url.mvn.repositories ", > https://maven.bang.priv.no/repository/@id=ukelonn@snapshots; > config:property-set org.ops4j.pax.url.mvn.globalUpdatePolicy always > config:update > 6. Also from the karaf console, add the 4.3.2 staging maven repo (so > that karaf can provison stuff using maven): > config:edit org.ops4j.pax.url.mvn > config:property-append org.ops4j.pax.url.mvn.repositories ", > https://repository.apache.org/content/repositories/orgapachekaraf-1156/@id=karaf@staging > " > config:update > 7. Load myapps > feature:repo-add mvn:no.priv.bang.myapps/myapps/LATEST/xml/features > feature:install myapps > 8. Note: at this point command history work: I can do ctrl-p and see > the previous commands > 9. Stop karaf, edit jdbc urls and credentials in some of the > org.ops4j.datasource-*.cfg files > 10. Start karaf again and do "Ctrl-p" (because the arrow keys on my > laptop don't work so well) and there is no command history > > So the failure start at point 10, ie. from the console after stopping > and starting karaf. > > And this is something I do a lot with tarball karaf releases, and I've > never seen the command history go away before. > > Note: if you would like the applications to actually run, you would need > a PostgreSQL server running on the same host as karaf is running, with > blank databases > - authservice > - ukelonn > - handlereg > - sonar-collector > - oldalbum > all owned by PosgreSQL user "karaf" with password "karaf" (or stop and > edit the org.ops4j.datasource-*.cfg files to change databases names, > location or credentiials, like in 9. above) > > (but I don't think working apps is necessary for testing the command > history issue) > >
[ANN] Pax Transx 0.5.1 released
Hello I'd like to announce the minor release of Pax Transx project with a fix allowing to run pax-transx-tm-narayana on JDK11. The changelog is here: https://github.com/ops4j/org.ops4j.pax.transx/milestone/7?closed=1 kind regards Grzegorz Grzybek
[ANN] Pax JDBC 1.5.1 released
Hello I'd like to announce the minor release of Pax JDBC projec with a fix to how Oracle And HSQLDB drivers are handled. The changelog is here: https://github.com/ops4j/org.ops4j.pax.jdbc/milestone/27?closed=1 kind regards Grzegorz Grzybek
Re: [VOTE] Apache Karaf runtime 4.3.1 release
+1 regards Grzegorz Grzybek wt., 30 mar 2021 o 21:32 Matt Pavlovich napisał(a): > +1 > > - Downloaded and started unix dist release (no errors, no ‘online’ > artifacts required) > - Added dist repo as a mvn repo > - Installed a few karaf features successfully (scr, etc) > > Matt Pavlovich > > > On Mar 29, 2021, at 8:14 AM, Jean-Baptiste Onofre > wrote: > > > > Hi everyone, > > > > I submit Apache Karaf runtime 4.3.1 to your vote. > > > > This release includes bunch of dependency upgrades, fixes, and > improvements, especially: > > > > - java.* now exported by system packages (as expected since R7) > > - fixed on configuration with json format > > - jetty alias feature for backward compatibility > > - resolver parallelism default value fixed (to run on Kubernetes by > default) > > - fix on SSH, log commands > > - improvement on the JMX layer (especially JMXMP) > > - env/prop interpolation support on the SSH client > > - add property to disable auto refresh in features service > > - and much more ! > > > > Please take a look on Release Notes for details ! > > > > Release Notes: > > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12348818 > < > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12348818 > > > > > > Staging Repository: > > https://repository.apache.org/content/repositories/orgapachekaraf-1155/ > <https://repository.apache.org/content/repositories/orgapachekaraf-1155/> > > > > Staging Dist: > > https://dist.apache.org/repos/dist/dev/karaf/4.3.1/ < > https://dist.apache.org/repos/dist/dev/karaf/4.3.1/> > > > > Git tag: > > karaf-4.3.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: [INFO] Apache Karaf 5 will be internally based on OSGi R8
Quoting one statement of yours: So for long running apps graal cost is wayy more than the runtime gain > and I guess it is where Karaf 5 will sit, long running aggregated and > unified apps (by providing a single admin interface for all kind of apps > and not a different one for spring/spring-boot, microprofile, ee, osgi > etc). > I agree. I still believe in "Java applications servers" (whatever the set of standards - real or de-facto - is used). And I still believe in long-running apps. regards Grzegorz Grzybek czw., 25 mar 2021 o 10:33 Romain Manni-Bucau napisał(a): > Le jeu. 25 mars 2021 à 09:35, Grzegorz Grzybek a > écrit : > > > Thanks Romain for the details! (see inline) > > > > czw., 25 mar 2021 o 08:31 Romain Manni-Bucau > > napisał(a): > > > > > Le jeu. 25 mars 2021 à 07:13, Grzegorz Grzybek > a > > > écrit : > > > > > > > Good morning! > > > > > > > > śr., 24 mar 2021 o 19:57 Romain Manni-Bucau > > > > napisał(a): > > > > > > > > > in terms of arch yes, the key feature is to have a tree classloader > > and > > > > not > > > > > a graph (drops all the build complexity of OSGi and enable scanning > > > > > pluggability, yeah). > > > > > > > > > > > > > Graph → Tree sounds like OSGi → JavaEE... > > > > This can prevent user feature to install a bundle that overrides > system > > > > services I know that (without "134 Subsystem Service > Specification" > > > and > > > > without hooks) effectively OSGi runtime is "flat" - every bundle wire > > is > > > > equal and resolution rules apply. Also every OSGi service is equal > and > > > > service rank is taken into account. > > > > > > > > > > Yes and no, a service registration can still use @Priority or a SPI > > method > > > to be sorted, only thing it can prevent is to put conflicting deps in > the > > > same bootstrap classloader (that said these days OSGi is rarely used > for > > > that and since by design the bootstrap loader will be a single app - ie > > > without any conflict at build time - it is actually sane). > > > > > > > In JavaEE, a WAR can (mostly) configure some providers, so e.g., > > DocumentBuilderFactory may return WAR-specific instance. But it's not > > possible to affect this service loading in other WARs. > > In OSGi, a bundle can register some service that'll become the valid > > service for remaining bundles. > > So I understand that Karaf 5 keeps the OSGi philosophy here, right? > > > > Yes and not, the small language trick is do you speak of bootstrap services > or profile or app in Karaf 5. > Bootstrap services can do whatever they want (ie same as OSGi in terms of > impact even if technicaly it is not linked) but all other layers > (profile+app) must stay static and almost immutable. > > > > > > > > > > > > > > > > > > > > I'm trying to imagine how "it’s powered by OSGi R8 (but you will see > > that > > > > it’s more an internal point)" works - is the "Level1: Karaf itself" a > > > > graph-based layer of bundle classloaders, while applications are > given > > > > their own single classloader (kind of like WebSphere is (was?) based > on > > > > OSGi and WARs/EARs hand single classloader or like Wildfly/EAP that's > > > > internally a graph of JBoss Modules, while WARs/EARs have single > > > > classloader)? > > > > > > > > java.util.ServiceLoader is dynamic in nature and is a final (IMO) and > > > quite > > > > elegant discovery solution in tree-(ClassLoader)-based monoliths > where > > > you > > > > "deploy" applications. And it's reflection based. > > > > > > > > > > Last point does not have to be true, see some graalvm integrations for > > > example, it is reflection less depends how you handle the build phase > but > > > being reflection "full" by default enables to keep the tooling > (testing) > > > working without breaking your IDE. > > > > > > > Mind that I'm not very experienced with Graal/Quarkus, so my questions > may > > be invalid ;) > > > > I was expecting it to come at some point - and btw we can note the fun > thing that the big change is GraalVM but everybody speaks of Quarkus which > is just a rebranding of already existing thing
Re: [INFO] Apache Karaf 5 will be internally based on OSGi R8
Thanks Romain for the details! (see inline)
czw., 25 mar 2021 o 08:31 Romain Manni-Bucau
napisał(a):
> Le jeu. 25 mars 2021 à 07:13, Grzegorz Grzybek a
> écrit :
>
> > Good morning!
> >
> > śr., 24 mar 2021 o 19:57 Romain Manni-Bucau
> > napisał(a):
> >
> > > in terms of arch yes, the key feature is to have a tree classloader and
> > not
> > > a graph (drops all the build complexity of OSGi and enable scanning
> > > pluggability, yeah).
> > >
> >
> > Graph → Tree sounds like OSGi → JavaEE...
> > This can prevent user feature to install a bundle that overrides system
> > services I know that (without "134 Subsystem Service Specification"
> and
> > without hooks) effectively OSGi runtime is "flat" - every bundle wire is
> > equal and resolution rules apply. Also every OSGi service is equal and
> > service rank is taken into account.
> >
>
> Yes and no, a service registration can still use @Priority or a SPI method
> to be sorted, only thing it can prevent is to put conflicting deps in the
> same bootstrap classloader (that said these days OSGi is rarely used for
> that and since by design the bootstrap loader will be a single app - ie
> without any conflict at build time - it is actually sane).
>
In JavaEE, a WAR can (mostly) configure some providers, so e.g.,
DocumentBuilderFactory may return WAR-specific instance. But it's not
possible to affect this service loading in other WARs.
In OSGi, a bundle can register some service that'll become the valid
service for remaining bundles.
So I understand that Karaf 5 keeps the OSGi philosophy here, right?
>
>
> >
> > I'm trying to imagine how "it’s powered by OSGi R8 (but you will see that
> > it’s more an internal point)" works - is the "Level1: Karaf itself" a
> > graph-based layer of bundle classloaders, while applications are given
> > their own single classloader (kind of like WebSphere is (was?) based on
> > OSGi and WARs/EARs hand single classloader or like Wildfly/EAP that's
> > internally a graph of JBoss Modules, while WARs/EARs have single
> > classloader)?
> >
> > java.util.ServiceLoader is dynamic in nature and is a final (IMO) and
> quite
> > elegant discovery solution in tree-(ClassLoader)-based monoliths where
> you
> > "deploy" applications. And it's reflection based.
> >
>
> Last point does not have to be true, see some graalvm integrations for
> example, it is reflection less depends how you handle the build phase but
> being reflection "full" by default enables to keep the tooling (testing)
> working without breaking your IDE.
>
Mind that I'm not very experienced with Graal/Quarkus, so my questions may
be invalid ;)
>
>
> > How about graal/quarkus?
> > Let me be clear here - quarkus/graal/native approach is cool and makes
> Java
> > great again™, but I know that "enteprise" still likes the idea of
> > "application servers", so I hope Karaf5 is NOT going to be
> > "Kubernetes/OpenShift first" - long running processes with reflection and
> > dynamic classloading are still relevant.
> >
>
> Can you precise it there? Quarkus has two modes: JVM (where it is
> equivalent to most microprofile servers without the standard/spec support)
> and native mode (where arthur does the same closer to graalvm).
> First mode does not need much but last one does not concern karaf 5 AFAIK
> since spring-boot has its own graal integration, microprofile servers too
> (potentially EE ones too even if I didnt see one yet) and OSGi has its own
> through winegroewer so overall Karaf 5 sounds like the aggregator platform
> which would fallback on dropping it to be graal compliant (since you'll
> drop classloaders which makes all the power of the solution.
>
I imagine that Quarkus/Graal is designed mostly to develop apps that can
quickly start/stop and "application servers" is not the most desired goal
here.
And I was thinking about the native mode, where everything is mostly set up
at build time.
>
>
> >
> >
> > > In terms of service since the launcher is a monolith it has the key
> > > advantage to be able to scan all then dispatch so I guess we can just
> > have
> > > a ServiceLoader kind of SPI for "module service" impls and order them
> as
> > > needed. a ModuleService { setModuleServiceRegistry(Registry); } would
> > then
> > > do the trick probably, no need of fancy IoC for such low level
> framework
> > > IMHO.
> > >
> >
> > So clear distinguishing between "applications" an
Re: [INFO] Apache Karaf 5 will be internally based on OSGi R8
Good morning!
śr., 24 mar 2021 o 19:57 Romain Manni-Bucau
napisał(a):
> in terms of arch yes, the key feature is to have a tree classloader and not
> a graph (drops all the build complexity of OSGi and enable scanning
> pluggability, yeah).
>
Graph → Tree sounds like OSGi → JavaEE...
This can prevent user feature to install a bundle that overrides system
services I know that (without "134 Subsystem Service Specification" and
without hooks) effectively OSGi runtime is "flat" - every bundle wire is
equal and resolution rules apply. Also every OSGi service is equal and
service rank is taken into account.
I'm trying to imagine how "it’s powered by OSGi R8 (but you will see that
it’s more an internal point)" works - is the "Level1: Karaf itself" a
graph-based layer of bundle classloaders, while applications are given
their own single classloader (kind of like WebSphere is (was?) based on
OSGi and WARs/EARs hand single classloader or like Wildfly/EAP that's
internally a graph of JBoss Modules, while WARs/EARs have single
classloader)?
java.util.ServiceLoader is dynamic in nature and is a final (IMO) and quite
elegant discovery solution in tree-(ClassLoader)-based monoliths where you
"deploy" applications. And it's reflection based.
How about graal/quarkus?
Let me be clear here - quarkus/graal/native approach is cool and makes Java
great again™, but I know that "enteprise" still likes the idea of
"application servers", so I hope Karaf5 is NOT going to be
"Kubernetes/OpenShift first" - long running processes with reflection and
dynamic classloading are still relevant.
> In terms of service since the launcher is a monolith it has the key
> advantage to be able to scan all then dispatch so I guess we can just have
> a ServiceLoader kind of SPI for "module service" impls and order them as
> needed. a ModuleService { setModuleServiceRegistry(Registry); } would then
> do the trick probably, no need of fancy IoC for such low level framework
> IMHO.
>
So clear distinguishing between "applications" and "server plugins" (with
e.g., replaceable Jackson as JSON provider) - am I interpreting your
statements correctly Romain?
regards
Grzegorz Grzybek
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> | Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le mer. 24 mars 2021 à 19:13, Jean-Baptiste Onofre a
> écrit :
>
> > Hi Romain,
> >
> > About OSGi, the way I did it (up to now), it’s as you describe:
> >
> > - Karaf "launcher"
> > — Libraries service
> > — Profiles service
> > — SpringBootModuleService
> > — OsgiModuleService
> > — MicroprofileModuleService (not yet started)
> >
> > The framework is only started when the first OSGi module is deployed.
> >
> > If the user deploys only SpringBoot apps in Karaf, he won’t have any OSGi
> > framework.
> >
> > Is it what you expected ?
> >
> > On Karaf "launcher", we have services available (for now just using
> > karaf.getService("id")).
> >
> > I would love your feedback here. Thoughts ?
> >
> > Regards
> > JB
> >
> > > Le 24 mars 2021 à 19:03, Romain Manni-Bucau a
> > écrit :
> > >
> > > Le mer. 24 mars 2021 à 17:35, Jean-Baptiste Onofre a
> > > écrit :
> > >
> > >> Actually, spec like as DocuentBuilder would be rather a library,
> shared
> > by
> > >> all launchers.
> > >>
> > >
> > > Ok but what about jackson? the same?
> > >
> > > Joke apart what if spring-boot-app1 uses one impl and spring-boot-app2
> > uses
> > > another one?
> > >
> > > Think at the end there is the JVM, the framework stack which is
> isolated
> > > from the app and the apps or it does not move the ball very far from
> what
> > > we have today.
> > >
> > > Until there is it is EE server - in terms of architecture not
> scope/impl.
> > > But the gold of this solution is the ability to configure the leakage
> > > between layers/profiles to let an app override and potentially
> > > aggregate/share parts. Obvious example is the http service which can
> leak
> > > in spring boot app to override the servlet layer enabling to admistrate
> > it
> > > globally. Anothe
Re: [INFO] Apache Karaf 5 will be internally based on OSGi R8
Hello
OSGi Core R8 still assumes req/cap model[1] and resolution:
The Framework must resolve bundles.
>
If OSGi (and thus resolution) is _internal_, what kind of "classpath"
("module path"?) will users see? Looking forward for 1-feet overview of
Karaf 5 ;)
Is Connect specification[2] the inherent part of Karaf5? Is "classpath"
generally flat, hierarchical or irrelevant (?) by default?
Anyway - the future looks bright ;)
regards
Grzegorz Grzybek
===
[1]:
https://docs.osgi.org/specification/osgi.core/8.0.0/framework.module.html#framework.module-resolving
[2]:
https://docs.osgi.org/specification/osgi.core/8.0.0/framework.connect.html
śr., 24 mar 2021 o 15:24 Jean-Baptiste Onofre napisał(a):
> Hi guys,
>
> As you probably know, we are working on first Karaf 5 MVP, which is a
> complete Karaf refactoring.
>
> We will share some details soon, but I can already inform you that
> internally, it’s powered by OSGi R8 (but you will see that it’s more an
> internal point).
>
> Regards
> JB
Re: [VOTE] Apache Karaf runtime 4.2.11 release
+1 I checked with Fuse-Karaf and everything works regards Grzegorz Grzybek wt., 9 mar 2021 o 12:56 Jean-Baptiste Onofre napisał(a): > Hi everyone, > > I submit Apache Karaf runtime 4.2.11 to your vote. > > This release includes bunch of dependency upgrades, fixes, and > improvements, especially: > > - fix on SSH stream > - fix on log:* commands > - improvement on the JMX layer (especially JMXMP) > - env/prop interpolation support on the SSH client > - add property to disable auto refresh in features service > - stronger JAAS encryption algorithms support > - updated Spring versions > - and much more ! > > Please take a look on Release Notes for details ! > > Release Notes: > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12348692 > > Staging Repository: > https://repository.apache.org/content/repositories/orgapachekaraf-1154/ > > Staging Dist: > https://dist.apache.org/repos/dist/dev/karaf/4.2.11/ > > Git tag: > karaf-4.2.11 > > Please vote to approve this release: > > [ ] +1 Approve the release > [ ] -1 Don't approve the release (please provide specific comments) > > This vote will be open for at least 72 hours. > > Regards > JB
Re: [VOTE] Apache Karaf runtime 4.2.11 release
Hello wt., 9 mar 2021 o 23:27 Robert Varga napisał(a): > On 09/03/2021 12:56, Jean-Baptiste Onofre wrote: > > Hi everyone, > > > > I submit Apache Karaf runtime 4.2.11 to your vote. > > [snip] > > I ran smoke tests with odlparent-7.0.x. > > There are two new misalignments between karaf-4.2.11 and pax-web-7.2.23: > - javax.interceptor-api/1.2.2 vs 1.2 > - org.apache.servicemix.bundles.javax-inject/1_3 vs 1_2 > Yes, sorry for this inconvenience. I had to bump these two after test failures related to new Pax Jdbc + Transx + JMS... Remember, it can always be solved with (etc/org.apache.karaf.features.xml): http://karaf.apache.org/xmlns/features-processing/v1.0.0;> ... ... regards Grzegorz Grzybek > > I found nothing obviously wrong and we can monkey-patch this > inconsistency downstream. > > +1, non-binding. > > Regards, > Robert > >
Re: Board report March '21
Hello Thanks for the report - Looks good! regards Grzegorz Grzybek pt., 5 mar 2021 o 14:11 Achim Nierbeck napisał(a): > Hi JB, > > Thanks for taking care of this. Looks good to me. > > regards, Achim > > Am Fr., 5. März 2021 um 08:55 Uhr schrieb Jean-Baptiste Onofre < > j...@nanthrax.net>: > > > Hi guys, > > > > I prepared the Karaf board report for this month: > > > > https://cwiki.apache.org/confluence/display/KARAF/Board+Reports < > > https://cwiki.apache.org/confluence/display/KARAF/Board+Reports> > > > > Can you please take a look and let me know if I forgot something or if > you > > wanna make some updates ? > > > > I would like to subit the report tomorrow (or tonight if there’s no > > changes to perform). > > > > Thanks, > > Regards > > JB > > > > -- > > 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> >
OPS4J projects migration from OPS4J (cloud) Jira to GitHub issues
Hello I'm proud to announce that I've just finished the migration of OPS4J Jira issues to GitHub. We were discussing this ~half a year ago. For each Jira issue I've migrated: - description and comments preserving html (converted to markdown), creation dates and authors (although not pointing to GH users, which is obvious) - Jira statuses, issue types, components and labels as GitHub labels - Jira fix versions as GitHub milestones with due date and closed status - Images - Attachments - Jira inter-project references as real GitHub references - cross project! (i.e., PAXWEB issues referencing PAXLOGGING issues are changed to working GitHub issue references between org.ops4j.pax.web to org.ops4j.pax.logging projects) These projects were fully migrated: - TOOLS = ops4j/org.ops4j.tools - PAXJMS = ops4j/org.ops4j.pax.jms - PAXTRANSX = ops4j/org.ops4j.pax.transx - PAXJDBC = ops4j/org.ops4j.pax.jdbc - PAXTIPI = ops4j/org.ops4j.pax.tipi - PAXLOGGING = ops4j/org.ops4j.pax.logging - PAXEXAM = ops4j/org.ops4j.pax.exam2 - PAXURL = ops4j/org.ops4j.pax.url - PAXTB = ops4j/org.ops4j.pax.tinybundles - BASE = ops4j/org.ops4j.base - PAXSB = ops4j/org.ops4j.pax.swissbox - PAXCDI = ops4j/org.ops4j.pax.cdi - PAXRUNNER = ops4j/org.ops4j.pax.runner - PAXSCANNER = ops4j/org.ops4j.pax.scanner - PAXCONSTRUCT = ops4j/org.ops4j.pax.construct - PAXSHIRO = ops4j/org.ops4j.pax.shiro - PAXWEB = ops4j/org.ops4j.pax.web These GitHub projects have not their issues migrated from Jira to GitHub (usually they're inactive, or I simply didn't work on them before), though if you like, I may migrate them: - ops4j/exam-eclipse - ops4j/git-helpers - ops4j/ops4j.github.io - ops4j/ops4j-infra - ops4j/org.ops4j.dadl - ops4j/org.ops4j.mpjp - ops4j/org.ops4j.orient - ops4j/org.ops4j.pax.ace-maven-plugin - ops4j/org.ops4j.pax.carrot - ops4j/org.ops4j.pax.clapper - ops4j/org.ops4j.pax.confman - ops4j/org.ops4j.pax.exam1 - ops4j/org.ops4j.pax.jmx - ops4j/org.ops4j.pax.jpa - ops4j/org.ops4j.pax.monitoradmin - ops4j/org.ops4j.pax.remote - ops4j/org.ops4j.pax.useradmin - ops4j/org.ops4j.pax.vaadin - ops4j/org.ops4j.pax.warp - ops4j/org.ops4j.pax.wicket - ops4j/org.ops4j.ramler - ops4j/org.ops4j.resources - ops4j/org.ops4j.xvisitor - ops4j/pax-repository - ops4j/peaberry Kind regards and I invite you to contribute to OPS4J projects at GitHub ;) Grzegorz Grzybek
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, Pax JMS and Pax JDBC. This is a simultaneous release with mutual version alignment and certain amount of refreshment. This is also a first release of these projects after their issues were migrated from OPS4J Jira to GitHub issues. The relevant changelogs are here: - Pax Transx: https://github.com/ops4j/org.ops4j.pax.transx/milestone/4?closed=1 - Pax JMS: https://github.com/ops4j/org.ops4j.pax.jms/milestone/8?closed=1 - Pax JDBC: https://github.com/ops4j/org.ops4j.pax.jdbc/milestone/26?closed=1 The notable changes are: *Pax Transx:* - Atomikos TM upgraded to 5.0.x - Narayana TM upgraded to 5.10.x *Pax JMS:* - Added integration tests based on Artemis *Pax JDBC:* - MS SQL Karaf feature uses official MS SQL JDBC driver and no special DataSourceFactory, as the official driver supports OSGi CMPN JDBC specification - Oracle feature uses official Oracle driver available from Maven Central - Commons DBCP 2 upgraded to 2.8.0 - I added instructions about running external libraries using docker/podman (includes Oracle, MS SQL Server and DB2) kind regards Grzegorz Grzybek
Re: Migration of OPS4J projects from Jira to Github
Hello After a little problem, where my "ops4j-issues" Github account was suspended, I finally got an answer from Github Support and the account was verified. I've fully finished the migration of PAXJMS project - completing the migration with issue references. As with Spring projects, I've simply added an separated section in the body of the issue, which looks like this: **Referenced issues** **relates to:** * ops4j/org.ops4j.pax.jdbc#104 - NPE on oracle thin client with TNS key-value syntax in jdbc url [PAXJDBC-147] Within given project, the link is just e.g., "#104", but I've added some checks that allow me to cross reference between already migrated projects. See an example of an issue with links: https://github.com/ops4j/org.ops4j.pax.jms/issues/48 kind regards Grzegorz Grzybek wt., 9 lut 2021 o 15:51 Matt Pavlovich napisał(a): > Grzegorz- > > Nice work! I think having the projects on GitHub will reduce efforts of > the core contributors and will make it more accessible for new contributors > as well. > > -Matt Pavlovich > > > On Feb 9, 2021, at 7:44 AM, Grzegorz Grzybek > wrote: > > > > Hello > > > > Thanks to Jürgen Schmid, I was able to set up "ops4j-issues" GitHub > account > > with my current gmail address. I'll continue (if there are no objections) > > with the migration using this account. > > > > kind regards > > Grzegorz Grzybek > > > > wt., 9 lut 2021 o 12:51 Grzegorz Grzybek > napisał(a): > > > >> Hello > >> > >> I'd like to let you know that I've migrated these projects from OPS4J > Jira > >> to Github: > >> - PAX TRANSX: > >> > https://github.com/ops4j/org.ops4j.pax.transx/issues?q=is%3Aissue+is%3Aall > >> - PAX JMS: > >> https://github.com/ops4j/org.ops4j.pax.jms/issues?q=is%3Aissue+is%3Aall > >> - PAX JDBC: > >> > https://github.com/ops4j/org.ops4j.pax.jdbc/issues?q=is%3Aissue+is%3Aall > >> > >> These issues are taken into account: > >> - Jira components, statuses, resolutions, issue types and labels are > >> converted to Github labels > >> - Jira versions are converted to Github milestones > >> - The Jira fields that couldn't be mapped, are added below "---" line in > >> the body of the GitHub issue (like vote/watch count, affected versions, > >> fixed versions and attachments) > >> - Attachment links still point to Jira, but inline images are properly > >> displayed > >> - Jira issues received "famous last comments" pointing to relevant > Github > >> issues > >> - Jira screen schemes were migrated to a scheme, were you can't create > >> new issue > >> - HTML is converted to GitHub flavored markdown > >> - all @xxx values (like @Service or @param) occurrences are properly > >> quoted in backticks to prevent unnecessary GitHub mentions > >> > >> One remaining thing to do, which is almost ready is the conversion of > Jira > >> issue references to GitHub issue references - but I want to do proper > cross > >> references between Pax projects at GitHub - not only within single > project. > >> > >> I was inspired by > >> > https://spring.io/blog/2019/01/15/spring-framework-s-migration-from-jira-to-github-issues > >> blog post which made me aware of few things. > >> > >> *The biggest problem I see is that all the comments and all the issues > are > >> created by me... Even if the creation dates are preserved, I simply > can't > >> (and don't want to) get proper Jira - GitHub user mapping.* > >> > >> In case of Spring migration, they created special GitHub user, but I > can't > >> create another one using my gmail address. And I don't want to create > weird > >> fake addresses. > >> > >> You can check quite raw tools at > >> > https://github.com/ops4j/org.ops4j.tools/blob/master/jira2github/data/readme.adoc > >> > >> Before I proceed with "bigger" projects like Pax Logging or Pax Web, I'd > >> appreciate your feedback. > >> > >> kind regards > >> Grzegorz Grzybek > >> > >
Re: Coming releases
Hello Thanks for the update. Indeed - I'm releasing Pax Transx and Pax Jdbc (Thanks +Benjamin Graf for Oracle JDBC driver hint!). And one request for comment, as I believe it needs some attention of others, not only of JBO - please have a look at https://issues.apache.org/jira/browse/KARAF-7032 which (I hope) cleans up the state of `javax.transaction` and `javax.transaction.xa` packages. With the suggested changes (PR links attached) I run successful tests with different JTA scenarios, including DBCP2. There's also a new JtaTest I've added to Karaf. kind regards Grzegorz Grzybek czw., 18 lut 2021 o 13:17 Jean-Baptiste Onofre napisał(a): > Hi guys, > > Quick update about the releases. > > Aries Proxy and Blueprint releases are on vote. I should be able to close > the vote tomorrow. > > Regarding PAX * releases, I did a new PAX URL release, and I’m on PAX Web > now (couple of issues to address). I will move forward on other PAX > releases to have all dependencies aligned. > Greg is on some other PAX releases (Pax JDBC, …). > > The first target is Karaf 4.2.11. I’m still targeting end of this week for > 4.2.11. > > However, I’m postponing 4.3.1 for end of next week as I have some code > change on the way. > > I will keep you posted. > > Regards > JB > > > Le 13 févr. 2021 à 06:46, Jean-Baptiste Onofre a > écrit : > > > > Hi guys, > > > > Just to let you know that I’m working on dependencies releases (Aries > Proxy, Aries Blueprint, PAX *, …) for Karaf 4.3.1 and 4.2.11. > > > > I should have the votes submitted during the week end. > > > > I will keep you posted. > > > > Regards > > JB > > > >> Le 9 févr. 2021 à 05:55, Jean-Baptiste Onofre a > écrit : > >> > >> Hi everyone, > >> > >> Just a quick update about the release schedule: > >> > >> - Apache Karaf Decanter 2.7.0 will be on vote tonight or tomorrow > morning. I’m preparing the latest PR (adding HDFS and S3 appenders). > >> - Apache Karaf 4.3.1 and 4.2.11 should be on vote during next week end. > I’m doing the Jira triage right now. > >> > >> I will keep you posted soon ! > >> > >> Thanks, > >> Regards > >> JB > >> > >>> Le 24 janv. 2021 à 17:44, Jean-Baptiste Onofre a > écrit : > >>> > >>> Hi guys, > >>> > >>> I was busy with ActiveMQ 5.16.1 release. > >>> > >>> So, new update about coming releases and some teasing ;) > >>> > >>> 1. I’m working on Decanter 2.7.0 release, I should be able to submit > to vote by the end of the week > >>> 2. In the meantime, I’m preparing 4.3.1. Vote time target is in about > 10 days > >>> > >>> About Karaf 5, I did good progress and I’m preparing a complete > README.md in the repo as base for discussion. > >>> I will sync with François this week but I don’t want to hold the > presentation for too long. > >>> > >>> Stay tuned ! > >>> > >>> Regards > >>> JB > >>> > >>>> Le 4 janv. 2021 à 06:08, Jean-Baptiste Onofre a > écrit : > >>>> > >>>> Hi guys, > >>>> > >>>> Just to let you know that I have some delay for these releases, > especially 4.3.1. I did good progress but need some more days. > >>>> > >>>> I hope to submit these releases to vote by the end of the > week/beginning of next week. > >>>> > >>>> Regards > >>>> JB > >>>> > >>>>> Le 15 déc. 2020 à 14:40, Jean-Baptiste Onofre a > écrit : > >>>>> > >>>>> Hi guys, > >>>>> > >>>>> As you have probably seen, Apache Karaf Decanter 2.6.0 is in vote. > >>>>> > >>>>> Now, I’m focus on Karaf 4.2.11 and 4.3.1 releases. I’m working on > Pax Web releases now and then I will move forward on these releases > preparation. > >>>>> > >>>>> Stay tuned ! > >>>>> > >>>>> Regards > >>>>> JB > >>>> > >>> > >> > > > >
Re: Migration of OPS4J projects from Jira to Github
Hello Thanks to Jürgen Schmid, I was able to set up "ops4j-issues" GitHub account with my current gmail address. I'll continue (if there are no objections) with the migration using this account. kind regards Grzegorz Grzybek wt., 9 lut 2021 o 12:51 Grzegorz Grzybek napisał(a): > Hello > > I'd like to let you know that I've migrated these projects from OPS4J Jira > to Github: > - PAX TRANSX: > https://github.com/ops4j/org.ops4j.pax.transx/issues?q=is%3Aissue+is%3Aall > - PAX JMS: > https://github.com/ops4j/org.ops4j.pax.jms/issues?q=is%3Aissue+is%3Aall > - PAX JDBC: > https://github.com/ops4j/org.ops4j.pax.jdbc/issues?q=is%3Aissue+is%3Aall > > These issues are taken into account: > - Jira components, statuses, resolutions, issue types and labels are > converted to Github labels > - Jira versions are converted to Github milestones > - The Jira fields that couldn't be mapped, are added below "---" line in > the body of the GitHub issue (like vote/watch count, affected versions, > fixed versions and attachments) > - Attachment links still point to Jira, but inline images are properly > displayed > - Jira issues received "famous last comments" pointing to relevant Github > issues > - Jira screen schemes were migrated to a scheme, were you can't create > new issue > - HTML is converted to GitHub flavored markdown > - all @xxx values (like @Service or @param) occurrences are properly > quoted in backticks to prevent unnecessary GitHub mentions > > One remaining thing to do, which is almost ready is the conversion of Jira > issue references to GitHub issue references - but I want to do proper cross > references between Pax projects at GitHub - not only within single project. > > I was inspired by > https://spring.io/blog/2019/01/15/spring-framework-s-migration-from-jira-to-github-issues > blog post which made me aware of few things. > > *The biggest problem I see is that all the comments and all the issues are > created by me... Even if the creation dates are preserved, I simply can't > (and don't want to) get proper Jira - GitHub user mapping.* > > In case of Spring migration, they created special GitHub user, but I can't > create another one using my gmail address. And I don't want to create weird > fake addresses. > > You can check quite raw tools at > https://github.com/ops4j/org.ops4j.tools/blob/master/jira2github/data/readme.adoc > > Before I proceed with "bigger" projects like Pax Logging or Pax Web, I'd > appreciate your feedback. > > kind regards > Grzegorz Grzybek >
Migration of OPS4J projects from Jira to Github
Hello I'd like to let you know that I've migrated these projects from OPS4J Jira to Github: - PAX TRANSX: https://github.com/ops4j/org.ops4j.pax.transx/issues?q=is%3Aissue+is%3Aall - PAX JMS: https://github.com/ops4j/org.ops4j.pax.jms/issues?q=is%3Aissue+is%3Aall - PAX JDBC: https://github.com/ops4j/org.ops4j.pax.jdbc/issues?q=is%3Aissue+is%3Aall These issues are taken into account: - Jira components, statuses, resolutions, issue types and labels are converted to Github labels - Jira versions are converted to Github milestones - The Jira fields that couldn't be mapped, are added below "---" line in the body of the GitHub issue (like vote/watch count, affected versions, fixed versions and attachments) - Attachment links still point to Jira, but inline images are properly displayed - Jira issues received "famous last comments" pointing to relevant Github issues - Jira screen schemes were migrated to a scheme, were you can't create new issue - HTML is converted to GitHub flavored markdown - all @xxx values (like @Service or @param) occurrences are properly quoted in backticks to prevent unnecessary GitHub mentions One remaining thing to do, which is almost ready is the conversion of Jira issue references to GitHub issue references - but I want to do proper cross references between Pax projects at GitHub - not only within single project. I was inspired by https://spring.io/blog/2019/01/15/spring-framework-s-migration-from-jira-to-github-issues blog post which made me aware of few things. *The biggest problem I see is that all the comments and all the issues are created by me... Even if the creation dates are preserved, I simply can't (and don't want to) get proper Jira - GitHub user mapping.* In case of Spring migration, they created special GitHub user, but I can't create another one using my gmail address. And I don't want to create weird fake addresses. You can check quite raw tools at https://github.com/ops4j/org.ops4j.tools/blob/master/jira2github/data/readme.adoc Before I proceed with "bigger" projects like Pax Logging or Pax Web, I'd appreciate your feedback. kind regards Grzegorz Grzybek
Re: Coming releases
Hello Thanks JBO for the update! And traditionally, a little summary about Pax Web 8 - and also traditionally, pax-web-extender-war was not a 2-week task. I've again had to rewrite much of the lifecycle and WAR/WAB processing. I had to (wanted to) properly implement searching for web-fragment.xml and fragment JARs, I had to map Servlet spec / JavaEE concept of WEB-INF/lib/*.jar + "container jars" into OSGi. ServletContainerInitializers were also not handled properly (consistently) according to JavaEE spec. Parsing of web[-fragment].xml descriptors is now done using original/full/compliant parser from tomcat-util-scan, but the "publishing part" is still not ready yet. What has to be finished (but again, I had to step away for a while) is the integration of WAB contexts with Whiteboard/HttpService contexts. - Imagine you install a WAB with /my-context path (in Web-ContextPath header), but there already is a Whiteboard ServletContextHelper with osgi.http.whiteboard.context.path=/my-context - WAB has to be kept on hold. Now (in Pax Web 7), the conflict is checked only between other WABs - imagine you have a WAB with some context path and install whiteboard components - that should be supported (for example - whiteboard-register a filter to "alter" the context from a WAB). But what should happen if the WAB is gone? Now it's an open question... - and so on and so on... A bit different thing is related to my research about JavaEE API bundles... I've created: - https://github.com/ops4j/org.ops4j.pax.transx/issues/33 - https://github.com/eclipse-ee4j/jca-api/issues/120 - https://github.com/eclipse-ee4j/jta-api/issues/186 With some observations about version packaging... I've sent an email to felix/dev mailing list, but didn't get any answer. See https://www.mail-archive.com/dev%40felix.apache.org/msg51498.html kind regards Grzegorz Grzybek wt., 9 lut 2021 o 05:55 Jean-Baptiste Onofre napisał(a): > Hi everyone, > > Just a quick update about the release schedule: > > - Apache Karaf Decanter 2.7.0 will be on vote tonight or tomorrow morning. > I’m preparing the latest PR (adding HDFS and S3 appenders). > - Apache Karaf 4.3.1 and 4.2.11 should be on vote during next week end. > I’m doing the Jira triage right now. > > I will keep you posted soon ! > > Thanks, > Regards > JB > > > Le 24 janv. 2021 à 17:44, Jean-Baptiste Onofre a > écrit : > > > > Hi guys, > > > > I was busy with ActiveMQ 5.16.1 release. > > > > So, new update about coming releases and some teasing ;) > > > > 1. I’m working on Decanter 2.7.0 release, I should be able to submit to > vote by the end of the week > > 2. In the meantime, I’m preparing 4.3.1. Vote time target is in about 10 > days > > > > About Karaf 5, I did good progress and I’m preparing a complete > README.md in the repo as base for discussion. > > I will sync with François this week but I don’t want to hold the > presentation for too long. > > > > Stay tuned ! > > > > Regards > > JB > > > >> Le 4 janv. 2021 à 06:08, Jean-Baptiste Onofre a > écrit : > >> > >> Hi guys, > >> > >> Just to let you know that I have some delay for these releases, > especially 4.3.1. I did good progress but need some more days. > >> > >> I hope to submit these releases to vote by the end of the > week/beginning of next week. > >> > >> Regards > >> JB > >> > >>> Le 15 déc. 2020 à 14:40, Jean-Baptiste Onofre a > écrit : > >>> > >>> Hi guys, > >>> > >>> As you have probably seen, Apache Karaf Decanter 2.6.0 is in vote. > >>> > >>> Now, I’m focus on Karaf 4.2.11 and 4.3.1 releases. I’m working on Pax > Web releases now and then I will move forward on these releases preparation. > >>> > >>> Stay tuned ! > >>> > >>> Regards > >>> JB > >> > > > >
Re: Transaction APIs...
I've create https://issues.apache.org/jira/browse/DBCP-571 to (hopefully) get some feedback from DBCP2 devs. regards Grzegorz Grzybek pon., 1 lut 2021 o 17:57 Jean-Baptiste Onofre napisał(a): > Hi, > > Thanks for sharing. I will comment in the issue. > > 1. Karaf spec effort should cleanup the export to "force" the use of > bundles (and limit jre.properties). > 2. If DBCP2 is really problematic, we can always "wrap" is, fixing the > headers, at Karaf (as we do for some bundles). > > Regards > JB > > > Le 1 févr. 2021 à 17:39, Grzegorz Grzybek a > écrit : > > > > Hello > > > > I was checking how to make Pax Transx project more consistent wrt JTA 1.2 > > APIs. So I started digging and added my findings to > > https://github.com/ops4j/org.ops4j.pax.transx/issues/33 > > > > (btw - I've migrated first Pax project - Pax Transx - from OPS4J Jira to > > Github issues) > > > > I don't want to copy entire investigation here, but summarizing: > > > > - javax.transaction/javax.transaction-api/1.2 works best in Karaf > > because it has ... `Require-Bundle: system.bundle` > > - javax.transaction/javax.transaction-api/1.3 imports (but doesn't > > export) "javax.transaction.xa" package, which is exported by Karaf (and > > available in JDK 8/9+) only with confusing `partial=true; > > mandatory:=partial` decorations > > - Karaf should NOT export `javax.transaction` package in > > etc/jre.properties on JDK11, as there's no such package in JDK11. > > Fortunately it's also exported with the above decorations, so normal > bundle > > (importing `javax.transaction` package) won't resolve anyway > > - the problematic bundle is DBCP2 which uses the _partial_ attribute, > > but fortunately (and even in more confusing way) only for > > `javax.transaction.xa` package, which is definitely not partial at all > > (it's complete both in JDK 8 and 9+) > > > > I invite you to comment under > > https://github.com/ops4j/org.ops4j.pax.transx/issues/33 if you have any > > ideas. > > > > kind regards > > Grzegorz Grzybek > >
Transaction APIs...
Hello I was checking how to make Pax Transx project more consistent wrt JTA 1.2 APIs. So I started digging and added my findings to https://github.com/ops4j/org.ops4j.pax.transx/issues/33 (btw - I've migrated first Pax project - Pax Transx - from OPS4J Jira to Github issues) I don't want to copy entire investigation here, but summarizing: - javax.transaction/javax.transaction-api/1.2 works best in Karaf because it has ... `Require-Bundle: system.bundle` - javax.transaction/javax.transaction-api/1.3 imports (but doesn't export) "javax.transaction.xa" package, which is exported by Karaf (and available in JDK 8/9+) only with confusing `partial=true; mandatory:=partial` decorations - Karaf should NOT export `javax.transaction` package in etc/jre.properties on JDK11, as there's no such package in JDK11. Fortunately it's also exported with the above decorations, so normal bundle (importing `javax.transaction` package) won't resolve anyway - the problematic bundle is DBCP2 which uses the _partial_ attribute, but fortunately (and even in more confusing way) only for `javax.transaction.xa` package, which is definitely not partial at all (it's complete both in JDK 8 and 9+) I invite you to comment under https://github.com/ops4j/org.ops4j.pax.transx/issues/33 if you have any ideas. kind regards Grzegorz Grzybek
Re: [PROPOSAL] Disable autoRefresh on features service by default and simple optional features service
Hello Thanks JBO for the proposal, which concerns very important "feature, not a problem" of OSGi... To be honest I don't have clear statement about when to disable autorefresh (4.3 or 5.x), but let me share my view on it. We (Red Hat Fuse team) have been struggling with "unnecessary refreshes" for long time in Fuse 6, which is based on Karaf 2.4, but with Karaf 4.x resolver and In Fuse 7 (based on Karaf 4). Fuse 6 in fabric mode is something more complex than pure Karaf, as it has the concept of "profiles" which allow to collect features + bundles (+ bunch of other stuff) in single entity to be assigned to a container. And a container may have many profiles (thus many sets of features + bundles) assigned. What (from user point of view) was a simple operation like: `container-add-profile `, may end up with few minutes of Maven downloading and a cycle of bundle refreshes. Putting Fuse 6/Fabric8 aside, Karaf feature was indeed (as JBO explained) a way to install many bundles in "a transaction" without a need to go through all existing bundles and refreshing them as needed. So my first hesitation is - how many `feature:install` commands (with autoRefresh = false) will have to be followed by explicit `osgi:refresh`? On the other hand, when we stop treating Karaf as very-long running application server, how many times will we even perform `feature:install`? We'll rather have a custom distro, where all necessary bundles are installed/available from start. Here, autoRefresh=false is indeed more natural. Another thing to remember is that Karaf resolver may "reach out" to bundles that have to be refreshed upon feature installation, if there are relevant "wires" between the bundles. We've seen many times that refreshing a bundle (we had this with ActiveMQ + Camel) doesn't necessary lead to refresh of all the bundles, because there was no wire between the bundles - because maven-bundle-plugin didn't generate one, because the ONLY link between a blueprint bundle with Camel context and ActiveMQ bundle was «from="failover:xxx"» Camel declaration, which wasn't recognized by maven-bundle-plugin plugins. Over the time, I've been personally involved in "fixing unnecessary refreshes" bugs many times - like splitting pax-logging into pax-logging-api + pax-logging-service (done by +Guillaume Nodet ) or splitting pax-logging-log4j2 into a bundle + fragment (done by JBO). In Fuse we were carefully influencing etc/startup.properties and rewriting many features to be more consistent and less vulnerable to unnecessary refreshes. But summarizing, I'd keep autoRefresh=true in all the scenarios, where Karaf is used as "application server" and switch it to autoRefresh=false in µservices / custom distro / single start mode. And looking forward Karaf 5 and new feature mechanism, I'd rather turn autoRefresh off in Karaf 5... regards Grzegorz Grzybek pt., 8 sty 2021 o 07:31 Jean-Baptiste Onofre napisał(a): > Hi everyone, > > We got several user feedback, complaining about unexpected and cascaded > (unrelated) refresh while installing features. > > As reminder, a refresh can happen when: > - bundle A imports package foo:1 and a bundle provides newer foo package > version. In that case, the features service will refresh A to use the > newest package version. > - bundle A has an optional import to package foo and a bundle provides > this package. In that case, the features service will refresh A to actually > use the import as it’s a "resolved" optional. > - bundle A is wired to bundle B (from a package perspective or > requirement) and B is refreshed. In that case, the features service will > refresh A as B is itself refreshed (for the previous reasons for instance). > This can cause "cascading" refresh. > > A refresh means that a bundle can be restarted (if the bundle contains an > activator or similar (DS component, blueprint bundle)). > > In this PR https://github.com/apache/karaf/pull/1287 < > https://github.com/apache/karaf/pull/1287>, I propose to introduce a new > property autoRefresh in etc/org.apache.karaf.features.cfg to disable the > auto refresh by the features service (and let the user decides when he > wants to trigger refresh with bundle:refresh command for instance). > I propose to keep autoRefresh=true on 4.2.x and turn autoRefresh=false on > 4.3.x. > > Thoughts ? > > On the other hand (and to prepare the "path" to Karaf5), I have created a > new "simple features service" (PR will be open soon) that: > > - just take the features definition in order (ignoring start level) > - ignore requirement/capability (no resolver) > - no auto refresh > > Basically, if you have the following feature definition: > > > bar > A > B > > > The
Re: Happy Christmas
Too late for Christmas wishes, but I'd like to wish you all happy New Year - the year without face masks, the year of Linux on Desktop™, Karaf 5, Pax Web 8 and Half Life 3 ;) Let us all forget about 2020 asap! kind regards Grzegorz Grzybek czw., 24 gru 2020 o 19:01 Geaaru napisał(a): > Happy Christmas to you too and @devs > > On Thu, Dec 24, 2020, 6:28 PM Jean-Baptiste Onofre > wrote: > > > Hi Karafers, > > > > On behalf of the Karaf team, I wish you a very happy Christmas. > > > > I think we all deserve good time with friends and family (obviously in > > respect of Covid related directives). > > > > I will send a longer email during the week end with a Karaf gift and a > > summary of this past year for Karaf community ;) > > > > So, again, have great time and happy Christmas. > > > > Regards > > JB >
[PAX-WEB 8] Another obstacle - WABs and virtual hosts
Hello I'm progressing well with simplification/stabilization of WAB support in Pax Web 8. Here's a draft schema of how it works now with Pax Web 7 1) Bundles with Web-ContextPath manifest header are "tracked" as "web apps" 2) web.xml parsing (if such descriptor is available) is performed in the thread that activates the bundle - so it's usually FelixStartLevel thread ( *bad!*) 3) a WebApp with web.xml started is returned as "extension", which is "started" in one of 3 (*hardcoded number!*) threads, but before it is started, it is associated with a ServiceTracker for HttpService services and when such tracker is notified, WebAppDependencyHolder service is registered 4) when "starting", it is determined whether the bundle's "context name" and "virtual hosts list" are non-conflicting to prevent tracking two WARs with same context (that's fine). *But this doesn't involve verification with contexts created using Whiteboard or HttpService!* 5) non-conflicting bundle is "published", but this only means registration of service listener for WebAppDependencyHolder services for given bundle - such service becomes available when HttpService is available 6) so when WebAppDependencyHolder is passed to a service listener, we finally have a) parsed WebApp, b) HttpService (WebContainer) instance, we can now "register" such WebApp 7) "registration" is performed in various threads - depending on what was first - HttpService or the WebApp 8) "registration" involves passing a registration visitor to WebApp.accept() method and consists of interaction with HttpService/WebContainer to register servlets, filters, etc. in WebContainer As you can see this is a pattern where entities are synchronized using service trackers/listeners and OSGi services being registered with no reason - for example IMO there should be no need to register WebAppDependencyHolder OSGi service, as it contains only a reference to bundle-scoped HttpService and one (one!) ServletContainerInitializer - no idea who could use such OSGi service. The bigger problem is VHost → contextName → List mapping: 1) it's not consistent with conflict-prevention where Whiteboard and HttpService contexts are involved 2) there's a way to "alter" a web context created by WAR extender using Whiteboard registration of additional elements (like filters) to the same context - but there's no implementation of the scenario, where WAR is uninstalled - what should be done with the additional filters? 3) virtual host handling is totally inconsistent between runtimes. in Tomcat, a virtual host is separate entity - "above the context", while in Jetty it's a "property of the context" that allows/rejects a request for given context when VHost (Host: header) doesn't match. In Undertow it's just yet another handler that accepts/rejects a request (similar behavior to Jetty). So please give me some more time ;) regards Grzregorz Grzybek
Re: [X-Mas Gift] Panel discussion about Karaf 5
Hello Great idea! I'd be glad to join in reasonable hours ;) And +1 for quick summary of the "state of OSGi". regards Grzegorz Grzybek śr., 16 gru 2020 o 00:43 Bernd Eckenfels napisał(a): > Hello, > > Yes this sounds interesting, would like to listen in. > > BTW if you can spare 5 minutes of this call to generally talk about OSGi > and it’s Future, it would be even better. > > Gruss > Bernd > -- > http://bernd.eckenfels.net > > Von: Jean-Baptiste Onofre > Gesendet: Tuesday, December 15, 2020 6:32:15 PM > An: dev@karaf.apache.org ; u...@karaf.apache.org < > u...@karaf.apache.org> > Betreff: [X-Mas Gift] Panel discussion about Karaf 5 > > Hi guys, > > Maybe some of you know that I started to work on Karaf 5. > > I have something that it’s almost "usable". > > Before sending a global discussion thread on the mailing list, I would > like to evaluate the ideas & big changes I did. > > I would like to know if some of you would be interested by a panel > discussion call to introduce Karaf 5 (limited audience at first step). > > The agenda of this call would be: > 1. Pros/Cons about Karaf as it is today > 2. Concepts in Karaf 5 (module, extension, …) > 3. Building & running > 4. Live demo > > It could be recorded/webinar style (not necessary live call) for about 20 > people at first step (both Karaf developers and users). > The purpose is to evaluate the direction. > > Thoughts ? > Who would be interested ? > > Thanks, > Regards > JB >
Re: [VOTE] Apache Karaf Decanter 2.6.0
+1 (binding) regards Grzegorz Grzybek wt., 15 gru 2020 o 14:39 Jean-Baptiste Onofre napisał(a): > +1 (binding) > > Gently reminder about this vote. > > Thanks, > Regards > JB > > > Le 14 déc. 2020 à 06:10, Jean-Baptiste Onofre a écrit > : > > > > Hi everyone, > > > > I submit Apache Karaf Decanter 2.6.0 to your vote. This release contains > bug fixes, dependencies upgrade, and new features, especially: > > > > * New SNMP collector > > * New Camel processor > > * New GroupBy processor > > * Improvements on REST and Socket collectors > > * Better coverage with itests > > > > You can take a look on the Release Notes for details. > > > > Release Notes: > > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12348394 > < > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12348394 > > > > > > Staging Repository: > > https://repository.apache.org/content/repositories/orgapachekaraf-1152/ > <https://repository.apache.org/content/repositories/orgapachekaraf-1152/> > > > > Staging Dist: > > https://dist.apache.org/repos/dist/dev/karaf/decanter/2.6.0/ < > https://dist.apache.org/repos/dist/dev/karaf/decanter/2.6.0/> > > > > Git tag: > > decanter-2.6.0 > > > > Please vote to approve this release: > > > > [ ] +1 Approve the release > > [ ] -1 Don't approve the release (please provide specific comments) > > > > This vote will be open for at least 72 hours. > > > > Regards > > JB > >
Re: Coming releases
Hello Thanks JBO for the update! If you try upgrading to Jetty 9.4.35, mind that jetty-servlet bundle started to require a package from jetty-util-ajax. See https://github.com/eclipse/jetty.project/issues/5539 (I had to tackle this in Pax Web 8). BTW - I'm just refactoring pax-web-extender-war, so the lifecycle is simplified and matches what I did in pax-web-extender-whiteboard. regards Grzegorz Grzybek wt., 15 gru 2020 o 14:40 Jean-Baptiste Onofre napisał(a): > Hi guys, > > As you have probably seen, Apache Karaf Decanter 2.6.0 is in vote. > > Now, I’m focus on Karaf 4.2.11 and 4.3.1 releases. I’m working on Pax Web > releases now and then I will move forward on these releases preparation. > > Stay tuned ! > > Regards > JB
