Re: Moving documentation to Git

[Jean-Baptiste Onofré]

Awesome ! Thanks !

Regards
JB

On Tue, Aug 22, 2023 at 1:48 PM Oliver Lietz  wrote:
>
> Hi *,
>
> We discussed in 2020 to switch over from Confluence and Jira to GitHub Pages
> and Issues.
> Migration of issues to GitHub was done by Grzegorz a while back.
> I will now start working on documentation with Antora in Pax TinyBundles and
> Pax Exam to have something up-to-date on https://ops4j.github.io/
>
> Regards,
> O.
>
>
>
> --
> --
> --
> OPS4J - http://www.ops4j.org - ops4j@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/2305118.ElGaqSPkdT%40madness.front.ruhr.

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@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/CAB8EV3R-kFpV%2B%3DNq%2BQeeBUjMAeVG0RXuf4Sumq%3DbVf2rCqYT5A%40mail.gmail.com.

Re: PaxWeb 7.2.29 - Jetty upgrade?

[Jean-Baptiste Onofré]

Hi Richard,

Both releases are planned for next week on my TODO. I was busy with
ActiveMQ release, now on vote, so I will be back on Karaf this week
end.

Regards
JB

On Thu, Aug 25, 2022 at 1:42 PM 'Richard Hierlmeier' via OPS4J
 wrote:
>
> Do you have a release schedule for PAX-WEB 7.2.x and Karaf 4.3.8?
>
> Richard
>
> jeanbapti...@gmail.com schrieb am Mittwoch, 17. August 2022 um 07:08:06 UTC+2:
>>
>> By the way, I just checked, and as I thought, it's already done for
>> Jetty 9.4.48 upgrade on Pax Web 7.3.x:
>>
>> https://github.com/apache/karaf/commit/62ebc20609
>>
>> Regarding upgrade on Pax Web 7.2.x, Karaf 4.2.x is not active anymore,
>> so I invite you to upgrade to Karaf 4.3.x.
>>
>> Regards
>> JB
>>
>> On Thu, Aug 11, 2022 at 8:30 AM 'Richard Hierlmeier' via OPS4J
>>  wrote:
>> >
>> > I tried to upgrade my application to Karaf 4.4 to get Jetty 9.4.48, 
>> > however I found some show stoppers.
>> >
>> > I really would appreciate a release of Karaf 4.3 with an updated PaxWeb 7 
>> > version.
>> >
>> > Regards
>> >
>> > Richard
>> >
>> > Daniel Stoch schrieb am Mittwoch, 10. August 2022 um 10:06:33 UTC+2:
>> >>
>> >> Hi,
>> >>
>> >> Is PaxWeb 7.2.x line is still maintained? Actual version 7.2.29 uses 
>> >> Jetty 9.4.43.v20210629 which has some vulnerabilities.
>> >> Is it possible to release a new PaxWeb 7.2.x version with newer Jetty 
>> >> version (as I can see PaxWeb 7.3.6 uses Jetty 9.4.48.v20220622)?
>> >>
>> >> --
>> >> Best regards,
>> >> Daniel Stoch
>> >
>> > --
>> > --
>> > --
>> > 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+un...@googlegroups.com.
>> > To view this discussion on the web visit 
>> > https://groups.google.com/d/msgid/ops4j/08f475ac-d3d1-4ec1-be8b-662f12418ff8n%40googlegroups.com.
>
> --
> --
> --
> OPS4J - http://www.ops4j.org - ops4j@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/b29a4ae0-8dd9-4cb5-93e0-d33e3f2c793en%40googlegroups.com.

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@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/CAB8EV3R70gONOGGUpPkq4Or%2BhSN%3Ddnkro16XLqjWCRDMC6nvUA%40mail.gmail.com.

Fwd: PaxWeb 7.2.29 - Jetty upgrade?

[Jean-Baptiste Onofré]

By the way, I just checked, and as I thought, it's already done for
Jetty 9.4.48 upgrade on Pax Web 7.3.x:

https://github.com/apache/karaf/commit/62ebc20609

Regarding upgrade on Pax Web 7.2.x, Karaf 4.2.x is not active anymore,
so I invite you to upgrade to Karaf 4.3.x.

Regards
JB

On Thu, Aug 11, 2022 at 8:30 AM 'Richard Hierlmeier' via OPS4J
 wrote:
>
> I tried to upgrade my application to Karaf 4.4 to get Jetty  9.4.48, however 
> I found some show stoppers.
>
> I really would appreciate a release of Karaf 4.3 with an updated PaxWeb 7 
> version.
>
> Regards
>
>Richard
>
> Daniel Stoch schrieb am Mittwoch, 10. August 2022 um 10:06:33 UTC+2:
>>
>> Hi,
>>
>> Is PaxWeb 7.2.x line is still maintained? Actual version 7.2.29 uses Jetty 
>> 9.4.43.v20210629 which has some vulnerabilities.
>> Is it possible to release a new PaxWeb 7.2.x version with newer Jetty 
>> version (as I can see PaxWeb 7.3.6 uses Jetty 9.4.48.v20220622)?
>>
>> --
>> Best regards,
>> Daniel Stoch
>
> --
> --
> --
> OPS4J - http://www.ops4j.org - ops4j@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/08f475ac-d3d1-4ec1-be8b-662f12418ff8n%40googlegroups.com.

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@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/CAB8EV3QTtxsbdo4ZOMM9ii%3DnkwEr6vzUCfoVj44a%3DPv8NqOPNQ%40mail.gmail.com.

Fwd: [DISCUSSION] Move PAX projects to Apache Karaf ?

[Jean-Baptiste Onofré]

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
> >
> >
> >
> > Am Do., 24. Feb. 2022 um 22:44 Uhr schrieb Eric Lilja  >> :
> >
> >> Personally, I would love to see this change and the other people in my
> >> organization liked the proposal as well.
> >>
> >> - Eric L
> >>
> >> On Thu, Feb 24, 2022 at 3:04 PM Jean-Baptiste Onofré 
> >> wrote:
> >>
> >>> Hi guys,
> >>>
> >>> Some of you already pinged me to share concerns about PAX projects
> >>> governance. I think it's my duty to share these concerns and discuss
> >>> possible actions.
> >>>
> >>> Apache Karaf is one of the biggest consumers of PAX projects.
> >>>
> >>> However, PAX projects use a "self own" designed governance:
> >>> - for contribution/IP
> >>> - for release
> >>> - for CVE/Security
> >>> - ...
> >>>
> >>> And it could be seen as a major concern for Apache Karaf users, as PAX
> >>> projects are not necessarily "aligned" with Apache Foundation rules.
> >>>
> >>> I would like to start a discussion on both Karaf and OPS4J communities
> >>> to "move" PAX projects as Karaf subproject (like karaf-pax).
> >>> Concretely, it would mean that:
> >>> 1. Karaf PAX projects would use org.apache.karaf.pax namespace
> >>> 2. Karaf PAX releases will have to follow the Apache release process
> >>> (binding votes, 3 days vote period, ...)
> >>> 3. Any active contributor on PAX projects would be invited as Karaf
> >>> committer
> >>>
> >>> Thoughts ?
> >>>
> >>> Regards
> >>> JB
> >>>
> >>
> >
> >
>
> --
> --
> --
> OPS4J - http://www.ops4j.org - ops4j@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/5ff43da6-8d5f-43f4-e6e6-86af4fb162b9%40code-house.org.

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@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/CAB8EV3R_U7YGErd41FcwwSRyavz0BYzvCKH%2BA%2BAAaF2jho7Rcw%40mail.gmail.com.

Fwd: [DISCUSSION] Move PAX projects to Apache Karaf ?

[Jean-Baptiste Onofré]

Hi Achim

Just wanted to share concerns I received. Basically, PAX projects are
"free fields", without strong guarantee in the release (not formal
staging/vote/review).

It doesn't mean we don't do that, it's just not strongly enforced ;)

I don't mean we *have to* do it, I'm just sharing comments that I got.

Regards
JB

On Thu, Feb 24, 2022 at 4:43 PM 'Achim Nierbeck' via OPS4J
 wrote:
>
> Hi JB,
>
> Before I come to any conclusion, I would really like to understand what kind 
> of issue/problem you would like to solve with this, which is easier to solve 
> under an apache umbrella.
>
> thanks, Achim
>
> Am Do., 24. Feb. 2022 um 15:04 Uhr schrieb Jean-Baptiste Onofré 
> :
>>
>> Hi guys,
>>
>> Some of you already pinged me to share concerns about PAX projects
>> governance. I think it's my duty to share these concerns and discuss
>> possible actions.
>>
>> Apache Karaf is one of the biggest consumers of PAX projects.
>>
>> However, PAX projects use a "self own" designed governance:
>> - for contribution/IP
>> - for release
>> - for CVE/Security
>> - ...
>>
>> And it could be seen as a major concern for Apache Karaf users, as PAX
>> projects are not necessarily "aligned" with Apache Foundation rules.
>>
>> I would like to start a discussion on both Karaf and OPS4J communities
>> to "move" PAX projects as Karaf subproject (like karaf-pax).
>> Concretely, it would mean that:
>> 1. Karaf PAX projects would use org.apache.karaf.pax namespace
>> 2. Karaf PAX releases will have to follow the Apache release process
>> (binding votes, 3 days vote period, ...)
>> 3. Any active contributor on PAX projects would be invited as Karaf committer
>>
>> Thoughts ?
>>
>> 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 - http://www.ops4j.org - ops4j@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/CAD0r13d2v73ipZrZOD3r9oL9wtSKZj7x2dc4%2By6sWg1rRyvWow%40mail.gmail.com.

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@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/CAB8EV3Sg0t%2BeRfNq%2BoxG9%3Dt6TS_mK0wV6Hr4nkSfNt22WCRx3A%40mail.gmail.com.

Fwd: [DISCUSSION] Move PAX projects to Apache Karaf ?

[Jean-Baptiste Onofré]

Hi guys,

Some of you already pinged me to share concerns about PAX projects
governance. I think it's my duty to share these concerns and discuss
possible actions.

Apache Karaf is one of the biggest consumers of PAX projects.

However, PAX projects use a "self own" designed governance:
- for contribution/IP
- for release
- for CVE/Security
- ...

And it could be seen as a major concern for Apache Karaf users, as PAX
projects are not necessarily "aligned" with Apache Foundation rules.

I would like to start a discussion on both Karaf and OPS4J communities
to "move" PAX projects as Karaf subproject (like karaf-pax).
Concretely, it would mean that:
1. Karaf PAX projects would use org.apache.karaf.pax namespace
2. Karaf PAX releases will have to follow the Apache release process
(binding votes, 3 days vote period, ...)
3. Any active contributor on PAX projects would be invited as Karaf committer

Thoughts ?

Regards
JB

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@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/CAB8EV3R5FCXaWMkhCYLGcEC8eeeJ079WL8-4ct1DXBS7kavtsw%40mail.gmail.com.

Re: [PAXEXAM] Cannot build project org.ops4j.pax.exam2, cannot resolve org.ops4j.pax.swissbox:pax-swissbox-core:jar:1.8.4-SNAPSHOT

[Jean-Baptiste Onofré]

Hi

I did swissbox 1.8.4 release already, so, we can upgrade pax exam to this 
version.

Regards
JB

> Le 26 mai 2021 à 22:20, Васил Зорев  a écrit :
> 
> Changing the swissbox dependency version from 1.8.4-SNAPSHOT to 1.8.4 works. 
> It's good enough for me for local tests. Let me know if it *must* be a 
> snapshot version.
> 
> Regards,
> Vassil
> 
> В 22:58:38 ч. UTC+3на сряда, 26 май 2021 г. Васил Зорев написа:
> Seems I cannot access the repository at all.
> 
> 
> Is it only available to committers?
> 
> На вт, 25.05.2021 г. в 22:13 ч. Васил Зорев  > написа:
> Do I have to pull and build swissbox locally as well?
> 
> В 20:55:36 ч. UTC+3на вторник, 25 май 2021 г. Васил Зорев написа:
> Hello,
> 
> I have a very basic (possibly stupid) question.
> 
> I forked https://github.com/ops4j/org.ops4j.pax.exam2 
>  and tried a "mvn clean 
> install" but it immediately broke with the following error:
> 
> [ERROR] Failed to execute goal on project pax-exam-container-rbc: Could not 
> resolve dependencies for project 
> org.ops4j.pax.exam:pax-exam-container-rbc:bundle:5.0.0-SNAPSHOT: The 
> following artifacts could not be resolved: 
> org.ops4j.pax.swissbox:pax-swissbox-core:jar:1.8.4-SNAPSHOT, 
> org.ops4j.pax.swissbox:pax-swissbox-tracker:jar:1.8.4-SNAPSHOT: Failure to 
> find org.ops4j.pax.swissbox:pax-swissbox-core:jar:1.8.4-SNAPSHOT in 
> https://oss.sonatype.org/content/repositories/ops4j-snapshots 
>  was cached in 
> the local repository, resolution will not be reattempted until the update 
> interval of sonatype-nexus-snapshots has elapsed or updates are forced -> 
> [Help 1]
> 
> Any ideas or hints?
> 
> Thank you,
> Regards,
> Vassil
> 
> -- 
> -- 
> --
> OPS4J - http://www.ops4j.org  - op...@googlegroups.com 
> 
> 
> --- 
> You received this message because you are subscribed to a topic in the Google 
> Groups "OPS4J" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/ops4j/HOy7PUfX9pI/unsubscribe 
> .
> To unsubscribe from this group and all its topics, send an email to 
> ops4j+un...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/ops4j/9a72e0b8-882a-4b1f-b56f-24dc8120df9fn%40googlegroups.com
>  
> .
> 
> -- 
> -- 
> --
> OPS4J - http://www.ops4j.org  - ops4j@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/82bc6173-c1f7-47ef-9cdf-026c92f986e1n%40googlegroups.com
>  
> .

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@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/8B1BC800-A607-4C84-8051-464519A03520%40gmail.com.

Re: [PAXEXAM] Cannot build project org.ops4j.pax.exam2, cannot resolve org.ops4j.pax.swissbox:pax-swissbox-core:jar:1.8.4-SNAPSHOT

[Jean-Baptiste Onofré]

Hi,

I did the swissbox 1.8.4 release already, so we can upgrade to this version
in Pax Exam.

Regards
JB

On Wed, May 26, 2021 at 10:20 PM Васил Зорев 
wrote:

> Changing the swissbox dependency version from 1.8.4-SNAPSHOT to 1.8.4
> works. It's good enough for me for local tests. Let me know if it *must* be
> a snapshot version.
>
> Regards,
> Vassil
>
> В 22:58:38 ч. UTC+3на сряда, 26 май 2021 г. Васил Зорев написа:
>
>> Seems I cannot access the repository at all.
>>
>> [image: Capture.PNG]
>> Is it only available to committers?
>>
>> На вт, 25.05.2021 г. в 22:13 ч. Васил Зорев 
>> написа:
>>
>>> Do I have to pull and build swissbox locally as well?
>>>
>>> В 20:55:36 ч. UTC+3на вторник, 25 май 2021 г. Васил Зорев написа:
>>>
 Hello,

 I have a very basic (possibly stupid) question.

 I forked https://github.com/ops4j/org.ops4j.pax.exam2 and tried a "mvn
 clean install" but it immediately broke with the following error:

 [ERROR] Failed to execute goal on project pax-exam-container-rbc: Could
 not resolve dependencies for project
 org.ops4j.pax.exam:pax-exam-container-rbc:bundle:5.0.0-SNAPSHOT: The
 following artifacts could not be resolved:
 org.ops4j.pax.swissbox:pax-swissbox-core:jar:1.8.4-SNAPSHOT,
 org.ops4j.pax.swissbox:pax-swissbox-tracker:jar:1.8.4-SNAPSHOT: Failure to
 find org.ops4j.pax.swissbox:pax-swissbox-core:jar:1.8.4-SNAPSHOT in
 https://oss.sonatype.org/content/repositories/ops4j-snapshots was
 cached in the local repository, resolution will not be reattempted until
 the update interval of sonatype-nexus-snapshots has elapsed or updates are
 forced -> [Help 1]

 Any ideas or hints?

 Thank you,
 Regards,
 Vassil

>>> --
>>> --
>>> --
>>> OPS4J - http://www.ops4j.org - op...@googlegroups.com
>>>
>>> ---
>>> You received this message because you are subscribed to a topic in the
>>> Google Groups "OPS4J" group.
>>> To unsubscribe from this topic, visit
>>> https://groups.google.com/d/topic/ops4j/HOy7PUfX9pI/unsubscribe.
>>> To unsubscribe from this group and all its topics, send an email to
>>> ops4j+un...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/ops4j/9a72e0b8-882a-4b1f-b56f-24dc8120df9fn%40googlegroups.com
>>> 
>>> .
>>>
>> --
> --
> --
> OPS4J - http://www.ops4j.org - ops4j@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/82bc6173-c1f7-47ef-9cdf-026c92f986e1n%40googlegroups.com
> 
> .
>

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@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/CAB8EV3T6_LiYihbJc7gv58bX3w2hpqSsOZNvw5_YW4DPKPsL7Q%40mail.gmail.com.

Re: [PAXEXAM] Cannot build project org.ops4j.pax.exam2, cannot resolve org.ops4j.pax.swissbox:pax-swissbox-core:jar:1.8.4-SNAPSHOT

[Jean-Baptiste Onofré]

Hi,

ops4j snapshot repository doesn't exist anymore. You have to build SNAPSHOT
locally (at least for ops4j projects).

Regards
JB

On Wed, May 26, 2021 at 9:58 PM Васил Зорев 
wrote:

> Seems I cannot access the repository at all.
>
> [image: Capture.PNG]
> Is it only available to committers?
>
> На вт, 25.05.2021 г. в 22:13 ч. Васил Зорев 
> написа:
>
>> Do I have to pull and build swissbox locally as well?
>>
>> В 20:55:36 ч. UTC+3на вторник, 25 май 2021 г. Васил Зорев написа:
>>
>>> Hello,
>>>
>>> I have a very basic (possibly stupid) question.
>>>
>>> I forked https://github.com/ops4j/org.ops4j.pax.exam2 and tried a "mvn
>>> clean install" but it immediately broke with the following error:
>>>
>>> [ERROR] Failed to execute goal on project pax-exam-container-rbc: Could
>>> not resolve dependencies for project
>>> org.ops4j.pax.exam:pax-exam-container-rbc:bundle:5.0.0-SNAPSHOT: The
>>> following artifacts could not be resolved:
>>> org.ops4j.pax.swissbox:pax-swissbox-core:jar:1.8.4-SNAPSHOT,
>>> org.ops4j.pax.swissbox:pax-swissbox-tracker:jar:1.8.4-SNAPSHOT: Failure to
>>> find org.ops4j.pax.swissbox:pax-swissbox-core:jar:1.8.4-SNAPSHOT in
>>> https://oss.sonatype.org/content/repositories/ops4j-snapshots was
>>> cached in the local repository, resolution will not be reattempted until
>>> the update interval of sonatype-nexus-snapshots has elapsed or updates are
>>> forced -> [Help 1]
>>>
>>> Any ideas or hints?
>>>
>>> Thank you,
>>> Regards,
>>> Vassil
>>>
>> --
>> --
>> --
>> OPS4J - http://www.ops4j.org - ops4j@googlegroups.com
>>
>> ---
>> You received this message because you are subscribed to a topic in the
>> Google Groups "OPS4J" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/ops4j/HOy7PUfX9pI/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> ops4j+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/ops4j/9a72e0b8-882a-4b1f-b56f-24dc8120df9fn%40googlegroups.com
>> 
>> .
>>
> --
> --
> --
> OPS4J - http://www.ops4j.org - ops4j@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/CAMhFuoCAG5YNgCeUpW_iJWhAKg0EMCrPLxhTZcLXUaRCC668eA%40mail.gmail.com
> 
> .
>

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@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/CAB8EV3RWyoQK3XvU4dzZ-pV69Ygu0177qbVucBwk3gj1iLAHZQ%40mail.gmail.com.

Re: upgrade to Jetty 9.4.39.v20210325

[Jean-Baptiste Onofré]

Hi,

I already released 7.2.x and 7.3.x with Jetty 9.4.40 update. I will tackle 
7.4.x.

Regards
JB

> Le 17 mai 2021 à 11:13, 'Fabien S' via OPS4J  a écrit 
> :
> 
> Hi all,
> Would you have any idea when a new version 7.4.2 of Pax Web would be 
> available? In the projects of my company, we have to make the decision either 
> to wait for it, or to release our software without upgrading Pax Web (and 
> possibly applying some workarounds to prevent the Deny of service 
> vulnerability).
> 
> Cheers,
> Fabien
> 
> On Tuesday, 13 April 2021 at 09:18:01 UTC+2 jeanbapti...@gmail.com wrote:
> I’m doing on all branches.
> 
> Regards
> JB
> 
> 
>> Le 13 avr. 2021 à 08:30, Grzegorz Grzybek > > a écrit :
>> 
> 
>> Hello
>> 
>> Yes - an upgrade to Jetty 9.4.39 is fine. Just no need to do it in `main` 
>> branch, because I've already updated it locally in very not-ready-yet code.
>> 
>> regards
>> Grzegorz
>> 
>> wt., 13 kwi 2021 o 08:25 'Fabien S' via OPS4J > > napisał(a):
>> Hi, thank you a lot for your help and explanations!
>> Regarding the vulnerability, maybe it's possible to include in the code of 
>> the application this work-around:
>> https://github.com/eclipse/jetty.project/security/advisories/GHSA-26vr-8j45-3r4w
>>  
>> <https://github.com/eclipse/jetty.project/security/advisories/GHSA-26vr-8j45-3r4w>
>> but I'm not sure it would handle all the cases, so relying on an official 
>> fix from Jetty would be safer.
>> 
>> Cheers,
>> Fabien
>> 
>> On Monday, 12 April 2021 at 20:50:48 UTC+2 gr.gr...@gmail.com 
>>  wrote:
>> Hello
>> 
>> Just an information about Pax Web and main branch. I've recently renamed 
>> "master-improvements" branch to "main" - I had two goals with this action:
>>  - show that my long-developed "master-improvements" branch, where I've 
>> literally refactored big part of Pax Web (to adjust to new Whiteboard 
>> requirements) is ready to be worked on by others
>>  - adjust to new standards, where "main" is the new "master"
>> 
>> Unfortunately this new "main" branch is still far from being released (I had 
>> few months break again and I have to "feel" it again) and usual practice, 
>> where some change is always made in newest branch and then backported to 
>> maintenance branches. "main" branch is MUCH different than pax-web-7.2.x – 
>> pax-web-7.4.x branches.
>> 
>> Also, remember that 3 active maintenance branches of Pax Web are:
>>  - pax-web-7.2.x - the branch used by Karaf 4.2.x, with Jetty 9, Tomcat 8 
>> and Undertow 1.x - the branch using Servlet API 3.1
>>  - pax-web-7.3.x - the "tech preview branch 1" with Jetty 9, Tomcat 9 and 
>> Undertow 2.0.x - the branch using Servlet API 4
>>  - pax-web-7.4.x - the "tech preview branch 2" with Jetty 9, Tomcat 9 and 
>> Undertow 2.2.x - the branch using Servlet API 4 and Undertow 2.2.x which 
>> "got back" OSGi metadata since 2.2.5.Final 
>> (https://issues.redhat.com/browse/UNDERTOW-1852 
>> <https://issues.redhat.com/browse/UNDERTOW-1852>)
>> 
>> Karaf 4.3.x chose pax-web-7.3.x despite it's still not proper OSGi CMPN 7 
>> implementation (the goal is to have Pax Web 8 compliant to OSGi CMPN 7 
>> specification, but it reaally required lots of fundamental changes, 
>> I was describing for at least a year).
>> 
>> I hope this clarifies the state of Pax Web.
>> 
>> kind regards
>> Grzegorz Grzybek
>> 
>> pon., 12 kwi 2021 o 20:26 Jean-Baptiste Onofré > 
>> napisał(a):
>> Hi,
>> 
>> It’s already plan and I have Pax Web releases on the way, including this and 
>> other fixes.
>> 
>> So, don’t worry, we will have the Pax Web releases tomorrow.
>> 
>> Regards
>> JB
>> 
>>> Le 12 avr. 2021 à 18:25, 'Fabien S' via OPS4J > a 
>>> écrit :
>>> 
>>> I created this issue about the upgrade to Jetty 9.4.39.v20210325 because 
>>> some lower version are impacted by CVE-2021-28165.
>>> 
>>> https://github.com/ops4j/org.ops4j.pax.web/issues/1594 
>>> <https://github.com/ops4j/org.ops4j.pax.web/issues/1594>
>>> 
>>> I wanted to try to do the change by myself, and I hoped that creating a 
>>> pull request would allow me to run the regression tests but in fact I don't 
>>> know how to trigger these tests. I'm not even sure that I created a commit 
>>> for the right target branch. Could anybody 

Re: upgrade to Jetty 9.4.39.v20210325

[Jean-Baptiste Onofré]

I’m doing on all branches.

Regards
JB

> Le 13 avr. 2021 à 08:30, Grzegorz Grzybek  a écrit :
> 
> Hello
> 
> Yes - an upgrade to Jetty 9.4.39 is fine. Just no need to do it in `main` 
> branch, because I've already updated it locally in very not-ready-yet code.
> 
> regards
> Grzegorz
> 
> wt., 13 kwi 2021 o 08:25 'Fabien S' via OPS4J  <mailto:ops4j@googlegroups.com>> napisał(a):
> Hi, thank you a lot for your help and explanations!
> Regarding the vulnerability, maybe it's possible to include in the code of 
> the application this work-around:
> https://github.com/eclipse/jetty.project/security/advisories/GHSA-26vr-8j45-3r4w
>  
> <https://github.com/eclipse/jetty.project/security/advisories/GHSA-26vr-8j45-3r4w>
> but I'm not sure it would handle all the cases, so relying on an official fix 
> from Jetty would be safer.
> 
> Cheers,
> Fabien
> 
> On Monday, 12 April 2021 at 20:50:48 UTC+2 gr.gr...@gmail.com 
> <mailto:gr.gr...@gmail.com> wrote:
> Hello
> 
> Just an information about Pax Web and main branch. I've recently renamed 
> "master-improvements" branch to "main" - I had two goals with this action:
>  - show that my long-developed "master-improvements" branch, where I've 
> literally refactored big part of Pax Web (to adjust to new Whiteboard 
> requirements) is ready to be worked on by others
>  - adjust to new standards, where "main" is the new "master"
> 
> Unfortunately this new "main" branch is still far from being released (I had 
> few months break again and I have to "feel" it again) and usual practice, 
> where some change is always made in newest branch and then backported to 
> maintenance branches. "main" branch is MUCH different than pax-web-7.2.x – 
> pax-web-7.4.x branches.
> 
> Also, remember that 3 active maintenance branches of Pax Web are:
>  - pax-web-7.2.x - the branch used by Karaf 4.2.x, with Jetty 9, Tomcat 8 and 
> Undertow 1.x - the branch using Servlet API 3.1
>  - pax-web-7.3.x - the "tech preview branch 1" with Jetty 9, Tomcat 9 and 
> Undertow 2.0.x - the branch using Servlet API 4
>  - pax-web-7.4.x - the "tech preview branch 2" with Jetty 9, Tomcat 9 and 
> Undertow 2.2.x - the branch using Servlet API 4 and Undertow 2.2.x which "got 
> back" OSGi metadata since 2.2.5.Final 
> (https://issues.redhat.com/browse/UNDERTOW-1852 
> <https://issues.redhat.com/browse/UNDERTOW-1852>)
> 
> Karaf 4.3.x chose pax-web-7.3.x despite it's still not proper OSGi CMPN 7 
> implementation (the goal is to have Pax Web 8 compliant to OSGi CMPN 7 
> specification, but it reaally required lots of fundamental changes, I 
> was describing for at least a year).
> 
> I hope this clarifies the state of Pax Web.
> 
> kind regards
> Grzegorz Grzybek
> 
> pon., 12 kwi 2021 o 20:26 Jean-Baptiste Onofré > 
> napisał(a):
> Hi,
> 
> It’s already plan and I have Pax Web releases on the way, including this and 
> other fixes.
> 
> So, don’t worry, we will have the Pax Web releases tomorrow.
> 
> Regards
> JB
> 
>> Le 12 avr. 2021 à 18:25, 'Fabien S' via OPS4J > a 
>> écrit :
>> 
>> I created this issue about the upgrade to Jetty 9.4.39.v20210325 because 
>> some lower version are impacted by CVE-2021-28165.
>> 
>> https://github.com/ops4j/org.ops4j.pax.web/issues/1594 
>> <https://github.com/ops4j/org.ops4j.pax.web/issues/1594>
>> 
>> I wanted to try to do the change by myself, and I hoped that creating a pull 
>> request would allow me to run the regression tests but in fact I don't know 
>> how to trigger these tests. I'm not even sure that I created a commit for 
>> the right target branch. Could anybody assist me please?
>> 
>> Cheers,
>> Fabien
>> 
>> -- 
>> -- 
>> --
>> OPS4J - http://www.ops4j.org <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+un...@googlegroups.com <>.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/ops4j/c195a8ad-7e90-47ff-b4ff-aa0435e58528n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/ops4j/c195a8ad-7e90-47ff-b4ff-aa0435e58528n%40googlegroups.com?utm_medium=email_source=footer>.
> 
> 
> -- 
> -- 
> --
> OPS4J - http://www.ops4j.org <http://www.ops4j.org/> 

Re: upgrade to Jetty 9.4.39.v20210325

[Jean-Baptiste Onofré]

Hi,

It’s already plan and I have Pax Web releases on the way, including this and 
other fixes.

So, don’t worry, we will have the Pax Web releases tomorrow.

Regards
JB

> Le 12 avr. 2021 à 18:25, 'Fabien S' via OPS4J  a 
> écrit :
> 
> I created this issue about the upgrade to Jetty 9.4.39.v20210325 because some 
> lower version are impacted by CVE-2021-28165.
> 
> https://github.com/ops4j/org.ops4j.pax.web/issues/1594
> 
> I wanted to try to do the change by myself, and I hoped that creating a pull 
> request would allow me to run the regression tests but in fact I don't know 
> how to trigger these tests. I'm not even sure that I created a commit for the 
> right target branch. Could anybody assist me please?
> 
> Cheers,
> Fabien
> 
> -- 
> -- 
> --
> OPS4J - http://www.ops4j.org  - ops4j@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/c195a8ad-7e90-47ff-b4ff-aa0435e58528n%40googlegroups.com
>  
> .

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@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/98638032-D996-4E58-BC9E-42B18FD34872%40gmail.com.

Re: [PAX WEB] Default branch name change

[Jean-Baptiste Onofré]

+1

Thanks for tackling this.

Regards
JB

> Le 9 avr. 2021 à 12:26, Grzegorz Grzybek  a écrit :
> 
> Hello
> 
> I just wanted to write that I've changed the default branch in 
> https://github.com/ops4j/org.ops4j.pax.web 
>  project.
> According to new standards, it's "main" branch.
> 
> What's more, I kept previous "master" branch and the new "main" is actually 
> my long-developed "master-improvements" branch, where I really try hard 
> (sorry again for the delay) to rewrite several areas (probably all) to 
> conform to Whiteboard, Http and Web Applications specifications 
> (respectively: chapters 140, 102 and 128 of OSGi CMPN).
> 
> kind regards
> Grzegorz Grzybek
> 
> -- 
> -- 
> --
> OPS4J - http://www.ops4j.org  - ops4j@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/CAAdXmhoakxOwDaq63Lu-s9Z6sZ9M3DeHWn0tdtT1ssD4OWuy%3Dw%40mail.gmail.com
>  
> .

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@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/F097AA72-1C8D-4F98-8F55-2250A52AE29C%40gmail.com.

Re: [PAX-WEB] Warning "failed to parse and instantiate of javax.servlet.ServletContainerInitializer in classpath"

[Jean-Baptiste Onofré]

Hi,

I would check the TCCL and the import. It’s hard to say without knowing the 
weaving.

Regards
JB

> Le 13 févr. 2021 à 16:18, Alain Picard  a 
> écrit :
> 
> Bonjour Jean-Baptiste,
> 
> This is not running under Karaf, just running as a standard PDE OSGi project 
> and it is using Pax Web (7.2..21) with Jetty (9.4.36)
> 
> Here's a small snippet of the log, with some failed, 1 success and 1 skipped.
> 09:18:11.955  [paxweb-config-1-thread-1] ::: INFO  
> o.o.p.w.u.ServletContainerInitializerScanner - will add 
> ch.qos.logback.classic.servlet.LogbackServletContainerInitializer to 
> ServletContainerInitializers
> 09:18:11.957  [paxweb-config-1-thread-1] ::: WARN  
> o.o.p.w.u.ServletContainerInitializerScanner - failed to parse and 
> instantiate of javax.servlet.ServletContainerInitializer in classpath
> 09:18:11.958  [paxweb-config-1-thread-1] ::: INFO  
> o.o.p.w.u.ServletContainerInitializerScanner - will add 
> org.eclipse.jetty.websocket.server.NativeWebSocketServletContainerInitializer 
> to ServletContainerInitializers
> 09:18:11.962  [paxweb-config-1-thread-1] ::: INFO  
> o.o.p.w.u.ServletContainerInitializerScanner - added 
> ServletContainerInitializer: 
> org.eclipse.jetty.websocket.server.NativeWebSocketServletContainerInitializer
> 09:18:11.962  [paxweb-config-1-thread-1] ::: INFO  
> o.o.p.w.u.ServletContainerInitializerScanner - will add 
> org.apache.jasper.servlet.JasperInitializer to ServletContainerInitializers
> 09:18:11.962  [paxweb-config-1-thread-1] ::: INFO  
> o.o.p.w.u.ServletContainerInitializerScanner - Skipt 
> org.apache.jasper.servlet.JasperInitializer, because specialized handler will 
> be present
> 09:18:11.962  [paxweb-config-1-thread-1] ::: INFO  
> o.o.p.w.u.ServletContainerInitializerScanner - will add 
> ch.qos.logback.classic.servlet.LogbackServletContainerInitializer to 
> ServletContainerInitializers
> 
> Let me know if I can provide more detailed information or perform additional 
> debugging.
> 
> Alain
> On Saturday, February 13, 2021 at 9:55:49 AM UTC-5 jeanbapti...@gmail.com 
> wrote:
> Hi Alain,
> 
> Are you using Karaf or you are running it on your own ?
> 
> That would be great if you describe a bit the environment, especially which 
> Pax projects are you using (pax logging, pax web, …).
> 
> Regards
> JB
> 
> 
>> Le 13 févr. 2021 à 14:48, Alain Picard > > a écrit :
>> 
> 
>> I am getting a few hundred of these in my log. I have found and read the 
>> following post  from 2015 
>> but that is not really answering the question.
>> 
>> First it would be great to update the log message to provide some context 
>> like:
>> log.warn("failed to parse and instantiate of 
>> javax.servlet.ServletContainerInitializer ({}) in classpath of context 
>> bundle {}", className, bundle);
>> 
>> But I seem to be having issue with a couple of cases. A few dealing with 
>> Atmosphere and most from 
>> ch.qos.logback.classic.servlet.LogbackServletContainerInitializer. When 
>> looking at the bundle, those bundles are not even aware of logback and will 
>> not find the class, and it's not visible to the server bundle either. More 
>> than likely that bundle is transitively reachable, but that doesn't imply 
>> downstream visibility, which is what is required for the bundle or server 
>> bundle to load the class.
>> 
>> I'm not sure at that point why that would trigger a warning and or why we 
>> would want to apply our search transitively in the first place, but I might 
>> be missing some obvious use cases.
>> 
>> Thanks for enlightening me.
>> 
>> Cheers,
>> Alain
>> 
>> 
> 
>> -- 
>> -- 
>> --
>> 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+un...@googlegroups.com 
>> .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/ops4j/e9436f50-0e74-473c-a9bc-02b9e35a845dn%40googlegroups.com
>>  
>> .
> 
> 
> -- 
> -- 
> --
> OPS4J - http://www.ops4j.org  - ops4j@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/ee728336-67f8-4b6e-8359-bf330215e5dcn%40googlegroups.com
>  
> .

-- 
-- 
--
OPS4J - http://www.ops4j.org 

Re: [PAX-WEB] Warning "failed to parse and instantiate of javax.servlet.ServletContainerInitializer in classpath"

[Jean-Baptiste Onofré]

Hi Alain,

Are you using Karaf or you are running it on your own ?

That would be great if you describe a bit the environment, especially which Pax 
projects are you using (pax logging, pax web, …).

Regards
JB

> Le 13 févr. 2021 à 14:48, Alain Picard  a 
> écrit :
> 
> I am getting a few hundred of these in my log. I have found and read the 
> following post  from 2015 
> but that is not really answering the question.
> 
> First it would be great to update the log message to provide some context 
> like:
> log.warn("failed to parse and instantiate of 
> javax.servlet.ServletContainerInitializer ({}) in classpath of context bundle 
> {}", className, bundle);
> 
> But I seem to be having issue with a couple of cases. A few dealing with 
> Atmosphere and most from 
> ch.qos.logback.classic.servlet.LogbackServletContainerInitializer. When 
> looking at the bundle, those bundles are not even aware of logback and will 
> not find the class, and it's not visible to the server bundle either. More 
> than likely that bundle is transitively reachable, but that doesn't imply 
> downstream visibility, which is what is required for the bundle or server 
> bundle to load the class.
> 
> I'm not sure at that point why that would trigger a warning and or why we 
> would want to apply our search transitively in the first place, but I might 
> be missing some obvious use cases.
> 
> Thanks for enlightening me.
> 
> Cheers,
> Alain
> 
> 
> -- 
> -- 
> --
> OPS4J - http://www.ops4j.org  - ops4j@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/e9436f50-0e74-473c-a9bc-02b9e35a845dn%40googlegroups.com
>  
> .

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@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/FD9DDBB8-0953-4CBB-AB05-0EED5BE20617%40gmail.com.

Re: Migration from Jira to Github issues

[Jean-Baptiste Onofré]

Hi,

It sounds good to me !

Thanks,
Regards
JB

> Le 1 févr. 2021 à 09:38, Grzegorz Grzybek  a écrit :
> 
> Hello
> 
> Some time ago[1] we were discussing the idea whether to move to Github issues 
> and move away from Jira. The main reason was related to registration/spam 
> problems at cloud Jira/Confluence.
> I think all involved agreed that it's a good idea.
> 
> I've prepared a raw tool[2] with only a `main()` method that uses 3 
> configuration files:
> * etc/users.properties which map Cloud Jira user UUIDs into names (please let 
> me know if it's desired or not)
> * etc/application-template.properties, which should be copied to (now 
> .gitignored) etc/application.properties that configure github token, org and 
> repository
> * data/*.xml which contains all Jira issues exported from "all issues report" 
> at Cloud Jira
> 
> I don't want to migrate all the projects without some feedback ;)
> For now I took PAXTRANSX Jira issues and I've imported them into my 
> project[3]. Please see if the format I used is sufficient.
> 
> I used the unofficial Github API described here[4] which was also used when 
> Spring projects were migrating[5].
> Links to users and attachments still lead to Cloud Jira (just as with Spring 
> issues).
> 
> I used jsoup to parse HTML comments and descriptions and I did trivial HTML → 
> Markdown translation, so at least all the formatting used in PAXTRANSX 
> project is preserved. When I see more formatting in other OPS4J projects, 
> I'll handle it.
> 
> I want to start with projects like PAXJDBC, PAXJMS and PAXURL and at some 
> point migrate PAXWEB project (around the time I finally release Pax Web 8).
> 
> looking forward to your feedback!
> Grzegorz Grzybek
> ---
> [1]: https://groups.google.com/g/ops4j/c/RE_r3cxtwSQ 
> 
> [2]: https://github.com/ops4j/org.ops4j.tools/tree/master/jira2github 
> 
> [3]: https://github.com/grgrzybek/test2github/issues 
> 
> [4]: https://gist.github.com/jonmagic/5282384165e0f86ef105 
> 
> [5]: 
> https://spring.io/blog/2019/01/15/spring-framework-s-migration-from-jira-to-github-issues
>  
> 
> 
> -- 
> -- 
> --
> OPS4J - http://www.ops4j.org  - ops4j@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/CAAdXmhqCh4UpLpyCVuXZ%2BrHe92DOnRiM511c6d3LkBz7R%3DJvyQ%40mail.gmail.com
>  
> .

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@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/04288C9A-14AB-4B64-A49F-07F51D3F06D6%40gmail.com.

Re: Cannot start Felix-Fileinstall in pax-container-forked

[Jean-Baptiste Onofré]

Hi Muza,

Do you provide file install system properties in the test 
(felix.fileinstall.dir, etc) ?

Regards
JB

> Le 8 déc. 2020 à 20:20, Muza  a écrit :
> 
> Hello.
> 
> I was using pax-exam-container-forked, and having trouble starting 
> org.apache.felix.fileinstall bundle. The test-container freezes and does not 
> respond. 
> 
> Would be much appreciated if someone can give an advice on how I can resolve 
> this error (e.g configuration adjustments)
> 
> 
> Best regards,
> Muza
> 
> -- 
> -- 
> --
> OPS4J - http://www.ops4j.org  - ops4j@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/ad732cb2-e7d7-42f6-b117-7bedf07cf0den%40googlegroups.com
>  
> .

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@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/849E2CC5-9687-46EE-A6A4-2BB73BED7BF0%40gmail.com.

Re: Pax Web the discovery of the Servlet Initializers seems to be fundamentally flawed.

[Jean-Baptiste Onofré]

Hi,

SpiFly can help, and you can always use direct war/webapp (not webbundle).

Regards
JB

On Sun, Nov 1, 2020 at 6:56 PM 'paul stanley' via OPS4J <
ops4j@googlegroups.com> wrote:

> Hi Grzegorz,
>
> Sorry about the delay in getting back to you.
>
> I realise your concerns about sci's from different webapps interfering
> with each other. However the SCI mechanism appears to be the way that the
> other web technologies, such as JAXRS and SpringMVC have a chance to detect
> and influence the creation of the servlet.
>
> Given that ServiceLoader architecture is being used, is it unreasonable
> that all possible instances for the SCI get asked to look at the bundle and
> initialize the context is appropriate?
>
> If not, then we need another way to extend the WebExtender with other web
> frameworks, allowing them to get  involved with servlet creation. Which
> does not include altering the webapp in some OSGI specific way.
>
> Cheers
> Paul
> On 30 Oct 2020, at 08:46, Grzegorz Grzybek  wrote:
>>
>> Hello
>>
>> czw., 29 paź 2020 o 19:50 Matt Pavlovich < m...@hyte.io> napisał(a):
>>
>>> Paul--
>>>
>>> You might checkout a BundleTracker.  A BundleTracker is ensured to get a
>>> callback for every bundle, regardless as to when your bundle started. With
>>> a BundleListener, there is a race condition that you may not be activated
>>> before some bundles that you care about.
>>>
>>
>> It's not about bundle tracker or listener. Whiteboard implementation uses
>> such tracker to ensure that when a bundle is gone, all associated contexts
>> and web elements should be deregistered.
>> It's more about which bundles should be scanned for
>> ServletContainerInitializers. imagine you install two "sets" of bundles
>> (e.g., Karaf features) - you don't want SCIs from one feature (web
>> application) to be used in another feature/web application...
>>
>> regards
>> Grzegorz Grzybek
>>
>>
>>>
>>> ref:
>>> https://docs.osgi.org/specification/osgi.core/7.0.0/util.tracker.html#d0e52020
>>>
>>> -Matt
>>>
>>> On Thursday, October 29, 2020 at 1:17:19 PM UTC-5
>>> 8.apri...@googlemail.com wrote:
>>>

 Thanks Grzegorz.  I know what you mean about doing my "normal job", I
 also have be careful as to what can be shared to the community.

 I realise that the ServiceLoader is a bit of a problem and I've already
 had to alter other standard services to be bundle-aware.  Which is why I
 think implementing a Bundle Listener could be a better approach for the
 SCI's.

 I'm out of the office for a couple of weeks so I'm going to look
 prototyping a solution when I get back.

 Cheers
 Paul
 On 29 Oct 2020, at 13:28, Grzegorz Grzybek < gr.gr...@gmail.com>
 wrote:

> Hello
>
> You're generally right. I'm working on Pax Web 8 improvements (actual,
> full implementation of OSGi CMPN R6+ Whiteboard specification + 
> HttpService
> specification + Web Applications Specification) and I tackled the problem
> of ServletContainerInitializers.
>
> The problem is that OSGi CMPN spec doesn't mention SCIs at all, only
> Web Applications Specification generally assumes that "web bundle" should
> be processed ("extended") by the implementation which involves web.xml
> parsing + fragments parsing + (possibly) "classpath scanning". See for
> example:
>
> A WAB can optionally contain a web.xml resource to specify additional
>> configuration. This web.xml must be found with the Bundle
>> *findEntries* method at the path WEB-INF/web.xml. The findEntries
>> method includes fragments, allowing the web.xml to be provided by a
>> fragment.
>>
>
> So here there's nothing about "scanning other bundles" not referred
> through "fragment" relationship.
>
> Also:
>
> Unlike a WAR, a WAB is not constrained to package classes and code
>> resources in the WEB-INF/classes directory or dependent JARs in
>> WEB-INF/lib/ only. These entries can be packaged in any way that's valid
>> for an OSGi bundle as long as such directories and JARs are part of 
>> bundle
>> class path as set with the Bundle-ClassPath header and any attached
>> fragments. JARs that are specified in the Bundle-ClassPath header are
>> treated like JARs in the WEB-INF/lib/ directory of the Servlet
>> specification. Similarly, any directory that is part of the
>> Bundle-ClassPath header is treated like WEB-INF/classes directory of the
>> Servlet specification.
>>
>
> So again - you can "bring" additional libraries to your "bundle
> classpath" by referring them in "Bundle-ClassPath" header. No scanning of
> everything (that's for example tracked by BundleListener).
>
> And about java.util.ServiceLoader (which should in theory be a
> suggestion to how ServletContainerInitializer "services" are found),
> "java.util.ServiceLoader#load(java.lang.Class, 

Re: [PROPOSAL] Release Pax Exam 5.0.0

[Jean-Baptiste Onofré]

Hi,

Just a quick update: Pax Exam 4.13.4 has been released. Now I'm working on
Pax Exam 5.0.0 with JUnit 5.x support.

Regards
JB

On Tue, Sep 29, 2020 at 8:16 AM Arnoud Glimmerveen <
arnoudglimmerv...@gmail.com> wrote:

> As a Pax Exam user I would love to see this release become available! :)
>
> On Wednesday, September 23, 2020 at 7:16:52 AM UTC+2
> jeanbapti...@gmail.com wrote:
>
>> Hi,
>>
>> just a quick update: I will cut Pax Exam 4.13.4 today.
>>
>> The purpose of Pax Exam 5.0.0 is also to upgrade to JUnit 5. So, I will
>> take time to finalize/test this.
>>
>> Thanks,
>> Regards
>> JB
>>
>> On Tue, Sep 22, 2020 at 1:45 PM Jean-Baptiste Onofré <
>> jeanbapti...@gmail.com> wrote:
>>
>>> Hi,
>>>
>>> As we fixed several issues and did some changes in Pax Exam master, I
>>> think it makes sense to cut Pax Exam 5.0.0.
>>>
>>> I have a couple of things to add but the release is almost ready.
>>>
>>> No objection ?
>>>
>>> Thanks,
>>> Regards
>>> JB
>>>
>> --
> --
> --
> OPS4J - http://www.ops4j.org - ops4j@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/01f9720a-e93e-43db-820d-fe0ee251ab10n%40googlegroups.com
> <https://groups.google.com/d/msgid/ops4j/01f9720a-e93e-43db-820d-fe0ee251ab10n%40googlegroups.com?utm_medium=email_source=footer>
> .
>

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@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/CAB8EV3Q2fqZkTYwcX4g%3DL9%2B0o9NQ3B4_SuTFiD-keBM31VV%3Dqg%40mail.gmail.com.

Re: [PROPOSAL] Release Pax Exam 5.0.0

[Jean-Baptiste Onofré]

Hi,

just a quick update: I will cut Pax Exam 4.13.4 today.

The purpose of Pax Exam 5.0.0 is also to upgrade to JUnit 5. So, I will
take time to finalize/test this.

Thanks,
Regards
JB

On Tue, Sep 22, 2020 at 1:45 PM Jean-Baptiste Onofré <
jeanbaptiste.ono...@gmail.com> wrote:

> Hi,
>
> As we fixed several issues and did some changes in Pax Exam master, I
> think it makes sense to cut Pax Exam 5.0.0.
>
> I have a couple of things to add but the release is almost ready.
>
> No objection ?
>
> Thanks,
> Regards
> JB
>

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@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/CAB8EV3Q7GW5U%2BpPrh9-44%2BnptVLgY0%2BRs3EuCHTOmK3g7uCNmQ%40mail.gmail.com.

[PROPOSAL] Release Pax Exam 5.0.0

[Jean-Baptiste Onofré]

Hi,

As we fixed several issues and did some changes in Pax Exam master, I think
it makes sense to cut Pax Exam 5.0.0.

I have a couple of things to add but the release is almost ready.

No objection ?

Thanks,
Regards
JB

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@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/CAB8EV3TDTkjhGfpFWVN2weRXNsn5phRE6d-bbLcOigW20ep%3DBg%40mail.gmail.com.

Re: [Pax-Web] Update Tomcat Versions

[Jean-Baptiste Onofré]

Hi Stephan,

Thanks for the update.

A side topic we already discussed a bit with Greg is about the effort to
have more "isolated" bundles for jetty, tomcat and undertow. Today, we are
suffering a lot to maintain at same level the Pax Web API with the three
containers. Clearly some methods of the API are mostly Jetty related and
not easy to implement with other containers.
So, I wonder at some point if we should not have pure httpService impl at a
high level, and a specific service/API for each container.

It would allow us to simplify a lot Pax Web and move forward faster.

Regards
JB


On Mon, Jul 6, 2020 at 4:28 PM Stephan Siano  wrote:

> Hi,
>
> I released the two tipi versions. I also updated the 7.2.x branch and
> created a pull request for the 7.3.x branch. In order to achieve this, I
> had to update some integration tests (mainly timing and dependency issues)
> to get the tomcat integration tests working both with the old and the
> updated tomcat version.
>
> I am a bit unsure how to proceed with the master and the
> master-improvements branch. The master branch does not seem very active to
> me (and is still on tomcat 8.5), the master-improvements branch seems to be
> work in progress. What is the current state of the tests in these branches?
> Should I update both of them? If yes, to which Tomcat version should I
> update the master branch, 8.5.56 as 7.2.x?
>
> Best regards
> Stephan
>
>
> Am Dienstag, 23. Juni 2020 16:03:22 UTC+2 schrieb Grzegorz Grzybek:
>>
>> Hello
>>
>>
>>- Tomcat 8 update requires tipi release.
>>- Pax Web 7.3.x already uses Tomcat 9 (I've released the tipi
>>packages, based (as of pax web 7.3.7) 9.0.16 - remember, 7.3.x is the 
>> "tech
>>preview release" with Servlet API 4 == Tomcat 9, Undertow 2 and
>>unfortunately same Jetty 9 (because Jetty 10 will be Servlet API 4, but at
>>the same time, it switches to jakarta.* packages)
>>- Pax Web 8 will use latest Tomcat 9 and get rid of tipi packages
>>(Tomcat jars will be exported from pax-web-tomcat and 
>> pax-web-tomcat-common
>>bundles (the latter is new)).
>>
>> regards
>> Grzegorz Grzybek
>>
>> wt., 23 cze 2020 o 15:46 Jean-Baptiste Onofré 
>> napisał(a):
>>
>>> Hi,
>>>
>>> It sounds good. Tomcat 8.x should be easy, Tomcat 9 probably needs API
>>> updates.
>>>
>>> Regards
>>> JB
>>>
>>>
>>> On Tue, Jun 23, 2020 at 9:19 AM Stephan Siano  wrote:
>>>
>>>> Hi,
>>>>
>>>> It has been quite a while since the Tomcat version was updated in
>>>> Pax-Web. The 7.2.x branch references Tomcat 8.5.32 and the 3.x and master
>>>> branches references Tomcat 9.0.16.
>>>>
>>>> These versions are from June 2018 and February 2019, so I think we
>>>> should update to more recent versions 8.5.56 and 9.0.36.
>>>>
>>>> What do you think?
>>>>
>>>> Best regards
>>>> Stephan
>>>>
>>>> --
>>>> --
>>>> --
>>>> 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 op...@googlegroups.com.
>>>> To view this discussion on the web visit
>>>> https://groups.google.com/d/msgid/ops4j/e532dfc0-9e4a-40ad-b427-3c28130e4a36o%40googlegroups.com
>>>> <https://groups.google.com/d/msgid/ops4j/e532dfc0-9e4a-40ad-b427-3c28130e4a36o%40googlegroups.com?utm_medium=email_source=footer>
>>>> .
>>>>
>>> --
>>> --
>>> --
>>> 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 op...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/ops4j/CAB8EV3Th0_sAKCEDpRWmfT%3DxCdiENqw0yyXGvqEd2mnXVhYyJA%40mail.gmail.com
>>> <https://groups.google.com/d/msgid/ops4j/CAB8EV3Th0_sAKCEDpRWmfT%3DxCdiENqw0yyXGvqEd2mnXVhYyJA%40mail.gmail.com?utm_medium=email_source=footer>
>>> .
>>>
>> --
> --
> --
> OPS4J - http://www.ops

Re: [Pax-Web] Update Tomcat Versions

[Jean-Baptiste Onofré]

Hi,

It sounds good. Tomcat 8.x should be easy, Tomcat 9 probably needs API
updates.

Regards
JB


On Tue, Jun 23, 2020 at 9:19 AM Stephan Siano  wrote:

> Hi,
>
> It has been quite a while since the Tomcat version was updated in Pax-Web.
> The 7.2.x branch references Tomcat 8.5.32 and the 3.x and master branches
> references Tomcat 9.0.16.
>
> These versions are from June 2018 and February 2019, so I think we should
> update to more recent versions 8.5.56 and 9.0.36.
>
> What do you think?
>
> Best regards
> Stephan
>
> --
> --
> --
> OPS4J - http://www.ops4j.org - ops4j@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/e532dfc0-9e4a-40ad-b427-3c28130e4a36o%40googlegroups.com
> 
> .
>

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@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/CAB8EV3Th0_sAKCEDpRWmfT%3DxCdiENqw0yyXGvqEd2mnXVhYyJA%40mail.gmail.com.

Re: Pax exam test failing with gave up waiting for service org.ops4j.pax.exam.ProbeInvoker

[Jean-Baptiste Onofré]

Hi Christian,

Don't you have anything in the log at bootstrap ? Most of the time, when I
have this kind of problem, it's because there's something missing to
actually start the framework.

Regards
JB

On Sat, Jun 6, 2020 at 12:30 PM Christian Schneider 
wrote:

> I have a pax exam test that fails consistently with "gave up waiting for
> service org.ops4j.pax.exam.ProbeInvoker" see exception below.
> The strange thing is that just before this exception the pax exam probe
> bundle finds my test and registers the ProbeInvoker service.
>
> Any idea what is going on there?
>
> I am using pax exam 4.13.0 and the native container.
>
> Christian
>
> ---
>
> 2020-06-06 12:26:29,372 DEBUG
> org.ops4j.pax.exam.nat.internal.NativeTestContainer Installed bundle
> PAXEXAM-PROBE-1964da24-e6fc-4516-b617-578e6e26e5b2 as Bundle ID 42
>
> org.ops4j.pax.logging.pax-logging-api[org.ops4j.pax.swissbox.extender.BundleWatcher]
> : Scanning bundle [PAXEXAM-PROBE-1964da24-e6fc-4516-b617-578e6e26e5b2]
>
> org.ops4j.pax.logging.pax-logging-api[org.ops4j.pax.swissbox.extender.BundleWatcher]
> : Found resources [ManifestEntry{ key=PaxExam-Executable,
> value=PaxExam-8603a386-8755-430b-bd65-56d3da212f47, }, ManifestEntry{
> key=PaxExam-8603a386-8755-430b-bd65-56d3da212f47,
> value=com.adobe.granite.distribution.journal.pipeline.it.osgi.PipelineOSGiTest;test
> }]
>
> org.ops4j.pax.exam.extender.service[org.ops4j.pax.exam.raw.extender.intern.Probe]
> : Test PaxExam-Executable to be in
> PaxExam-8603a386-8755-430b-bd65-56d3da212f47,
>
> org.ops4j.pax.exam.extender.service[org.ops4j.pax.exam.raw.extender.intern.Probe]
> : Test PaxExam-8603a386-8755-430b-bd65-56d3da212f47 to be in
> PaxExam-8603a386-8755-430b-bd65-56d3da212f47,
>
> org.ops4j.pax.exam.extender.service[org.ops4j.pax.exam.raw.extender.intern.Probe]
> : Registering Service: org.ops4j.pax.exam.ProbeInvoker with
> Probe-Signature="PaxExam-8603a386-8755-430b-bd65-56d3da212f47" and
> expression="com.adobe.granite.distribution.journal.pipeline.it.osgi.PipelineOSGiTest;test"
>
>
> ---
>
> org.ops4j.pax.swissbox.tracker.ServiceLookupException: gave up waiting for
> service org.ops4j.pax.exam.ProbeInvoker
> at
> org.ops4j.pax.swissbox.tracker.ServiceLookup.getService(ServiceLookup.java:161)
> at
> org.ops4j.pax.swissbox.tracker.ServiceLookup.getService(ServiceLookup.java:104)
> at
> org.ops4j.pax.exam.nat.internal.NativeTestContainer.call(NativeTestContainer.java:110)
> at
> org.ops4j.pax.exam.spi.reactors.AllConfinedStagedReactor.invoke(AllConfinedStagedReactor.java:84)
> at
> org.ops4j.pax.exam.junit.impl.ProbeRunner$2.evaluate(ProbeRunner.java:267)
> at
> org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
> at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
> at org.ops4j.pax.exam.junit.impl.ProbeRunner.run(ProbeRunner.java:98)
> at org.ops4j.pax.exam.junit.PaxExam.run(PaxExam.java:93)
> at
> org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:89)
> at
> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:41)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:542)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:770)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:464)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:210)
>
>
> --
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Computer Scientist
> http://www.adobe.com
>
> --
> --
> --
> OPS4J - http://www.ops4j.org - ops4j@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/CAH6_LNmFDjcgQ48CgYoPg72mV4ifiruZ8nHsmnss9Si%2BfQjE%3Dg%40mail.gmail.com
> 
> .
>

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@googlegroups.com

--- 
You received this message because you are subscribed to the Google Groups 
"OPS4J" group.
To unsubscribe from 

Re: Cannot start pax-web-jetty-bundle - Package uses conflict: Import-Package: org.ops4j.pax.web.service

[Jean-Baptiste Onofré]

Hi,

If you take a look on the Jetty Karaf feature, you can see the
javax.servlet is installed as bundle:

https://github.com/ops4j/org.ops4j.pax.web/blob/pax-web-7.2.x/pax-web-features/src/main/resources/features.xml#L38

So you have to do the same. As Pax Web is "container" agnostic (meaning it
can run tomcat, jetty, undertow), the API can't use package provided by
impl bundle.
That's why you have to install javax.servlet bundle for pax-web-api.

Furthermore, pax-web-jetty bundle also imports javax.servlet:
https://github.com/ops4j/org.ops4j.pax.web/blob/pax-web-7.2.x/pax-web-jetty/pom.xml#L68

So, if you just install javax.servlet bundle, it will just run fine.

PS: Karaf simplify a lot the installation thanks to the features.

Regards
JB

On Fri, May 8, 2020 at 12:00 PM Daniel Stoch  wrote:

> Hi,
>
> I have a strange error when trying to run a couple of bundles (using
> Equinox) including 4 from Pax-Web 7.2.10. In some other, more complex
> scenario, these Pax-Web also starts properly but I cannot find why.
> - pax-web-api
> - pax-web-spi
> - pax-web-jetty-bundle
> - pax-web-extender-whiteboard
>
> These bundles could not be resolved:
> - javax.servlet is exported by pax-web-jetty-bundle and it is needed by
> pax-web-api
> - but pax-web-api exports org.ops4j.pax.web.service which is required by
> pax-web-jetty-bundle
>
> org.osgi.framework.BundleException: The bundle
> "org.ops4j.pax.web.pax-web-api_7.2.10 [12]" could not be resolved. Reason:
> Missing Constraint: Import-Package: javax.servlet; version="[2.3.0,4.0.0)"
> org.osgi.framework.BundleException: The bundle
> "org.ops4j.pax.web.pax-web-jetty-bundle_7.2.10 [5]" could not be resolved.
> Reason: Package uses conflict: Import-Package: org.ops4j.pax.web.service;
> version="7.2.10"
> org.osgi.framework.BundleException: The bundle
> "org.ops4j.pax.web.pax-web-extender-whiteboard_7.2.10 [9]" could not be
> resolved. Reason: Missing Constraint: Import-Package:
> org.ops4j.pax.web.service; version="7.2.10"
> org.osgi.framework.BundleException: The bundle
> "org.ops4j.pax.web.pax-web-spi_7.2.10 [20]" could not be resolved. Reason:
> Missing Constraint: Import-Package: org.ops4j.pax.web.service;
> version="7.2.10"
>
>
> How to solve this problem (what can be wrong, how to diagnose it) or what
> am i doing wrong?
>
> --
> Best regards,
> Daniel Stoch
>
> --
> --
> --
> OPS4J - http://www.ops4j.org - ops4j@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/05b0f11c-54c2-46b2-a30a-11bf5b8a40ea%40googlegroups.com
> 
> .
>

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@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/CAB8EV3SitHTEPFoKL%3D8WLgkG1heADmLqf5zDfjBAwpz%2B_LzHrw%40mail.gmail.com.

Re: Pax Logging loses track of loggers because of change made when you added generics in December 2015

[Jean-Baptiste Onofré]

Good, thanks for the update.

Regards
JB

On Mon, May 4, 2020 at 10:43 AM Grzegorz Grzybek 
wrote:

> Hello
>
> Nope, it's not. Though I've enhanced the memory-related tests. And I'll
> prepare new 1.11.x/2.0.x releases too, because of
> https://ops4j1.jira.com/browse/PAXLOGGING-312 ==
> https://issues.apache.org/jira/browse/LOG4J2-2819 == CVE-2020-9488 soon.
>
> regards
> Grzegorz Grzybek
>
> pon., 4 maj 2020 o 10:41 Jean-Baptiste Onofré <
> jeanbaptiste.ono...@gmail.com> napisał(a):
>
>> Hi Grzegorz,
>>
>> Pax Logging 1.11.x is not impacted ?
>>
>> Regards
>> JB
>>
>> On Mon, May 4, 2020 at 10:40 AM Grzegorz Grzybek 
>> wrote:
>>
>>> Hello again
>>>
>>> Without waiting, I've just released pax-logging 1.10.6 version - I hope
>>> it'll solve all your (Monica Ron) problems ;)
>>>
>>> regards
>>> Grzegorz Grzybek
>>>
>>> pon., 4 maj 2020 o 09:10 Grzegorz Grzybek 
>>> napisał(a):
>>>
>>>> Hello³
>>>>
>>>> And finally - many many thanks for your patch! I'm grateful because
>>>> after applying your patch without changes, my Memory tests (extended to
>>>> cover all remaining logging APIs/facades) pass without memory leaks on
>>>> -Xmx64m.
>>>>
>>>> The change is:
>>>> https://github.com/ops4j/org.ops4j.pax.logging/commit/665cf32d53c9c0ea3316b9ab15a36a909bac78ad
>>>>
>>>> Now the last thing is - if you want a release 1.10.6, just let me know.
>>>>
>>>> kind regards
>>>> Grzegorz Grzybek
>>>>
>>>> pon., 4 maj 2020 o 08:43 Grzegorz Grzybek 
>>>> napisał(a):
>>>>
>>>>> Hello²
>>>>>
>>>>> In Pax Logging 1.10.x it's not that good.
>>>>>
>>>>>  - org.ops4j.pax.logging.log4jv2.Log4jv2Logger - 10001 instances - ok
>>>>>  - org.ops4j.pax.logging.log4j2.internal.PaxLoggerImpl - 10010
>>>>> instances - ok
>>>>>  - org.apache.logging.log4j.core.Logger - 10010 instances - ok
>>>>>  - org.ops4j.pax.logging.internal.TrackingLogger - 60011 instances - ok
>>>>>  - org.apache.log4j.logger - 185599 instances - not ok
>>>>>  - org.ops4j.pax.logging.avalon.AvalongLogger - 185599 instances - not
>>>>> ok
>>>>>  - org.apache.commons.logging.internal.JclLogger - 185600 instances -
>>>>> not ok
>>>>>  - org.apache.juli.logging.internal.JuliLogger - 185600 instances -
>>>>> not ok
>>>>>
>>>>> SLF4J, JBossLogging seems to be properly GCed. Log4j2 loggers are ok.
>>>>> Log4j1, Avalon, JCL and JULI are broken in Pax Logging 1.10.x
>>>>>
>>>>> Checking your patches now ;)
>>>>>
>>>>> regards
>>>>> Grzegorz Grzybek
>>>>>
>>>>> pon., 4 maj 2020 o 08:02 Grzegorz Grzybek 
>>>>> napisał(a):
>>>>>
>>>>>> Hello
>>>>>>
>>>>>> FYI, I've changed the memory tests to do logging via 7 "frontends"
>>>>>> for each of 3 "backends". These frontends are:
>>>>>>
>>>>>> org.slf4j.Logger slf4jLogger =
>>>>>> org.slf4j.LoggerFactory.getLogger(name);
>>>>>> slf4jLogger.trace("TRACE through SLF4J");
>>>>>>
>>>>>> org.apache.commons.logging.Log commonsLogger =
>>>>>> org.apache.commons.logging.LogFactory.getLog(name);
>>>>>> commonsLogger.trace("TRACE through Apache Commons Logging");
>>>>>>
>>>>>> org.apache.juli.logging.Log juliLogger =
>>>>>> org.apache.juli.logging.LogFactory.getLog(name);
>>>>>> juliLogger.trace("TRACE through JULI Logging");
>>>>>>
>>>>>> org.apache.avalon.framework.logger.Logger avalonLogger =
>>>>>> org.ops4j.pax.logging.avalon.AvalonLogFactory.getLogger(name);
>>>>>> avalonLogger.debug("DEBUG through Avalon Logger API");
>>>>>>
>>>>>> org.jboss.logging.Logger jbossLogger =
>>>>>> org.jboss.logging.Logger.getLogger(name);
>>>>>> jbossLogger.trace("TRACE through JBoss Logging Logger API");
>>>>>>
>>>>>> org.apache.log4j.Logger log4j1Logger =
>>>>>> org.a

Re: Pax Logging loses track of loggers because of change made when you added generics in December 2015

[Jean-Baptiste Onofré]

Hi Grzegorz,

Pax Logging 1.11.x is not impacted ?

Regards
JB

On Mon, May 4, 2020 at 10:40 AM Grzegorz Grzybek 
wrote:

> Hello again
>
> Without waiting, I've just released pax-logging 1.10.6 version - I hope
> it'll solve all your (Monica Ron) problems ;)
>
> regards
> Grzegorz Grzybek
>
> pon., 4 maj 2020 o 09:10 Grzegorz Grzybek 
> napisał(a):
>
>> Hello³
>>
>> And finally - many many thanks for your patch! I'm grateful because after
>> applying your patch without changes, my Memory tests (extended to cover all
>> remaining logging APIs/facades) pass without memory leaks on -Xmx64m.
>>
>> The change is:
>> https://github.com/ops4j/org.ops4j.pax.logging/commit/665cf32d53c9c0ea3316b9ab15a36a909bac78ad
>>
>> Now the last thing is - if you want a release 1.10.6, just let me know.
>>
>> kind regards
>> Grzegorz Grzybek
>>
>> pon., 4 maj 2020 o 08:43 Grzegorz Grzybek 
>> napisał(a):
>>
>>> Hello²
>>>
>>> In Pax Logging 1.10.x it's not that good.
>>>
>>>  - org.ops4j.pax.logging.log4jv2.Log4jv2Logger - 10001 instances - ok
>>>  - org.ops4j.pax.logging.log4j2.internal.PaxLoggerImpl - 10010 instances
>>> - ok
>>>  - org.apache.logging.log4j.core.Logger - 10010 instances - ok
>>>  - org.ops4j.pax.logging.internal.TrackingLogger - 60011 instances - ok
>>>  - org.apache.log4j.logger - 185599 instances - not ok
>>>  - org.ops4j.pax.logging.avalon.AvalongLogger - 185599 instances - not ok
>>>  - org.apache.commons.logging.internal.JclLogger - 185600 instances -
>>> not ok
>>>  - org.apache.juli.logging.internal.JuliLogger - 185600 instances - not
>>> ok
>>>
>>> SLF4J, JBossLogging seems to be properly GCed. Log4j2 loggers are ok.
>>> Log4j1, Avalon, JCL and JULI are broken in Pax Logging 1.10.x
>>>
>>> Checking your patches now ;)
>>>
>>> regards
>>> Grzegorz Grzybek
>>>
>>> pon., 4 maj 2020 o 08:02 Grzegorz Grzybek 
>>> napisał(a):
>>>
 Hello

 FYI, I've changed the memory tests to do logging via 7 "frontends" for
 each of 3 "backends". These frontends are:

 org.slf4j.Logger slf4jLogger = org.slf4j.LoggerFactory.getLogger(name);
 slf4jLogger.trace("TRACE through SLF4J");

 org.apache.commons.logging.Log commonsLogger =
 org.apache.commons.logging.LogFactory.getLog(name);
 commonsLogger.trace("TRACE through Apache Commons Logging");

 org.apache.juli.logging.Log juliLogger =
 org.apache.juli.logging.LogFactory.getLog(name);
 juliLogger.trace("TRACE through JULI Logging");

 org.apache.avalon.framework.logger.Logger avalonLogger =
 org.ops4j.pax.logging.avalon.AvalonLogFactory.getLogger(name);
 avalonLogger.debug("DEBUG through Avalon Logger API");

 org.jboss.logging.Logger jbossLogger =
 org.jboss.logging.Logger.getLogger(name);
 jbossLogger.trace("TRACE through JBoss Logging Logger API");

 org.apache.log4j.Logger log4j1Logger =
 org.apache.log4j.Logger.getLogger(name);
 log4j1Logger.trace("TRACE through Log41 v2 API");

 org.apache.logging.log4j.Logger log4j2Logger =
 org.apache.logging.log4j.LogManager.getLogger(name);
 log4j2Logger.trace("TRACE through Log4J v2 API");

 Tests with -Xmx64M run like this:

 [INFO] Running org.ops4j.pax.logging.it.Log4J1MemoryIntegrationTest
 [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
 65.928 s - in org.ops4j.pax.logging.it.Log4J1MemoryIntegrationTest
 [INFO] Running org.ops4j.pax.logging.it.Log4J2MemoryIntegrationTest
 [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
 73.524 s - in org.ops4j.pax.logging.it.Log4J2MemoryIntegrationTest
 [INFO] Running org.ops4j.pax.logging.it.LogbackMemoryIntegrationTest
 [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
 68.748 s - in org.ops4j.pax.logging.it.LogbackMemoryIntegrationTest

 and in memory dump I saw exactly 70016 instances of PaxLoggerImpl and
 TrackingLogger - which perfectly match what I wanted to achieve with 2.0.x
 and 1.11.x

 Now I'll check these tests with 1.10.x.

 regards
 Grzegorz Grzybek

 śr., 22 kwi 2020 o 06:46 Grzegorz Grzybek 
 napisał(a):

> Thanks! Definitely I'll use these patches to fix it in the project.
>
> regards and stay healthy!
> Grzegorz Grzybek
>
> wt., 21 kwi 2020 o 14:30 Monica Ron  napisał(a):
>
>> Thanks. I decided to change my approach. I am not using the previous
>> patch anymore.
>>
>> I patched the ThreadContext (based on PAXLOGGING-244), reworked my
>> code to use the ThreadContext instead of modifying the logger name, and
>> also made some changes to the pax-logging-api to fix some of the leak
>> issues and to address inconsistencies between the various logging
>> implementations. For my pax-logging-api changes, some of it follows what
>> was done in the 1.11.x branch for PAXLOGGING-307. I no longer swap the
>> order of the 

Re: Jira or github?

[Jean-Baptiste Onofré]

+1 to use github tools.

Regards
JB

On Mon, Apr 27, 2020 at 9:15 AM 'Achim Nierbeck' via OPS4J <
ops4j@googlegroups.com> wrote:

> Hi,
>
> in the past we needed to do a "lock-down" on self-registration for the
> Jira Instance due to tremendous amount of spam in Jira Issues and on the
> confluence pages.
> This increases the burden for people to file new Issues :(
>
> How about changing to github completely for issues and documentation?
>
> regards, Achim
>
>
> --
>
> Apache Member
> Apache Karaf  Committer & PMC
> OPS4J Pax Web  Committer &
> Project Lead
> blog 
> Co-Author of Apache Karaf Cookbook 
>
> --
> --
> --
> OPS4J - http://www.ops4j.org - ops4j@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/CAD0r13feKZeAJor0EVdTFuqMgur-h2arxmrAjyT4ak8k%2B_WnXg%40mail.gmail.com
> 
> .
>

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@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/CAB8EV3S0mm3qZT6rwymeYL7mTOaS%2B_im%3DihwmkFidtvYpG2KsQ%40mail.gmail.com.

Re: [PAX-EXAM] Sporadic ServiceLookupException in JUnitProbeInvokerFactory.createProbeInvoker

[Jean-Baptiste Onofré]

Hi,

yes, it makes sense. Let me know if you want to create the PR else I will
do it.

Thanks,
Regards
JB

On Sat, Apr 25, 2020 at 8:34 AM Matteo Rulli  wrote:

> Hello,
>
> We are using Pax-Exam to run integration tests based on Apache Karaf. On
> particularly heavy tests we experience sporadic ServiceLookupException in
> JUnitProbeInvokerFactory.createProbeInvoker, something like this:
>
> org.ops4j.pax.swissbox.tracker.ServiceLookupException: gave up waiting for
> service org.ops4j.pax.exam.util.Injector
>  at org.ops4j.pax.swissbox.tracker.ServiceLookup.getService(ServiceLookup.
> java:199) ~[306:org.ops4j.pax.swissbox.tracker:1.8.3]
>  at org.ops4j.pax.swissbox.tracker.ServiceLookup.getService(ServiceLookup.
> java:119) ~[306:org.ops4j.pax.swissbox.tracker:1.8.3]
>  at org.ops4j.pax.swissbox.tracker.ServiceLookup.getService(ServiceLookup.
> java:72) ~[306:org.ops4j.pax.swissbox.tracker:1.8.3]
>  at org.ops4j.pax.exam.invoker.junit.internal.JUnitProbeInvokerFactory.
> createProbeInvoker(JUnitProbeInvokerFactory.java:35) ~[?:?]
>  at org.ops4j.pax.exam.raw.extender.intern.Parser.createInvoker(Parser.
> java:94) ~[?:?]
>  at org.ops4j.pax.exam.raw.extender.intern.Parser.make(Parser.java:81)
> ~[?:?]
>  at org.ops4j.pax.exam.raw.extender.intern.Parser.(Parser.java:67)
> ~[?:?]
>  at org.ops4j.pax.exam.raw.extender.intern.TestBundleObserver.
> addingEntries(TestBundleObserver.java:69) ~[?:?]
>  at org.ops4j.pax.swissbox.extender.BundleWatcher$3.run(BundleWatcher.java
> :226) [303:org.ops4j.pax.swissbox.extender:1.8.3]
>  at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511
> ) [?:?]
>  at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
>  at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.
> access$201(ScheduledThreadPoolExecutor.java:180) [?:?]
>  at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.
> run(ScheduledThreadPoolExecutor.java:293) [?:?]
>  at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.
> java:1149) [?:?]
>  at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.
> java:624) [?:?]
>  at java.lang.Thread.run(Thread.java:748) [?:?]
>
> At the time being we are solving these errors running tests twice but this
> is quite unsatisfactory.
>
> I see that the createProbeInvoker use the default 10 seconds timeout to
> get the Injector service. Would it be possible to apply the same approach
> adopted here
> ?
> I would submitted a PR but I don't have access rights to create an issue on
> Jira.
>
> Thank you very much,
> Matteo
>
> --
> --
> --
> OPS4J - http://www.ops4j.org - ops4j@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/726f50f1-2534-45b6-8fef-3dbb4f731a10%40googlegroups.com
> 
> .
>

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@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/CAB8EV3QW0kv%3DLu5FK3rb9pAJgdRbmp6WyMvuyriCNm%2Bvt74FYw%40mail.gmail.com.

Re: Spring Cleanup of OPS4J

[Jean-Baptiste Onofré]

Hi Toni,

Thanks for starting this. I will update the wiki page as well.

Regards
JB

On Thu, Apr 9, 2020 at 12:42 PM Toni Menzel  wrote:

> Hey,
>
> With the Domain transitioning of the ops4j.org domain from Niclas to JB
> and the official decommissioning of ci.ops4j.org Jenkins we are kicking
> of the spring cleanup of OPS4J I guess.
>
> For me it was enlightening how many subprojects actually exist under the
> OPS4J Umbrella. I started gathering some data here:
> https://github.com/ops4j/ops4j.github.io/wiki
>
> It would be cool if project mantainers can update their project with
> latest release, existing CI pipeline on some Saas and project activity
> there.
> Feel free to add extra metadata/Columns if it helps getting a better
> picture.
>
> From there we can move on shaping a simple website and organizing a
> default CI/CD pipeline SaaS where needed.
>
> If there is interest, I am open for an online/video discussion at some
> point too.
>
> Stay healthy,
> Toni
>
> *Toni Menzel | Developer Experience Consultant @ rebaze GmbH
> *
> *#DevEx*
>
> --
> --
> --
> OPS4J - http://www.ops4j.org - ops4j@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/CAEjgzHRYp_ijcB%2B1OqTPJSn0bRCdChAjW2GMZKuA6%3Dd2M%2Bg59Q%40mail.gmail.com
> 
> .
>

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@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/CAB8EV3R8yiELKCgNsPLHG3H6hfHfwK%2B1xKLYRi2zjgJeTyLSeg%40mail.gmail.com.

Re: [VOTE] JB Onofre takes over ops4j domains

[Jean-Baptiste Onofré]

Hi,

Just to let you know that domains transfer is now effective. Niclas and I
have manage the transfer.

Regards
JB

On Fri, Apr 3, 2020 at 8:45 AM Niclas Hedhman  wrote:

> I think we have consensus, and I will initiate domain transfer off-list
> with JB
>
> Thanks everyone for giving your support.
>
> On Thu, Apr 2, 2020 at 9:12 PM Freeman Fang 
> wrote:
>
>> +1 and thanks for JB to take over.
>>
>> Thanks Niclas!
>> Freeman
>>
>> On Tue, Mar 31, 2020 at 2:23 AM Niclas Hedhman 
>> wrote:
>>
>>>
>>> Since the OPS4J inception in 2005, I have paid the ops4j domain names. I
>>> think 15-16 years is enough, and have recently announced that I am no
>>> longer willing to be the custodian of these domain names.
>>>
>>> JB Onofre has offered to take over.
>>>
>>> Vote;
>>>
>>> [ ] - JB Onofre as new custodian
>>> [ ] - No. Let's find some other solution.
>>>
>>>
>>> // Niclas
>>>
>>> --
>>> --
>>> --
>>> OPS4J - http://www.ops4j.org - ops4j@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/CADmm%2BKc%2BU1zrh162G2ohMDO2Vr3WP4TkFkHZ2QWe1KC5G9Mz-A%40mail.gmail.com
>>> 
>>> .
>>>
>> --
>> --
>> --
>> OPS4J - http://www.ops4j.org - ops4j@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/CAM0LEOaHLVubGKcNYNyCjtFWYrKrkKWatMcP_hc8cWaAeSFMNQ%40mail.gmail.com
>> 
>> .
>>
> --
> --
> --
> OPS4J - http://www.ops4j.org - ops4j@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/CADmm%2BKe%2BsfeUh59rw7gRvyy1QEJ0g3RsCZ7gErRQHmY-Wfm78Q%40mail.gmail.com
> 
> .
>

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@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/CAB8EV3Q0z-5%2BUdTM%3Dd24meOo7ChX-%3Dff15vxM4897Bxyc_-zCQ%40mail.gmail.com.

Re: [VOTE] Decommissioning of old jenkins instance ci.ops4j.org

[Jean-Baptiste Onofré]

+1

Regards
JB

Le ven. 3 avr. 2020 à 10:27, Toni Menzel  a écrit :

> Hey,
>
> For some years we had a jenkins CI instance running on a rented hetzner
> server.
> As mentioned before, this instance seems dysfunctional and not used
> anymore.
>
> So I would like to vote for decommissioning that.
> The cancelation date would be *16th of April*.
>
> Once we decide on getting rid of that server bill, I am happy to sponsor a
> replacement SaaS if there is nothing suitable available for OSS capacities.
>
> I just feel that the manually maintained jenkins server is not that giving
> that much value and should be replaced by a more modern pipeline.
>
> [ ] yes, decommission that instance and let's modernize things
> [ ] no, don‘t do it now, my project is actually using it ci.ops4j.org and
> cannot use github actions or similar (please get in contact)
>
> Vote closes not earlier than next wednesday april 8th.
>
> Stay healthy everyone,
> Toni
>
> --
> --
> --
> OPS4J - http://www.ops4j.org - ops4j@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/CAEjgzHSpTa%2B74YLivjwcdEwO4KTOJ8%3Dtm%3DFBhZZC%3DtnXgP828Q%40mail.gmail.com
> 
> .
>

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@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/CAB8EV3TrWxQs4fVETOMjUpJOBt%2Bu098_O0sU7VjLZmnrCJ4fZg%40mail.gmail.com.

Re: ops4j domain names

[Jean-Baptiste Onofré]

Even if we go to ops4j.github.com, I think it will be helpful to redirect
from ops4j.org. So, I volunteer to "take" the ops4j domain. It will give us
time to "transfer" resources to github.

OK with that ?

Regards
JB

On Tue, Mar 31, 2020 at 4:15 AM Niclas Hedhman  wrote:

>
> The thread's primary question is;
>
> Shall I a) let the ops4j domain names expire, or b) transfer them to
> someone else? If b), then Who/What?
>
> The rest is "interesting" but actually "out of scope" for something very
> concrete in 10 weeks time. The full structure of community can in principle
> be discussed/decided later, or not...
>
>
> // Niclas
>
> On Mon, Mar 30, 2020 at 10:37 PM Jean-Baptiste Onofré <
> jeanbaptiste.ono...@gmail.com> wrote:
>
>> I agree.
>>
>> What do you think I start a vote on the mailing list to propose to move
>> to ops4j.github.com ?
>>
>> Regards
>> JB
>>
>> On Mon, Mar 30, 2020 at 4:34 PM Peter Neubauer 
>> wrote:
>>
>>> Thanks Niclas for bringing up the issue!
>>>
>>> FWIW - I think Github is basically what OPS4J set out to be
>>> code-contribution-wise. IMHO going back to Apache is a matter of the
>>> community deciding if the barriers for governance/contribution are lower
>>> now. Otherwise - I think just moving everything to Github - only would be
>>> the lowest-threshold option here.
>>>
>>> /peter
>>>
>>> On Monday, March 23, 2020 at 8:50:52 AM UTC+1, Guillaume Nodet wrote:
>>>>
>>>> Imho, we should switch everything to github.  I wouldn't even bother
>>>> paying for a domain, i think something like ops4j.github.org is enough.
>>>>
>>>> Le mer. 19 févr. 2020 à 13:01, Toni Menzel  a
>>>> écrit :
>>>>
>>>>> *TL/TR:*
>>>>> I'd be also happy to pay for ops4j.org (the one that is actively used
>>>>> atm).
>>>>>
>>>>> *Long version:*
>>>>> Since this is coming up now, there is a general question were to go
>>>>> with OPS4J in general.
>>>>>
>>>>> It predated github and probably was back then the easiest way to get
>>>>> hands dirty in a non-trivial java based OSS community where trust was
>>>>> default. Think about it, back then everyone could get write access to the
>>>>> subversion repo and start hacking on new or existing projects. Including
>>>>> admin access to jira and whatever else was existing back then. Pax URL, 
>>>>> Pax
>>>>> Runner, Pax Exam, Pax Construct etc. all got initiated by individuals
>>>>> without asking for permission. I mean.. thats Names like Pax Tinybundles
>>>>> got to life.. but oh well.
>>>>>
>>>>> Now, why am I writing this: there is - at least for pax url, web and
>>>>> exam - a huge user base that seems to be quite healthy. Even if there is
>>>>> just that "ops4j" name of the github organization now, no website etc.
>>>>>
>>>>> So, question: what are the options? Let me just drop them here that
>>>>> come to my mind (ordered from easy-as-py to more complicated options):
>>>>>
>>>>>- keep things as is, find individual sponsors like I do with the
>>>>>Build Server (who uses that still by the way??), and JB or me (this 
>>>>> means
>>>>>I'd be also fine to pay for the org domain that is in active use,too 
>>>>> btw).
>>>>>It would be good to have two different companies or legal entities 
>>>>> backing
>>>>>this anyway.
>>>>>- Modernize OPS4J a bit. Get it a landing page at least and a
>>>>>clear who is behind all this, who pays etc. Maybe look at Github 
>>>>> Sponsoring
>>>>>to spread costs across user base - avoid single entity control.
>>>>>- Maybe look into making it a proper foundation or at least an
>>>>>entity that makes the work here eligible for future donations. I am not
>>>>>sure of this is worth it. But i feel Open Source != Open Governance.
>>>>>- Retire non active projects and donate active projects to apache.
>>>>>Probably difficult because of Intellectual Property)
>>>>>
>>>>> wdyt?
>>>>> Toni
>>>>>
>>>>>
>>>>>
>>>>>
>>&g

Re: ops4j domain names

[Jean-Baptiste Onofré]

I agree.

What do you think I start a vote on the mailing list to propose to move to
ops4j.github.com ?

Regards
JB

On Mon, Mar 30, 2020 at 4:34 PM Peter Neubauer 
wrote:

> Thanks Niclas for bringing up the issue!
>
> FWIW - I think Github is basically what OPS4J set out to be
> code-contribution-wise. IMHO going back to Apache is a matter of the
> community deciding if the barriers for governance/contribution are lower
> now. Otherwise - I think just moving everything to Github - only would be
> the lowest-threshold option here.
>
> /peter
>
> On Monday, March 23, 2020 at 8:50:52 AM UTC+1, Guillaume Nodet wrote:
>>
>> Imho, we should switch everything to github.  I wouldn't even bother
>> paying for a domain, i think something like ops4j.github.org is enough.
>>
>> Le mer. 19 févr. 2020 à 13:01, Toni Menzel  a
>> écrit :
>>
>>> *TL/TR:*
>>> I'd be also happy to pay for ops4j.org (the one that is actively used
>>> atm).
>>>
>>> *Long version:*
>>> Since this is coming up now, there is a general question were to go with
>>> OPS4J in general.
>>>
>>> It predated github and probably was back then the easiest way to get
>>> hands dirty in a non-trivial java based OSS community where trust was
>>> default. Think about it, back then everyone could get write access to the
>>> subversion repo and start hacking on new or existing projects. Including
>>> admin access to jira and whatever else was existing back then. Pax URL, Pax
>>> Runner, Pax Exam, Pax Construct etc. all got initiated by individuals
>>> without asking for permission. I mean.. thats Names like Pax Tinybundles
>>> got to life.. but oh well.
>>>
>>> Now, why am I writing this: there is - at least for pax url, web and
>>> exam - a huge user base that seems to be quite healthy. Even if there is
>>> just that "ops4j" name of the github organization now, no website etc.
>>>
>>> So, question: what are the options? Let me just drop them here that come
>>> to my mind (ordered from easy-as-py to more complicated options):
>>>
>>>- keep things as is, find individual sponsors like I do with the
>>>Build Server (who uses that still by the way??), and JB or me (this means
>>>I'd be also fine to pay for the org domain that is in active use,too 
>>> btw).
>>>It would be good to have two different companies or legal entities 
>>> backing
>>>this anyway.
>>>- Modernize OPS4J a bit. Get it a landing page at least and a clear
>>>who is behind all this, who pays etc. Maybe look at Github Sponsoring to
>>>spread costs across user base - avoid single entity control.
>>>- Maybe look into making it a proper foundation or at least an
>>>entity that makes the work here eligible for future donations. I am not
>>>sure of this is worth it. But i feel Open Source != Open Governance.
>>>- Retire non active projects and donate active projects to apache.
>>>Probably difficult because of Intellectual Property)
>>>
>>> wdyt?
>>> Toni
>>>
>>>
>>>
>>>
>>> *Toni Menzel | rebaze.com <https://www.rebaze.com> | growing developer
>>> culture*
>>>
>>>
>>> On Wed, Feb 19, 2020 at 12:37 PM Jean-Baptiste Onofré <
>>> jeanbapti...@gmail.com> wrote:
>>>
>>>> Hi Niclas
>>>>
>>>> First of all, thanks a lot for all what you did (and still doing ).
>>>>
>>>> I’m ready to take the hand for the domain and finance them.
>>>>
>>>> Thoughts ?
>>>>
>>>> Regards
>>>> JB
>>>>
>>>> Le mer. 19 févr. 2020 à 12:13, Niclas Hedhman  a
>>>> écrit :
>>>>
>>>>> Everyone,
>>>>> In a few months time (June), the OPS4J domain names are up for
>>>>> renewal. And I have been paying for those for 15 years now, and since I no
>>>>> longer participate in OPS4J I would like to transfer the domain names. But
>>>>> where to??
>>>>>
>>>>> Ideally a foundation that would be Ok to take it over, otherwise to a
>>>>> trusted community member.
>>>>>
>>>>> Ideas are welcome, and should be discussed. I have no opinion and will
>>>>> simply follow what you all can agree on.
>>>>>
>>>>> ops4j.org
>>>>> ops4j.net
>>>>> ops4j.com

Re: ops4j domain names

[Jean-Baptiste Onofré]

Not formal one yet. I can start a vote.

Regards
JB

On Mon, Mar 23, 2020 at 9:58 AM Toni Menzel  wrote:

> yep, moving CI to 100% githib actions would allow us to decommission the
> old Jenkins instance.
> Is there a resolution regarding the domain names yet?
>
> *Toni Menzel | Strategic Software Delivery Consultant @ rebaze GmbH*
> Consultant profiletonimenzel.com <https://www.tonimenzel.com>
> Consultancy profile  rebaze.com <https://www.rebaze.com>
> *#CloudNative #Accelerate #DevEx*
>
>
> On Mon, Mar 23, 2020 at 9:49 AM Jean-Baptiste Onofré <
> jeanbaptiste.ono...@gmail.com> wrote:
>
>> That's a good idea.
>>
>> Regards
>> JB
>>
>> On Mon, Mar 23, 2020 at 8:50 AM Guillaume Nodet 
>> wrote:
>>
>>> Imho, we should switch everything to github.  I wouldn't even bother
>>> paying for a domain, i think something like ops4j.github.org is enough.
>>>
>>> Le mer. 19 févr. 2020 à 13:01, Toni Menzel  a
>>> écrit :
>>>
>>>> *TL/TR:*
>>>> I'd be also happy to pay for ops4j.org (the one that is actively used
>>>> atm).
>>>>
>>>> *Long version:*
>>>> Since this is coming up now, there is a general question were to go
>>>> with OPS4J in general.
>>>>
>>>> It predated github and probably was back then the easiest way to get
>>>> hands dirty in a non-trivial java based OSS community where trust was
>>>> default. Think about it, back then everyone could get write access to the
>>>> subversion repo and start hacking on new or existing projects. Including
>>>> admin access to jira and whatever else was existing back then. Pax URL, Pax
>>>> Runner, Pax Exam, Pax Construct etc. all got initiated by individuals
>>>> without asking for permission. I mean.. thats Names like Pax Tinybundles
>>>> got to life.. but oh well.
>>>>
>>>> Now, why am I writing this: there is - at least for pax url, web and
>>>> exam - a huge user base that seems to be quite healthy. Even if there is
>>>> just that "ops4j" name of the github organization now, no website etc.
>>>>
>>>> So, question: what are the options? Let me just drop them here that
>>>> come to my mind (ordered from easy-as-py to more complicated options):
>>>>
>>>>- keep things as is, find individual sponsors like I do with the
>>>>Build Server (who uses that still by the way??), and JB or me (this 
>>>> means
>>>>I'd be also fine to pay for the org domain that is in active use,too 
>>>> btw).
>>>>It would be good to have two different companies or legal entities 
>>>> backing
>>>>this anyway.
>>>>- Modernize OPS4J a bit. Get it a landing page at least and a clear
>>>>who is behind all this, who pays etc. Maybe look at Github Sponsoring to
>>>>spread costs across user base - avoid single entity control.
>>>>- Maybe look into making it a proper foundation or at least an
>>>>entity that makes the work here eligible for future donations. I am not
>>>>sure of this is worth it. But i feel Open Source != Open Governance.
>>>>- Retire non active projects and donate active projects to apache.
>>>>Probably difficult because of Intellectual Property)
>>>>
>>>> wdyt?
>>>> Toni
>>>>
>>>>
>>>>
>>>>
>>>> *Toni Menzel | rebaze.com <https://www.rebaze.com> | growing developer
>>>> culture*
>>>>
>>>>
>>>> On Wed, Feb 19, 2020 at 12:37 PM Jean-Baptiste Onofré <
>>>> jeanbaptiste.ono...@gmail.com> wrote:
>>>>
>>>>> Hi Niclas
>>>>>
>>>>> First of all, thanks a lot for all what you did (and still doing ).
>>>>>
>>>>> I’m ready to take the hand for the domain and finance them.
>>>>>
>>>>> Thoughts ?
>>>>>
>>>>> Regards
>>>>> JB
>>>>>
>>>>> Le mer. 19 févr. 2020 à 12:13, Niclas Hedhman  a
>>>>> écrit :
>>>>>
>>>>>> Everyone,
>>>>>> In a few months time (June), the OPS4J domain names are up for
>>>>>> renewal. And I have been paying for those for 15 years now, and since I 
>>>>>> no
>>>>>> longe

Re: ops4j domain names

[Jean-Baptiste Onofré]

That's a good idea.

Regards
JB

On Mon, Mar 23, 2020 at 8:50 AM Guillaume Nodet  wrote:

> Imho, we should switch everything to github.  I wouldn't even bother
> paying for a domain, i think something like ops4j.github.org is enough.
>
> Le mer. 19 févr. 2020 à 13:01, Toni Menzel  a
> écrit :
>
>> *TL/TR:*
>> I'd be also happy to pay for ops4j.org (the one that is actively used
>> atm).
>>
>> *Long version:*
>> Since this is coming up now, there is a general question were to go with
>> OPS4J in general.
>>
>> It predated github and probably was back then the easiest way to get
>> hands dirty in a non-trivial java based OSS community where trust was
>> default. Think about it, back then everyone could get write access to the
>> subversion repo and start hacking on new or existing projects. Including
>> admin access to jira and whatever else was existing back then. Pax URL, Pax
>> Runner, Pax Exam, Pax Construct etc. all got initiated by individuals
>> without asking for permission. I mean.. thats Names like Pax Tinybundles
>> got to life.. but oh well.
>>
>> Now, why am I writing this: there is - at least for pax url, web and exam
>> - a huge user base that seems to be quite healthy. Even if there is just
>> that "ops4j" name of the github organization now, no website etc.
>>
>> So, question: what are the options? Let me just drop them here that come
>> to my mind (ordered from easy-as-py to more complicated options):
>>
>>- keep things as is, find individual sponsors like I do with the
>>Build Server (who uses that still by the way??), and JB or me (this means
>>I'd be also fine to pay for the org domain that is in active use,too btw).
>>It would be good to have two different companies or legal entities backing
>>this anyway.
>>- Modernize OPS4J a bit. Get it a landing page at least and a clear
>>who is behind all this, who pays etc. Maybe look at Github Sponsoring to
>>spread costs across user base - avoid single entity control.
>>- Maybe look into making it a proper foundation or at least an entity
>>that makes the work here eligible for future donations. I am not sure of
>>this is worth it. But i feel Open Source != Open Governance.
>>- Retire non active projects and donate active projects to apache.
>>Probably difficult because of Intellectual Property)
>>
>> wdyt?
>> Toni
>>
>>
>>
>>
>> *Toni Menzel | rebaze.com <https://www.rebaze.com> | growing developer
>> culture*
>>
>>
>> On Wed, Feb 19, 2020 at 12:37 PM Jean-Baptiste Onofré <
>> jeanbaptiste.ono...@gmail.com> wrote:
>>
>>> Hi Niclas
>>>
>>> First of all, thanks a lot for all what you did (and still doing ).
>>>
>>> I’m ready to take the hand for the domain and finance them.
>>>
>>> Thoughts ?
>>>
>>> Regards
>>> JB
>>>
>>> Le mer. 19 févr. 2020 à 12:13, Niclas Hedhman  a
>>> écrit :
>>>
>>>> Everyone,
>>>> In a few months time (June), the OPS4J domain names are up for renewal.
>>>> And I have been paying for those for 15 years now, and since I no longer
>>>> participate in OPS4J I would like to transfer the domain names. But where
>>>> to??
>>>>
>>>> Ideally a foundation that would be Ok to take it over, otherwise to a
>>>> trusted community member.
>>>>
>>>> Ideas are welcome, and should be discussed. I have no opinion and will
>>>> simply follow what you all can agree on.
>>>>
>>>> ops4j.org
>>>> ops4j.net
>>>> ops4j.com
>>>>
>>>>
>>>> Cheers
>>>> Niclas
>>>>
>>>> --
>>>> --
>>>> --
>>>> OPS4J - http://www.ops4j.org - ops4j@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/CADmm%2BKf7a0rzdkro7v-rxBV1p1-KkSMTE_BQT2HhUZyOUM9jyA%40mail.gmail.com
>>>> <https://groups.google.com/d/msgid/ops4j/CADmm%2BKf7a0rzdkro7v-rxBV1p1-KkSMTE_BQT2HhUZyOUM9jyA%40mail.gmail.com?utm_medium=email_source=footer>
>>>>

Re: Will ServletContext OSGi service injections be available in the OSGi 7 compatible web whiteboard

[Jean-Baptiste Onofré]

Hi

AFAIR, those properties are already supported in Pax Web.

Regards
JB

On Mon, Mar 23, 2020 at 12:25 AM Steinar Bang  wrote:

> > Grzegorz Grzybek  >:
>
> >> Will it be possible to get a ServletContext OSGi service injected into a
> >> @Reference, when using the web whiteboard of OSGi 7?
> >>
>
> > Sure - it's described in 128.3.4 Publishing the Servlet Context chapter
> of
> > CMPN specification and I think it should already be a case (at least
> that's
> > what I remember from JBoss Fuse (based on Karaf)).
>
> Thanks Grzegorz!
>
> I've been successful in injecting the service, but not in filtering to
> get the right service.
>
> I got injections in this variant:
> @Reference
> public void setServletContext(ServletContext context) {
> this.context = context;
> }
>
> But I got no injections in:
> @Reference(target = "(osgi.web.symbolicname=authservice)")
> public void setServletContext(ServletContext context) {
> this.context = context;
> }
>
> And I got no injections in:
> @Reference(target = "(osgi.web.contextpath=/authservice)")
> public void setServletContext(ServletContext context) {
> this.context = context;
> }
>
> The ServletContextHelper creating the context, is:
> @Component(
> property= {
>
> HttpWhiteboardConstants.HTTP_WHITEBOARD_CONTEXT_NAME+"=authservice",
>
> HttpWhiteboardConstants.HTTP_WHITEBOARD_CONTEXT_PATH+"=/authservice"},
> service=ServletContextHelper.class,
> immediate=true
> )
> public class AuthserviceServletContextHelper extends ServletContextHelper
> { }
>
> > About actual Whiteboard R7 annotations - support for those has yet to be
> > added to Pax Web.
>
> Looking forward to this happening.
>
> Thanks again!
>
> --
> --
> --
> OPS4J - http://www.ops4j.org - ops4j@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/86zhc8t1ji.fsf%40dod.no.
>

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@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/CAB8EV3Tv0GfLMnw0N6dmBNoSq6T95Aoguo569A4_zMgMjNf6bQ%40mail.gmail.com.

Re: [PAX EXAM] Release 4.13.3

[Jean-Baptiste Onofré]

Hi,

No problem, I will tackle that.

Regards
JB

On Sat, Mar 21, 2020 at 9:46 PM Eric Lilja  wrote:

> That would be awesome to get a release out if we have fix for PAXEXAM-920!
>
> JB: Do you have the possibility to get this release out?
>
> - Eric L
>
> On Friday, March 13, 2020 at 9:46:11 AM UTC+1, Oliver Lietz wrote:
>>
>> Hi *,
>>
>> Can someone please look into PAXEXAM-920 and cut a release?
>>
>> Thanks,
>> O.
>>
>>
>>
>>
>> --
> --
> --
> OPS4J - http://www.ops4j.org - ops4j@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/14a642b9-cdfd-4ed5-8f55-f5d461f3c343%40googlegroups.com
> 
> .
>

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@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/CAB8EV3TV_zXYDJ0MMyJ4GFzrj9Q3ejiEawSuSUA3zf3b-ckfKw%40mail.gmail.com.

Re: Maven Aether configuration

[Jean-Baptiste Onofré]

Hi Jared,

I mean that you can define the pax-url configuration in the @Configuration.
It's where you can define the repositories URL, especially you have to use
https for Central (it will be changed by default in Karaf 4.2.9):

https://github.com/apache/karaf/blob/master/itests/common/src/main/java/org/apache/karaf/itests/KarafTestSupport.java#L211

Regards
JB

On Thu, Mar 5, 2020 at 8:38 PM Jared Whiklo  wrote:

> Sorry JB, I don't know what you mean by that?
>
> Is this outside of the actual test? Is there a configuration file I
> should have somewhere specific that defines this?
>
> I am really quite a novice at Pax Exam stuff.
>
> cheers,
> jared
>
> On 2020-03-05 1:32 p.m., Jean-Baptiste Onofré wrote:
> > Why not simply update the pax url cfg file in the pax exam config ?
> >
> > Regards
> > JB
> >
> > Le jeu. 5 mars 2020 à 20:01, Jared Whiklo  > <mailto:jwhi...@gmail.com>> a écrit :
> >
> > Thank you Grzegorz,
> >
> > Here is the test currently
> >
> >
> https://github.com/whikloj/Alpaca/blob/fix-pax-exam/karaf/src/test/java/ca/islandora/alpaca/karaf/KarafIT.java
> >
> > The only solution I have found is to change my personal maven
> > settings.xml to include a repository or mirror for Maven central
> > with the https scheme.
> >
> > But unfortunately that means anyone trying to build this also
> > requires that setup (and Travis-CI), which makes it seem like it is
> > not the correct solution.
> >
> > cheers,
> > jared
> >
> > On Wednesday, 4 March 2020 23:48:12 UTC-6, Grzegorz Grzybek wrote:
> >
> > Hello
> >
> > Can you share your failing test via Github? I run many Karaf
> > Pax-Exam tests everyday...
> >
> > regards
> > Grzegorz Grzybek
> >
> > --
> > --
> > --
> > OPS4J - http://www.ops4j.org - ops4j@googlegroups.com
> > <mailto:ops4j@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
> > <mailto:ops4j+unsubscr...@googlegroups.com>.
> > To view this discussion on the web visit
> >
> https://groups.google.com/d/msgid/ops4j/97913dd1-3c66-4f64-87f5-1febc9d2a63d%40googlegroups.com
> > <
> https://groups.google.com/d/msgid/ops4j/97913dd1-3c66-4f64-87f5-1febc9d2a63d%40googlegroups.com?utm_medium=email_source=footer
> >.
> >
> > --
> > --
> > --
> > OPS4J - http://www.ops4j.org - ops4j@googlegroups.com
> >
> > ---
> > You received this message because you are subscribed to a topic in the
> > Google Groups "OPS4J" group.
> > To unsubscribe from this topic, visit
> > https://groups.google.com/d/topic/ops4j/pJ98QaBVPfE/unsubscribe.
> > To unsubscribe from this group and all its topics, send an email to
> > ops4j+unsubscr...@googlegroups.com
> > <mailto:ops4j+unsubscr...@googlegroups.com>.
> > To view this discussion on the web visit
> >
> https://groups.google.com/d/msgid/ops4j/CAB8EV3TxumiSJ1y-eDFeoXPvsJn_X3HWqfikSBmhWyrd%3DBXFFQ%40mail.gmail.com
> > <
> https://groups.google.com/d/msgid/ops4j/CAB8EV3TxumiSJ1y-eDFeoXPvsJn_X3HWqfikSBmhWyrd%3DBXFFQ%40mail.gmail.com?utm_medium=email_source=footer
> >.
>
> --
> Jared Whiklo
> Pronouns: he/him/his
> jwhi...@gmail.com
> --
> I've learned that you shouldn't compare yourself to others - they are
> more screwed up than you think.
>
> --
> --
> --
> OPS4J - http://www.ops4j.org - ops4j@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/97bebfae-5840-4b2c-e33c-0db7f2af472f%40gmail.com
> .
>

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@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/CAB8EV3S5ZODmZgDBao3O5FjUYyDTzyd24KMtvJRWxTNyunkKKg%40mail.gmail.com.

Re: Maven Aether configuration

[Jean-Baptiste Onofré]

Why not simply update the pax url cfg file in the pax exam config ?

Regards
JB

Le jeu. 5 mars 2020 à 20:01, Jared Whiklo  a écrit :

> Thank you Grzegorz,
>
> Here is the test currently
>
>
> https://github.com/whikloj/Alpaca/blob/fix-pax-exam/karaf/src/test/java/ca/islandora/alpaca/karaf/KarafIT.java
>
> The only solution I have found is to change my personal maven settings.xml
> to include a repository or mirror for Maven central with the https scheme.
>
> But unfortunately that means anyone trying to build this also requires
> that setup (and Travis-CI), which makes it seem like it is not the correct
> solution.
>
> cheers,
> jared
>
> On Wednesday, 4 March 2020 23:48:12 UTC-6, Grzegorz Grzybek wrote:
>>
>> Hello
>>
>> Can you share your failing test via Github? I run many Karaf Pax-Exam
>> tests everyday...
>>
>> regards
>> Grzegorz Grzybek
>>
>> --
> --
> --
> OPS4J - http://www.ops4j.org - ops4j@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/97913dd1-3c66-4f64-87f5-1febc9d2a63d%40googlegroups.com
> 
> .
>

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@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/CAB8EV3TxumiSJ1y-eDFeoXPvsJn_X3HWqfikSBmhWyrd%3DBXFFQ%40mail.gmail.com.

Re: Maven Aether configuration

[Jean-Baptiste Onofré]

Hi

Sorry I jump late on this thread.

I don’t have any problem in Karaf (we have bunch of tests running daily
without problem).

I guess you are on Windows platform right ? Which jdk version ?

Anything special about network (like a proxy to access Internet) ?

Regards
JB

Le mer. 4 mars 2020 à 22:40, Jared Whiklo  a écrit :

> So I went ahead and modified the test to have a hardcoded maven URL for
> the apache-karaf artifact.
>
> final String karafDistributionUrl = 
> "https://repo1.maven.org/maven2/org/apache/karaf/apache-karaf/; +
> karafVersion + "/apache-karaf-" + karafVersion + ".zip";
>
> But the ArchiveExtractor doesn't like ".zip" unless you are using a "file://" 
> scheme. It does like "/zip"  with "http" but I'm not sure how to use that as 
> the actual URL doesn't have a "/zip" included?
>
> So I tried switching "https" for "file" anyways. It took a long time to fail, 
> but eventually it did with a Connection timeout.
>
> At this point I'm stumped and wondering how other people are using Pax-Exam? 
> Is it just the Karaf test container setup that is broken?
>
> If anyone has a suggestion please send it along
>
> cheers,
> jared
>
> --
> --
> --
> OPS4J - http://www.ops4j.org - ops4j@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/782d8fb8-2104-4f7e-aa7d-d2b2659121de%40googlegroups.com
> 
> .
>

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@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/CAB8EV3SqhvCFc4sSjZH2zMyXw%3D1LMW5ng5MGuL2P88UZgbYEqw%40mail.gmail.com.

Re: [PAX EXAM] Release 4.13.2

[Jean-Baptiste Onofré]

Hi

Yes the announcement with change log will be made here. I’m preparing this.

Stay tuned !

Regards
JB

Le sam. 22 févr. 2020 à 20:43, Eric Lilja  a écrit :

>
>
> On Friday, February 21, 2020 at 8:32:40 AM UTC+1, Jean-Baptiste Onofré
> wrote:
>>
>> Hi,
>>
>> Pax Exam 4.13.2 has been released. I'm preparing the news on OPS4J site
>> and I will send the announcement email.
>>
>>
>>>
>
> Thanks for doing the release! Will the announcement be made here as well?
> I'm interested in reading the full changelog. Also very happy to read in
> another thread in this forum that you will pick up Pax Exam version 5!
> We've been using Pax Exam to test our Karaf-based solutions for years, and
> it's nice to see it get more attention as it was starting to feel like a
> weaker, and weaker link in the eco system
>
> - Eric L
>
> --
> --
> --
> OPS4J - http://www.ops4j.org - ops4j@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/c515fe9d-8da9-4b66-9196-92c520009cfa%40googlegroups.com
> <https://groups.google.com/d/msgid/ops4j/c515fe9d-8da9-4b66-9196-92c520009cfa%40googlegroups.com?utm_medium=email_source=footer>
> .
>

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@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/CAB8EV3TVV71EbibEyam_ZcnQo4OC12n1bVO5urx%3DHh7siqpjoA%40mail.gmail.com.

Re: [PAX EXAM] Release 4.13.2

[Jean-Baptiste Onofré]

Hi,

Pax Exam 4.13.2 has been released. I'm preparing the news on OPS4J site and
I will send the announcement email.

Regards
JB

On Wed, Feb 19, 2020 at 11:11 PM Oliver Lietz  wrote:

> On Wednesday, February 19, 2020 11:40:53 AM CET Jean-Baptiste Onofré wrote:
> > Sure. I will.
>
> Done. PAXEXAM-934 and dependency updates (fixing HTTP issue with Maven
> Central).
>
> Please go ahead, JB.
>
> Thanks,
> O.
>
> > Le mer. 19 févr. 2020 à 11:23, Oliver Lietz  a
> écrit :
> > > On Wednesday, February 19, 2020 7:07:24 AM CET Jean-Baptiste Onofré
> wrote:
> > > > Hi
> > > >
> > > > I will.
> > >
> > > Let me add some dependency updates and improvements before cutting the
> > > release. Can you add version 4.13.2 to JIRA?
> > >
> > > Thanks,
> > > O.
> > >
> > > > Regards
> > > > JB
> > > >
> > > > Le mer. 19 févr. 2020 à 00:35, Oliver Lietz  a
> > >
> > > écrit :
> > > > > Hi *,
> > > > >
> > > > > I need a new release of Pax Exam: 4.13.2
> > > > > Who can manage versions in JIRA?
> > > > >
> > > > > Thanks,
> > > > > O.
> [...]
>
>
>
> --
> --
> --
> OPS4J - http://www.ops4j.org - ops4j@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/6567372.OaYqkxrSbj%40madness.front.ruhr
> .
>

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@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/CAB8EV3SXR2F_Yd2THvwGROG6vpZKHED5Gh7CR%3Dfz3bpkzmL-ZQ%40mail.gmail.com.

Re: Upgrade Jetty Dependency to 9.4.24 or newer.

[Jean-Baptiste Onofré]

Hi

Yes I’m upgrading to jetty 9.4.26 in pax web 7.2 and 7.3.

I just have to fix a package change about jaspi.

It should be done today.

Regards
JB

Le jeu. 20 févr. 2020 à 09:10, Grzegorz Grzybek  a
écrit :

> Hello
>
> Jean-Baptiste - I saw you're upgrading Jetty in pax-web. Will you do it in
> 7.2.x and 7.3.x?
>
> regards
> Grzegorz Grzybek
>
> pt., 24 sty 2020 o 19:24 Rasmus Olesen 
> napisał(a):
>
>> Awesome
>>
>> We are currently using version 7.3.5.
>>
>> On Fri, 24 Jan 2020, 18:52 Grzegorz Grzybek, 
>> wrote:
>>
>>> Hello
>>>
>>> I'm reviewing Pax Web now and I'll take care of the upgrade. Which Pax
>>> Web version are you using? 7.2.x?
>>>
>>> regards
>>> Grzegorz Grzybek
>>>
>>> czw., 23 sty 2020 o 12:35 Rasmus Olesen 
>>> napisał(a):
>>>
 For some reason i can't access the Jira bug reporting system. its just
 an infinite loop of cant sign up because account already exists and cant
 login because you account is doesnt have access...

 So i hope that someone else will create a issue for this upgrade.

 Jetty 9.4.21 to 9.4.23 are all affected by the following CVE
 https://nvd.nist.gov/vuln/detail/CVE-2019-17632

 PAX currently builds against 9.4.22

 I know that newer of versions of Jetty might be "api"/runtime
 compatible, but it would still be nice to have PAX building against a newer
 and non CVE affected jetty version.

 /Rasmus

 --
 --
 --
 OPS4J - http://www.ops4j.org - ops4j@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/a21deba1-653e-4d04-b005-c9ed1f19f152%40googlegroups.com
 
 .

>>> --
>>> --
>>> --
>>> OPS4J - http://www.ops4j.org - ops4j@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/CAAdXmhoSv%2B8BX6S-GBZwQQBWc8Ww62%2BGPb6OxevkFOM9FB0wJA%40mail.gmail.com
>>> 
>>> .
>>>
>> --
>> --
>> --
>> OPS4J - http://www.ops4j.org - ops4j@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/CAA_naH8bEwc1L8KeAP%3DZrcHDQWbVREMut-2HMo4b8Q-OFxwySw%40mail.gmail.com
>> 
>> .
>>
> --
> --
> --
> OPS4J - http://www.ops4j.org - ops4j@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/CAAdXmhqo-dL4Q0e6uDHyNAeYDzcq8iuc4BDGiX%2B4nKZqWfdiVA%40mail.gmail.com
> 
> .
>

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@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/CAB8EV3SrSc6Db3gCLSk3pS3qA1Z0qercjot9VKX5qN1wC_9M3w%40mail.gmail.com.

Re: ops4j domain names

[Jean-Baptiste Onofré]

That's true, but I think that's also a drawback.

The leak of governance and the fact we don't have any staging on releases
could be seen as an issue.

That's why it could be interesting to have this under the "Karaf Umbrella".

Regards
JB

On Thu, Feb 20, 2020 at 7:58 AM 'Christoph Läubrich' via OPS4J <
ops4j@googlegroups.com> wrote:

> I always enjoyed the ease of contribution via github with minimal
> effort. While for apache-projects has always felt like a mess because of
> different hurdles.
>
> So I would defiantly vote for staying with github, dropping JIRA in
> favour of github issues (they improved the issue/project handling a lot)
> to centralize development to one place.
>
> Github even offers building "Actions" now so maybe this is also an
> alternative for custom build-server.
>
> Am 20.02.20 um 07:17 schrieb Jean-Baptiste Onofré:
> > Hi,
> >
> > If option 4 is interesting, we have to remember:
> >
> > 1. First, in which Apache umbrella project. I don't think Felix is a
> > good match as we might have some overlap with existing projects (felix
> > http, ...). Maybe Karaf ?
> > 2. We need to transfer IP and "PMC" set and ask in the Apache project
> > community with a formal vote.
> > 3. We will have to follow Apache process, especially for releases
> > (meaning at least 3 days vote, 3 binding votes, etc), extending Apache
> > pom, etc.
> >
> > So, IMHO, we have really two options:
> >
> > 1. We keep OPS4J community, do a cleanup (announcing non active projects)
> > 2. We move active Pax projects to Apache (obviously my preference would
> > be Karaf).
> >
> > Thoughts ?
> >
> > Regards
> > JB
> >
> > On Wed, Feb 19, 2020 at 1:01 PM Toni Menzel  > <mailto:toni.men...@rebaze.com>> wrote:
> >
> > *TL/TR:*
> > I'd be also happy to pay for ops4j.org <http://ops4j.org> (the one
> > that is actively used atm).
> >
> > *Long version:*
> > Since this is coming up now, there is a general question were to go
> > with OPS4J in general.
> >
> > It predated github and probably was back then the easiest way to get
> > hands dirty in a non-trivial java based OSS community where trust
> > was default. Think about it, back then everyone could get write
> > access to the subversion repo and start hacking on new or existing
> > projects. Including admin access to jira and whatever else was
> > existing back then. Pax URL, Pax Runner, Pax Exam, Pax Construct
> > etc. all got initiated by individuals without asking for permission.
> > I mean.. thats Names like Pax Tinybundles got to life.. but oh well.
> >
> > Now, why am I writing this: there is - at least for pax url, web and
> > exam - a huge user base that seems to be quite healthy. Even if
> > there is just that "ops4j" name of the github organization now, no
> > website etc.
> >
> > So, question: what are the options? Let me just drop them here that
> > come to my mind (ordered from easy-as-py to more complicated
> options):
> >
> >   * keep things as is, find individual sponsors like I do with the
> > Build Server (who uses that still by the way??), and JB or me
> > (this means I'd be also fine to pay for the org domain that is
> > in active use,too btw). It would be good to have two different
> > companies or legal entities backing this anyway.
> >   * Modernize OPS4J a bit. Get it a landing page at least and a
> > clear who is behind all this, who pays etc. Maybe look at Github
> > Sponsoring to spread costs across user base - avoid single
> > entity control.
> >   * Maybe look into making it a proper foundation or at least an
> > entity that makes the work here eligible for future donations. I
> > am not sure of this is worth it. But i feel Open Source != Open
> > Governance.
> >   * Retire non active projects and donate active projects to apache.
> > Probably difficult because of Intellectual Property)
> >
> > wdyt?
> > Toni
> >
> >
> > *Toni Menzel | rebaze.com <https://www.rebaze.com> | growing
> > developer culture
> >
> > *
> >
> >
> > On Wed, Feb 19, 2020 at 12:37 PM Jean-Baptiste Onofré
> >  > <mailto:jeanbaptiste.ono...@gmail.com>> wrote:
> >
> > Hi Niclas
> >
> > First of all, thanks a lot f

Re: ops4j domain names

[Jean-Baptiste Onofré]

Hi,

If option 4 is interesting, we have to remember:

1. First, in which Apache umbrella project. I don't think Felix is a good
match as we might have some overlap with existing projects (felix http,
...). Maybe Karaf ?
2. We need to transfer IP and "PMC" set and ask in the Apache project
community with a formal vote.
3. We will have to follow Apache process, especially for releases (meaning
at least 3 days vote, 3 binding votes, etc), extending Apache pom, etc.

So, IMHO, we have really two options:

1. We keep OPS4J community, do a cleanup (announcing non active projects)
2. We move active Pax projects to Apache (obviously my preference would be
Karaf).

Thoughts ?

Regards
JB

On Wed, Feb 19, 2020 at 1:01 PM Toni Menzel  wrote:

> *TL/TR:*
> I'd be also happy to pay for ops4j.org (the one that is actively used
> atm).
>
> *Long version:*
> Since this is coming up now, there is a general question were to go with
> OPS4J in general.
>
> It predated github and probably was back then the easiest way to get hands
> dirty in a non-trivial java based OSS community where trust was default.
> Think about it, back then everyone could get write access to the subversion
> repo and start hacking on new or existing projects. Including admin access
> to jira and whatever else was existing back then. Pax URL, Pax Runner, Pax
> Exam, Pax Construct etc. all got initiated by individuals without asking
> for permission. I mean.. thats Names like Pax Tinybundles got to life.. but
> oh well.
>
> Now, why am I writing this: there is - at least for pax url, web and exam
> - a huge user base that seems to be quite healthy. Even if there is just
> that "ops4j" name of the github organization now, no website etc.
>
> So, question: what are the options? Let me just drop them here that come
> to my mind (ordered from easy-as-py to more complicated options):
>
>- keep things as is, find individual sponsors like I do with the Build
>Server (who uses that still by the way??), and JB or me (this means I'd be
>also fine to pay for the org domain that is in active use,too btw). It
>would be good to have two different companies or legal entities backing
>this anyway.
>- Modernize OPS4J a bit. Get it a landing page at least and a clear
>who is behind all this, who pays etc. Maybe look at Github Sponsoring to
>spread costs across user base - avoid single entity control.
>- Maybe look into making it a proper foundation or at least an entity
>that makes the work here eligible for future donations. I am not sure of
>this is worth it. But i feel Open Source != Open Governance.
>- Retire non active projects and donate active projects to apache.
>Probably difficult because of Intellectual Property)
>
> wdyt?
> Toni
>
>
>
>
> *Toni Menzel | rebaze.com <https://www.rebaze.com> | growing developer
> culture*
>
>
> On Wed, Feb 19, 2020 at 12:37 PM Jean-Baptiste Onofré <
> jeanbaptiste.ono...@gmail.com> wrote:
>
>> Hi Niclas
>>
>> First of all, thanks a lot for all what you did (and still doing ).
>>
>> I’m ready to take the hand for the domain and finance them.
>>
>> Thoughts ?
>>
>> Regards
>> JB
>>
>> Le mer. 19 févr. 2020 à 12:13, Niclas Hedhman  a
>> écrit :
>>
>>> Everyone,
>>> In a few months time (June), the OPS4J domain names are up for renewal.
>>> And I have been paying for those for 15 years now, and since I no longer
>>> participate in OPS4J I would like to transfer the domain names. But where
>>> to??
>>>
>>> Ideally a foundation that would be Ok to take it over, otherwise to a
>>> trusted community member.
>>>
>>> Ideas are welcome, and should be discussed. I have no opinion and will
>>> simply follow what you all can agree on.
>>>
>>> ops4j.org
>>> ops4j.net
>>> ops4j.com
>>>
>>>
>>> Cheers
>>> Niclas
>>>
>>> --
>>> --
>>> --
>>> OPS4J - http://www.ops4j.org - ops4j@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/CADmm%2BKf7a0rzdkro7v-rxBV1p1-KkSMTE_BQT2HhUZyOUM9jyA%40mail.gmail.com
>>> <https://groups.google.com/d/msgid/ops4j/CADmm%2BKf7a0rzdkro7v-rxBV1p1-KkSMTE_BQT2HhUZyOUM9jyA%40

Re: [PAX EXAM] Release 4.13.2

[Jean-Baptiste Onofré]

Thanks for the update. I will proceed then.

Regards
JB

On Wed, Feb 19, 2020 at 11:11 PM Oliver Lietz  wrote:

> On Wednesday, February 19, 2020 11:40:53 AM CET Jean-Baptiste Onofré wrote:
> > Sure. I will.
>
> Done. PAXEXAM-934 and dependency updates (fixing HTTP issue with Maven
> Central).
>
> Please go ahead, JB.
>
> Thanks,
> O.
>
> > Le mer. 19 févr. 2020 à 11:23, Oliver Lietz  a
> écrit :
> > > On Wednesday, February 19, 2020 7:07:24 AM CET Jean-Baptiste Onofré
> wrote:
> > > > Hi
> > > >
> > > > I will.
> > >
> > > Let me add some dependency updates and improvements before cutting the
> > > release. Can you add version 4.13.2 to JIRA?
> > >
> > > Thanks,
> > > O.
> > >
> > > > Regards
> > > > JB
> > > >
> > > > Le mer. 19 févr. 2020 à 00:35, Oliver Lietz  a
> > >
> > > écrit :
> > > > > Hi *,
> > > > >
> > > > > I need a new release of Pax Exam: 4.13.2
> > > > > Who can manage versions in JIRA?
> > > > >
> > > > > Thanks,
> > > > > O.
> [...]
>
>
>
> --
> --
> --
> OPS4J - http://www.ops4j.org - ops4j@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/6567372.OaYqkxrSbj%40madness.front.ruhr
> .
>

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@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/CAB8EV3Sk61%3D8haFa6s65FUfKPz1Uh3gEBuKpADeQM03rru8cMg%40mail.gmail.com.

Re: ops4j domain names

[Jean-Baptiste Onofré]

Hi Toni

Thanks for bringing this discussion forward.

I agree with your statements. Let me get back with comments and proposals.

Regards
JB

Le mer. 19 févr. 2020 à 13:01, Toni Menzel  a
écrit :

> *TL/TR:*
> I'd be also happy to pay for ops4j.org (the one that is actively used
> atm).
>
> *Long version:*
> Since this is coming up now, there is a general question were to go with
> OPS4J in general.
>
> It predated github and probably was back then the easiest way to get hands
> dirty in a non-trivial java based OSS community where trust was default.
> Think about it, back then everyone could get write access to the subversion
> repo and start hacking on new or existing projects. Including admin access
> to jira and whatever else was existing back then. Pax URL, Pax Runner, Pax
> Exam, Pax Construct etc. all got initiated by individuals without asking
> for permission. I mean.. thats Names like Pax Tinybundles got to life.. but
> oh well.
>
> Now, why am I writing this: there is - at least for pax url, web and exam
> - a huge user base that seems to be quite healthy. Even if there is just
> that "ops4j" name of the github organization now, no website etc.
>
> So, question: what are the options? Let me just drop them here that come
> to my mind (ordered from easy-as-py to more complicated options):
>
>- keep things as is, find individual sponsors like I do with the Build
>Server (who uses that still by the way??), and JB or me (this means I'd be
>also fine to pay for the org domain that is in active use,too btw). It
>would be good to have two different companies or legal entities backing
>this anyway.
>- Modernize OPS4J a bit. Get it a landing page at least and a clear
>who is behind all this, who pays etc. Maybe look at Github Sponsoring to
>spread costs across user base - avoid single entity control.
>- Maybe look into making it a proper foundation or at least an entity
>that makes the work here eligible for future donations. I am not sure of
>this is worth it. But i feel Open Source != Open Governance.
>- Retire non active projects and donate active projects to apache.
>Probably difficult because of Intellectual Property)
>
> wdyt?
> Toni
>
>
>
>
> *Toni Menzel | rebaze.com <https://www.rebaze.com> | growing developer
> culture*
>
>
> On Wed, Feb 19, 2020 at 12:37 PM Jean-Baptiste Onofré <
> jeanbaptiste.ono...@gmail.com> wrote:
>
>> Hi Niclas
>>
>> First of all, thanks a lot for all what you did (and still doing ).
>>
>> I’m ready to take the hand for the domain and finance them.
>>
>> Thoughts ?
>>
>> Regards
>> JB
>>
>> Le mer. 19 févr. 2020 à 12:13, Niclas Hedhman  a
>> écrit :
>>
>>> Everyone,
>>> In a few months time (June), the OPS4J domain names are up for renewal.
>>> And I have been paying for those for 15 years now, and since I no longer
>>> participate in OPS4J I would like to transfer the domain names. But where
>>> to??
>>>
>>> Ideally a foundation that would be Ok to take it over, otherwise to a
>>> trusted community member.
>>>
>>> Ideas are welcome, and should be discussed. I have no opinion and will
>>> simply follow what you all can agree on.
>>>
>>> ops4j.org
>>> ops4j.net
>>> ops4j.com
>>>
>>>
>>> Cheers
>>> Niclas
>>>
>>> --
>>> --
>>> --
>>> OPS4J - http://www.ops4j.org - ops4j@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/CADmm%2BKf7a0rzdkro7v-rxBV1p1-KkSMTE_BQT2HhUZyOUM9jyA%40mail.gmail.com
>>> <https://groups.google.com/d/msgid/ops4j/CADmm%2BKf7a0rzdkro7v-rxBV1p1-KkSMTE_BQT2HhUZyOUM9jyA%40mail.gmail.com?utm_medium=email_source=footer>
>>> .
>>>
>> --
>> --
>> --
>> OPS4J - http://www.ops4j.org - ops4j@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/CAB8

Re: ops4j domain names

[Jean-Baptiste Onofré]

Hi Niclas

First of all, thanks a lot for all what you did (and still doing ).

I’m ready to take the hand for the domain and finance them.

Thoughts ?

Regards
JB

Le mer. 19 févr. 2020 à 12:13, Niclas Hedhman  a écrit :

> Everyone,
> In a few months time (June), the OPS4J domain names are up for renewal.
> And I have been paying for those for 15 years now, and since I no longer
> participate in OPS4J I would like to transfer the domain names. But where
> to??
>
> Ideally a foundation that would be Ok to take it over, otherwise to a
> trusted community member.
>
> Ideas are welcome, and should be discussed. I have no opinion and will
> simply follow what you all can agree on.
>
> ops4j.org
> ops4j.net
> ops4j.com
>
>
> Cheers
> Niclas
>
> --
> --
> --
> OPS4J - http://www.ops4j.org - ops4j@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/CADmm%2BKf7a0rzdkro7v-rxBV1p1-KkSMTE_BQT2HhUZyOUM9jyA%40mail.gmail.com
> 
> .
>

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@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/CAB8EV3QGMMWvzzCck96CxemuYgSiYWNcs%2BOGPXmtaKTthoJvrw%40mail.gmail.com.

Re: [PAX EXAM] Release 4.13.2

[Jean-Baptiste Onofré]

Sure. I will.

Le mer. 19 févr. 2020 à 11:23, Oliver Lietz  a écrit :

> On Wednesday, February 19, 2020 7:07:24 AM CET Jean-Baptiste Onofré wrote:
> > Hi
> >
> > I will.
>
> Let me add some dependency updates and improvements before cutting the
> release. Can you add version 4.13.2 to JIRA?
>
> Thanks,
> O.
>
> > Regards
> > JB
> >
> > Le mer. 19 févr. 2020 à 00:35, Oliver Lietz  a
> écrit :
> > > Hi *,
> > >
> > > I need a new release of Pax Exam: 4.13.2
> > > Who can manage versions in JIRA?
> > >
> > > Thanks,
> > > O.
> [...]
>
>
>
> --
> --
> --
> OPS4J - http://www.ops4j.org - ops4j@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/1913191.HhQKl5TqLv%40madness.front.ruhr
> .
>

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@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/CAB8EV3RXBk-0HYmWLS69K5nZ8xpkMMmwszerVCTyTv6ttAgpOQ%40mail.gmail.com.

Re: Using GitHub Issues and Pages

[Jean-Baptiste Onofré]

Hi

To be honest I prefer jira over GitHub issue. However, regarding the use we
do of Jira, GitHub issues could be an alternative.
Quite the same about Confluence.

So, I'm +0 about that, let's wait what the others are thinking about that.

Regards
JB

Le mer. 19 févr. 2020 à 00:43, Oliver Lietz  a écrit :

> Hi *,
>
> How about dropping JIRA and Confluence and fully leveraging GitHub for
> OPS4J's
> projects?
>
> Regards,
> O.
>
>
>
>
> --
> --
> --
> OPS4J - http://www.ops4j.org - ops4j@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/2208945.GiKWtrRqj9%40madness.front.ruhr
> .
>

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@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/CAB8EV3Rswwdopn6zh-ZPxWnxA2dFUbx839WRRcu2ouyUjmbRhg%40mail.gmail.com.

Re: [PAX EXAM] 5 – status?

[Jean-Baptiste Onofré]

Hi

I will populate jira for the roadmap.

Regards
JB

Le mer. 19 févr. 2020 à 00:31, Oliver Lietz  a écrit :

> On Tuesday, February 18, 2020 9:04:20 PM CET Jean-Baptiste Onofré wrote:
> > Hi
> >
> > Yes. After discussed with Romain we identified several improvements.
> > We plan to work on this starting from next week.
>
> Great news, JB!
>
> Is there already a roadmap?
>
> O.
>
> > I would like to release pax exam 5 in couple of weeks.
> >
> > Regards
> > JB
> >
> > Le mar. 18 févr. 2020 à 19:53, Oliver Lietz  a
> écrit :
> > > Hi *,
> > >
> > > What is the status of Pax Exam 5?
> > > Anyone still working on it?
> > >
> > > Thanks,
> > > O.
> [...]
>
>
>
> --
> --
> --
> OPS4J - http://www.ops4j.org - ops4j@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/1894859.DYr1CQ9XjO%40madness.front.ruhr
> .
>

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@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/CAB8EV3Q9x0mbp6KddOWr7RLCsqwfSLMO0HjK7D3sEsxqXdTSRQ%40mail.gmail.com.

Re: [PAX EXAM] Release 4.13.2

[Jean-Baptiste Onofré]

Hi

I will.

Regards
JB

Le mer. 19 févr. 2020 à 00:35, Oliver Lietz  a écrit :

> Hi *,
>
> I need a new release of Pax Exam: 4.13.2
> Who can manage versions in JIRA?
>
> Thanks,
> O.
>
>
>
>
> --
> --
> --
> OPS4J - http://www.ops4j.org - ops4j@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/7682379.qZPg9MAYzA%40madness.front.ruhr
> .
>

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@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/CAB8EV3RfiaDMa8K40gVuz%3DrB25R-uNSxJivSUVZooovCwXpZ9A%40mail.gmail.com.

Re: [PAX EXAM] 5 – status?

[Jean-Baptiste Onofré]

Hi

Yes. After discussed with Romain we identified several improvements.
We plan to work on this starting from next week.

I would like to release pax exam 5 in couple of weeks.

Regards
JB

Le mar. 18 févr. 2020 à 19:53, Oliver Lietz  a écrit :

> Hi *,
>
> What is the status of Pax Exam 5?
> Anyone still working on it?
>
> Thanks,
> O.
>
>
>
>
> --
> --
> --
> OPS4J - http://www.ops4j.org - ops4j@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/1752490.BzjIWqZvl2%40madness.front.ruhr
> .
>

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@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/CAB8EV3SZpSjk5oGMSiCqHxzkUcKUz-GU3co_Q4XAPXYgir3qkQ%40mail.gmail.com.

Re: [PAX WEB] Url Pattern is auto-generated from Alias and how to register exact url pattern

[Jean-Baptiste Onofré]

Hi

Yeah it’s just a documentation manner imho.

Regards
JB

Le mar. 18 févr. 2020 à 17:19, Miroslav Beranič 
a écrit :

> Grzegorz,
>
> thank you for this in depth explanation. I guess what is missing here is
> updated documentation? It sure looks like, this is by-the-spec
> implementation, but can be miss-used as I've demonstrated.
>
> Kind Regards,
> Miroslav
>
>
> V V ned., 16. feb. 2020 ob 12:51 je oseba 'Achim Nierbeck' via OPS4J <
> ops4j@googlegroups.com> napisala:
>
>> Agree
>>
>> Jean-Baptiste Onofré  schrieb am Sa. 15.
>> Feb. 2020 um 21:45:
>>
>>> Hi
>>>
>>> According to the spec, I would agree. +1.
>>>
>>> Regards
>>> JB
>>>
>>> Le sam. 15 févr. 2020 à 17:31, Grzegorz Grzybek 
>>> a écrit :
>>>
>>>> Hello
>>>>
>>>> I've finally found the answer to your question:
>>>>
>>>> For example, Servlet, registered with /hello, also matches /hello/1,
>>>>> but I want /hello/1 to return HTTP 404.
>>>>>
>>>>
>>>> I've read the 102nd chapter of OSGi CMPN Http Service spec and I found:
>>>>
>>>> *102.4 Mapping HTTP Requests to Servlet and Resource Registrations*
>>>>
>>>> When an HTTP request comes in from a client, the Http Service checks to
>>>> see if the requested URI matches any registered aliases. A URI matches only
>>>> if the path part of the URI is *exactly the same* string. Matching is
>>>> case sensitive.
>>>>
>>>> Which initially made me think that you're correct. But check this out:
>>>>
>>>> If it does match, a matching registration takes place, which is
>>>> processed as follows:
>>>> [...]
>>>> 6. If there is no match, the *Http Service must attempt to match
>>>> sub-strings of the requested URI to registered aliases*. The
>>>> sub-strings of the requested URI are selected by removing the last "/" and
>>>> everything to the right of the last "/".
>>>>
>>>> The Http Service must repeat this process until either a match is found
>>>> or the sub-string is an empty string. [...]
>>>>
>>>> So, because Pax Web doesn't do what Tomcat/Jetty/Undertow do perfectly
>>>> (VHost/Context/Servlet mapping), I think that actually an "/alias" should
>>>> *always* be changed to "/alias/*" to comply with specification.
>>>>
>>>> If you want to do exact matching, just use the methods accepting URL
>>>> parameters.
>>>>
>>>> +Achim Nierbeck , +Jean-Baptiste Onofré
>>>>  do you agree?
>>>>
>>>> regards
>>>> Grzegorz Grzybek
>>>>
>>>> czw., 6 lut 2020 o 12:14 Miroslav Beranič 
>>>> napisał(a):
>>>>
>>>>> Hi all,
>>>>>
>>>>> I work with Pax Web on Karaf 4.3.0. I am trying to register Servlet
>>>>> with exact url, but I see url pattern is auto-generated from alias.
>>>>> I look at the current master branch - version 8.0.0-SNAPSHOT. Class:
>>>>>
>>>>> org.ops4j.pax.web.service.spi.model.ServletModel
>>>>>
>>>>>
>>>>> constructor:
>>>>> #ServletModel(org.ops4j.pax.web.service.spi.model.ContextModel,
>>>>> javax.servlet.Servlet, java.lang.String, java.lang.String[],
>>>>> java.lang.String, java.util.Dictionary,
>>>>> java.lang.Integer, java.lang.Boolean, 
>>>>> javax.servlet.MultipartConfigElement)
>>>>>
>>>>>
>>>>> it calles method ( private static )
>>>>> new String[]{aliasAsUrlPattern(alias)}
>>>>>
>>>>>
>>>>> private static String aliasAsUrlPattern(final String alias) {
>>>>> String urlPattern = alias;
>>>>> if (urlPattern != null && !urlPattern.equals("/")
>>>>> && !urlPattern.contains("*")) {
>>>>> if (urlPattern.endsWith("/")) {
>>>>> urlPattern = urlPattern + "*";
>>>>> } else {
>>>>> urlPattern = urlPattern + "/*";
>>>>> }
>>>>> }
>>>>> return urlPattern;
>&g

Re: [PAX WEB] Url Pattern is auto-generated from Alias and how to register exact url pattern

[Jean-Baptiste Onofré]

Hi

According to the spec, I would agree. +1.

Regards
JB

Le sam. 15 févr. 2020 à 17:31, Grzegorz Grzybek  a
écrit :

> Hello
>
> I've finally found the answer to your question:
>
> For example, Servlet, registered with /hello, also matches /hello/1, but I
>> want /hello/1 to return HTTP 404.
>>
>
> I've read the 102nd chapter of OSGi CMPN Http Service spec and I found:
>
> *102.4 Mapping HTTP Requests to Servlet and Resource Registrations*
>
> When an HTTP request comes in from a client, the Http Service checks to
> see if the requested URI matches any registered aliases. A URI matches only
> if the path part of the URI is *exactly the same* string. Matching is
> case sensitive.
>
> Which initially made me think that you're correct. But check this out:
>
> If it does match, a matching registration takes place, which is processed
> as follows:
> [...]
> 6. If there is no match, the *Http Service must attempt to match
> sub-strings of the requested URI to registered aliases*. The sub-strings
> of the requested URI are selected by removing the last "/" and everything
> to the right of the last "/".
>
> The Http Service must repeat this process until either a match is found or
> the sub-string is an empty string. [...]
>
> So, because Pax Web doesn't do what Tomcat/Jetty/Undertow do perfectly
> (VHost/Context/Servlet mapping), I think that actually an "/alias" should
> *always* be changed to "/alias/*" to comply with specification.
>
> If you want to do exact matching, just use the methods accepting URL
> parameters.
>
> +Achim Nierbeck , +Jean-Baptiste Onofré
>  do you agree?
>
> regards
> Grzegorz Grzybek
>
> czw., 6 lut 2020 o 12:14 Miroslav Beranič 
> napisał(a):
>
>> Hi all,
>>
>> I work with Pax Web on Karaf 4.3.0. I am trying to register Servlet with
>> exact url, but I see url pattern is auto-generated from alias.
>> I look at the current master branch - version 8.0.0-SNAPSHOT. Class:
>>
>> org.ops4j.pax.web.service.spi.model.ServletModel
>>
>>
>> constructor:
>> #ServletModel(org.ops4j.pax.web.service.spi.model.ContextModel,
>> javax.servlet.Servlet, java.lang.String, java.lang.String[],
>> java.lang.String, java.util.Dictionary,
>> java.lang.Integer, java.lang.Boolean, javax.servlet.MultipartConfigElement)
>>
>>
>> it calles method ( private static )
>> new String[]{aliasAsUrlPattern(alias)}
>>
>>
>> private static String aliasAsUrlPattern(final String alias) {
>> String urlPattern = alias;
>> if (urlPattern != null && !urlPattern.equals("/")
>> && !urlPattern.contains("*")) {
>> if (urlPattern.endsWith("/")) {
>> urlPattern = urlPattern + "*";
>> } else {
>> urlPattern = urlPattern + "/*";
>> }
>> }
>> return urlPattern;
>> }
>>
>>
>> so it always creates a url pattern, as I guess the name suggest, but why?
>> I would like to register exact URL, not the pattern. As it looks now, this
>> is not possible to do - as there is no argument to pass in to control the
>> flow.
>>
>> As it looks from the git history/log this is quite "old" code - from 2008
>> - 2013, so I guess this is not new and I guess everybody are ok with this?
>> So in this case, what is the usecase for it? As for my usecase - this is
>> not the required behavior.
>>
>> For example, Servlet, registered with /hello, also matches /hello/1, but
>> I want /hello/1 to return HTTP 404.
>>
>>
>> So for now, only really question is - is this expected behavior or is
>> there a room to change this? If so, how can one, with existing solution,
>> register Servlet with exact URL?
>>
>> Exact strack of calls looks like this:
>>
>> :53, ServletModel (org.ops4j.pax.web.service.spi.model)
>> registerServlet:224, HttpServiceStarted
>> (org.ops4j.pax.web.service.internal)
>> registerServlet:210, HttpServiceStarted
>> (org.ops4j.pax.web.service.internal)
>> registerServlet:69, HttpServiceProxy (org.ops4j.pax.web.service.internal)
>> register:97, ServletWebElement
>> (org.ops4j.pax.web.extender.whiteboard.internal.element)
>> registerWebElement:392, WebApplication
>> (org.ops4j.pax.web.extender.whiteboard.internal)
>> addWebElement:188, WebApplication
>> (org.ops4j.pax.web.extender.whiteboard.internal)
>> addingService:193, AbstractTracker
>> (org.ops4j.pax

Re: [Pax Web] Model change in R7

[Jean-Baptiste Onofré]

Hi Grzegorz

Thanks a lot for your detailed email ! That's a great update and you are
faster than I (I'm sorry I'm late on Pax Web :/ ).
I will ping you on Slack asap to see how I can help.

Regards
JB

On Wed, Feb 12, 2020 at 6:07 PM Grzegorz Grzybek 
wrote:

> Hello
>
> A quick summary of my pending review of Pax Web 8.
>
> I'm reviewing the code from the perspective of:
>  - R7 Whiteboard implementation (allowing e.g.,
> `osgi.http.whiteboard.context.select=(osgi.http.whiteboard.context.name
> =*)`)
>  - Virtual Hosts (Pax Web supports them in Jetty only it seems)
>  - "shared contexts" with special handling of shared HttpContext (old
> HttpService spec), while new ServletContextHelper is "shared" by default
>
> Current "model" is roughly:
>  - ServerModel - ensures uniqueness of element registration
>  - ServiceModel - organizes web elements registered through given,
> bundle-scoped HttpService (which is not that useful in Whiteboard)
>  - ContextModel - which roughly relates to single WAR (web.xml) and
> conflicts with concepts kept at ServiceModel level
>  - ServletModel, FilterModel - that's ok
>
> The problems are:
>  - "virtual host" is only additional layer of mapping inside ServerModel
> and requires tricks when a context is part of multiple virtual hosts (which
> is possible and natural in all 3 runtimes)
>  - ContextModel is tied to bundle (and classloader!) though it should
> model a "context" potentially populated with web elements coming from
> different bundles (if needed)
>
> Specification allows some exotic scenarios:
>  - non default (non "/") context path is allowed ONLY if you register
> ServletContextHelper with a property/annotation
>  - this can potentially switch "default" (OSGi) context to non "/" context
> path
>  - Pax Web allowed to do the same with "old" HttpContext (specify a path)
>  - if two ServletContextHelpers with different name and the same path are
> specified, servlets using two different ServletContextHelpers can be
> registered to the same physical (server specific) context handler - Pax Web
> doesn't handle it well
>
> My current findings:
>  - I've introduced VirtualHostModel to allow namespace clash detection at
> VHost level (not specified by OSGi CMPN) - the goal is to unify Virtual
> Host handling for 3 runtimes
>  - I've split ContextModel into ServletContextModel and OsgiContextModel
> to match specification (where two+ different ServletContextHelpers may
> actually refer to single server-specific context)
>  - I think about removing ServiceModel, because it was HttpService (non
> Whiteboard) centric
>  - I progressed with unification of HttpContext and ServletContextHelper
>  - I'm implementing "transactional" behavior for web element registration
>  - I'm reviewing the layers of interfaces (http service → service
> controller → server state → server abstraction  → actual server), where
> each layer contain interfaces with methods like start() or registerXXX().
>
> Anyway - it became bigger mess than I expected, but I still see the light
> in the tunnel :)
>
> best regards
> Grzegorz Grzybek
>
> --
> --
> --
> OPS4J - http://www.ops4j.org - ops4j@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/CAAdXmhpd%2BR%2BZoM5Jqm7dF0V2jogOVxyJ4%2BxfFwX7WGWUPEV1uQ%40mail.gmail.com
> 
> .
>

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@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/CAB8EV3T3wjnG2ThWgr%3DJ6-HY_jiys4abuuaQcg4Av36990AUpg%40mail.gmail.com.

Re: [PAX WEB] Url Pattern is auto-generated from Alias and how to register exact url pattern

[Jean-Baptiste Onofré]

Hi

Can you please share how you register the servlet ? Via the
httpService.register, Servlet service registration or whiteboard ?

Thanks,
Regards
JB

On Thu, Feb 6, 2020 at 12:14 PM Miroslav Beranič <
miroslav.bera...@mibesis.si> wrote:

> Hi all,
>
> I work with Pax Web on Karaf 4.3.0. I am trying to register Servlet with
> exact url, but I see url pattern is auto-generated from alias.
> I look at the current master branch - version 8.0.0-SNAPSHOT. Class:
>
> org.ops4j.pax.web.service.spi.model.ServletModel
>
>
> constructor:
> #ServletModel(org.ops4j.pax.web.service.spi.model.ContextModel,
> javax.servlet.Servlet, java.lang.String, java.lang.String[],
> java.lang.String, java.util.Dictionary,
> java.lang.Integer, java.lang.Boolean, javax.servlet.MultipartConfigElement)
>
>
> it calles method ( private static )
> new String[]{aliasAsUrlPattern(alias)}
>
>
> private static String aliasAsUrlPattern(final String alias) {
> String urlPattern = alias;
> if (urlPattern != null && !urlPattern.equals("/")
> && !urlPattern.contains("*")) {
> if (urlPattern.endsWith("/")) {
> urlPattern = urlPattern + "*";
> } else {
> urlPattern = urlPattern + "/*";
> }
> }
> return urlPattern;
> }
>
>
> so it always creates a url pattern, as I guess the name suggest, but why?
> I would like to register exact URL, not the pattern. As it looks now, this
> is not possible to do - as there is no argument to pass in to control the
> flow.
>
> As it looks from the git history/log this is quite "old" code - from 2008
> - 2013, so I guess this is not new and I guess everybody are ok with this?
> So in this case, what is the usecase for it? As for my usecase - this is
> not the required behavior.
>
> For example, Servlet, registered with /hello, also matches /hello/1, but I
> want /hello/1 to return HTTP 404.
>
>
> So for now, only really question is - is this expected behavior or is
> there a room to change this? If so, how can one, with existing solution,
> register Servlet with exact URL?
>
> Exact strack of calls looks like this:
>
> :53, ServletModel (org.ops4j.pax.web.service.spi.model)
> registerServlet:224, HttpServiceStarted
> (org.ops4j.pax.web.service.internal)
> registerServlet:210, HttpServiceStarted
> (org.ops4j.pax.web.service.internal)
> registerServlet:69, HttpServiceProxy (org.ops4j.pax.web.service.internal)
> register:97, ServletWebElement
> (org.ops4j.pax.web.extender.whiteboard.internal.element)
> registerWebElement:392, WebApplication
> (org.ops4j.pax.web.extender.whiteboard.internal)
> addWebElement:188, WebApplication
> (org.ops4j.pax.web.extender.whiteboard.internal)
> addingService:193, AbstractTracker
> (org.ops4j.pax.web.extender.whiteboard.internal.tracker)
> addingService:46, AbstractTracker
> (org.ops4j.pax.web.extender.whiteboard.internal.tracker)
> customizerAdding:941, ServiceTracker$Tracked (org.osgi.util.tracker)
> customizerAdding:870, ServiceTracker$Tracked (org.osgi.util.tracker)
> trackAdding:256, AbstractTracked (org.osgi.util.tracker)
> track:229, AbstractTracked (org.osgi.util.tracker)
> serviceChanged:901, ServiceTracker$Tracked (org.osgi.util.tracker)
> invokeServiceListenerCallback:990, EventDispatcher
> (org.apache.felix.framework)
> fireEventImmediately:838, EventDispatcher (org.apache.felix.framework)
> fireServiceEvent:545, EventDispatcher (org.apache.felix.framework)
> fireServiceEvent:4595, Felix (org.apache.felix.framework)
> registerService:3587, Felix (org.apache.felix.framework)
> registerService:348, BundleContextImpl (org.apache.felix.framework)
> registerService:355, BundleContextImpl (org.apache.felix.framework)
>
> I've changed this in my branch, added additional method with same name and
> initParams:
>
> private static String aliasAsUrlPattern(final String alias, final
> Dictionary initParams) {
>final Object exactUrlPatternFromAliasParam =
> initParams.get("exactUrlPattern");
>Boolean exactUrlPatternFromAlias = Boolean.FALSE;
>if (null != exactUrlPatternFromAliasParam) {
>   if (exactUrlPatternFromAliasParam instanceof String) {
>  final String flag = ((String)
> exactUrlPatternFromAliasParam).toLowerCase();
>  exactUrlPatternFromAlias = Boolean.parseBoolean(flag);
>} else if(exactUrlPatternFromAliasParam instanceof Boolean) {
>  final Boolean flag = (Boolean) exactUrlPatternFromAliasParam;
>  exactUrlPatternFromAlias = flag;
>   } else if (exactUrlPatternFromAliasParam instanceof Serializable) {
>  final String flag =
> exactUrlPatternFromAliasParam.toString().toLowerCase();
>  exactUrlPatternFromAlias = Boolean.parseBoolean(flag);
>}
>}
>final String result;
>if (Boolean.TRUE.equals(exactUrlPatternFromAlias)) {
>   // Break the reference
>   result = alias.toString();
>} else {
>   result = aliasAsUrlPattern(alias);
>}
>return 

Re: [PAX WEB] Url Pattern is auto-generated from Alias and how to register exact url pattern

[Jean-Baptiste Onofré]

Hi Grzegorz,

Let's sync together about action plan as I started some changes as well.

Regards
JB

On Thu, Feb 6, 2020 at 12:48 PM Grzegorz Grzybek 
wrote:

> Hello
>
> Yes - this is all confusing... I'm just in the process of reviewing master
> branch (pax web 8.0.0-SNAPSHOT) to check R7 (and even R6) compliance
> There's really lot to do still...
>
> Indeed - I checked
> org.ops4j.pax.web.service.spi.model.ServletModel#aliasAsUrlPattern() and it
> really changes alias like "/something" into "/something/*", but Http
> Service specification explicitly says (102.2 Registering Servlets):
>
> For example, if the Http Service implementation is listening to port 80 on
> the machine www.acme.com and the Servlet object is registered with the
> *name* "/servlet" [...]
>
> I noticed that the spec is not clear about "name" vs. "alias" vs. "URI
> pattern"... And I believe your interpretation is the correct one - "alias"
> is "exact URI pattern"... Of course it still doesn't tell anything about
> actual context to use for servlet registration (I'm just working on making
> it less confusing in pax web 8).
>
> So the only recommendation I have for you is not to use direct
> registration (httpService.registerServlet()), but to use whiteboard
> approach and register Servlet.class OSGi service using
> "BundleContext.registerService(Servlet.class, servlet, props)" where
> properties include either:
>
> props.put("urlPatterns", new String[] { "/hello" }); // old Pax Web
> approach
>
> or:
>
> props.put("osgi.http.whiteboard.servlet.pattern", new String[] { "/hello"
> }); // new R6+ Whiteboard approach (chapter 140.4 "Registering Servlets").
>
> I hope this helps and explains the confusion.
>
> regards
> Grzegorz Grzybek
>
> czw., 6 lut 2020 o 12:14 Miroslav Beranič 
> napisał(a):
>
>> Hi all,
>>
>> I work with Pax Web on Karaf 4.3.0. I am trying to register Servlet with
>> exact url, but I see url pattern is auto-generated from alias.
>> I look at the current master branch - version 8.0.0-SNAPSHOT. Class:
>>
>> org.ops4j.pax.web.service.spi.model.ServletModel
>>
>>
>> constructor:
>> #ServletModel(org.ops4j.pax.web.service.spi.model.ContextModel,
>> javax.servlet.Servlet, java.lang.String, java.lang.String[],
>> java.lang.String, java.util.Dictionary,
>> java.lang.Integer, java.lang.Boolean, javax.servlet.MultipartConfigElement)
>>
>>
>> it calles method ( private static )
>> new String[]{aliasAsUrlPattern(alias)}
>>
>>
>> private static String aliasAsUrlPattern(final String alias) {
>> String urlPattern = alias;
>> if (urlPattern != null && !urlPattern.equals("/")
>> && !urlPattern.contains("*")) {
>> if (urlPattern.endsWith("/")) {
>> urlPattern = urlPattern + "*";
>> } else {
>> urlPattern = urlPattern + "/*";
>> }
>> }
>> return urlPattern;
>> }
>>
>>
>> so it always creates a url pattern, as I guess the name suggest, but why?
>> I would like to register exact URL, not the pattern. As it looks now, this
>> is not possible to do - as there is no argument to pass in to control the
>> flow.
>>
>> As it looks from the git history/log this is quite "old" code - from 2008
>> - 2013, so I guess this is not new and I guess everybody are ok with this?
>> So in this case, what is the usecase for it? As for my usecase - this is
>> not the required behavior.
>>
>> For example, Servlet, registered with /hello, also matches /hello/1, but
>> I want /hello/1 to return HTTP 404.
>>
>>
>> So for now, only really question is - is this expected behavior or is
>> there a room to change this? If so, how can one, with existing solution,
>> register Servlet with exact URL?
>>
>> Exact strack of calls looks like this:
>>
>> :53, ServletModel (org.ops4j.pax.web.service.spi.model)
>> registerServlet:224, HttpServiceStarted
>> (org.ops4j.pax.web.service.internal)
>> registerServlet:210, HttpServiceStarted
>> (org.ops4j.pax.web.service.internal)
>> registerServlet:69, HttpServiceProxy (org.ops4j.pax.web.service.internal)
>> register:97, ServletWebElement
>> (org.ops4j.pax.web.extender.whiteboard.internal.element)
>> registerWebElement:392, WebApplication
>> (org.ops4j.pax.web.extender.whiteboard.internal)
>> addWebElement:188, WebApplication
>> (org.ops4j.pax.web.extender.whiteboard.internal)
>> addingService:193, AbstractTracker
>> (org.ops4j.pax.web.extender.whiteboard.internal.tracker)
>> addingService:46, AbstractTracker
>> (org.ops4j.pax.web.extender.whiteboard.internal.tracker)
>> customizerAdding:941, ServiceTracker$Tracked (org.osgi.util.tracker)
>> customizerAdding:870, ServiceTracker$Tracked (org.osgi.util.tracker)
>> trackAdding:256, AbstractTracked (org.osgi.util.tracker)
>> track:229, AbstractTracked (org.osgi.util.tracker)
>> serviceChanged:901, ServiceTracker$Tracked (org.osgi.util.tracker)
>> invokeServiceListenerCallback:990, EventDispatcher
>> (org.apache.felix.framework)
>> fireEventImmediately:838, 

Re: [PAX WEB] 10 ways (in one of several categories) to register a servlet

[Jean-Baptiste Onofré]

Hi,

I think a cleanup is required.

For Pax Web 8.x, I would simply go with removing the discussed items.

Regards
JB

On 03/02/2020 11:54, Grzegorz Grzybek wrote:
> Hello
>
> I'm reviewing the consistency, stability and user-friendliness of Pax
> Web 8 and I tell myself that if now is not the good time to review the
> interfaces, then we'll never do it.
>
> So, `org.ops4j.pax.web.service.WebContainer` (extension of
> `org.osgi.service.http.HttpService`) allows a servlet to be registered
> in ten (10) ways with different combination of these registration
> parameters:
>  - alias
>  - servlet (instance)
>  - servlet class
>  - servlet name
>  - url patterns
>  - init params
>  - load-on-startup (flag)
>  - async (flag)
>  - multipartConfig (class from javax.servlet API 3+)
>  - http context (org.osgi.service.http.HttpContext)
>
> (so again, magic "10")
>
> Additionally, users may:
>  - register org.ops4j.pax.web.service.whiteboard.ServletMapping
> service that specifies 9 out of 10 of the above parameters directly in
> object's fields
>  - register javax.servlet.Servlet service, where 5 parameters may be
> specified inside service registration dictionary (some Pax Web
> specific and 4 from OSGi CMPN Whiteboard specification)
>  - some parameters may be discovered from annotations on registered
> service's class
>
> None of WebContainer.registerServlet(...) methods accept
> ServletMapping directly. In both cases (user registers ServletMapping
> and user registers Servlet with service properties), relevant trackers
> eventually call
> org.ops4j.pax.web.service.WebContainer#registerServlet() with 8 out of
> 10 parameters (alias is just one of the patterns):
>  - javax.servlet.Servlet
>  - java.lang.String name
>  - java.lang.String[] urlPatterns
>  - java.util.Dictionary initParams
>  - java.lang.Integer loadOnStartup
>  - java.lang.Boolean asyncSupported
>  - javax.servlet.MultipartConfigElement
>  - org.osgi.service.http.HttpContext
>
> It may be a bit confusing... And there are
> org.ops4j.pax.web.service.whiteboard.WhiteboardXXX interfaces (for DTO
> purposes)
>
> We could remove all the variants entirely and leave method that simply
> accept org.ops4j.pax.web.service.whiteboard.ServletMapping (because
> it's now part of the API anyway) that could be created in builder-like
> way.
>
> Or we could @Deprecate the variants...
>
> I don't want to start revolution, I just want to ensure everything is
> consistent.
>
> regards
> Grzegorz Grzybek
> -- 
> -- 
> --
> OPS4J - http://www.ops4j.org - ops4j@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/CAAdXmhqXXt3USsZ14HFFEGz3vY7rU5zEgU5XrmEjWoMTd00TEg%40mail.gmail.com
> .

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@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/196d3c36-65b2-13d2-6c44-8c2ea0d24fd7%40gmail.com.

Re: [PAX-WEB] Interfaces, number of methods and miscellaneous information

[Jean-Baptiste Onofré]

Hi Grzegorz,

I think we can improve some interfaces, especially WebContainer and
Configuration.

Jetty 10 is not an option yet to me as it requires Java 13. IMHO, it's a
too large jump.

I would rather stay with Jetty 9 and Servlet 3.1 for now.

Regards
JB

On 27/01/2020 10:07, Grzegorz Grzybek wrote:
> Hello
>
> I'm trying to do some refactoring of Pax Web for coming 8.0.0 (R7)
> release. The goal is to have support for Undertow 2, Tomcat 9 and
> Jetty 10 (Undertow 2 and Tomcat 9 are already supported in Pax Web
> "special" 7.3.x branch).
>
> I also want to take the opportunity and review some interfaces and how
> Pax Web generally handles resources.
>
> For interfaces, org.ops4j.pax.web.service.WebContainer has 54 methods,
> including 7 overridden methods named "registerServlet"...
> org.ops4j.pax.web.service.spi.ServerController also grown too big
> (IMO). I had to create
> org.ops4j.pax.web.service.spi.ServerControllerEx to not break semantic
> versioning - now I want to merge them into one.
> org.ops4j.pax.web.service.spi.Configuration interface is also strange
> - it has way too many methods, adding new option requires API change
> and there's only one implementation - I don't see any benefit in
> keeping current shape of this interface...
>
> As for resource handling, I had case where WAR bundle with embedded
> primefaces.jar didn't work - because MyFaces wasn't able to find all
> configs (faces, taglib and facelets) in such WAR. The reason is mixing
> classloader and non-classloader resource loading.
>
> Also xbean-finder we use in Pax Web now doesn't use "new" Wiring API
> at all to load resources.
>
> I'm not ready yet with the changes, but I think I can show something
> soon. Full refactoring worked well (IMO) with Pax Logging, where not
> only I've unified the way 3 logging libraries are used, but I also
> increased number of integration tests from 1 to 120.
>
> regards
> Grzegorz Grzybek
> -- 
> -- 
> --
> OPS4J - http://www.ops4j.org - ops4j@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/CAAdXmhoEVTTDjSEOrou7gYj428Lr9e8A8gxbM3WP9ZR_imj5-A%40mail.gmail.com
> .

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@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/ac6c7dda-b441-2b84-9bb9-9d020b74ca52%40gmail.com.

Re: State of Pax-Web integrationtests?

[Jean-Baptiste Onofré]

Hi Achim,

If you checked on master, we are working on the R7 support, so we have
some parts broken.

The pax-web-7.2.x (used in Karaf) should be fine for itests.

Regards
JB

On 11/01/2020 12:38, 'Achim Nierbeck' via OPS4J wrote:
> Hi,
>
> as I wanted to take a look if the github project build is sufficient,
> instead of travis etc.
> I wanted to check the build locally.
> But right now, the integration tests don't seem to work properly.
> At least not all of them.
> The following tests are failing: [ERROR] Failures:
> [ERROR]   WebContainerSpdyIntegrationTest.listBundles:120 Bundle
> should be active: org.apache.felix.scr [20]
> [ERROR]  
> WhiteboardR6DtoIntegrationTest>AbstractWhiteboardR6DtoIntegrationTest.testRequestInfoDto_CustomContext:316->AbstractWhiteboardR6DtoIntegrationTest.lambda$testRequestInfoDto_CustomContext$30:316
> CustomContext ServletContext not found
> [ERROR] Errors:
> [ERROR]   CdiIntegrationTest.testCdi » Connect Connection refused
> [ERROR]   WarJsfCdiIntegrationTest.testCdi » Connect Connection refused
> [ERROR]   WarJsfResourcehandlerIntegrationTest.testJsfResourceHandler
> » ClassNotFound or...
> [ERROR]   WarJsfResourcehandlerIntegrationTest.testResourceUnavailble
> » ClassNotFound or...
> [ERROR]   WarJsfResourcehandlerIntegrationTest.testServiceOverride »
> ClassNotFound org.o...
> [ERROR]  
> WhiteboardDSRestartIntegrationTest>AbstractWhiteboardDSRestartIntegrationTest.setUp:48->AbstractControlledTestBase.installAndStartBundle:250
> » Bundle
> [ERROR]  
> WhiteboardDSRestartIntegrationTest>AbstractWhiteboardDSRestartIntegrationTest.setUp:48->AbstractControlledTestBase.installAndStartBundle:250
> » Bundle
> [ERROR]  
> WhiteboardDSRestartIntegrationTest>AbstractWhiteboardDSRestartIntegrationTest.setUp:48->AbstractControlledTestBase.installAndStartBundle:250
> » Bundle
> [ERROR]  
> WhiteboardDSRestartIntegrationTest>AbstractWhiteboardDSRestartIntegrationTest.setUp:48->AbstractControlledTestBase.installAndStartBundle:250
> » Bundle
> [ERROR]  
> WhiteboardDSRestartIntegrationTest>AbstractWhiteboardDSRestartIntegrationTest.setUp:48->AbstractControlledTestBase.installAndStartBundle:250
> » Bundle
> [ERROR]  
> WhiteboardIntegrationTest>AbstractWhiteboardIntegrationTest.testMultipleContextMappingsWithDTOsCheck:223
> » IllegalState
> [ERROR]  
> WhiteboardR6DtoIntegrationTest.testAllSamplesRegisteredAsExpected »
> Connect Co...
> [ERROR]  
> WhiteboardR6DtoIntegrationTest>AbstractWhiteboardR6DtoIntegrationTest.testRequestInfoDto:291
> » ClassCast
> [ERROR]  
> WhiteboardR6DtoIntegrationTest>AbstractWhiteboardR6DtoIntegrationTest.testRuntimeDto:161->AbstractWhiteboardR6DtoIntegrationTest.withService:149
> » IllegalState
> [ERROR]  
> WhiteboardR6DtoIntegrationTest>AbstractWhiteboardR6DtoIntegrationTest.testRuntimeDtoWithFailedServices:274->AbstractWhiteboardR6DtoIntegrationTest.withService:149
> » IllegalState
>
> Is this just for me, or do we have a general problem with the project?
>
> regards, Achim
>
> -- 
>
> Apache Member
> Apache Karaf  Committer & PMC
> OPS4J Pax Web 
> Committer & Project Lead
> blog 
> Co-Author of Apache Karaf Cookbook 
>
> -- 
> -- 
> --
> OPS4J - http://www.ops4j.org - ops4j@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/CAD0r13f%3DPeaNfpS2%3D04%3D4CTQr2EMPZy99G2O81OpB%3D6zy%2B_XYg%40mail.gmail.com
> .

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@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/a54cf018-1445-d909-cb3b-e78cf39e5fcd%40gmail.com.

Re: pax-logging 1.11.4 release?

[Jean-Baptiste Onofré]

Yeah agree. I can also tackle the release if needed.

Regards
JB

Le jeu. 2 janv. 2020 à 17:26, Matt Pavlovich  a écrit :

> Grzegorz-
>
> I saw you just merged support for log4j2 2.13.0 into the 1.11.4 branch.
> What are your thoughts on timing for a 1.11.4 release? A Karaf 4.2.8 is in
> the works, it'd be good to get that in for a number of fixes and dependency
> alignment (KARAF-6574).
>
> Thanks,
> Matt
>
> --
> --
> --
> OPS4J - http://www.ops4j.org - ops4j@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/e49e4fa5-7e33-4aa3-b343-a22180db098a%40googlegroups.com
> 
> .
>

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@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/CAB8EV3RzkVfErDMT33ERY8gPYbTvdvr%3DcxN2i8Adm9GXB1NNeQ%40mail.gmail.com.

Re: [snapshot] - Repository

[Jean-Baptiste Onofré]

Hi,

Some Pax projects (like Pax Web) used both Jenkins AND Travis. We still 
have the configuration in place.


Regards
JB

On 02/12/2019 11:24, françois papon wrote:

Thanks JB!

I also check http://ci.ops4j.org/jenkins/ and it's very slow and unusable.

Is there an another CI for the projects? (like Travis).

regards,

*François Papon*
*papon...@gmail.com <mailto:papon...@gmail.com>*


Le lun. 2 déc. 2019 à 11:20, Jean-Baptiste Onofré 
mailto:jeanbaptiste.ono...@gmail.com>> 
a écrit :


Hi,

Let me check.

I keep you posted.

Regards
JB

On 02/12/2019 11:01, françois papon wrote:

Hi,

The
https://oss.sonatype.org/content/repositories/ops4j-snapshots/ is
not available.

Is it normal? May be the repository have been moved?

regards,

* François*
-- 
-- 
--

OPS4J - http://www.ops4j.org - ops4j@googlegroups.com
<mailto:ops4j@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
<mailto:ops4j+unsubscr...@googlegroups.com>.
To view this discussion on the web visit

https://groups.google.com/d/msgid/ops4j/CAJ1FmOgGX7SC5V27x88U%2BDAen02eMWm1WUbyZpoFq-jotondUw%40mail.gmail.com

<https://groups.google.com/d/msgid/ops4j/CAJ1FmOgGX7SC5V27x88U%2BDAen02eMWm1WUbyZpoFq-jotondUw%40mail.gmail.com?utm_medium=email_source=footer>.
-- 
-- 
--

OPS4J - http://www.ops4j.org - ops4j@googlegroups.com
<mailto:ops4j@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
<mailto:ops4j+unsubscr...@googlegroups.com>.
To view this discussion on the web visit

https://groups.google.com/d/msgid/ops4j/1eabdde2-01a1-8cfe-ac12-a2b7902aeb6e%40gmail.com

<https://groups.google.com/d/msgid/ops4j/1eabdde2-01a1-8cfe-ac12-a2b7902aeb6e%40gmail.com?utm_medium=email_source=footer>.

--
--
--
OPS4J - http://www.ops4j.org - ops4j@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 
<mailto:ops4j+unsubscr...@googlegroups.com>.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/ops4j/CAJ1FmOjmxWkaVa8ELw4q_bA9jCp%3Dw1n09%3DP22tBY7i3iv0pp9Q%40mail.gmail.com 
<https://groups.google.com/d/msgid/ops4j/CAJ1FmOjmxWkaVa8ELw4q_bA9jCp%3Dw1n09%3DP22tBY7i3iv0pp9Q%40mail.gmail.com?utm_medium=email_source=footer>.


--
--
--
OPS4J - http://www.ops4j.org - ops4j@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/6ac8d225-fa0c-2942-d5c2-bb5651298ca1%40gmail.com.

Re: [snapshot] - Repository

[Jean-Baptiste Onofré]

Hi,

Let me check.

I keep you posted.

Regards
JB

On 02/12/2019 11:01, françois papon wrote:

Hi,

The https://oss.sonatype.org/content/repositories/ops4j-snapshots/ is 
not available.


Is it normal? May be the repository have been moved?

regards,

* François*
--
--
--
OPS4J - http://www.ops4j.org - ops4j@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/CAJ1FmOgGX7SC5V27x88U%2BDAen02eMWm1WUbyZpoFq-jotondUw%40mail.gmail.com 
.


--
--
--
OPS4J - http://www.ops4j.org - ops4j@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/1eabdde2-01a1-8cfe-ac12-a2b7902aeb6e%40gmail.com.

Re: Pax-Testing camel routes in Karaf with CamelTestSupport on recent versions

[Jean-Baptiste Onofré]

Hi Dietrich,

Yeah, it's a pretty old blog post ;) I think it makes sense to add or
extend the Karaf examples.

I will do it.

Thanks,
Regards
JB

On 30/11/2019 10:25, Dietrich Schulten wrote:
> Exactly. Those spring and activemq versions were a bit painful indeed :)
>
> Btw your old blog code is running again 
> https://github.com/dschulten/blog-camel-blueprint/tree/karaf4-paxexam4. Care 
> for a PR to your blog sample after 4.2.8 is out?
>
> Best,
> Dietrich
>

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@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/3e2b52e5-4b34-9d12-6030-c3b8dac97ba6%40gmail.com.

Re: Pax-Testing camel routes in Karaf with CamelTestSupport on recent versions

[Jean-Baptiste Onofré]

Hi Dietrich

Just a small note: I did cleanups/improvements on KarafTestSupport in
Karaf 4.2.8-SNAPSHOT. It's easier to use now. So I would advice to use
KarafTestSupport from Karaf 4.2.8-SNAPSHOT (I'm preparing Karaf 4.2.8
anyway ;) ).

Regards
JB

On 29/11/2019 12:03, Dietrich Schulten wrote:
> Hi,
>
> thank you very much, I was already wondering if CamelTestSupport is
> still a good fit for Pax Karaf Tests. You gave a clear opinion here :)
>
> I see you have built your test upon KarafTestSupport and I was already
> able to get that to work in my environment, so that looks most promising.
> I'll try to update my clone of your older tutorial accordingly.
>
> Best,
> Dietrich
>
>
> Am Freitag, 29. November 2019 10:02:38 UTC+1 schrieb Jean-Baptiste
> Onofré:
>
> Hi,
>
> CamelTestSupport is for utest whereas pax-exam is more for itest.
>
> You can take a look on some itest I did about Camel, for instance:
>
> 
> https://github.com/apache/karaf-decanter/pull/111/files#diff-f23addf50c34ea79c8df17bb2861d649
> 
> <https://github.com/apache/karaf-decanter/pull/111/files#diff-f23addf50c34ea79c8df17bb2861d649>
>
> So, you should *NOT* use CamelTestSupport for itest (and keep it
> for utest), and directly use producerTemplate, etc for itest.
>
> Regards
>
> JB
>
> On 29/11/2019 09:59, Dietrich Schulten wrote:
>> Hi,
>>
>> I want to test Camel routes in Karaf. I use Pax-Exam to run Karaf. 
>> For older Karaf and Camel versions, I found a blog article by
>> J.B. Onofre which shows how one can use CamelTestSupport to do that.
>>
>> I got it working on JDK 8 for an older combination of Camel,
>> Karaf and PaxExam with numerous adjustments (see links below).
>> But when I switch to the current versions (Camel 2.24.2, Karaf
>> 4.2.7, Pax-Exam 4.13.1), the CamelTestSupport setup fails,
>> complaining with ClassNotFoundException:
>> org.apache.camel.util.jndi.CamelInitialContextFactory.
>>
>> When I disable the CamelTestSupport.setUp()method by overriding
>> it with an empty method, I can see that the camel-core feature is
>> present:
>>
>> 
>> assertTrue(featuresService.isInstalled(featuresService.getFeature("camel-core")));
>>
>> I have also tried to import
>> the org.apache.camel.util.jndi package into the probe bundle. The
>> package gets exported by the camel-core bundle jar, at least its
>> MANIFEST.MF says so.
>>
>>     @ProbeBuilder
>>     public TestProbeBuilder probeConfiguration(TestProbeBuilder
>> probe) {
>>         probe.setHeader(Constants.IMPORT_PACKAGE,
>> "*,org.apache.camel.util.jndi");
>>         return probe;
>>     }
>>
>> The import appears to work, at least I get no import error during
>> test execution.
>>
>> Why can the test bundle not find the CamelInitialContextFactory?
>>
>> I have created a clone of J.B. Onofre's Github example which
>> fixes the JDK 8 issues and another one with recent versions which
>> demonstrates the problem.
>>
>> Works: Karaf 2.4 with Camel 2.12.1 on JDK 8
>> <https://github.com/dschulten/blog-camel-blueprint/tree/karaf24-jdk8>
>> Fails: Karaf 4.2.7 using Camel 2.24.2
>> <https://github.com/dschulten/blog-camel-blueprint/tree/karaf4-paxexam4>.
>>
>> Here is my stack overflow question with all the details and other
>> attempts I have made:
>> 
>> https://stackoverflow.com/questions/59075424/testing-camel-2-24-x-routes-in-karaf-4-2-7-with-cameltestsupport
>> 
>> <https://stackoverflow.com/questions/59075424/testing-camel-2-24-x-routes-in-karaf-4-2-7-with-cameltestsupport>
>>
>> Best,
>> Dietrich
>> -- 
>> -- 
>> --
>> 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 op...@googlegroups.com .
>> To view this discussion on the web visit
>> 
>> https://groups.google.com/d/msgid/ops4j/99d4fc11-99bb-44b9-8385-f07bd559a22c%40googlegroups.com
>> 
>> <https://groups.google.com/d/msgid/ops4j/99d4fc11-99bb-44b9-8385-f07bd559a22c%40googlegroups.com?utm_medium=email_source=footer>.
>
> -- 
> -- 
> 

Re: Pax-Testing camel routes in Karaf with CamelTestSupport on recent versions

[Jean-Baptiste Onofré]

Hi,

CamelTestSupport is for utest whereas pax-exam is more for itest.

You can take a look on some itest I did about Camel, for instance:

https://github.com/apache/karaf-decanter/pull/111/files#diff-f23addf50c34ea79c8df17bb2861d649

So, you should *NOT* use CamelTestSupport for itest (and keep it for
utest), and directly use producerTemplate, etc for itest.

Regards

JB

On 29/11/2019 09:59, Dietrich Schulten wrote:
> Hi,
>
> I want to test Camel routes in Karaf. I use Pax-Exam to run Karaf. 
> For older Karaf and Camel versions, I found a blog article by J.B.
> Onofre which shows how one can use CamelTestSupport to do that.
>
> I got it working on JDK 8 for an older combination of Camel, Karaf and
> PaxExam with numerous adjustments (see links below). But when I switch
> to the current versions (Camel 2.24.2, Karaf 4.2.7, Pax-Exam 4.13.1),
> the CamelTestSupport setup fails, complaining
> with ClassNotFoundException:
> org.apache.camel.util.jndi.CamelInitialContextFactory.
>
> When I disable the CamelTestSupport.setUp()method by overriding it
> with an empty method, I can see that the camel-core feature is present:
>
> assertTrue(featuresService.isInstalled(featuresService.getFeature("camel-core")));
>
> I have also tried to import the org.apache.camel.util.jndi package
> into the probe bundle. The package gets exported by the camel-core
> bundle jar, at least its MANIFEST.MF says so.
>
>     @ProbeBuilder
>     public TestProbeBuilder probeConfiguration(TestProbeBuilder probe) {
>         probe.setHeader(Constants.IMPORT_PACKAGE,
> "*,org.apache.camel.util.jndi");
>         return probe;
>     }
>
> The import appears to work, at least I get no import error during test
> execution.
>
> Why can the test bundle not find the CamelInitialContextFactory?
>
> I have created a clone of J.B. Onofre's Github example which fixes the
> JDK 8 issues and another one with recent versions which demonstrates
> the problem.
>
> Works: Karaf 2.4 with Camel 2.12.1 on JDK 8
> 
> Fails: Karaf 4.2.7 using Camel 2.24.2
> .
>
> Here is my stack overflow question with all the details and other
> attempts I have made:
> https://stackoverflow.com/questions/59075424/testing-camel-2-24-x-routes-in-karaf-4-2-7-with-cameltestsupport
>
> Best,
> Dietrich
> -- 
> -- 
> --
> OPS4J - http://www.ops4j.org - ops4j@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/99d4fc11-99bb-44b9-8385-f07bd559a22c%40googlegroups.com
> .

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@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/e1c60b1a-4581-f8a4-80c7-e156f07545a3%40gmail.com.

Re: Pax Runner Issue with Java11

[Jean-Baptiste Onofré]

Hi Rome,

For Pax Runner you are right (I don't have the issue in Pax Exam as we
are using Karaf).

I will create the Jira and fix that.

Regards
JB

On 01/11/2019 19:39, Rome Agapkin wrote:
> i have just checked the source code of the pax-runner-platform project
> and see that there is no execution environment in
>
> /pax-runner-platform/src/main/resources/META-INF/platform/ee
>
> for neither one above java 8, so i'm wondering, what would be
> necessary to create one, beside removing outdated packages like
> javax.xml. and others...?
> -- 
> -- 
> --
> OPS4J - http://www.ops4j.org - ops4j@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/cce76364-42fa-4229-879c-dcb973979ee1%40googlegroups.com
> .

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@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/a5a48408-f22c-40d9-2807-a8c3c4737cbd%40gmail.com.

Re: Derby is looking for assistance with OSGi compatibility

[Jean-Baptiste Onofré]

Nice !

Don't hesitate to ping if needed !

Regards
JB

On 18/10/2019 13:22, Mark Raynsford wrote:
> On 2019-10-18T07:02:55 +0200
> 'Christoph Läubrich' via OPS4J  wrote:
>
>> IMO instead of adding own support we better should convince open-source 
>> projects to add first-class support for osgi/JDBC service, so +1 for the 
>> request from my side. As it seems you have added initial code for derby 
>> (or at least readded it) you might want to contribute the code to 
>> derby-project under required license?
> Thanks, all!
>
> Yes, I'm going to get the OSGi headers into the published Derby
> artifacts (at a minimum) this weekend. Implementing the OSGi JDBC
> service also looks pretty easy, so I'll be attempting that too.
>

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@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/d3cc8e70-2d5f-a027-12f2-2ec639eefd1f%40gmail.com.


signature.asc
Description: OpenPGP digital signature

Re: Derby is looking for assistance with OSGi compatibility

[Jean-Baptiste Onofré]

Hi,

I agree, my point is that we can help anyway directly in the project.
Pax JDBC is more a workaround at driver level.

Regards
JB

On 18/10/2019 07:02, 'Christoph Läubrich' via OPS4J wrote:
> I already commented there, in a perfect world there would be no need
> to have extra libs to use JDBC drivers in OSGi, thats why I add
> support for it whenever possible even though it often takes some time
> (approx 8 month in both cases):
>
> https://github.com/microsoft/mssql-jdbc/pull/700
> https://github.com/MariaDB/mariadb-connector-j/pull/133
>
> IMO instead of adding own support we better should convince
> open-source projects to add first-class support for osgi/JDBC service,
> so +1 for the request from my side. As it seems you have added initial
> code for derby (or at least readded it) you might want to contribute
> the code to derby-project under required license?
>
> Am 18.10.19 um 06:16 schrieb Jean-Baptiste Onofré:
>> Hi Mark,
>>
>> I will take a look on the Jira. As we are working on Pax JDBC, and Derby
>> is used there (wrapped), we already have good OSGi support in Derby.
>>
>> Thanks for sharing,
>>
>> Regards
>> JB
>>
>> On 17/10/2019 21:09, 'Mark Raynsford' via OPS4J wrote:
>>> Hello!
>>>
>>> I recently posted to the Derby list because I noticed that Derby
>>> 10.15.1.3 didn't have any OSGi headers in the manifest. Rick Hillegas
>>> emailed back and has created an issue to track this:
>>>
>>>    https://issues.apache.org/jira/browse/DERBY-7056
>>>
>>> He said: "None of the active Derby contributors is an OSGi expert. We
>>> will need your advice on what's required."
>>>
>>> I'm by no means an OSGi expert, although I do have some idea as to what
>>> probably needs to be done, having assisted various other projects with
>>> OSGi compatibility. It occurred to me, however, that I know of a few
>>> people who know OSGi, know JDBC, and know Derby to some extent. :)
>>>
>>> I'd appreciate your input on that ticket, if you can spare the time.
>>>
>>
>

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@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/4cebb553-7ea3-1e14-081c-962f6e3a38e3%40gmail.com.

Re: Derby is looking for assistance with OSGi compatibility

[Jean-Baptiste Onofré]

Hi Mark,

I will take a look on the Jira. As we are working on Pax JDBC, and Derby
is used there (wrapped), we already have good OSGi support in Derby.

Thanks for sharing,

Regards
JB

On 17/10/2019 21:09, 'Mark Raynsford' via OPS4J wrote:
> Hello!
>
> I recently posted to the Derby list because I noticed that Derby
> 10.15.1.3 didn't have any OSGi headers in the manifest. Rick Hillegas
> emailed back and has created an issue to track this:
>
>   https://issues.apache.org/jira/browse/DERBY-7056
>
> He said: "None of the active Derby contributors is an OSGi expert. We
> will need your advice on what's required."
>
> I'm by no means an OSGi expert, although I do have some idea as to what
> probably needs to be done, having assisted various other projects with
> OSGi compatibility. It occurred to me, however, that I know of a few
> people who know OSGi, know JDBC, and know Derby to some extent. :)
>
> I'd appreciate your input on that ticket, if you can spare the time.
>

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@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/b6d82825-2f33-de2e-3f77-a264818c4f9a%40gmail.com.


signature.asc
Description: OpenPGP digital signature

Re: Servlet Filters registered, activated but not processing request

[Jean-Baptiste Onofré]

Hi

As said, I did a fix on pax web 7.2.10 about twice service registration. It
might help.

Regards
JB

Le sam. 14 sept. 2019 à 19:41, Nhut Thai Le  a écrit :

> We recently upgrade to pax-web 7.2.10 and i haven't seen this happen again
> yet. Even with 7.2.4 it only happened a few times, I'll post the heap dump
> and instance of Filter. However, in my question, i showed that all of my 4
> filters have been registered and they have componentId, doesnt it mean they
> are instantiated?
>
> Thai
>
> On Tuesday, September 10, 2019 at 5:04:19 AM UTC-4, Grzegorz Grzybek wrote:
>>
>> Hello
>>
>> org.ops4j.pax.web.service.internal.HttpServiceStarted#registerFilter()
>> method should correctly take service ranking into account.
>>
>> With Jetty, filters are registered (sorted by rank) inside
>> org.ops4j.pax.web.service.jetty.internal.JettyServerImpl#addFilter(), you
>> could enable "org.ops4j.pax.web.service.jetty.internal" DEBUG level to
>> check what has happened.
>>
>> Heap dump would be interesting too to check if all filters were
>> registered.
>>
>> Do you have Karaf output (if using Karaf at all) for list of services
>> with objectClass=javax.servlet.Filter?
>>
>> regards
>> Grzegorz Grzybek
>>
>> czw., 15 sie 2019 o 17:30 Nhut Thai Le  napisał(a):
>>
>>> Hello,
>>>
>>> I have 4 servlet filters for one ServletContextHelper, having the same
>>> filter pattern and they are from the same bundle and have different
>>> ranking. When starting server, i see these filters have been registered:
>>>
>>> {javax.servlet.Filter}={service.id=992, service.bundleid=405,
>>> service.scope=prototype, *service.ranking=11*,
>>> osgi.http.whiteboard.context.select=(osgi.http.whiteboard.context.name=
>>> *WebviewerServletContextHelper*),
>>> filter.init.excludedUrls=/zkcomet,/logout/select,/logout,
>>> osgi.http.whiteboard.filter.pattern=/*, component.name
>>> =com.castortech.iris.ba.web.filters.*BaSessionFilter*,
>>> osgi.http.whiteboard.filter.asyncSupported=true, component.id=1186}
>>>   "Registered by bundle:" 
>>> *com.castortech.iris.ba.web.filters_1.0.0.qualifier
>>> [405]*
>>>   "Bundles using service"
>>> org.ops4j.pax.web.pax-web-extender-whiteboard_7.2.4 [8]
>>> {javax.servlet.Filter}={service.id=1352, service.bundleid=405,
>>> service.scope=prototype, *service.ranking=3*,
>>> osgi.http.whiteboard.context.select=(osgi.http.whiteboard.context.name=
>>> *WebviewerServletContextHelper*), filter.init.excludedUrls=/zkcomet,
>>> osgi.http.whiteboard.filter.pattern=/*, component.name
>>> =com.castortech.iris.ba.web.filters.*TenantFilter*,
>>> osgi.http.whiteboard.filter.asyncSupported=true, component.id=1185}
>>>   "Registered by bundle:" 
>>> *com.castortech.iris.ba.web.filters_1.0.0.qualifier
>>> [405]*
>>>   "Bundles using service"
>>> org.ops4j.pax.web.pax-web-extender-whiteboard_7.2.4 [8]
>>> {javax.servlet.Filter}={service.id=652, service.bundleid=405,
>>> service.scope=prototype, *service.ranking=2*,
>>> osgi.http.whiteboard.context.select=(osgi.http.whiteboard.context.name=
>>> *WebviewerServletContextHelper*), filter.init.excludedUrls=/zkcomet,
>>> osgi.http.whiteboard.filter.pattern=/*, component.name
>>> =com.castortech.iris.ba.web.filters.*KeycloakSessionFilter*,
>>> osgi.http.whiteboard.filter.asyncSupported=true, component.id=1161}
>>>   "Registered by bundle:" 
>>> *com.castortech.iris.ba.web.filters_1.0.0.qualifier
>>> [405]*
>>>   "Bundles using service"
>>> org.ops4j.pax.web.pax-web-extender-whiteboard_7.2.4 [8]
>>> {javax.servlet.Filter}={service.id=653, service.bundleid=405,
>>> service.scope=prototype, *service.ranking=1*,
>>> osgi.http.whiteboard.context.select=(osgi.http.whiteboard.context.name=
>>> *WebviewerServletContextHelper*), component.name
>>> =com.castortech.iris.ba.web.filters.*AuthenticationFilterForWebViewer*,
>>> component.id=1164,
>>> keycloak.config.resolver=com.castortech.iris.ba.web.filters.BundleBasedKeycloakConfigResolver,
>>> filter.init.excludedUrls=/zkcomet, osgi.http.whiteboard
>>> .filter.pattern=/*, osgi.http.whiteboard.filter.asyncSupported=true}
>>>   "Registered by bundle:" 
>>> *com.castortech.iris.ba.web.filters_1.0.0.qualifier
>>> [405]*
>>>   "Bundles using service"
>>> org.ops4j.pax.web.pax-web-extender-whiteboard_7.2.4 [8]
>>>
>>> Normally the request is processed by all 4 filters in ascending order,
>>> but this morning, after i restart the server I see when a request come in,
>>> it arrives at the TenantFilte (ranking=3) skipping filters ranking 1 and 2.
>>>
>>> [image: filterErr1.PNG]
>>>
>>> Anyone has an idea why would this happen?
>>>
>>>
>>>
>>>
>>> --
>>> --
>>> --
>>> 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 op...@googlegroups.com.
>>> To view this discussion on the web visit
>>> 

Re: PAXWEB 7.3.x - release?

[Jean-Baptiste Onofré]

+1, go for it

I will deal with 7.2.11 release.

Thanks
Regards
JB

Le ven. 13 sept. 2019 à 03:59, Grzegorz Grzybek  a
écrit :

> Hello
>
> I'm planning to release pax web 7.3.4 with recent fixes and dependency
> upgrades.
>
> Please mind, that this is *not* a version to be used in upcoming Karaf
> 4.2.7 (where pax-web 7.2.x is used). 7.3.x is the branch, where Tomcat 9
> and Undertow 2 are used as kind of tech-preview before R7-compliant (soon™)
> Pax Web 8.x.
>
> Any objections?
>
> kind regards
> Grzegorz Grzybek
>
> --
> --
> --
> OPS4J - http://www.ops4j.org - ops4j@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/CAAdXmhqvFrynJ9rwgnudm7xVW9roerP_4CA4yd%2BrX8O8GCzFhg%40mail.gmail.com
> 
> .
>

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@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/CAB8EV3QHihUgg67yb0H-fpcYzzj9GOg9VM17YN-0Wq1GU%2B9rvA%40mail.gmail.com.

Re: [PAX-WEB] next 7.2.x release soon?

[Jean-Baptiste Onofré]

Yeah, I'm fixing the latest itests issues and we are good to go.

The release will happen very soon.

Regards
JB

Le jeu. 12 sept. 2019 à 08:08, DEREK MCKEOWN  a écrit :

> Hi,
>
> Any updates on this?
>
> Regards
> Derek
>
> Sent from my iPhone
>
> On 29 Aug 2019, at 10:34, Jean-Baptiste Onofré <
> jeanbaptiste.ono...@gmail.com> wrote:
>
> Hi
>
> I'm working on some security updates. I will cut the release before the
> end of this week.
>
> Regards
> JB
>
> Le jeu. 29 août 2019 à 09:19, Derek Mckeown  a écrit :
>
>> Hi,
>>
>> was this 7.2.10? can I ask if there's a rough estimate for 7.2.11 coming
>> out?
>>
>> Regards
>> Derek
>>
>> On Monday, August 19, 2019 at 11:59:53 AM UTC+1, Jean-Baptiste Onofré
>> wrote:
>>>
>>> Hi
>>>
>>> Yes, it's plan to cut a release this week.
>>>
>>> Regards
>>> JB
>>>
>>> Le lun. 19 août 2019 à 12:40, Jens Kordowski  a
>>> écrit :
>>>
>>>> Hi,
>>>>
>>>> I was wondering when there will be a new 7.2.x release of pax web. Any
>>>> plans?
>>>>
>>>> Best regards
>>>> Jens
>>>>
>>>> --
>>>> --
>>>> --
>>>> 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 op...@googlegroups.com.
>>>> To view this discussion on the web visit
>>>> https://groups.google.com/d/msgid/ops4j/33dbb25e-8485-471a-bdab-2fa53df131b5%40googlegroups.com
>>>> <https://groups.google.com/d/msgid/ops4j/33dbb25e-8485-471a-bdab-2fa53df131b5%40googlegroups.com?utm_medium=email_source=footer>
>>>> .
>>>>
>>> --
>> --
>> --
>> OPS4J - http://www.ops4j.org - ops4j@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/23e89390-8ba1-48ad-83ea-649d1b866f8f%40googlegroups.com
>> <https://groups.google.com/d/msgid/ops4j/23e89390-8ba1-48ad-83ea-649d1b866f8f%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
> --
> --
> --
> OPS4J - http://www.ops4j.org - ops4j@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/CAB8EV3SQu_iSZ4hF%3Dc3-sYoE9nbALEtZPJWcsrBm9QP-r-zkZw%40mail.gmail.com
> <https://groups.google.com/d/msgid/ops4j/CAB8EV3SQu_iSZ4hF%3Dc3-sYoE9nbALEtZPJWcsrBm9QP-r-zkZw%40mail.gmail.com?utm_medium=email_source=footer>
> .
>
> --
> --
> --
> OPS4J - http://www.ops4j.org - ops4j@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/FCB3EEEC-C76C-48E2-9108-C600361A0E1F%40gmail.com
> <https://groups.google.com/d/msgid/ops4j/FCB3EEEC-C76C-48E2-9108-C600361A0E1F%40gmail.com?utm_medium=email_source=footer>
> .
>

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@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/CAB8EV3Rkb4_aNK8xS6cjoNmKQkfbbmMwDsdwC0ME57FRJE-jbg%40mail.gmail.com.

Re: [PAX-WEB] next 7.2.x release soon?

[Jean-Baptiste Onofré]

Hi

I'm working on some security updates. I will cut the release before the end
of this week.

Regards
JB

Le jeu. 29 août 2019 à 09:19, Derek Mckeown  a écrit :

> Hi,
>
> was this 7.2.10? can I ask if there's a rough estimate for 7.2.11 coming
> out?
>
> Regards
> Derek
>
> On Monday, August 19, 2019 at 11:59:53 AM UTC+1, Jean-Baptiste Onofré
> wrote:
>>
>> Hi
>>
>> Yes, it's plan to cut a release this week.
>>
>> Regards
>> JB
>>
>> Le lun. 19 août 2019 à 12:40, Jens Kordowski  a
>> écrit :
>>
>>> Hi,
>>>
>>> I was wondering when there will be a new 7.2.x release of pax web. Any
>>> plans?
>>>
>>> Best regards
>>> Jens
>>>
>>> --
>>> --
>>> --
>>> 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 op...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/ops4j/33dbb25e-8485-471a-bdab-2fa53df131b5%40googlegroups.com
>>> <https://groups.google.com/d/msgid/ops4j/33dbb25e-8485-471a-bdab-2fa53df131b5%40googlegroups.com?utm_medium=email_source=footer>
>>> .
>>>
>> --
> --
> --
> OPS4J - http://www.ops4j.org - ops4j@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/23e89390-8ba1-48ad-83ea-649d1b866f8f%40googlegroups.com
> <https://groups.google.com/d/msgid/ops4j/23e89390-8ba1-48ad-83ea-649d1b866f8f%40googlegroups.com?utm_medium=email_source=footer>
> .
>

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@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/CAB8EV3SQu_iSZ4hF%3Dc3-sYoE9nbALEtZPJWcsrBm9QP-r-zkZw%40mail.gmail.com.

Re: [PAX-WEB] next 7.2.x release soon?

[Jean-Baptiste Onofré]

Hi

Yes, it's plan to cut a release this week.

Regards
JB

Le lun. 19 août 2019 à 12:40, Jens Kordowski  a
écrit :

> Hi,
>
> I was wondering when there will be a new 7.2.x release of pax web. Any
> plans?
>
> Best regards
> Jens
>
> --
> --
> --
> OPS4J - http://www.ops4j.org - ops4j@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/33dbb25e-8485-471a-bdab-2fa53df131b5%40googlegroups.com
> 
> .
>

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@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/CAB8EV3SwSHV5XixufRAAXZwYGooWZ0Mb%3DPBWDQ1Yg6ktwzJiDQ%40mail.gmail.com.

Re: pax-web-extender-whiteboard Servlet filters ordering

[Jean-Baptiste Onofré]

Hi,

Sorry, I meant 7.3.x ;)

Regards
JB

On 12/08/2019 20:25, Nhut Thai Le wrote:
> Hi JB,
>
> I haven't tried 4.3.x, but mine is 7.2.4 and it is much latter. Can
> you elaborate why i should try an older version?
>
> Thai
>
> On Mon, Aug 12, 2019 at 1:48 PM Jean-Baptiste Onofré
> mailto:jeanbaptiste.ono...@gmail.com>>
> wrote:
>
> Hi
>
> Did you try with pax web 4.3.x ?
>
> Regards
> JB
>
> Le lun. 12 août 2019 à 17:33, Nhut Thai Le  <mailto:n...@castortech.com>> a écrit :
>
> Hello,
>
> I am using paxweb 7.2.4 and I have 4 servlet filters,
> annotated with service.ranking from 0 -> 3, according to the
> osgi cmpn 6/7, the filter with higher rank will be executed
> earlier so i expected my http request to pass through the
> filters in the following order 3 -> 2 -> 1 -> 0. However, when
> i trace the code, i see the request come right to my filter
> with rank 0. Is this a bug in paxweb or it is intended to
> behave that way.
>
> Thai
>
>
> -- 
> -- 
> --
> OPS4J - http://www.ops4j.org - ops4j@googlegroups.com
> <mailto:ops4j@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
> <mailto:ops4j+unsubscr...@googlegroups.com>.
> To view this discussion on the web visit
> 
> https://groups.google.com/d/msgid/ops4j/d12dec17-c64b-451d-adc8-5f25162ed20e%40googlegroups.com
> 
> <https://groups.google.com/d/msgid/ops4j/d12dec17-c64b-451d-adc8-5f25162ed20e%40googlegroups.com?utm_medium=email_source=footer>.
>
> -- 
> -- 
> --
> OPS4J - http://www.ops4j.org - ops4j@googlegroups.com
> <mailto:ops4j@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
> <mailto:ops4j+unsubscr...@googlegroups.com>.
> To view this discussion on the web visit
> 
> https://groups.google.com/d/msgid/ops4j/CAB8EV3RQOn6W-cz3gJv59qyvp51jw4E3H0A7VExK1TGwCMF%3DoQ%40mail.gmail.com
> 
> <https://groups.google.com/d/msgid/ops4j/CAB8EV3RQOn6W-cz3gJv59qyvp51jw4E3H0A7VExK1TGwCMF%3DoQ%40mail.gmail.com?utm_medium=email_source=footer>.
>
>
>
> -- 
> Castor Technologies Inc
> 460 rue St-Catherine St Ouest, Suite 613 
> Montréal, Québec H3B-1A7
> (514) 360-7208 o
> (514) 798-2044 f
> n...@castortech.com <mailto:n...@castortech.com>
> www.castortech.com <http://www.castortech.com> 
>
> CONFIDENTIALITY NOTICE: The information contained in this e-mail is
> confidential and may be proprietary information intended only for the
> use of the individual or entity to whom it is addressed. If the reader
> of this message is not the intended recipient, you are hereby notified
> that any viewing, dissemination, distribution, disclosure, copy or use
> of the information contained in this e-mail message is strictly
> prohibited. If you have received and/or are viewing this e-mail in
> error, please immediately notify the sender by reply e-mail, and
> delete it from your system without reading, forwarding, copying or
> saving in any manner. Thank you.
> AVIS DE CONFIDENTIALITE: L’information contenue dans ce message est
> confidentiel, peut être protégé par le secret professionnel et est
> réservé à l'usage exclusif du destinataire. Toute autre personne est
> par les présentes avisée qu'il lui est strictement interdit de
> diffuser, distribuer ou reproduire ce message. Si vous avez reçu cette
> communication par erreur, veuillez la détruire immédiatement et en
> aviser l'expéditeur. Merci.
> -- 
> -- 
> --
> OPS4J - http://www.ops4j.org - ops4j@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
> <mailto:ops4j+unsubscr...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/ops4j/CAJVRZt_1gHhoLXV_cNPyeayoc5mnG3xN%3Dt5N1FwS7Xv4gPAsAA%40mail.gmail.com
> <https://groups.google.com/d/msgid/ops4j/CAJVRZt_1gHhoLXV_cNPy

Re: pax-web-extender-whiteboard Servlet filters ordering

[Jean-Baptiste Onofré]

Hi

Did you try with pax web 4.3.x ?

Regards
JB

Le lun. 12 août 2019 à 17:33, Nhut Thai Le  a écrit :

> Hello,
>
> I am using paxweb 7.2.4 and I have 4 servlet filters, annotated with
> service.ranking from 0 -> 3, according to the osgi cmpn 6/7, the filter
> with higher rank will be executed earlier so i expected my http request to
> pass through the filters in the following order 3 -> 2 -> 1 -> 0. However,
> when i trace the code, i see the request come right to my filter with rank
> 0. Is this a bug in paxweb or it is intended to behave that way.
>
> Thai
>
>
> --
> --
> --
> OPS4J - http://www.ops4j.org - ops4j@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/d12dec17-c64b-451d-adc8-5f25162ed20e%40googlegroups.com
> 
> .
>

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@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/CAB8EV3RQOn6W-cz3gJv59qyvp51jw4E3H0A7VExK1TGwCMF%3DoQ%40mail.gmail.com.

Re: filter.init in pax-web-extender-whiteboard 7.2.4 does not populate FilterConfig object

[Jean-Baptiste Onofré]

Hi,

I'm already working on Pax Web currently (starting R7 support), I will
take a look on this one as well.

Regards
JB

On 31/07/2019 06:44, Grzegorz Grzybek wrote:
> Hello
>
> This could be a bug.
> There are two more issues related to incorrect implementation of R6
> Whiteboard:
>  - https://ops4j1.jira.com/browse/PAXWEB-1123
>  - https://ops4j1.jira.com/browse/PAXWEB-1124
>
> Please create PAXWEB issue for this.
>
> I'm going to switch to PAXWEB soon (after finishing my
> refactoring/polishing/cleaning work at PAXLOGGING) and review R6 (and
> R7) compliance.
>
> regards
> Grzegorz Grzybek
>
> wt., 30 lip 2019 o 22:06 Nhut Thai Le  > napisał(a):
>
> Hello,
>
> I'm using pax-web-extender-whiteboard 7.2.4 and my servlet filter
> is annotated as below:
> @Component(
> service = Filter.class,
> scope = ServiceScope.PROTOTYPE,
> property = {
> "osgi.http.whiteboard.filter.pattern=" + PathConstants.ROOT_PATH 
> + "*",
> "osgi.http.whiteboard.context.select=(osgi.http.whiteboard.context.name
> 
> =WebviewerServletContextHelper)",
> "osgi.http.whiteboard.filter.asyncSupported=true",
> Constants.SERVICE_RANKING + ":Integer=1",
> HttpWhiteboardConstants.HTTP_WHITEBOARD_FILTER_INIT_PARAM_PREFIX +
> "excludedUrls=" + PathConstants.ZKCOMET_PATH
> }
> )
> public final class AuthenticationFilterForWebViewer implements
> Filter {
>
>   public void init(FilterConfig filterConfig) throws
> ServletException {
> String excludePattern =
> filterConfig.getInitParameter("excludedUrls"); //$NON-NLS-1$
>                 .
> }
> }
>
> But in the init method, i got null when using
> filterConfig.getInitParameter("excludedUrls"). But if i use
> 
> filterConfig.getInitParameter(HttpWhiteboardConstants.HTTP_WHITEBOARD_FILTER_INIT_PARAM_PREFIX
> + "excludedUrls") then i got the value. Is this a known bug since
> my understand from http whoteboard R6 is that i can get the value
> from FilterConfig without the filter.init prefix ?
>
> Thai
> -- 
> -- 
> --
> OPS4J - http://www.ops4j.org - ops4j@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/7437580c-041a-4fa8-ba18-39836f4d3c30%40googlegroups.com
> 
> .
>
> -- 
> -- 
> --
> OPS4J - http://www.ops4j.org - ops4j@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/CAAdXmhqZkwQP2byi3Y4HrE8ZYM3AGscQKTE%3D%2BDeoXR2U4pkYQA%40mail.gmail.com
> .

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@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/a61453d9-f1b9-87d7-87a3-75d42b60852c%40gmail.com.

Re: [PAXLOGGING] JDK 11 support

[Jean-Baptiste Onofré]

Sweet !

Thanks !

Regards
JB

Le mer. 24 juil. 2019 à 14:29, Grzegorz Grzybek  a
écrit :

> Hello
>
> Just for your information - I fixed master and paxlogging-1.11.x so all
> integration (native and Karaf) tests work under JDK8 and JDK11.
>
> best regards
> Grzegorz Grzybek
>
> --
> --
> --
> OPS4J - http://www.ops4j.org - ops4j@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/CAAdXmhqVC5xWTqrxzVXjV-Yr6SO5JJBGFZMJioaO3GwmWBjFtQ%40mail.gmail.com
> 
> .
>

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@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/CAB8EV3RSh1fLzF5yYmbtf50XfVQKDQ0y9zG7Kcc2nXKnK2umEg%40mail.gmail.com.

Re: [PAX-LOGGING] Releasing 1.11.0 soon?

[Jean-Baptiste Onofré]

Hey

I'm working on it. I will cut 1.10.2 tomorrow and then I will move forward
on 1.11.0 just after.

Regards
JB

Le mar. 23 juil. 2019 à 20:12, Markus Rathgeb  a
écrit :

> Definitely, I would like to update master to 2.0.0 version with OSGi R7
>> support (PAXLOGGING-255 I started during the week end).Regards
>>
>
> Any news on adding OSGi R7 support?
> I tried to build the current master brunch (without -it* modules) but
> already the API fails to build.
>
> --
> --
> --
> OPS4J - http://www.ops4j.org - ops4j@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/ace5ab84-43d5-4c61-b5d8-65e57860696f%40googlegroups.com
> 
> .
>

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@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/CAB8EV3S__CWNHAF%3DR3tLGzOQiedkg9nqjyFh4mkQk3N%2Bgi__WA%40mail.gmail.com.

Re: Releasing pax-jdbc and pax-jms (problem at Sonatype)

[Jean-Baptiste Onofré]

Thanks

I already sent an email about that. It should be on the way.

I have some pax releases on the way.

Regards
JB

Le jeu. 18 juil. 2019 à 08:19, Grzegorz Grzybek  a
écrit :

> Hello
>
> I created https://issues.sonatype.org/browse/OSSRH-50164 to track the
> problem with the release of pax-transx, pax-jdbc and pax-jms.
>
> regards
> Grzegorz Grzybek
>
> śr., 17 lip 2019 o 10:19 Grzegorz Grzybek 
> napisał(a):
>
>> Hello
>>
>> I've prepared/performed releases of:
>>  - pax-transx 0.4.4
>>  - pax-jms 1.0.5
>>  - pax-jdbc 1.4.0
>>
>> However there's some Sonatype problem. I can't release repos
>> orgops4j-1390, orgops4j-1392 and orgops4j-1393:
>>  - https://oss.sonatype.org/content/repositories/orgops4j-1390
>>  - https://oss.sonatype.org/content/repositories/orgops4j-1392
>>  - https://oss.sonatype.org/content/repositories/orgops4j-1393
>>
>> Releasing fails with "org.sonatype.nexus.proxy.walker.WalkerException:
>> Aborted walking on repository ID='orgops4j-1390' from path='/'.".
>>
>> I'll be trying and keep you informed.
>>
>> regards
>> Grzegorz Grzybek
>>
>> czw., 4 lip 2019 o 14:23 Benjamin Graf 
>> napisał(a):
>>
>>> Hi Grzegorz ,
>>>
>>> enjoy your free time :)
>>>
>>> Regards
>>> Benjamin
>>>
>>> *Gesendet:* Donnerstag, 04. Juli 2019 um 07:34 Uhr
>>> *Von:* "Grzegorz Grzybek" 
>>> *An:* "Benjamin Graf" 
>>> *Betreff:* Re: Releasing pax-jdbc and pax-jms
>>> Hi
>>>
>>> I'm out of office till 15th of July and can't release it now. Please
>>> write to ops4j mailing list :)
>>>
>>> regards
>>> Grzegorz Grzybek
>>>
>>> śr., 3 lip 2019, 20:32 użytkownik Benjamin Graf 
>>> napisał:
>>>
 Hi Grzegorz,

 I just upgraded to jasypt 1.9.3 analogues to Karaf. Could you please
 take a release for pax-jdbc and pax-jms? I'll send a PR for upgrading
 Karaf later on.

 Thanks

 Benjamin


>>>
>>> --
> --
> --
> OPS4J - http://www.ops4j.org - ops4j@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/CAAdXmhp%3D0K6pJKzykfDwkB7%2BBcu9%2B0LKQby6m6rBxVgnqvCzTg%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@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/CAB8EV3Qjo%2BmeMgCc6%2BJGQMbxX1BKdVbite8Kr7poDZ8zqZgUSQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PAX-EXAM] Release 4.13.2?

[Jean-Baptiste Onofré]

Hi

I will. Thanks.

Regards
JB

Le lun. 15 juil. 2019 à 09:56, Arnoud Glimmerveen <
arnoudglimmerv...@gmail.com> a écrit :

> Hi all,
>
> There is a relatively minor change already merged in the 4.x branch that
> enables Pax Exam to 'play nice' with more recent versions of compendium
> services such as LogService or Declarative Services.
> Is one of the Pax-Exam maintainers able and willing to cut a 4.13.2
> release to allow Pax Exam users to benefit from this change?
>
> Best regards,
>
> Arnoud Glimmerveen.
>
> --
> --
> --
> OPS4J - http://www.ops4j.org - ops4j@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/befc0bc0-5009-4b5b-a09b-cf339589%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@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/CAB8EV3SMjdFoM70yNo%3D-CMjoKeafKS%3DOhdymK8w-PC-d8bWmVw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: PAX WEB: Websocket annotations working?

[Jean-Baptiste Onofré]

+1 to create a Jira related to undertow.

Regards
JB

On 02/07/2019 13:51, Stephan Siano wrote:
> Hi,
>
> OK, I have merged my two changes (the general enablement of the
> websocket integration test and the fix to provide websocket support
> for tomcat) into the pax-web-7.2.x, pax-web-7.3.x, and the master branch.
>
> The whiteboard support for websockets still does not work for all
> containers (that's what is PAXWEB-1027 is mainly about) and the
> websocket support via WAB with the undertow container also doesn't
> work (the test for that is ignored for undertow).
>
> Shall I create a JITA task for the undertow container (though I will
> not be able to actually fix the issue there)?
>
> Best regards
> Stephan
>
> Am Montag, 1. Juli 2019 20:33:58 UTC+2 schrieb Jean-Baptiste Onofré:
>
> Thanks Stephan
>
> I will take a look.
>
> Regards
> JB
>
> Le mer. 26 juin 2019 à 14:32, Stephan Siano  > a écrit :
>
> OK, I created a first pull request that only contains the test
> changes. It's for the pax-web-7.2.x branch right now, but it
> should also work in master and pax-web-7.3.x branches (I can
> create pull requests also for these branches, but I would
> prefer to complete the review first). I have set you as a
> reviewer for it. I have not included the Tomcat patch because
> I would prefer to have different commits for the test
> extensions and the coding changes and because while the change
> makes the websocket test run on tomcat it has side effects on
>     other tests (without websockets).
>
> Am Mittwoch, 26. Juni 2019 13:25:01 UTC+2 schrieb
> Jean-Baptiste Onofré:
>
> +1 to reuse PAXWEB-1027, and happy to work with you on
> this one ;)
>
> Regards
> JB
>
> On 26/06/2019 11:33, Stephan Siano wrote:
>> Hi,
>>
>> I did some further work on the topic. Here are my results:
>>
>> 1. I have some changes that are required to get the tests
>> working at all. There is some heavy use of service
>> loaders in the websocket API, which doesn't play too well
>> with OSGi, so some tricks with ThreadContext class
>> loaders are needed.
>> 2. With these changes the tests works with the jetty
>> container (I don't know who parses these Annotations, but
>> obviously something in Jetty does).
>> 3. I did some change to the sample bundle to have it
>> register itself programatically (as an option). With this
>> change, the test will work on Tomcat, so the runtime does
>> work in tomcat but the automatic registration doesn't. In
>> order to make that working, I needed to register an
>> additional ServletContainerInitializer in pax-web-tomcat.
>> 4. I could not get it working with the Undertow container
>> (the registration, the test does work but returns a 404
>> when trying to upgrade the websocket), which means that
>> the endpoint is not registered.
>>
>> I think I should contribute what I have now because it
>> will bring us a working test for websockets on Jetty and
>> at least partially working websocket support on Tomcat.
>> Do I create a new JIRA item for that or do I re-use
>> PAXWEB-1027, which is still open?
>>
>> Does anybody know how the websocket endpoint annotation
>> parsing works in pax-web-jetty (and maybe how we can get
>> the same functionality with Tomcat and Undertow)?
>>
>> Best regards
>> Stephan
>>
>> Am Dienstag, 25. Juni 2019 17:45:03 UTC+2 schrieb Achim
>> Nierbeck:
>>
>> Hi,
>>
>> when I first started to look into websockets, there
>> needed to be extra Bundles installed for Jetty.
>> That's about 4 to 5 years ago :)
>> But I haven't looked into the annotations, as far as
>> I can remember.
>>
>> Regards, Achim
>>
>>
>> Am Di., 25. Juni 2019 um 16:49 Uhr schrieb
>> Jean-Baptiste Onofré :
>>
>> I mean that it's a similar pattern we use for
>> other "connector".
>

Re: PAX WEB: Websocket annotations working?

[Jean-Baptiste Onofré]

Thanks Stephan

I will take a look.

Regards
JB

Le mer. 26 juin 2019 à 14:32, Stephan Siano  a
écrit :

> OK, I created a first pull request that only contains the test changes.
> It's for the pax-web-7.2.x branch right now, but it should also work in
> master and pax-web-7.3.x branches (I can create pull requests also for
> these branches, but I would prefer to complete the review first). I have
> set you as a reviewer for it. I have not included the Tomcat patch because
> I would prefer to have different commits for the test extensions and the
> coding changes and because while the change makes the websocket test run on
> tomcat it has side effects on other tests (without websockets).
>
> Am Mittwoch, 26. Juni 2019 13:25:01 UTC+2 schrieb Jean-Baptiste Onofré:
>>
>> +1 to reuse PAXWEB-1027, and happy to work with you on this one ;)
>>
>> Regards
>> JB
>> On 26/06/2019 11:33, Stephan Siano wrote:
>>
>> Hi,
>>
>> I did some further work on the topic. Here are my results:
>>
>> 1. I have some changes that are required to get the tests working at all.
>> There is some heavy use of service loaders in the websocket API, which
>> doesn't play too well with OSGi, so some tricks with ThreadContext class
>> loaders are needed.
>> 2. With these changes the tests works with the jetty container (I don't
>> know who parses these Annotations, but obviously something in Jetty does).
>> 3. I did some change to the sample bundle to have it register itself
>> programatically (as an option). With this change, the test will work on
>> Tomcat, so the runtime does work in tomcat but the automatic registration
>> doesn't. In order to make that working, I needed to register an additional
>> ServletContainerInitializer in pax-web-tomcat.
>> 4. I could not get it working with the Undertow container (the
>> registration, the test does work but returns a 404 when trying to upgrade
>> the websocket), which means that the endpoint is not registered.
>>
>> I think I should contribute what I have now because it will bring us a
>> working test for websockets on Jetty and at least partially working
>> websocket support on Tomcat. Do I create a new JIRA item for that or do I
>> re-use PAXWEB-1027, which is still open?
>>
>> Does anybody know how the websocket endpoint annotation parsing works in
>> pax-web-jetty (and maybe how we can get the same functionality with Tomcat
>> and Undertow)?
>>
>> Best regards
>> Stephan
>>
>> Am Dienstag, 25. Juni 2019 17:45:03 UTC+2 schrieb Achim Nierbeck:
>>>
>>> Hi,
>>>
>>> when I first started to look into websockets, there needed to be extra
>>> Bundles installed for Jetty.
>>> That's about 4 to 5 years ago :)
>>> But I haven't looked into the annotations, as far as I can remember.
>>>
>>> Regards, Achim
>>>
>>>
>>> Am Di., 25. Juni 2019 um 16:49 Uhr schrieb Jean-Baptiste Onofré <
>>> jeanbapti...@gmail.com>:
>>>
>>>> I mean that it's a similar pattern we use for other "connector".
>>>>
>>>> By the way, did you take a look on the websocket example in Karaf ?
>>>>
>>>> Regards
>>>> JB
>>>> On 25/06/2019 16:22, Stephan Siano wrote:
>>>>
>>>> Hi,
>>>>
>>>> I'm not so sure whether this is easy. I couldn't find anything about
>>>> the web socket annotations in the War extender (plus the annotation scanner
>>>> in the War extender creates some kind of dummy web.xml structure from the
>>>> scanned annotations, but there are no web.xml entries for websockets).
>>>>
>>>> Nevertheless, are you interested in my changes to the tests? I think
>>>> with these changes the tests start again (at least on Tomcat and Undertow),
>>>> but the tests fail. I also tried to register the Websocket programatically
>>>> with a ContextListener but there I couldn't get the ServerContainer from
>>>> the ServletContext (AFAIK this should work via servletContext.
>>>> getAttribute("javax.websocket.server.ServerContainer");). There is
>>>> probably all the websocket infrastructure missing in the Pax-Web classes.
>>>>
>>>> Best regards
>>>> Stephan
>>>>
>>>> On Tuesday, June 25, 2019 at 3:40:22 PM UTC+2, Jean-Baptiste Onofré
>>>> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> AFAIR, it's not yet fully supported.
>>>>>
>>>>

Re: PAX WEB: Websocket annotations working?

[Jean-Baptiste Onofré]

+1 to reuse PAXWEB-1027, and happy to work with you on this one ;)

Regards
JB

On 26/06/2019 11:33, Stephan Siano wrote:
> Hi,
>
> I did some further work on the topic. Here are my results:
>
> 1. I have some changes that are required to get the tests working at
> all. There is some heavy use of service loaders in the websocket API,
> which doesn't play too well with OSGi, so some tricks with
> ThreadContext class loaders are needed.
> 2. With these changes the tests works with the jetty container (I
> don't know who parses these Annotations, but obviously something in
> Jetty does).
> 3. I did some change to the sample bundle to have it register itself
> programatically (as an option). With this change, the test will work
> on Tomcat, so the runtime does work in tomcat but the automatic
> registration doesn't. In order to make that working, I needed to
> register an additional ServletContainerInitializer in pax-web-tomcat.
> 4. I could not get it working with the Undertow container (the
> registration, the test does work but returns a 404 when trying to
> upgrade the websocket), which means that the endpoint is not registered.
>
> I think I should contribute what I have now because it will bring us a
> working test for websockets on Jetty and at least partially working
> websocket support on Tomcat. Do I create a new JIRA item for that or
> do I re-use PAXWEB-1027, which is still open?
>
> Does anybody know how the websocket endpoint annotation parsing works
> in pax-web-jetty (and maybe how we can get the same functionality with
> Tomcat and Undertow)?
>
> Best regards
> Stephan
>
> Am Dienstag, 25. Juni 2019 17:45:03 UTC+2 schrieb Achim Nierbeck:
>
> Hi,
>
> when I first started to look into websockets, there needed to be
> extra Bundles installed for Jetty.
> That's about 4 to 5 years ago :)
> But I haven't looked into the annotations, as far as I can remember.
>
> Regards, Achim
>
>
> Am Di., 25. Juni 2019 um 16:49 Uhr schrieb Jean-Baptiste Onofré
> >:
>
> I mean that it's a similar pattern we use for other "connector".
>
> By the way, did you take a look on the websocket example in
> Karaf ?
>
> Regards
> JB
>
> On 25/06/2019 16:22, Stephan Siano wrote:
>> Hi,
>>
>> I'm not so sure whether this is easy. I couldn't find
>> anything about the web socket annotations in the War extender
>> (plus the annotation scanner in the War extender creates some
>> kind of dummy web.xml structure from the scanned annotations,
>> but there are no web.xml entries for websockets). 
>>
>> Nevertheless, are you interested in my changes to the tests?
>> I think with these changes the tests start again (at least on
>> Tomcat and Undertow), but the tests fail. I also tried to
>> register the Websocket programatically with a ContextListener
>> but there I couldn't get the ServerContainer from the
>> ServletContext (AFAIK this should work
>> via 
>> servletContext.getAttribute("javax.websocket.server.ServerContainer");).
>> There is probably all the websocket infrastructure missing in
>> the Pax-Web classes.
>>
>> Best regards
>> Stephan
>>
>> On Tuesday, June 25, 2019 at 3:40:22 PM UTC+2, Jean-Baptiste
>> Onofré wrote:
>>
>> Hi,
>>
>> AFAIR, it's not yet fully supported.
>>
>> But easy to add/fix, I will tackle that.
>>
>> Regards
>> JB
>>
>> On 25/06/2019 15:25, Stephan Siano wrote:
>>> Hi,
>>>
>>> I have a question concerning web sockets in Pax-Web:
>>>
>>> A colleague of mine is trying to deploy a war on a
>>> Pax-Web container that contains some annotated websocket
>>> server endpoints. This works with other web containers
>>> but not on Pax web (he is getting a 404 response when he
>>> is trying to upgrade the connection).
>>>
>>> I looked into the Pax-Web integration tests and it
>>> turned out that there is an integration test for a very
>>> similar scenario
>>> WebSocketIntegrationTest,testWebSocket() which uses
>>> the websocket-jsr356 sample bundle.
>>>
>>> However, this test was disabled. Even wors

Re: PAX WEB: Websocket annotations working?

[Jean-Baptiste Onofré]

I mean that it's a similar pattern we use for other "connector".

By the way, did you take a look on the websocket example in Karaf ?

Regards
JB

On 25/06/2019 16:22, Stephan Siano wrote:
> Hi,
>
> I'm not so sure whether this is easy. I couldn't find anything about
> the web socket annotations in the War extender (plus the annotation
> scanner in the War extender creates some kind of dummy web.xml
> structure from the scanned annotations, but there are no web.xml
> entries for websockets). 
>
> Nevertheless, are you interested in my changes to the tests? I think
> with these changes the tests start again (at least on Tomcat and
> Undertow), but the tests fail. I also tried to register the Websocket
> programatically with a ContextListener but there I couldn't get the
> ServerContainer from the ServletContext (AFAIK this should work
> via servletContext.getAttribute("javax.websocket.server.ServerContainer");).
> There is probably all the websocket infrastructure missing in the
> Pax-Web classes.
>
> Best regards
> Stephan
>
> On Tuesday, June 25, 2019 at 3:40:22 PM UTC+2, Jean-Baptiste Onofré
> wrote:
>
> Hi,
>
> AFAIR, it's not yet fully supported.
>
> But easy to add/fix, I will tackle that.
>
> Regards
> JB
>
> On 25/06/2019 15:25, Stephan Siano wrote:
>> Hi,
>>
>> I have a question concerning web sockets in Pax-Web:
>>
>> A colleague of mine is trying to deploy a war on a Pax-Web
>> container that contains some annotated websocket server
>> endpoints. This works with other web containers but not on Pax
>> web (he is getting a 404 response when he is trying to upgrade
>> the connection).
>>
>> I looked into the Pax-Web integration tests and it turned out
>> that there is an integration test for a very similar scenario
>> WebSocketIntegrationTest,testWebSocket() which uses
>> the websocket-jsr356 sample bundle.
>>
>> However, this test was disabled. Even worse, it did not work
>> anymore after the test client was moved from the jetty http
>> client to the apache http client (because it currently uses a
>> jetty websocket client which relies on the jetty http client).
>>
>> I changed the test infrastructure to use a jsr356 client (with
>> the container specific implementation) and with some hassle
>> around the class loading because of the pax-exam infrastructure I
>> could likely get this running (at least with tomcat and
>> undertow). However on both containers I get a 404 response code
>> when upgrading the connection (as my colleague got with his
>> websocket endpoint.
>>
>> Did this ever work in Pax-Web? I couldn't find any coding that is
>> parsing for the ServerEndpoint annotation (only Servlet and other
>> stuff). Or is this still unimplemented?
>>
>> Best regards
>> Stephan
>> -- 
>> -- 
>> --
>> 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 op...@googlegroups.com .
>> To view this discussion on the web visit
>> 
>> https://groups.google.com/d/msgid/ops4j/1baaf72c-d85f-423f-a9f3-91974ca72ba4%40googlegroups.com
>> 
>> <https://groups.google.com/d/msgid/ops4j/1baaf72c-d85f-423f-a9f3-91974ca72ba4%40googlegroups.com?utm_medium=email_source=footer>.
>> For more options, visit https://groups.google.com/d/optout
>> <https://groups.google.com/d/optout>.
>
> -- 
> -- 
> --
> OPS4J - http://www.ops4j.org - ops4j@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
> <mailto:ops4j+unsubscr...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/ops4j/919b3351-ea5e-46e7-8e3c-310970cb71b1%40googlegroups.com
> <https://groups.google.com/d/msgid/ops4j/919b3351-ea5e-46e7-8e3c-310970cb71b1%40googlegroups.com?utm_medium=email_source=footer>.
> For more options, visit https://groups.google.com/d/optout.

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@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/0d56e6d8-2bad-fec5-f7e5-ccf6ba007882%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: PAX WEB: Websocket annotations working?

[Jean-Baptiste Onofré]

Hi,

AFAIR, it's not yet fully supported.

But easy to add/fix, I will tackle that.

Regards
JB

On 25/06/2019 15:25, Stephan Siano wrote:
> Hi,
>
> I have a question concerning web sockets in Pax-Web:
>
> A colleague of mine is trying to deploy a war on a Pax-Web container
> that contains some annotated websocket server endpoints. This works
> with other web containers but not on Pax web (he is getting a 404
> response when he is trying to upgrade the connection).
>
> I looked into the Pax-Web integration tests and it turned out that
> there is an integration test for a very similar scenario
> WebSocketIntegrationTest,testWebSocket() which uses
> the websocket-jsr356 sample bundle.
>
> However, this test was disabled. Even worse, it did not work anymore
> after the test client was moved from the jetty http client to the
> apache http client (because it currently uses a jetty websocket client
> which relies on the jetty http client).
>
> I changed the test infrastructure to use a jsr356 client (with the
> container specific implementation) and with some hassle around the
> class loading because of the pax-exam infrastructure I could likely
> get this running (at least with tomcat and undertow). However on both
> containers I get a 404 response code when upgrading the connection (as
> my colleague got with his websocket endpoint.
>
> Did this ever work in Pax-Web? I couldn't find any coding that is
> parsing for the ServerEndpoint annotation (only Servlet and other
> stuff). Or is this still unimplemented?
>
> Best regards
> Stephan
> -- 
> -- 
> --
> OPS4J - http://www.ops4j.org - ops4j@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/1baaf72c-d85f-423f-a9f3-91974ca72ba4%40googlegroups.com
> .
> For more options, visit https://groups.google.com/d/optout.

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@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/69e9cbc4-ed10-4698-6732-adad224f3876%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Pax Exam 4.12.0 release?

[Jean-Baptiste Onofré]

I will dig around that, good point.

Regards
JB

On 20/06/2019 11:15, 'Achim Nierbeck' via OPS4J wrote:
> Hi,
>
> one thing worries me here.
> Obviously Sonatype closed the snapshot repo for ops4j.
> Do we know why this happened?
> Have there been any information about this prior?
>
> thanks, Achim
>
>
> Am Do., 20. Juni 2019 um 10:48 Uhr schrieb Jean-Baptiste Onofré
> mailto:jeanbaptiste.ono...@gmail.com>>:
>
> Hi Jürgen,
>
> I will check the status and eventually cut the release.
>
> I keep you posted.
>
> Regards
> JB
>
> On 20/06/2019 10:48, Jürgen Schmid wrote:
>> Hi laeubi,
>>
>> just wanted to check the current release status.
>> Unfortunately the ops4j Repositories were shut down
>> (https://oss.sonatype.org/content/repositories/ops4j-snapshots)
>> and the Snapshot artifacts including the new RCP Eclipse
>> container feature are no more available. Due to the fact we are
>> using the version in production for our integration tests since
>> more than one year with just some minor issues we had to do a
>> fork and deploy the artifacts into our own nexus.
>>
>> In my opinion, you all did a great job getting pax exam to
>> support rcp testing and it would be sad if the feature will never
>> get released and snapshots are unavailable anymore.
>> I know, there are tests missing, but i think it would be a great
>> benefit releasing that feature. Mark that uncovered features as
>> experimental and ship it. Afterwards we can do pull requests to
>> eliminate issues from the community. 
>>
>> The issue popped up again because the ExamSystem streams the
>> bundle into a temporary folder and never cleans up them. I am
>> working on a patch to recognize the working directory to avoid
>> risking disk space on our build agents.
>>
>>
>>
>> Am Mittwoch, 2. Mai 2018 08:52:26 UTC+2 schrieb laeubi:
>>
>> The problem is that most code uses some kind of external
>> resources
>> (bundle, product/feature files and so on) what makes it hard
>> to write
>> real unit test.
>> So I'm currently evaluate how I can make a good test without
>> rely on
>> external (web) resources to much.
>>
>> Beside that, it would be good if you might can review the
>> documentation
>> at [1], Ive asked a while back in this group but have not
>> goten any
>> feedback on it yet.
>>
>> So if no one vetoes and you think the doku is comprehensive
>> enough for
>> someone to start with (if not feel free to enhance it of
>> course), I
>> think we can merge the PR and make a release.
>>
>>
>> 
>> [1]https://ops4j1.jira.com/wiki/spaces/PAXEXAM4/pages/167018497/Eclipse+PDE-Container
>>
>>
>> Am 01.05.2018 um 23:18 schrieb Jürgen Schmid:
>> > Hi Christoph,
>> >
>> > we are already using 5.0.0-Snapshot from ops4j repository.
>> > We started using the eclipse container with two existing
>> pde product configurations for integration tests and for
>> debugging a pde application within intellij instead of
>> eclipse successfully. (A big step forward!)
>> > Thanks for your contribution, are there some hot spots
>> which needs to be unit tested?
>> >
>> > Best, J
>> >
>> >> On 1. May 2018, at 19:25, 'Christoph Läubrich' via OPS4J
>>  wrote:
>> >>
>> >> Hi Jürgen,
>> >>
>> >> in fact there is only some unit-test missing (i'm
>> currently a little bit short of time), if you like you can
>> test the snapshot-5.0 version or build the corresponding
>> branch of the 4.12 line and do some testing, let me know if
>> you need help or there is anything missing.
>> >>
>> >> Would be cool to here back from you.
>> >>
>> >>> Am 01.05.2018 um 10:42 schrieb Jürgen Schmid:
>> >>> Are there any updates when the eclipse container will be
>> available as a release version?
>> >>> Are there any open tasks?
>> >>> This container would match perfectly in our production
>> environment 

Re: Pax Exam 4.12.0 release?

[Jean-Baptiste Onofré]

Hi Jürgen,

I will check the status and eventually cut the release.

I keep you posted.

Regards
JB

On 20/06/2019 10:48, Jürgen Schmid wrote:
> Hi laeubi,
>
> just wanted to check the current release status.
> Unfortunately the ops4j Repositories were shut down
> (https://oss.sonatype.org/content/repositories/ops4j-snapshots) and
> the Snapshot artifacts including the new RCP Eclipse container feature
> are no more available. Due to the fact we are using the version in
> production for our integration tests since more than one year with
> just some minor issues we had to do a fork and deploy the artifacts
> into our own nexus.
>
> In my opinion, you all did a great job getting pax exam to support rcp
> testing and it would be sad if the feature will never get released and
> snapshots are unavailable anymore.
> I know, there are tests missing, but i think it would be a great
> benefit releasing that feature. Mark that uncovered features as
> experimental and ship it. Afterwards we can do pull requests to
> eliminate issues from the community. 
>
> The issue popped up again because the ExamSystem streams the bundle
> into a temporary folder and never cleans up them. I am working on a
> patch to recognize the working directory to avoid risking disk space
> on our build agents.
>
>
>
> Am Mittwoch, 2. Mai 2018 08:52:26 UTC+2 schrieb laeubi:
>
> The problem is that most code uses some kind of external resources
> (bundle, product/feature files and so on) what makes it hard to write
> real unit test.
> So I'm currently evaluate how I can make a good test without rely on
> external (web) resources to much.
>
> Beside that, it would be good if you might can review the
> documentation
> at [1], Ive asked a while back in this group but have not goten any
> feedback on it yet.
>
> So if no one vetoes and you think the doku is comprehensive enough
> for
> someone to start with (if not feel free to enhance it of course), I
> think we can merge the PR and make a release.
>
>
> 
> [1]https://ops4j1.jira.com/wiki/spaces/PAXEXAM4/pages/167018497/Eclipse+PDE-Container
> 
> 
>
>
> Am 01.05.2018 um 23:18 schrieb Jürgen Schmid:
> > Hi Christoph,
> >
> > we are already using 5.0.0-Snapshot from ops4j repository.
> > We started using the eclipse container with two existing pde
> product configurations for integration tests and for debugging a
> pde application within intellij instead of eclipse successfully.
> (A big step forward!)
> > Thanks for your contribution, are there some hot spots which
> needs to be unit tested?
> >
> > Best, J
> >
> >> On 1. May 2018, at 19:25, 'Christoph Läubrich' via OPS4J
> > wrote:
> >>
> >> Hi Jürgen,
> >>
> >> in fact there is only some unit-test missing (i'm currently a
> little bit short of time), if you like you can test the
> snapshot-5.0 version or build the corresponding branch of the 4.12
> line and do some testing, let me know if you need help or there is
> anything missing.
> >>
> >> Would be cool to here back from you.
> >>
> >>> Am 01.05.2018 um 10:42 schrieb Jürgen Schmid:
> >>> Are there any updates when the eclipse container will be
> available as a release version?
> >>> Are there any open tasks?
> >>> This container would match perfectly in our production
> environment for testing pde.
>
> -- 
> -- 
> --
> OPS4J - http://www.ops4j.org - ops4j@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/c5df3468-6d05-4310-a696-c1ce831cfbbf%40googlegroups.com
> .
> For more options, visit https://groups.google.com/d/optout.

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@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/57098ed5-eb45-97ba-1aaa-8ad7d377243d%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Does pax-jms degrade the overall performance?

[Jean-Baptiste Onofré]

Why don't you set the connection factory directly on the camel-jms URI ?

For instance: 

Regards
JB

On 18/06/2019 16:02, Kushal Gautam wrote:
> well, I am using them as:
>
>  interface="javax.jms.ConnectionFactory"
> filter="(osgi.jndi.service.name=jms/eai.consumer)"
> availability="mandatory" />
>      interface="javax.jms.ConnectionFactory"
> filter="(osgi.jndi.service.name=jms/eai.producer)"
> availability="mandatory" />
>     
>      class="org.apache.camel.component.jms.JmsComponent">
>          ref="jmsConsumerConnectionFactory"/>
>     
>     
>      class="org.apache.camel.component.jms.JmsComponent">
>          ref="jmsProducerConnectionFactory"/>
>     
>
> On Tuesday, June 18, 2019 at 3:59:28 PM UTC+2, Jean-Baptiste Onofré
> wrote:
>
> If you have two ConnectionFactory services, maybe you use only one
> service, that would explain why you only have one connection (with
> one producer and one consumer).
>
> Regards
> JB
>
> On 18/06/2019 15:52, Kushal Gautam wrote:
>> Hi:
>>
>> ok. that's what I thought.
>>
>> So, here is my scenario. I have 4 karaf instances, and each
>> instance has two pax-jms configurations(one for producer and one
>> for consumer). But, in the connections tab, I see just one
>> connection per instance. Is this a normal behavior? Because, I
>> have two pax-jms configs and shldn't they have two connections
>> per instance, in this case? I have to verify this thing with my
>> previous implementation (while deploying broker as an artifact).
>>
>> Regards,
>> Cooshal.
>>
>> On Tuesday, June 18, 2019 at 3:45:41 PM UTC+2, Jean-Baptiste
>> Onofré wrote:
>>
>> Hi,
>>
>> That's the way JMS works.
>>
>> You create a ConnectionFactory. The connection factory
>> provides connections.
>>
>> A connection provides several sessions. A session is single
>> threaded, and "assigned" to an action (consume or produce).
>>
>> So, inside a single connection (for one client), you can have
>> bunch of sessions (some producing, some consuming). In Camel,
>> you can define the number of sessions per connection.
>>
>> For consuming, you can use the receive() method or a
>> MessageListener. The session is also where you define the ACK
>> mode (AUTO, CLIENT, DUPS, TRANSACTED).
>>
>> If you need more details, don't hesitate to ping me directly ;)
>>
>> Regards
>> JB
>>
>> On 18/06/2019 15:31, Kushal Gautam wrote:
>>> Hi again:
>>>
>>> I have a query on this issue.
>>>
>>> From the connections tab in the activemq webconsle, I see
>>> that my hundreds of connections are reduced to very few
>>> connections. That helped me resolve some jms-error issues,
>>> where my packets were being dropped because my broker was
>>> overloaded.
>>>
>>> When I look at the details of the connection, I see multiple
>>> consumer sessions. 
>>>
>>> I am not able to comprehend the working method of this. Are
>>> all these sessions using just one connection??
>>>
>>> Regards,
>>> Cooshal.
>>>
>>>
>>> On Monday, June 17, 2019 at 2:10:28 PM UTC+2, Grzegorz
>>> Grzybek wrote:
>>>
>>> Hello
>>>
>>> Hmm
>>>
>>> You wrote two similar blueprint files containing:
>>>
>>>     >> class="org.apache.activemq.ActiveMQConnectionFactory">
>>>         
>>>         
>>>         
>>>     
>>>
>>> Having etc/org.ops4j.connectionfactory-producer.cfg
>>> doesn't affect your ActiveMQCOnnectionFactory +
>>> org.apache.activemq.pool.PooledConnectionFactory beans...
>>>
>>> With pax-jms, you should expose underlying connection
>>> javax.jms.ConnectionFactory OSGi service
>>> (ActiveMQConnectionFactory) without
>>> org.apache.activ

Re: Does pax-jms degrade the overall performance?

[Jean-Baptiste Onofré]

If you have two ConnectionFactory services, maybe you use only one
service, that would explain why you only have one connection (with one
producer and one consumer).

Regards
JB

On 18/06/2019 15:52, Kushal Gautam wrote:
> Hi:
>
> ok. that's what I thought.
>
> So, here is my scenario. I have 4 karaf instances, and each instance
> has two pax-jms configurations(one for producer and one for consumer).
> But, in the connections tab, I see just one connection per instance.
> Is this a normal behavior? Because, I have two pax-jms configs and
> shldn't they have two connections per instance, in this case? I have
> to verify this thing with my previous implementation (while deploying
> broker as an artifact).
>
> Regards,
> Cooshal.
>
> On Tuesday, June 18, 2019 at 3:45:41 PM UTC+2, Jean-Baptiste Onofré
> wrote:
>
> Hi,
>
> That's the way JMS works.
>
> You create a ConnectionFactory. The connection factory provides
> connections.
>
> A connection provides several sessions. A session is single
> threaded, and "assigned" to an action (consume or produce).
>
> So, inside a single connection (for one client), you can have
> bunch of sessions (some producing, some consuming). In Camel, you
> can define the number of sessions per connection.
>
> For consuming, you can use the receive() method or a
> MessageListener. The session is also where you define the ACK mode
> (AUTO, CLIENT, DUPS, TRANSACTED).
>
> If you need more details, don't hesitate to ping me directly ;)
>
> Regards
> JB
>
> On 18/06/2019 15:31, Kushal Gautam wrote:
>> Hi again:
>>
>> I have a query on this issue.
>>
>> From the connections tab in the activemq webconsle, I see that my
>> hundreds of connections are reduced to very few connections. That
>> helped me resolve some jms-error issues, where my packets were
>> being dropped because my broker was overloaded.
>>
>> When I look at the details of the connection, I see multiple
>> consumer sessions. 
>>
>> I am not able to comprehend the working method of this. Are all
>> these sessions using just one connection??
>>
>> Regards,
>> Cooshal.
>>
>>
>> On Monday, June 17, 2019 at 2:10:28 PM UTC+2, Grzegorz Grzybek
>> wrote:
>>
>> Hello
>>
>> Hmm
>>
>> You wrote two similar blueprint files containing:
>>
>>     > class="org.apache.activemq.ActiveMQConnectionFactory">
>>         
>>         
>>         
>>     
>>
>> Having etc/org.ops4j.connectionfactory-producer.cfg doesn't
>> affect your ActiveMQCOnnectionFactory +
>> org.apache.activemq.pool.PooledConnectionFactory beans...
>>
>> With pax-jms, you should expose underlying connection
>> javax.jms.ConnectionFactory OSGi service
>> (ActiveMQConnectionFactory) without
>> org.apache.activemq.pool.PooledConnectionFactory.
>>
>> Probably with pax-jms you have 3 layers: pooled-jms →
>> PooledConnectionFactory → ActiveMQConnectionFactory.
>>
>> Now you don't need
>> org.apache.activemq.pool.PooledConnectionFactory beans.
>>
>> regards
>> Grzegorz Grzybek
>>
>>
>> pon., 17 cze 2019 o 13:05 Kushal Gautam 
>> napisał(a):
>>
>> Hi:
>>
>> this was my previous config:
>>
>> 
>> > xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0
>> <http://www.osgi.org/xmlns/blueprint/v1.0.0>"
>>            
>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance
>> <http://www.w3.org/2001/XMLSchema-instance>"
>>            
>> 
>> xmlns:cm="http://aries.apache.org/blueprint/xmlns/blueprint-cm/v1.3.0
>> <http://aries.apache.org/blueprint/xmlns/blueprint-cm/v1.3.0>"
>>             xsi:schemaLocation="
>>              
>>   http://www.osgi.org/xmlns/blueprint/v1.0.0
>> <http://www.osgi.org/xmlns/blueprint/v1.0.0> 
>> https://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd
>> <https://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd>
>>              
>>

Re: Does pax-jms degrade the overall performance?

[Jean-Baptiste Onofré]

Hi,

That's the way JMS works.

You create a ConnectionFactory. The connection factory provides connections.

A connection provides several sessions. A session is single threaded,
and "assigned" to an action (consume or produce).

So, inside a single connection (for one client), you can have bunch of
sessions (some producing, some consuming). In Camel, you can define the
number of sessions per connection.

For consuming, you can use the receive() method or a MessageListener.
The session is also where you define the ACK mode (AUTO, CLIENT, DUPS,
TRANSACTED).

If you need more details, don't hesitate to ping me directly ;)

Regards
JB

On 18/06/2019 15:31, Kushal Gautam wrote:
> Hi again:
>
> I have a query on this issue.
>
> From the connections tab in the activemq webconsle, I see that my
> hundreds of connections are reduced to very few connections. That
> helped me resolve some jms-error issues, where my packets were being
> dropped because my broker was overloaded.
>
> When I look at the details of the connection, I see multiple consumer
> sessions. 
>
> I am not able to comprehend the working method of this. Are all these
> sessions using just one connection??
>
> Regards,
> Cooshal.
>
>
> On Monday, June 17, 2019 at 2:10:28 PM UTC+2, Grzegorz Grzybek wrote:
>
> Hello
>
> Hmm
>
> You wrote two similar blueprint files containing:
>
>      class="org.apache.activemq.ActiveMQConnectionFactory">
>         
>         
>         
>     
>
> Having etc/org.ops4j.connectionfactory-producer.cfg doesn't affect
> your ActiveMQCOnnectionFactory +
> org.apache.activemq.pool.PooledConnectionFactory beans...
>
> With pax-jms, you should expose underlying connection
> javax.jms.ConnectionFactory OSGi service
> (ActiveMQConnectionFactory) without
> org.apache.activemq.pool.PooledConnectionFactory.
>
> Probably with pax-jms you have 3 layers: pooled-jms →
> PooledConnectionFactory → ActiveMQConnectionFactory.
>
> Now you don't need
> org.apache.activemq.pool.PooledConnectionFactory beans.
>
> regards
> Grzegorz Grzybek
>
>
> pon., 17 cze 2019 o 13:05 Kushal Gautam  > napisał(a):
>
> Hi:
>
> this was my previous config:
>
> 
> http://www.osgi.org/xmlns/blueprint/v1.0.0
> "
>            
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance
> "
>            
> xmlns:cm="http://aries.apache.org/blueprint/xmlns/blueprint-cm/v1.3.0
> "
>             xsi:schemaLocation="
>                 http://www.osgi.org/xmlns/blueprint/v1.0.0
>  
> https://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd
> 
>              
>   http://aries.apache.org/blueprint/xmlns/blueprint-cm/v1.3.0
>  
> http://aries.apache.org/schemas/blueprint-cm/blueprint-cm-1.3.0.xsd
> 
>             ">
>     
>      update-strategy="reload" >
>         
>              value="tcp://localhost:61616" />
>             
>             
>             
>              value="jms/producer" />
>              value="jms/consumer" />
>         
>       
>
>      class="org.apache.activemq.ActiveMQConnectionFactory">
>         
>         
>         
>     
>
>      class="org.apache.activemq.pool.PooledConnectionFactory">
>          value="${MAX_CONNECTIONS}" />
>          ref="activemqConnectionFactory" />
>     
>     
>      class="org.apache.activemq.pool.PooledConnectionFactory">
>          value="${MAX_CONNECTIONS}" />
>          ref="activemqConnectionFactory" />
>     
>
>      interface="javax.jms.ConnectionFactory">
>         
>             
>             http://osgi.jndi.service.name/>" value="${PRODUCER_JNDI_NAME}" />
>         
>     
>     
>      interface="javax.jms.ConnectionFactory">
>         
>             
>             http://osgi.jndi.service.name/>" value="${CONSUMER_JNDI_NAME}" />
>         
>     
>
> 
>
> I will try to see if I can get the stack trace. This problem
> is currently there in the prod. system. So, I have to check
> that once.
>
> Regards,
> Cooshal.
>
> 

Re: Problems running pax exam with openjdk-11

[Jean-Baptiste Onofré]

You can't use Felix framework 6 as it's OSGi R7.

I will take a look on your branch. I can confirm that karaf itests,
including pax jdbc work in itest.

Regards
JB

Le sam. 15 juin 2019 à 13:52, Steinar Bang  a écrit :

> I've pushed my current jdk11/pax exam experiments to this branch
>  https://github.com/steinarb/scratch/tree/authservice/use-java-11
>
> Freeman Fang's changes are in
>  https://github.com/steinarb/scratch/tree/authservice/fix-jdk-11-pax-exam
>
> One thing I noticed with "mvn dependency:tree" was that the JDBC pax
> karaf feature org.ops4j.pax.jdbc:pax-jdbc-features:xml:features:1.3.1
> pulled in both eclipse equinox and the felix OSGi framework:
> [INFO] +- org.ops4j.pax.jdbc:pax-jdbc-features:xml:features:1.3.1:compile
> [INFO] |  +- org.apache.karaf.features:framework:kar:4.1.1:compile
> [INFO] |  |  +- org.apache.karaf.features:base:jar:4.1.1:runtime
> [INFO] |  |  +- org.apache.karaf:org.apache.karaf.main:jar:4.1.1:runtime
> [INFO] |  |  |  +- org.apache.karaf:org.apache.karaf.util:jar:4.1.1:runtime
> [INFO] |  |  |  |  \-
> org.apache.felix:org.apache.felix.utils:jar:1.9.0:runtime
> [INFO] |  |  |  +- net.java.dev.jna:jna:jar:4.3.0:runtime
> [INFO] |  |  |  \- net.java.dev.jna:jna-platform:jar:4.3.0:runtime
> [INFO] |  |  +-
> org.apache.karaf:org.apache.karaf.exception:jar:4.1.1:runtime
> [INFO] |  |  +-
> org.apache.karaf.jaas:org.apache.karaf.jaas.boot:jar:4.1.1:runtime
> [INFO] |  |  +-
> org.apache.karaf.diagnostic:org.apache.karaf.diagnostic.boot:jar:4.1.1:runtime
> [INFO] |  |  +-
> org.eclipse.tycho:org.eclipse.osgi:jar:3.11.2.v20161107-1947:runtime   <--
> eclipse OSGi
> [INFO] |  |  +-
> org.apache.felix:org.apache.felix.framework:jar:5.6.2:runtime  <--
> felix framework 5.6.2
> [INFO] |  |  +- org.jline:jline:jar:3.2.0:compile
> [INFO] |  |  +- org.ops4j.pax.logging:pax-logging-api:jar:1.9.1:compile
> [INFO] |  |  +- org.ops4j.pax.logging:pax-logging-log4j2:jar:1.9.1:compile
> [INFO] |  |  +-
> org.apache.felix:org.apache.felix.fileinstall:jar:3.5.8:compile
> [INFO] |  |  +-
> org.apache.karaf.features:org.apache.karaf.features.extension:jar:4.1.1:compile
> [INFO] |  |  \-
> org.apache.karaf.features:org.apache.karaf.features.core:jar:4.1.1:compile
>
>
> So I suppressed both OSGi frameworks from the pax-jdbc-features
> dependency and tried first a new eclipse equinox version and then felix
> framework 6.0.3.
>
> Both gave me errors on framework initialization but the errors were
> different.
>
> When using eclipse equinox 3.13.0.v20180226-1711 I got the following
> stack trace (looks like it's getting the OSGi type definitions from a
> different bundle...?):
> Exception in thread "KarafEmbeddedRunner" java.lang.RuntimeException:
> java.lang.reflect.InvocationTargetException
> at
> org.ops4j.pax.exam.karaf.container.internal.runner.KarafEmbeddedRunner$1.run(KarafEmbeddedRunner.java:96)
> Caused by: java.lang.reflect.InvocationTargetException
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.ops4j.pax.exam.karaf.container.internal.runner.KarafEmbeddedRunner$1.run(KarafEmbeddedRunner.java:86)
> Caused by: java.lang.SecurityException: class
> "org.osgi.service.log.LogLevel"'s signer information does not match signer
> information of other classes in the same package
> at
> java.base/java.lang.ClassLoader.checkCerts(ClassLoader.java:1150)
> at
> java.base/java.lang.ClassLoader.preDefineClass(ClassLoader.java:905)
> at
> java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1014)
> at
> java.base/java.security.SecureClassLoader.defineClass(SecureClassLoader.java:174)
> at
> java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:802)
> at
> java.base/jdk.internal.loader.BuiltinClassLoader.findClassOnClassPathOrNull(BuiltinClassLoader.java:700)
> at
> java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader.java:623)
> at
> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:581)
> at
> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
> at
> org.eclipse.osgi.internal.log.EquinoxLogServices.(EquinoxLogServices.java:87)
> at
> org.eclipse.osgi.internal.framework.EquinoxContainer.(EquinoxContainer.java:65)
> at org.eclipse.osgi.launch.Equinox.(Equinox.java:31)
> at
> org.eclipse.osgi.launch.EquinoxFactory.newFramework(EquinoxFactory.java:24)
> at 

Re: [PAX-LOGGING] Releasing 1.11.0 soon?

[Jean-Baptiste Onofré]

Hi,

+1 for 1.11.0, I will test on karaf-4.2.x branch (maybe 1.10.2 to
cherry-pick PAXLOGGING-257 is also an option).

Definitely, I would like to update master to 2.0.0 version with OSGi R7
support (PAXLOGGING-255 I started during the week end).

Regards
JB

On 03/06/2019 12:08, Grzegorz Grzybek wrote:
> Hello
>
> After longer-than-expected work, I think master-improvements branch is
> in good shape now. Jean Babtiste-Onofre fixed PAXLOGGING-257,
> splitting pax-logging-log4j2 into "core" and "extra" (fragment)
> bundles, decreasing the number of cases when pax-logging-log4j2 refreshes.
>
> Total number of 91 integration tests pass (90 more than initially ;)).
>
> What do you think about releasing 1.11.0.CR1? Then we can try
> implementing R7 org.osgi.service.log in 2.0.0.
>
> best regards
> Grzegorz Grzybek
> -- 
> -- 
> --
> OPS4J - http://www.ops4j.org - ops4j@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/CAAdXmhoYWarwC-2RxgqM4YNzoOnMKHPauHGvDZzUh6Lq3YPW3g%40mail.gmail.com
> .
> For more options, visit https://groups.google.com/d/optout.

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@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/f9b7b695-dad3-c85f-0a0c-e76abb4e29d1%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PAX-LOGGING] New integration tests

[Jean-Baptiste Onofré]

Awesome ! Thanks !

I will take a look during the weekend.

Cheers
JB

On 16/05/2019 17:39, Grzegorz Grzybek wrote:
> Hello!
>
> Even more integration tests (including Logback) - I finally created
> the tests I always wanted - that restart/refresh pax-logging bundles
> inside the test itself!
>
> I finished Log4J1 cleanup, the API/Implementation is separated the
> best way I could do it. Everything is described in the readme -
> https://github.com/ops4j/org.ops4j.pax.logging/blob/master-improvements/readme.adoc.
> I even described *all* packages from log4j:log4j and
> log4j:apache-log4j-extras:
> https://github.com/ops4j/org.ops4j.pax.logging/tree/master-improvements#summary-of-package-splitting-for-log4j1
> - where does given package come from, in which bundles it's
> Private-Packaged or Export-Packaged (or both!).
> There's even nice table summarizing log levels/thresholds for
> Syslog/Log4J1/Log4J2/Logback/Slf4J/JUL/OSGi:
> https://github.com/ops4j/org.ops4j.pax.logging/blob/master-improvements/readme.adoc#level-and-threshold
>
> I took care that pax-logging project doesn't include *any* unchanged
> source file from log4j (or extras) - everything is either included and
> changed, or embedded using Private|Export-Package or
> maven-dependency-plugin:unpack (yes - it was needed). Details are
> described in:
>  - osgi.bnd file for pax-logging-service:
> https://github.com/ops4j/org.ops4j.pax.logging/blob/master-improvements/pax-logging-service/osgi.bnd#L22-L45
>  - pom.xml file for pax-logging-service:
> https://github.com/ops4j/org.ops4j.pax.logging/blob/master-improvements/pax-logging-service/pom.xml#L97-L142
>
>  – [INFO] Tests run: 1, Time elapsed: 1.264 s -
> AllLoggingFacadesIntegrationTest
>  – [INFO] Tests run: 1, Time elapsed: 1.254 s - CleanIntegrationTest
>  – [INFO] Tests run: 4, Time elapsed: 1.310 s - DefaultLogIntegrationTest
>  – [INFO] Tests run: 2, Time elapsed: 1.349 s -
> DefaultLogThresholdIntegrationTest
>  – [INFO] Tests run: 2, Time elapsed: 1.343 s -
> DefaultLogToFileSingletonIntegrationTest
>  – [INFO] Tests run: 4, Time elapsed: 1.511 s -
> Log4J1BuiltinAppendersIntegrationTest
>  – [INFO] Tests run: 9, Time elapsed: 1.498 s - Log4J1IntegrationTest
>  – [INFO] Tests run: 1, Time elapsed: 1.436 s -
> Log4J1LocationInfoIntegrationTest
>  – [INFO] Tests run: 1, Time elapsed: 1.403 s - Log4J1MDCIntegrationTest
>  – [INFO] Tests run: 1, Time elapsed: 1.355 s -
> Log4J1OsgiAppendersIntegrationTest
>  – [INFO] Tests run: 1, Time elapsed: 1.360 s -
> Log4J1OsgiErrorHandlersIntegrationTest
>  – [INFO] Tests run: 2, Time elapsed: 1.430 s -
> Log4J1OsgiLayoutsIntegrationTest
>  – [INFO] Tests run: 1, Time elapsed: 1.414 s -
> Log4J1*RefreshPaxLoggingApi*IntegrationTest
>  – [INFO] Tests run: 1, Time elapsed: 1.521 s -
> Log4J1*RestartBothPaxLoggingBundles*IntegrationTest
>  – [INFO] Tests run: 1, Time elapsed: 1.441 s -
> Log4J1*RestartPaxLoggingApi*IntegrationTest
>  – [INFO] Tests run: 1, Time elapsed: 1.529 s -
> Log4J1*RestartPaxLoggingService*IntegrationTest
>  – [INFO] Tests run: 1, Time elapsed: 1.455 s -
> Log4J1UpdateJULLoggerLevelsIntegrationTest
>  – [INFO] Tests run: 1, Time elapsed: 3.390 s -
> Log4J1WithConfigAdminIntegrationTest
>  – [INFO] Tests run: 1, Time elapsed: 1.457 s -
> Log4J1WithDefaultConfigurationAndNoLog4jDebugIntegrationTest
>  – [INFO] Tests run: 1, Time elapsed: 1.363 s -
> Log4J1WithDefaultConfigurationIntegrationTest
>  – [INFO] Tests run: 1, Time elapsed: 1.458 s -
> Log4J1WithoutEventAdminIntegrationTest
>  – [INFO] Tests run: 4, Time elapsed: 1.411 s - LogbackIntegrationTest
>  – [INFO] Tests run: 1, Time elapsed: 3.374 s -
> LogbackWithConfigAdminIntegrationTest
>  – [INFO] Tests run: 1, Time elapsed: 1.423 s -
> LogbackWithDefaultConfigurationAndNoLogbackDebugIntegrationTest
>  – [INFO] Tests run: 1, Time elapsed: 1.406 s -
> LogbackWithDefaultConfigurationIntegrationTest
>  – [INFO] Tests run: 1, Time elapsed: 1.352 s -
> LogbackWithoutEventAdminIntegrationTest
>  – [INFO] Tests run: 1, Time elapsed: 1.356 s -
> SimplestPaxLoggingServiceIntegrationTest
>
> best regards
> Grzegorz Grzybek
>
> wt., 14 maj 2019 o 15:45 Grzegorz Grzybek  > napisał(a):
>
> Hello
>
> I continue my work on making pax-logging more maintainable.
>
> The branch with work-in-progress is here
> 
> - check the long(ish) readme.
>
> Here are integration tests in 1.10.1:
>
> Running org.ops4j.pax.logging.it.appender.CustomAppenderTest
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
> 1.28 sec - in org.ops4j.pax.logging.it.appender.CustomAppenderTest
>
> Results :
>
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
>
> And here are tests I did so far:
>
> [INFO] Running
> org.ops4j.pax.logging.it.AllLoggingFacadesIntegrationTest
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time
> 

Re: bundle not resolved due to pax-jdbc while provisioning in karaf

[Jean-Baptiste Onofré]

See the Import-Service, that's the requirement. You have to provide a
bundle/feature with the capability.

I will provide an example to you.

Regards
JB

On 10/05/2019 09:16, Kushal Gautam wrote:
> Hi JB:
>
> here is my MANIFEST.MF file:
>
> Manifest-Version: 1.0
> Bnd-LastModified: 1557471966933
> Build-Jdk: 1.8.0_65
> Built-By: Kushal
> Bundle-Blueprint: OSGI-INF/blueprint/blueprint.xml
> Bundle-ManifestVersion: 2
> Bundle-Name: Karaf Plugin Demo
> Bundle-SymbolicName: org.apache.karaf.plugin-demo
> Bundle-Version: 1.0.0
> Created-By: Apache Maven Bundle Plugin
> Export-Package: infrastructure;uses:="org.apache.karaf.cellar.core,org
>  .osgi.service.cm
> <http://osgi.service.cm>,services";version="1.0.0",services;version="1.0.0",u
>  tils;version="1.0.0"
> Import-Package: javax.sql,org.apache.karaf.cellar.core;version="[4.1,5
>  )",org.osgi.framework;version="[1.7,2)",org.osgi.service.blueprint;ve
>  rsion="[1.0.0,2.0.0)",org.osgi.service.cm
> <http://org.osgi.service.cm>;version="[1.5,2)",services
> Import-Service: javax.sql.DataSource;multiple:=false;filter=(osgi.jndi
>  .service.name
> <http://service.name>=dw-datasource),org.apache.karaf.cellar.core.ClusterM
>  anager;multiple:=false,org.osgi.service.cm.ConfigurationAdmin;multipl
>  e:=false
> Require-Capability: osgi.ee <http://osgi.ee>;filter:="(&(osgi.ee
> <http://osgi.ee>=JavaSE)(version=1.6))"
> Tool: Bnd-4.2.0.201903051501
>
> Regards,
> Kushal.
>
> On Fri, May 10, 2019 at 7:28 AM Jean-Baptiste Onofré
> mailto:jeanbaptiste.ono...@gmail.com>>
> wrote:
>
> Hi,
>
> I guess your bundle contains Requirement in META-INF/MANIFEST. Did
> you check the feature providing the DataSource provides the
> Capability ?
>
> Regards
> JB
>
> On 09/05/2019 11:23, Kushal Gautam wrote:
>> yes, that's very confusing.
>>
>> As I said earlier, that I verified the existence of datasource
>> before installing the feature. Could it be because of the pooled
>> connection?
>>
>> Regards,
>> Kushal.
>>
>> On Thursday, May 9, 2019 at 11:06:50 AM UTC+2, Jean-Baptiste
>> Onofré wrote:
>>
>> Hi,
>>
>> Ok, that's weird, it means that your bundle is starting
>> before the DataSource service is available for sure.
>>
>> Regards
>> JB
>>
>> On 09/05/2019 10:56, Kushal Gautam wrote:
>>> Hi JB:
>>>
>>> just to confirm that availability="optional" in the service
>>> reference did the trick. Also, one of the crazy issues was
>>> the caching, which loaded the same old jar again and again
>>> (even though I had refreshed and replaced the jar). I did
>>> try with feature:repo-refresh and tried reboot as well. But,
>>> the issue with caching persisted. I had to try in a whole
>>> new container.
>>>
>>> Thank you for your help. Finally, I have a workaround to
>>> this issue.
>>>
>>> Regards,
>>> Kushal.
>>>
>>> On Thu, May 9, 2019 at 8:07 AM Jean-Baptiste Onofré
>>>  wrote:
>>>
>>> By the way, did you check you don't have a race
>>> condition like you start the bundle (installing the
>>> feature) whereas the datasource service is not yet there ?
>>>
>>> As workaround you can define the service ref as
>>> optional, it will reload once the service is there.
>>>
>>> Regards
>>> JB
>>>
>>> On 08/05/2019 23:00, Kushal Gautam wrote:
>>>> Hi:
>>>>
>>>> I have a bundle that depends on two different data
>>>> sources; and broker as well. 
>>>>
>>>> The bundle starts properly if I copy the osgi bundle
>>>> into deploy folder or install it using bundle:install
>>>> . Installing the bundle this way works
>>>> perfectly fine without any glitch.
>>>>
>>>> Instead, I tried to install it as a feature as:
>>>>
>>>> |
>>>> >>> MBEAN"version="1.0.0">
>>>>         file:D:/temp/stats-mbea

Re: Pax-exam with java11+ for karaf4

[Jean-Baptiste Onofré]

Hi Gareth,

I didn't start yet. Now that Karaf 4.2.5 has been released, I will work on
this one.

Regards
JB

On Mon, Apr 29, 2019 at 7:08 PM Gareth Healy  wrote:

> Hi Jean-Baptiste,
>
> Were you able to have a look? Need any more info from me?
>
> On Sunday, 21 April 2019 12:34:11 UTC+1, Jean-Baptiste Onofré wrote:
>>
>> I will take a look but probably the launcher to update.
>>
>> Le dim. 21 avr. 2019 à 11:39, Gareth Healy  a
>> écrit :
>>
>>> I am trying to get pax-exam testing karaf4 on java11 but looking at the
>>> logs, doesn't really tell me anything. It just seems "stuck".
>>>
>>> JUnit logs:
>>> https://gist.github.com/garethahealy/d4673886b37503352ce7660d46b66872
>>> Karaf logs:
>>> https://gist.github.com/garethahealy/73b551def070d1a07c035449f456977f
>>> Travis job showing full build:https://travis-ci.org/DozerMapper/dozer
>>> Code:
>>> https://github.com/DozerMapper/dozer/tree/master/tests/dozer-osgi-tests
>>>
>>> All tests work fine on jave 8, 9 and 10.
>>>
>>> Any ideas?
>>>
>>> --
>>> --
>>> --
>>> 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 op...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> --
> --
> --
> OPS4J - http://www.ops4j.org - ops4j@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.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@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.
For more options, visit https://groups.google.com/d/optout.

Re: Pax-exam with java11+ for karaf4

[Jean-Baptiste Onofré]

I will take a look but probably the launcher to update.

Le dim. 21 avr. 2019 à 11:39, Gareth Healy  a
écrit :

> I am trying to get pax-exam testing karaf4 on java11 but looking at the
> logs, doesn't really tell me anything. It just seems "stuck".
>
> JUnit logs:
> https://gist.github.com/garethahealy/d4673886b37503352ce7660d46b66872
> Karaf logs:
> https://gist.github.com/garethahealy/73b551def070d1a07c035449f456977f
> Travis job showing full build:https://travis-ci.org/DozerMapper/dozer
> Code:
> https://github.com/DozerMapper/dozer/tree/master/tests/dozer-osgi-tests
>
> All tests work fine on jave 8, 9 and 10.
>
> Any ideas?
>
> --
> --
> --
> OPS4J - http://www.ops4j.org - ops4j@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.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@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.
For more options, visit https://groups.google.com/d/optout.