Re: karaf-4.5.x?
On 8 Jan 2023, at 20:14, Jean-Baptiste Onofré wrote: Java 11 is not a point as it's already used on Karaf 4.4.x. Altho it seems we can run Karaf 4.4.x under JDK 8 - so now I'm curious. I assume nothings being targeting JDK 9+ byte code then. --- "The ease with which a change can be implemented has no relevance at all to whether it is the right change for the (Java) Platform for all time." Mark Reinhold. Mark Derricutt http://www.chaliceofblood.net http://www.theoryinpractice.net http://twitter.com/talios http://facebook.com/mderricutt https://mastodon.nz/@talios
Re: pax-web-8: handling security for non-existent resources?
Hello Robert!
Right, and this I think is actually a bug in Jolokia. I think it should
> set its context path to /jolokia and use urlPatterns=/*, right?
>
It's not a bug in Jolokia, but a limitation of the method to register a
servlet...
If you `git blame` related lines, you'll see:
https://github.com/rhuss/jolokia/blame/v1.7.2/agent/osgi/src/main/java/org/jolokia/osgi/JolokiaActivator.java#L322-L325
This code was added ... 12 years ago and the only method back then was to
use OSGi CMPN HttpService specification, which allowed to do these:
- register a servlet
- register resources
That's all. No filters, *no contexts other than "/"!*, no listeners, no
nothing...
Whiteboard specification is more flexible and I think this is what should
be done:
- please create a rhuss/jolokia GH issue with your problem, let me know
and I'll add my comments there (and PR to turn it into whiteboard)
- for now, you have to live with what we have. I agree that Jolokia
"takes over" the "/" context, but is it possible that you use different
context? and register a servlet to "/" that redirects all (but
"/jolokia/*") URIs to your context?
regards
Grzegorz Grzybek
niedz., 8 sty 2023 o 01:04 Robert Varga napisał(a):
> On 17/08/2022 08:31, Grzegorz Grzybek wrote:
> > Hello
>
> Hello Grzegorz,
>
> sorry for the late reply. I needed some time to get into this entire
> business.
>
> > Is this expected behaviour? I would have expected to hit
> >> ServiceAuthenticationHttpContext only when servicing /jolokia...
> >>
> >
> > /jolokia/* mapping (actually a one-element array of URL patterns) is a
> > mapping for org.jolokia.osgi.servlet.JolokiaServlet registered into "/"
> > (default), ROOT) context. See this in logs:
> >
> > Adding servlet
> >>
> ServletModel{id=ServletModel-3,name='org.jolokia.osgi.servlet.JolokiaServlet',alias='/jolokia',urlPatterns=[/jolokia/*],servlet=org.jolokia.osgi.servlet.JolokiaServlet@2d7892f6
> >> ,contexts=[{HS,OCM-4,context:570736934,/}]}
> >>
>
> Right, and this I think is actually a bug in Jolokia. I think it should
> set its context path to /jolokia and use urlPatterns=/*, right?
>
> That way...
>
> >
> > toString() method for ServletModel shows the associated (as in Whiteboard
> > specification) _contexts_. The single associated context is:
> >
> > {HS,OCM-4,context:570736934,/}
> >>
> >
> > HS means "Http Service", OCM-4 is an internal ID of the context and
> > "context:570736934" is generated name, because Jolokia's provided
> > "ServiceAuthenticationHttpContext"
> > is wrapped to match the API consistency internally. This
> > "ServiceAuthenticationHttpContext" is used by Jolokia to register the
> > servlet:
> >
> > service.registerServlet(getServletAlias(),
> > new
> > JolokiaServlet(context,restrictor),
> > getConfiguration(),
> > getHttpContext());
> >
> > (see 4th parameter - result of getHttpContext()).
> >
> > What's more important is that such context replaces default "/" context
> > from Whiteboard specification:
>
> it would just not do this...
>
> >> 2022-08-16T08:09:51,804 | INFO | paxweb-config-1-thread-1 |
> >> JettyServerWrapper | 474 -
> org.ops4j.pax.web.pax-web-jetty -
> >> 8.0.2 | Changing default OSGi context model for
> >> o.o.p.w.s.j.i.PaxWebServletContextHandler@14729e2e{/,null,STOPPED}
> >>> 2022-08-16T08:09:51,804 | INFO | paxweb-config-1-thread-1 |
> >> OsgiServletContext | 477 - org.ops4j.pax.web.pax-web-spi -
> >> 8.0.2 | Unegistering
> >>
> OsgiServletContext{model=OsgiContextModel{WB,id=OCM-1,name='default',path='/',bundle=org.ops4j.pax.web.pax-web-extender-whiteboard,context=(supplier)}}
> >> as OSGi service for "/" context path
> >>> 2022-08-16T08:09:51,804 | INFO | paxweb-config-1-thread-1 |
> >> OsgiServletContext | 477 - org.ops4j.pax.web.pax-web-spi -
> >> 8.0.2 | Registering
> >>
> OsgiServletContext{model=OsgiContextModel{HS,id=OCM-4,name='context:570736934',path='/',bundle=org.jolokia.osgi,context=WebContainerContextWrapper{bundle=org.jolokia.osgi_1.7.1
> >>
> [166],contextId='context:570736934',delegate=org.jolokia.osgi.security.ServiceAuthenticationHttpContext@2204c126
> }}}
> >> as OSGi service for "/" context path
> >
> >
> > See
> >
> {WB,id=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
>
Re: karaf-4.5.x?
Hi Robert, Java 11 is not a point as it's already used on Karaf 4.4.x. About slf4j 2.x/logback 1.4, it's already planned with Pax Logging 2.2.x. We plan to upgrade on Karaf 4.4.x (not sure it requires a 4.5.x release). On your point about Jetty 11 and jakarta namespace, there are a lot of impacts, including on OSGi CM. So definitely, it makes sense to have Karaf 4.5.x for that as the impact is important. Let me list all dependencies/impacts from Jakarta namespace move. Regards JB On Sun, Jan 8, 2023 at 12:16 AM Robert Varga wrote: > > Hello everyone, > > are there any plans for a karaf-4.5.x release? > > I think there is a number of breaking changes out there to warrant a > rather major step: > > - Java 11+ > - slf4j-2.0.x > - logback-1.4.x (Java 11, slf4j-2) > - pax-web-9.0.x (Java 11, jetty-10.x) > > Also, I think it is time to plan for jetty-11, i.e. jakarta.ee > namespace, as it is invariably coming down the pike, but that is a thing > of its own. > > Key drivers here for me are slf4j-2 (finally out) and jetty-10 (9.4 is > EOSL). Most of my projects are already on Java 17, all are on Java 11, > so yeah, I am biased :) > > Thanks, > Robert
Re: [VOTE] Apache Karaf OSGi runtime 4.4.3 release (take #2)
+1 Thanks and sorry for previous cancellation due to Pax Web upgrade ;) regards Grzegorz Grzybek sob., 7 sty 2023 o 06:44 Jean-Baptiste Onofré napisał(a): > Hi guys, > > I submit Apache Karaf OSGi runtime 4.4.3 release to your vote (take #2). > > This release is a maintenance release bringing a lot of dependency > updates and fixes. > Especially, this release includes: > - fix threads leak in karaf-maven-plugin (in verify feature goal) > - fix on JMX stub IP address assignation (especially on different > docker networks) > - re-add shell:alias command > - fix ssh client on Windows > - upgrade to Aries JAX RS Whiteboard 2.0.2 > - upgrade to Pax Web 8.0.15 > - and several dependency updates ! > > You can take a look on the Release Notes for details: > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12352267 > > Maven Staging Repository: > https://repository.apache.org/content/repositories/orgapachekaraf-1182/ > > Dist Staging Repository: > https://dist.apache.org/repos/dist/dev/karaf/4.4.3/ > > Git tag: > karaf-4.4.3 > > Please vote to approve this release: > [ ] +1 Approve the release > [ ] -1 Don't approve the release (please provide specific comments) > > This vote will be open for at least 72 hours. > > Regards > JB >
Re: karaf-4.5.x?
Hello Of course JBO has to answer, but I can give you some good news too ;) (sorry for top-posting). First - Karaf 4.4.x is already JDK11 only (kind of) - because it _can't_ be compiled using JDK8 - see https://issues.apache.org/jira/browse/KARAF-7312 and https://github.com/apache/karaf/blob/karaf-4.4.2/management/server/src/main/java/org/apache/karaf/management/internal/Activator.java#L115 - this constant is JDK9+ only. About Jetty 11 - it's kept in line with 10.x and the only difference is Servlet API used (4 with `javax.servlet` packages vs. 5 with `jakarta.servlet` package). Usage in OSGi however is far from ready, because OSGi CMPN 8.1 is just being released, however: - there's no HttpService chapter *at all* - there's only Whiteboard left and Web Apps (WABs) chapter is not updated to `jakarta`. See https://github.com/osgi/osgi/issues/499 - Pax Web 10 (yes, 10) is work in progress, because there are lot of changes enforced by javax → jakarta migration. See https://github.com/ops4j/org.ops4j.pax.web/issues/1802 About Pax Web 9 - actually, it should be a matter of replacing version 8 with 9 without _any problems_ - the release is compatible and because Pax Web 9 is JDK 11 only, it could switch (with minor changes related to websocket handling from Jetty 9 to Jetty 10. I think some Karaf 4.4.x soon could use Pax Web 9 and Jetty 10 - and that's where @Jean-Baptiste Onofré comment is needed ;) About SLF4J2 - I just can't help but share an insight into how I work ;) See: - I was working on Pax Web 10 and decided to run OSGi TCKs over it, so - I started checking https://github.com/osgi/osgi/ where the TCKs are stored, but I saw it's a `bnd` workspace, so - I started learning `bnd` and `bndtools`, because I'm pure Maven engineer, so - I got back to osgi/osgi project to check how they use `bnd` and saw that they run TCKs using Github Actions, so - I started learning Github Actions, because I never learned them because I always have this subconscious angst about exceed free plan, so - I decided to take simpler project and add Github Actions support there - I chose... Pax Logging, so - I got back to Pax Logging and recalled that it's about time to finish (created by me) https://github.com/ops4j/org.ops4j.pax.logging/issues/504 - upgrade to SLF4J 2 with Logback 1.3 Whew - summarizing, SLF4J2 is already supported in `main` branch (2.2.x) of Pax Logging and all the tests pass - the only issue I found was https://jira.qos.ch/browse/LOGBACK-1716 So soon (maybe even today) I'm going to release Pax Logging 2.2.1 with: - Log4j2 2.19.0 ( https://github.com/ops4j/org.ops4j.pax.logging/issues/505) - Reload4J 1.2.24 ( https://github.com/ops4j/org.ops4j.pax.logging/issues/509) - just an update, no CVEs, no breaking changes - SLF4J2 2.0.6 - and I committed a heresy, but pax-logging-api will export two major versions (and more minor versions) of `org.slf4j` package: 1.4.3, 1.5.11, 1.6.6, 1.7.36 and 2.0.6 - the first 4 versions were exported for long time, but I've never exported two different major versions before - fortunately OSGi can do it ;) - Logback 1.3.5 (upgrade from 1.2.11 for SLF4J 1.7.x), because Logback 1.4.5 is to be used with `jakarta` packages and we don't do it (OSGi CMPN) yet. I hope this long explanation answer is helpful ;) regards Grzegorz Grzybek niedz., 8 sty 2023 o 00:17 Robert Varga napisał(a): > Hello everyone, > > are there any plans for a karaf-4.5.x release? > > I think there is a number of breaking changes out there to warrant a > rather major step: > > - Java 11+ > - slf4j-2.0.x > - logback-1.4.x (Java 11, slf4j-2) > - pax-web-9.0.x (Java 11, jetty-10.x) > > Also, I think it is time to plan for jetty-11, i.e. jakarta.ee > namespace, as it is invariably coming down the pike, but that is a thing > of its own. > > Key drivers here for me are slf4j-2 (finally out) and jetty-10 (9.4 is > EOSL). Most of my projects are already on Java 17, all are on Java 11, > so yeah, I am biased :) > > Thanks, > Robert >
Re: pax-web-8: handling security for non-existent resources?
On 17/08/2022 08:31, Grzegorz Grzybek wrote:
Hello
Hello Grzegorz,
sorry for the late reply. I needed some time to get into this entire
business.
Is this expected behaviour? I would have expected to hit
ServiceAuthenticationHttpContext only when servicing /jolokia...
/jolokia/* mapping (actually a one-element array of URL patterns) is a
mapping for org.jolokia.osgi.servlet.JolokiaServlet registered into "/"
(default), ROOT) context. See this in logs:
Adding servlet
ServletModel{id=ServletModel-3,name='org.jolokia.osgi.servlet.JolokiaServlet',alias='/jolokia',urlPatterns=[/jolokia/*],servlet=org.jolokia.osgi.servlet.JolokiaServlet@2d7892f6
,contexts=[{HS,OCM-4,context:570736934,/}]}
Right, and this I think is actually a bug in Jolokia. I think it should
set its context path to /jolokia and use urlPatterns=/*, right?
That way...
toString() method for ServletModel shows the associated (as in Whiteboard
specification) _contexts_. The single associated context is:
{HS,OCM-4,context:570736934,/}
HS means "Http Service", OCM-4 is an internal ID of the context and
"context:570736934" is generated name, because Jolokia's provided
"ServiceAuthenticationHttpContext"
is wrapped to match the API consistency internally. This
"ServiceAuthenticationHttpContext" is used by Jolokia to register the
servlet:
service.registerServlet(getServletAlias(),
new
JolokiaServlet(context,restrictor),
getConfiguration(),
getHttpContext());
(see 4th parameter - result of getHttpContext()).
What's more important is that such context replaces default "/" context
from Whiteboard specification:
it would just not do this...
2022-08-16T08:09:51,804 | INFO | paxweb-config-1-thread-1 |
JettyServerWrapper | 474 - org.ops4j.pax.web.pax-web-jetty -
8.0.2 | Changing default OSGi context model for
o.o.p.w.s.j.i.PaxWebServletContextHandler@14729e2e{/,null,STOPPED}
2022-08-16T08:09:51,804 | INFO | paxweb-config-1-thread-1 |
OsgiServletContext | 477 - org.ops4j.pax.web.pax-web-spi -
8.0.2 | Unegistering
OsgiServletContext{model=OsgiContextModel{WB,id=OCM-1,name='default',path='/',bundle=org.ops4j.pax.web.pax-web-extender-whiteboard,context=(supplier)}}
as OSGi service for "/" context path
2022-08-16T08:09:51,804 | INFO | paxweb-config-1-thread-1 |
OsgiServletContext | 477 - org.ops4j.pax.web.pax-web-spi -
8.0.2 | Registering
OsgiServletContext{model=OsgiContextModel{HS,id=OCM-4,name='context:570736934',path='/',bundle=org.jolokia.osgi,context=WebContainerContextWrapper{bundle=org.jolokia.osgi_1.7.1
[166],contextId='context:570736934',delegate=org.jolokia.osgi.security.ServiceAuthenticationHttpContext@2204c126}}}
as OSGi service for "/" context path
See
{WB,id=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 then the context for '/' ...
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
Right, and the answer is 404, no matter auth result, because the
endpoint has been removed (same development iteration, previous patch,
but since it
karaf-4.5.x?
Hello everyone, are there any plans for a karaf-4.5.x release? I think there is a number of breaking changes out there to warrant a rather major step: - Java 11+ - slf4j-2.0.x - logback-1.4.x (Java 11, slf4j-2) - pax-web-9.0.x (Java 11, jetty-10.x) Also, I think it is time to plan for jetty-11, i.e. jakarta.ee namespace, as it is invariably coming down the pike, but that is a thing of its own. Key drivers here for me are slf4j-2 (finally out) and jetty-10 (9.4 is EOSL). Most of my projects are already on Java 17, all are on Java 11, so yeah, I am biased :) Thanks, Robert
Re: [VOTE] Apache Karaf OSGi runtime 4.4.3 release (take #2)
On 07/01/2023 06:43, Jean-Baptiste Onofré wrote: Hi guys, I submit Apache Karaf OSGi runtime 4.4.3 release to your vote (take #2). This release is a maintenance release bringing a lot of dependency updates and fixes. Especially, this release includes: - fix threads leak in karaf-maven-plugin (in verify feature goal) - fix on JMX stub IP address assignation (especially on different docker networks) - re-add shell:alias command - fix ssh client on Windows - upgrade to Aries JAX RS Whiteboard 2.0.2 - upgrade to Pax Web 8.0.15 - and several dependency updates ! You can take a look on the Release Notes for details: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12352267 Maven Staging Repository: https://repository.apache.org/content/repositories/orgapachekaraf-1182/ Dist Staging Repository: https://dist.apache.org/repos/dist/dev/karaf/4.4.3/ Git tag: karaf-4.4.3 Please vote to approve this release: [ ] +1 Approve the release [ ] -1 Don't approve the release (please provide specific comments) +1, non-binding, based on basic tests. Thanks, Robert
