Re: [HEADS UP] Releases plan: Decanter 2.3.0 and Karaf 4.2.9/4.3.0

[Jean-Baptiste Onofre]

Hi,

Yes, it’s already known and I have the jira about that. 

And it’s actually already fixed: it’s in Felix Gogo where jline version has not 
been updated.
I fixed that, I just have to cut the felix gogo release.

Regards
JB

> Le 21 mars 2020 à 09:54, Steinar Bang  a écrit :
> 
>> Jean-Baptiste Onofre :
> 
>> Hi Markus,
>> I’m working on including a fix. That’s why I don’t plan Karaf 4.2.9 at least 
>> during the week end (it gives time to address several issues including the 
>> "paste" one ;) ).
> 
> One more console issue I've seen, I don't know if it's reported (I
> didn't find anything in a quick scan of the open karaf JIRA issues):
> Piping commands, like e.g. "| less" doesn't work in 4.2.8:
>  karaf@root()> bundle:list | less
>  Error executing command: java.lang.reflect.InvocationTargetException
>  karaf@root()>
> 
> Piping to less works in karaf 4.2.7.
> 
> This is on debian 10.3 "buster" (ie. current debian stable) on amd64 and
> with apache started from unpacked binary tarball, ie. not using SSH.
> Java version is 11.0.6
> 

Re: [HEADS UP] Releases plan: Decanter 2.3.0 and Karaf 4.2.9/4.3.0

[Jean-Baptiste Onofre]

So, yes, paste issue (in jline) will be fixed and included in 4.2.9.

Regards
JB

> Le 21 mars 2020 à 09:55, Steinar Bang  a écrit :
> 
>> Steinar Bang :
> 
>> Hi,
>> Will 4.2.9 contain a fix for the ssh console issues?
> 
> Ie. the paste issue.
> 

Re: [HEADS UP] Releases plan: Decanter 2.3.0 and Karaf 4.2.9/4.3.0

[Steinar Bang]

> Steinar Bang :

> Hi,
> Will 4.2.9 contain a fix for the ssh console issues?

Ie. the paste issue.

Re: [HEADS UP] Releases plan: Decanter 2.3.0 and Karaf 4.2.9/4.3.0

[Steinar Bang]

> Jean-Baptiste Onofre :

> Hi Markus,
> I’m working on including a fix. That’s why I don’t plan Karaf 4.2.9 at least 
> during the week end (it gives time to address several issues including the 
> "paste" one ;) ).

One more console issue I've seen, I don't know if it's reported (I
didn't find anything in a quick scan of the open karaf JIRA issues):
 Piping commands, like e.g. "| less" doesn't work in 4.2.8:
  karaf@root()> bundle:list | less
  Error executing command: java.lang.reflect.InvocationTargetException
  karaf@root()>

Piping to less works in karaf 4.2.7.

This is on debian 10.3 "buster" (ie. current debian stable) on amd64 and
with apache started from unpacked binary tarball, ie. not using SSH.
Java version is 11.0.6

Re: [HEADS UP] Releases plan: Decanter 2.3.0 and Karaf 4.2.9/4.3.0

[Steinar Bang]

Hi,

Will 4.2.9 contain a fix for the ssh console issues?

Re: [HEADS UP] Releases plan: Decanter 2.3.0 and Karaf 4.2.9/4.3.0

[Jean-Baptiste Onofre]

Hi Markus,

I’m working on including a fix. That’s why I don’t plan Karaf 4.2.9 at least 
during the week end (it gives time to address several issues including the 
"paste" one ;) ).

Regards
JB

> Le 19 mars 2020 à 07:15, Markus Rathgeb  a écrit :
> 
> Hi,
> 
> thank you for your.
> Is there any change to get the c'n'p error (caused by jline) fixed for
> 4.2.9?
> 
> Best regards,
> Markus
> 
> Grzegorz Grzybek  schrieb am Do., 19. März 2020,
> 06:36:
> 
>> Hello
>> 
>> I can say only about Karaf 4.3.0. I'm indeed working on Pax Web 8 (I'm
>> finally at the stage where I can actually push some (almost) atomic
>> changes. Initially it was just 100+ files changed at once). Current state
>> can be checked in master-improvements branch
>> .
>> 
>> I found just too many places in Pax Web 7 that were just too much against
>> R6 specification and I needed ... more changes than I planned. Even if I've
>> not reviewed yet pax-web-extender-war, I've rebuilt the foundation so
>> seriously with both WAR and Whiteboard extenders in mind that it should be
>> easier to progress now.
>> 
>> The most important change in Pax Web 8 now is that there's clear
>> distinction between "OSGi Context Model" and "Servlet Context Model". Here
>> are some requirements that stem directly from specification and I've
>> already implemented them:
>> 
>>   - "Servlet Context Model" is in 1:1 relation with actual servlet context
>>   (or single, unique "context path" like "/c1")
>>   - "OSGi Context Model" is in 1:1 relation with HttpContext (from Http
>>   Service spec) or ServletContextHelper (from Whiteboard Service spec).
>> Such
>>   "OSGi context" "points to" single "Servlet Context"
>>   - *but* there may be many "OSGi Context Models" pointing to single
>>   "Servlet Context Model"
>>   - *also*, single Whiteboard-registered servlet may be associated with
>>   many "OSGi Context Models"
>> 
>> The implications are sometimes amazing:
>> 
>>   - a servlet may be registered to many "OSGi Context Models", which point
>>   to different "Servlet Context Models" - this means servlet /s may be
>>   available under /c1/s and /c2/s
>>   - a servlet may be registered to many "OSGi Context Models", which point
>>   to *the same* "Servlet Context Models" - this means servlet /s may be
>>   available under /c/s but handleSecurity() is taken from "OSGi Context
>>   Model" with highest ranking - Pax Web 7 didn't do that at all
>>   - a filter may be mapped to /* and be associated with many "OSGi Context
>>   Models", but should be added to filter chain ONLY if the chain ends
>> with a
>>   servlet associated with matching "OSGi Context Model"
>>   - a servlet associated wtih "OSGi Context Model" point to, say, /c1
>>   "Servlet Context" is available at, say, /c1/s. But when service
>>   registration properties for the associated ServletContextHelper (1:1
>> with
>>   "OSGi Context Model") change, servlet has to "switch" from /c1/s to,
>> say,
>>   /c2/s (or even /s when given "OSGi Context Model" starts being
>> associated
>>   with the default "Servlet Context Model"
>> 
>> So, you see (I hope) that Pax Web 8 is not going to be an easy release ;)
>> But I really try hard now...
>> 
>> regards
>> Grzegorz Grzybek
>> 
>> czw., 19 mar 2020 o 05:35 Jean-Baptiste Onofre 
>> napisał(a):
>> 
>>> Hi everyone,
>>> 
>>> First of all, I’m sorry for the ones who are on Slack, I have some
>>> connection issues since yesterday morning. It should be fixed by the end
>> of
>>> today max.
>>> 
>>> Anyway, I would like to move forward about the releases.
>>> 
>>> For this week, I would like to submit to vote:
>>> 
>>> - Decanter 2.3.0: it’s a major (very major ;)) release bringing new
>>> features (new alerting service with much better condition, time series,
>>> Prometheus appender, new collectors, …), updates (Elasticsearch 7
>> support,
>>> …) and fixes. I’m rebasing and polishing branches, I hope to submit
>>> Decanter release to vote during the week end.
>>> - Karaf 4.2.9, even if it doesn’t contain as much as 4.2.8, I would like
>>> to submit this release to vote as it contains the fix about HTTPs access
>> to
>>> Maven Central. As for Decanter, I plan the start the vote during the week
>>> end or early next week.
>>> - Karaf 4.3.0. We released 4.3.0.RC1 some weeks ago. Unfortunately we
>>> didn’t get lot of feedback. So, even if Pax Web is not fully ready for
>> OSGi
>>> R7 (thanks again to Greg for working hard on this), I propose to move
>>> forward on 4.3.0 "as it is". Thoughts ?
>>> 
>>> Regards
>>> JB
>> 

Re: [HEADS UP] Releases plan: Decanter 2.3.0 and Karaf 4.2.9/4.3.0

[Markus Rathgeb]

Hi,

thank you for your.
Is there any change to get the c'n'p error (caused by jline) fixed for
4.2.9?

Best regards,
Markus

Grzegorz Grzybek  schrieb am Do., 19. März 2020,
06:36:

> Hello
>
> I can say only about Karaf 4.3.0. I'm indeed working on Pax Web 8 (I'm
> finally at the stage where I can actually push some (almost) atomic
> changes. Initially it was just 100+ files changed at once). Current state
> can be checked in master-improvements branch
> .
>
> I found just too many places in Pax Web 7 that were just too much against
> R6 specification and I needed ... more changes than I planned. Even if I've
> not reviewed yet pax-web-extender-war, I've rebuilt the foundation so
> seriously with both WAR and Whiteboard extenders in mind that it should be
> easier to progress now.
>
> The most important change in Pax Web 8 now is that there's clear
> distinction between "OSGi Context Model" and "Servlet Context Model". Here
> are some requirements that stem directly from specification and I've
> already implemented them:
>
>- "Servlet Context Model" is in 1:1 relation with actual servlet context
>(or single, unique "context path" like "/c1")
>- "OSGi Context Model" is in 1:1 relation with HttpContext (from Http
>Service spec) or ServletContextHelper (from Whiteboard Service spec).
> Such
>"OSGi context" "points to" single "Servlet Context"
>- *but* there may be many "OSGi Context Models" pointing to single
>"Servlet Context Model"
>- *also*, single Whiteboard-registered servlet may be associated with
>many "OSGi Context Models"
>
> The implications are sometimes amazing:
>
>- a servlet may be registered to many "OSGi Context Models", which point
>to different "Servlet Context Models" - this means servlet /s may be
>available under /c1/s and /c2/s
>- a servlet may be registered to many "OSGi Context Models", which point
>to *the same* "Servlet Context Models" - this means servlet /s may be
>available under /c/s but handleSecurity() is taken from "OSGi Context
>Model" with highest ranking - Pax Web 7 didn't do that at all
>- a filter may be mapped to /* and be associated with many "OSGi Context
>Models", but should be added to filter chain ONLY if the chain ends
> with a
>servlet associated with matching "OSGi Context Model"
>- a servlet associated wtih "OSGi Context Model" point to, say, /c1
>"Servlet Context" is available at, say, /c1/s. But when service
>registration properties for the associated ServletContextHelper (1:1
> with
>"OSGi Context Model") change, servlet has to "switch" from /c1/s to,
> say,
>/c2/s (or even /s when given "OSGi Context Model" starts being
> associated
>with the default "Servlet Context Model"
>
> So, you see (I hope) that Pax Web 8 is not going to be an easy release ;)
> But I really try hard now...
>
> regards
> Grzegorz Grzybek
>
> czw., 19 mar 2020 o 05:35 Jean-Baptiste Onofre 
> napisał(a):
>
> > Hi everyone,
> >
> > First of all, I’m sorry for the ones who are on Slack, I have some
> > connection issues since yesterday morning. It should be fixed by the end
> of
> > today max.
> >
> > Anyway, I would like to move forward about the releases.
> >
> > For this week, I would like to submit to vote:
> >
> > - Decanter 2.3.0: it’s a major (very major ;)) release bringing new
> > features (new alerting service with much better condition, time series,
> > Prometheus appender, new collectors, …), updates (Elasticsearch 7
> support,
> > …) and fixes. I’m rebasing and polishing branches, I hope to submit
> > Decanter release to vote during the week end.
> > - Karaf 4.2.9, even if it doesn’t contain as much as 4.2.8, I would like
> > to submit this release to vote as it contains the fix about HTTPs access
> to
> > Maven Central. As for Decanter, I plan the start the vote during the week
> > end or early next week.
> > - Karaf 4.3.0. We released 4.3.0.RC1 some weeks ago. Unfortunately we
> > didn’t get lot of feedback. So, even if Pax Web is not fully ready for
> OSGi
> > R7 (thanks again to Greg for working hard on this), I propose to move
> > forward on 4.3.0 "as it is". Thoughts ?
> >
> > Regards
> > JB
>

Re: [HEADS UP] Releases plan: Decanter 2.3.0 and Karaf 4.2.9/4.3.0

[Grzegorz Grzybek]

Hello

I can say only about Karaf 4.3.0. I'm indeed working on Pax Web 8 (I'm
finally at the stage where I can actually push some (almost) atomic
changes. Initially it was just 100+ files changed at once). Current state
can be checked in master-improvements branch
.

I found just too many places in Pax Web 7 that were just too much against
R6 specification and I needed ... more changes than I planned. Even if I've
not reviewed yet pax-web-extender-war, I've rebuilt the foundation so
seriously with both WAR and Whiteboard extenders in mind that it should be
easier to progress now.

The most important change in Pax Web 8 now is that there's clear
distinction between "OSGi Context Model" and "Servlet Context Model". Here
are some requirements that stem directly from specification and I've
already implemented them:

   - "Servlet Context Model" is in 1:1 relation with actual servlet context
   (or single, unique "context path" like "/c1")
   - "OSGi Context Model" is in 1:1 relation with HttpContext (from Http
   Service spec) or ServletContextHelper (from Whiteboard Service spec). Such
   "OSGi context" "points to" single "Servlet Context"
   - *but* there may be many "OSGi Context Models" pointing to single
   "Servlet Context Model"
   - *also*, single Whiteboard-registered servlet may be associated with
   many "OSGi Context Models"

The implications are sometimes amazing:

   - a servlet may be registered to many "OSGi Context Models", which point
   to different "Servlet Context Models" - this means servlet /s may be
   available under /c1/s and /c2/s
   - a servlet may be registered to many "OSGi Context Models", which point
   to *the same* "Servlet Context Models" - this means servlet /s may be
   available under /c/s but handleSecurity() is taken from "OSGi Context
   Model" with highest ranking - Pax Web 7 didn't do that at all
   - a filter may be mapped to /* and be associated with many "OSGi Context
   Models", but should be added to filter chain ONLY if the chain ends with a
   servlet associated with matching "OSGi Context Model"
   - a servlet associated wtih "OSGi Context Model" point to, say, /c1
   "Servlet Context" is available at, say, /c1/s. But when service
   registration properties for the associated ServletContextHelper (1:1 with
   "OSGi Context Model") change, servlet has to "switch" from /c1/s to, say,
   /c2/s (or even /s when given "OSGi Context Model" starts being associated
   with the default "Servlet Context Model"

So, you see (I hope) that Pax Web 8 is not going to be an easy release ;)
But I really try hard now...

regards
Grzegorz Grzybek

czw., 19 mar 2020 o 05:35 Jean-Baptiste Onofre  napisał(a):

> Hi everyone,
>
> First of all, I’m sorry for the ones who are on Slack, I have some
> connection issues since yesterday morning. It should be fixed by the end of
> today max.
>
> Anyway, I would like to move forward about the releases.
>
> For this week, I would like to submit to vote:
>
> - Decanter 2.3.0: it’s a major (very major ;)) release bringing new
> features (new alerting service with much better condition, time series,
> Prometheus appender, new collectors, …), updates (Elasticsearch 7 support,
> …) and fixes. I’m rebasing and polishing branches, I hope to submit
> Decanter release to vote during the week end.
> - Karaf 4.2.9, even if it doesn’t contain as much as 4.2.8, I would like
> to submit this release to vote as it contains the fix about HTTPs access to
> Maven Central. As for Decanter, I plan the start the vote during the week
> end or early next week.
> - Karaf 4.3.0. We released 4.3.0.RC1 some weeks ago. Unfortunately we
> didn’t get lot of feedback. So, even if Pax Web is not fully ready for OSGi
> R7 (thanks again to Greg for working hard on this), I propose to move
> forward on 4.3.0 "as it is". Thoughts ?
>
> Regards
> JB