Re: [PROPOSAL] Release Pax Exam 5.0.0

[Jérémie Brébec]

Hello,

I dig up this old topic, but is pax exam still maintained ? I'm hopping to 
see a pax-exam with supports for junit5 ^^

Regards,

Jérémie

Le lundi 22 février 2021 à 09:16:28 UTC+1, gr.gr...@gmail.com a écrit :

> Hello
>
> I don't work on Pax Exam and sorry for hijacking the email - but are there 
> any objections whether I could migrate PAXEXAM project from Ops4J Jira to 
> Github issues?
> Note that I've already migrated:
>  - PAXJDBC
>  - PAXJMS
>  - PAXTRANSX
>  - PAXLOGGING
>  - PAXTIPI
>  - TOOLS
>
> regards
> Grzegorz Grzybek
>
> pon., 22 lut 2021 o 08:42 Arnoud Glimmerveen  
> napisał(a):
>
>> Hi JB,
>>
>> Could you share what the status is of this release of Pax Exam?
>>
>> Best regards,
>>
>> Arnoud.
>>
>> On Thursday, November 5, 2020 at 2:21:36 PM UTC+1 Arnoud Glimmerveen 
>> wrote:
>>
>>> Hi JB,
>>>
>>> How is the effort on getting a 5.0.0 release progressing? Are there any 
>>> hurdles to clear where others in the community perhaps could assist?
>>>
>>> Best regards,
>>>
>>> Arnoud
>>>
>>> On Tuesday, September 29, 2020 at 10:21:32 AM UTC+2 
>>> jeanbapti...@gmail.com wrote:
>>>
 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 <
 arnoudgl...@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 - 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/01f9720a-e93e-43db-820d-fe0ee251ab10n%40googlegroups.com
>  
> 
> .
>
 -- 
>> -- 
>> --
>> 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/8ad40cec-bfeb-4262-8f75-52b4df55a431n%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/529c6372-0e83-46d4-964b-b675967fa0f5n%40googlegroups.com.

Re: Jetty and HTTP2

[Jérémie Brébec]

Thanks !

Le lundi 17 janvier 2022 à 09:22:04 UTC+1, gr.gr...@gmail.com a écrit :

> Hello
>
> In theory - yes, it does support HTTP/2.
> In practice - also yes, because I see pax-web-jetty before version 8 
> indeed tries to instantiate 
> `org.eclipse.jetty.http2.server.HTTP2ServerConnectionFactory` and use it as 
> an argument to 
> `org.eclipse.jetty.server.AbstractConnector#addConnectionFactory()`.
> But in real practice - there are no integration tests in Pax Web that 
> ensure this is correct handling and what's more important (at least for me) 
> - that it's consistent across pax-web-jetty, pax-web-tomcat and 
> pax-web-undertow.
>
> In Pax Web 8 I'm going to add real integration tests (including for 
> example HTTP/2 over clear text), but it's not ready yet.
>
> regards
> Grzegorz Grzybek
>
> sob., 15 sty 2022 o 14:56 Jérémie Brébec  
> napisał(a):
>
>> Hello,
>>
>> Does pax-web (v7/Karaf 4.3) supports jetty and http/2 ?
>> I can't find a documentation on how to enable http2 with Karaf
>>
>> Regards,
>> Jérémie
>>
>> -- 
>> -- 
>> --
>> 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/261ee83f-08ba-4c05-b0b9-b88cdae34899n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/ops4j/261ee83f-08ba-4c05-b0b9-b88cdae34899n%40googlegroups.com?utm_medium=email&utm_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/40e783cb-0127-45e8-913a-6adc81efbd09n%40googlegroups.com.

Jetty and HTTP2

[Jérémie Brébec]

Hello,

Does pax-web (v7/Karaf 4.3) supports jetty and http/2 ?
I can't find a documentation on how to enable http2 with Karaf

Regards,
Jérémie

-- 
-- 
--
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/261ee83f-08ba-4c05-b0b9-b88cdae34899n%40googlegroups.com.

Re: Pax Logging 1.11 and System.out by the DefaultServiceLogger

[Jérémie Brébec]

I have created PAXLOGGING-274 
<https://ops4j1.jira.com/browse/PAXLOGGING-274>

Thanks !

Le vendredi 4 octobre 2019 16:20:08 UTC+2, Jérémie Brébec a écrit :
>
> Hello,
>
> I am upgrading to Karaf 4.2.7 with Pax Logging 1.11
>
> Everytime Karaf is started, I see this line in the console :
>
> org.ops4j.pax.url.wrap [org.ops4j.pax.url.commons.handler.HandlerActivator] 
> DEBUG : Handler for protocols [wrap] started
>
>
> I use a custom distribution with the static framework : the 
> startup.properties file is generated, and the start-level of pax.url.wrap 
> is lower than the start level of pax-logging-api
> As it starts before the pax-logging-api, it gets a "fallback logger" which 
> log with System.out.println()
>
> 1/ I can't change the threshold of this logger, because the property 
> "org.ops4j.pax.logging.DefaultServiceLog.level" is read only when the 
> pax-loggin-api is started
> 2/ I can't use a "FileServiceLogger" as a fallback because the 
> pax-url-wrap bundle is not starting (the logger is loaded in the activator 
> class, before the activator is called)
> 3/ I can use a BufferingLog. However, this function doesn't seem to be 
> fully implemented : the queue in this logger is never flushed/cleared.
>
> Is there a solution to my problem without patching the startup.properties 
> or the karaf features ?
>
> Regards,
> Jérémie
>
>

-- 
-- 
--
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/6cd16d32-880a-4ff2-acef-7b0061bc91f4%40googlegroups.com.

Re: Pax Logging 1.11 and System.out by the DefaultServiceLogger

[Jérémie Brébec]

Yes, however this property is only read in the pax-logging-api Activator 
(line 64) : If a bundle starts before the pax-logging-api, then the applied 
threshold will be "debug".


Le vendredi 4 octobre 2019 16:44:01 UTC+2, Grzegorz Grzybek a écrit :
>
> Hello Jérémie
>
> Karaf "official" distro simply has this in etc/system.properties:
>
> # Log level when the pax-logging service is not available
> # This level will only be used while the pax-logging service bundle
> # is not fully available.
> # To change log levels, please refer to the org.ops4j.pax.logging.cfg file
> # instead.
> org.ops4j.pax.logging.DefaultServiceLog.level = ERROR
>
> without it, Karaf would start with this message as well.
>
> And yes - pax-logging 1.11.x has lots of changes, adjustments and 
> polishing related also to "default" logger which I wanted to be operational 
> ASAP - even before pax-logging-api bundles gets ACTIVE.
>
> See new configuration page: 
> https://ops4j1.jira.com/wiki/spaces/paxlogging/pages/499351646/Documentation
>
> Details about "backendless" scenario is here: 
> https://ops4j1.jira.com/wiki/spaces/paxlogging/pages/499580944/Using+Pax+Logging+API+without+backend
>
> Log4j2 backend configuration: 
> https://ops4j1.jira.com/wiki/spaces/paxlogging/pages/499613746/Configuring+Log4J2
>
> A bit of background: 
> https://ops4j1.jira.com/wiki/spaces/paxlogging/pages/499384369/Concepts
>
> regards
> Grzegorz Grzybek
>
> pt., 4 paź 2019 o 16:20 Jérémie Brébec > 
> napisał(a):
>
>> Hello,
>>
>> I am upgrading to Karaf 4.2.7 with Pax Logging 1.11
>>
>> Everytime Karaf is started, I see this line in the console :
>>
>> org.ops4j.pax.url.wrap [org.ops4j.pax.url.commons.handler.HandlerActivator] 
>> DEBUG : Handler for protocols [wrap] started
>>
>>
>> I use a custom distribution with the static framework : the 
>> startup.properties file is generated, and the start-level of pax.url.wrap 
>> is lower than the start level of pax-logging-api
>> As it starts before the pax-logging-api, it gets a "fallback logger" 
>> which log with System.out.println()
>>
>> 1/ I can't change the threshold of this logger, because the property 
>> "org.ops4j.pax.logging.DefaultServiceLog.level" is read only when the 
>> pax-loggin-api is started
>> 2/ I can't use a "FileServiceLogger" as a fallback because the 
>> pax-url-wrap bundle is not starting (the logger is loaded in the activator 
>> class, before the activator is called)
>> 3/ I can use a BufferingLog. However, this function doesn't seem to be 
>> fully implemented : the queue in this logger is never flushed/cleared.
>>
>> Is there a solution to my problem without patching the startup.properties 
>> or the karaf features ?
>>
>> Regards,
>> Jérémie
>>
>> -- 
>> -- 
>> --
>> 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/3aa380f4-a831-4106-912e-f747bf29ef79%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/ops4j/3aa380f4-a831-4106-912e-f747bf29ef79%40googlegroups.com?utm_medium=email&utm_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/5625e728-4ab0-4596-9e08-77f5ecaf0eaa%40googlegroups.com.

Pax Logging 1.11 and System.out by the DefaultServiceLogger

[Jérémie Brébec]

Hello,

I am upgrading to Karaf 4.2.7 with Pax Logging 1.11

Everytime Karaf is started, I see this line in the console :

org.ops4j.pax.url.wrap [org.ops4j.pax.url.commons.handler.HandlerActivator] 
DEBUG : Handler for protocols [wrap] started


I use a custom distribution with the static framework : the 
startup.properties file is generated, and the start-level of pax.url.wrap 
is lower than the start level of pax-logging-api
As it starts before the pax-logging-api, it gets a "fallback logger" which 
log with System.out.println()

1/ I can't change the threshold of this logger, because the property 
"org.ops4j.pax.logging.DefaultServiceLog.level" is read only when the 
pax-loggin-api is started
2/ I can't use a "FileServiceLogger" as a fallback because the pax-url-wrap 
bundle is not starting (the logger is loaded in the activator class, before 
the activator is called)
3/ I can use a BufferingLog. However, this function doesn't seem to be 
fully implemented : the queue in this logger is never flushed/cleared.

Is there a solution to my problem without patching the startup.properties 
or the karaf features ?

Regards,
Jérémie

-- 
-- 
--
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/3aa380f4-a831-4106-912e-f747bf29ef79%40googlegroups.com.

Re: PaxWeb: WebSocketTracker and Object

[Jérémie Brébec]

Thanks !

By the way, the features processors you introduced in Karaf 4.2 is helping 
me a lot with this kind of patch :-)

Le jeudi 17 janvier 2019 14:32:12 UTC+1, Grzegorz Grzybek a écrit :
>
> Hi
>
> I reviewed PAXWEB-1119 and understood it. CMPN R7 Http Whiteboard spec 
> (chapter 140) doesn't say anything about websockets. So I'm fine with 
> forcing users to register WebSockets with "(websocket=true)" flag. If 
> websocket endpoint can be (thank you very much JavaEE! - or maybe OSGi 
> should add objectClass equivalent for annotations?) java.lang.Object, then 
> websocket=true is acceptable.
>
> I set fixVersion to 7.2.7 and 8.0.0.
>
> best regards
> Grzegorz Grzybek
>
> czw., 17 sty 2019 o 13:53 Grzegorz Grzybek  > napisał(a):
>
>> Hello
>>
>> Achim - any reason why this was not merged? Something's missing?
>>
>> regards
>> Grzegorz Grzybek
>>
>> czw., 17 sty 2019 o 13:36 Jérémie Brébec > > napisał(a):
>>
>>> I reopen (again) an old thread : Is there a plan to merge PAXWEB-1119 
>>> into master/7.2.x ? I have to cherry pick the patch/rebuild paxweb on every 
>>> upgrade.
>>>
>>>
>>> Le mardi 8 août 2017 08:24:24 UTC+2, Achim Nierbeck a écrit :
>>>>
>>>> Hi, 
>>>>
>>>> yes you're right using a non official osgi flag isn't good. 
>>>> Will create another one, as we've done in the past for the Whiteboard 
>>>> extension, when it wasn't in the spec. 
>>>>
>>>> regards, Achim 
>>>>
>>>>
>>>> 2017-08-07 20:26 GMT+02:00 Jérémie Brébec :
>>>>
>>>>> Thanks, this tracker breaks the laziness of most of my whiteboard 
>>>>> extenders (jaxrs, spring mvc @controller/@configuration, etc..). I didn't 
>>>>> find however any mention on WebSocket in the future R7 spec, neither on 
>>>>> the 
>>>>> felix/equinox implementation. 
>>>>>
>>>>> The only reference I found was in an implementation on Liferay, which 
>>>>> use properties under "org.osgi.http.websocket.endpoint.*" (imho, not a 
>>>>> good 
>>>>> choice to use "org.osgi" prefixes..)
>>>>>
>>>>>
>>>>>
>>>>> Le lundi 7 août 2017 18:25:25 UTC+2, Achim Nierbeck a écrit :
>>>>>>
>>>>>> BTW, just created the following improvement: 
>>>>>> https://ops4j1.jira.com/browse/PAXWEB-1119
>>>>>>
>>>>>> 2017-08-07 18:22 GMT+02:00 Achim Nierbeck :
>>>>>>
>>>>>>> Hi, 
>>>>>>>
>>>>>>> the problem I see with this is, if one registers a WebSocket as 
>>>>>>> Service, it usually doesn't need to be of a special Interface ... 
>>>>>>> I can see that a property might help. Will think about this a bit 
>>>>>>> more. 
>>>>>>>
>>>>>>> Right now you can't disable it.
>>>>>>>
>>>>>>> regards, Achim 
>>>>>>>
>>>>>>>
>>>>>>> 2017-08-07 14:00 GMT+02:00 Jérémie Brébec :
>>>>>>>
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> In pax web 6, a WebSocketTracker is created. This tracker "track" 
>>>>>>>> with a ServiceTracker every registration of services with the class 
>>>>>>>> "Object". This tracker resolves every service through 
>>>>>>>> bundleContext.getService().
>>>>>>>> As a consequence, every component registered with "Object" are 
>>>>>>>> resolved, breaking the Declaratives Services lazy properties.
>>>>>>>>
>>>>>>>> Is there a way to deactivate this tracker, or at least make it 
>>>>>>>> activate only with the presence of a property ? This tracker is not 
>>>>>>>> precise 
>>>>>>>> enough, imho, to systematically calls getService on every references.
>>>>>>>>
>>>>>>>> Regard,
>>>>>>>> Jérémie
>>>>>>>>
>>>>>>>> -- 
>>>>>>>> -- 
>>>>>>>> --
>>>>>>>> OPS4J - http://www.

Re: PaxWeb: WebSocketTracker and Object

[Jérémie Brébec]

I reopen (again) an old thread : Is there a plan to merge PAXWEB-1119 into 
master/7.2.x ? I have to cherry pick the patch/rebuild paxweb on every 
upgrade.


Le mardi 8 août 2017 08:24:24 UTC+2, Achim Nierbeck a écrit :
>
> Hi, 
>
> yes you're right using a non official osgi flag isn't good. 
> Will create another one, as we've done in the past for the Whiteboard 
> extension, when it wasn't in the spec. 
>
> regards, Achim 
>
>
> 2017-08-07 20:26 GMT+02:00 Jérémie Brébec  >:
>
>> Thanks, this tracker breaks the laziness of most of my whiteboard 
>> extenders (jaxrs, spring mvc @controller/@configuration, etc..). I didn't 
>> find however any mention on WebSocket in the future R7 spec, neither on the 
>> felix/equinox implementation. 
>>
>> The only reference I found was in an implementation on Liferay, which use 
>> properties under "org.osgi.http.websocket.endpoint.*" (imho, not a good 
>> choice to use "org.osgi" prefixes..)
>>
>>
>>
>> Le lundi 7 août 2017 18:25:25 UTC+2, Achim Nierbeck a écrit :
>>>
>>> BTW, just created the following improvement: 
>>> https://ops4j1.jira.com/browse/PAXWEB-1119
>>>
>>> 2017-08-07 18:22 GMT+02:00 Achim Nierbeck :
>>>
>>>> Hi, 
>>>>
>>>> the problem I see with this is, if one registers a WebSocket as 
>>>> Service, it usually doesn't need to be of a special Interface ... 
>>>> I can see that a property might help. Will think about this a bit more. 
>>>>
>>>> Right now you can't disable it.
>>>>
>>>> regards, Achim 
>>>>
>>>>
>>>> 2017-08-07 14:00 GMT+02:00 Jérémie Brébec :
>>>>
>>>>> Hello,
>>>>>
>>>>> In pax web 6, a WebSocketTracker is created. This tracker "track" with 
>>>>> a ServiceTracker every registration of services with the class "Object". 
>>>>> This tracker resolves every service through bundleContext.getService().
>>>>> As a consequence, every component registered with "Object" are 
>>>>> resolved, breaking the Declaratives Services lazy properties.
>>>>>
>>>>> Is there a way to deactivate this tracker, or at least make it 
>>>>> activate only with the presence of a property ? This tracker is not 
>>>>> precise 
>>>>> enough, imho, to systematically calls getService on every references.
>>>>>
>>>>> Regard,
>>>>> Jérémie
>>>>>
>>>>> -- 
>>>>> -- 
>>>>> --
>>>>> 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.
>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>
>>>>
>>>>
>>>>
>>>> -- 
>>>>
>>>> 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>
>>>>
>>>> Software Architect / Project Manager / Scrum Master 
>>>>
>>>>
>>>
>>>
>>> -- 
>>>
>>> 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>
>>>
>>> Software Architect / Project Manager / Scrum Master 
>>>
>>> -- 
>> -- 
>> --
>> 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 .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
>
> 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>
>
> Software Architect / Project Manager / Scrum Master 
>
>

-- 
-- 
--
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: PaxWeb: Jetty and GZipHandler

[Jérémie Brébec]

I have created this ticket: https://ops4j1.jira.com/browse/PAXWEB-1189

Thanks !

Le mercredi 16 janvier 2019 15:55:56 UTC+1, Jean-Baptiste Onofré a écrit :
>
> As it's a jetty handler, I think it's cleaner to keep it in jetty.xml.
>
> @Jérémie: can you please create the Jira ? I will fix that quickly.
>
> Regards
>
> JB
> On 16/01/2019 15:52, Grzegorz Grzybek wrote:
>
> Hmm, it deserves PAXWEB jira issue.
>
> We should either allow it to be configured in etc/jetty.xml or just enable 
> (true/false) it in etc/org.ops4j.pax.web.cfg.
> But I don't think I'll fix it today ;)
>
> regards
> Grzegorz Grzybek
>
> śr., 16 sty 2019 o 15:46 Jérémie Brébec  > napisał(a):
>
>> I have attached the patch I use. With this patch, I can use the 
>> GzipHandler with this configuration : 
>>
>> 
>>  
>>
>>  
>>> "org.eclipse.jetty.server.handler.gzip.GzipHandler">
>>  
>>
>>  
>>
>>  
>>
>>
>> Le mercredi 16 janvier 2019 15:39:49 UTC+1, Jérémie Brébec a écrit : 
>>>
>>> I don't know if it's an issue in paxweb or just a configuration 
>>> difficult to write. 
>>>
>>> I want to activate a GzipHandler in order to gzip contents served by my 
>>> servlets. The old Jetty GzipFilter is deprecated and do nothing.
>>>
>>> This Handler is a HandlerWrapper, it hooks the handler chain in order to 
>>> provider a wrapped response (which do the gzip encoding). I am not able to 
>>> configure such handlers in the jetty.xml (PaxWeb-Jetty assumes at several 
>>> location that the first handler is the JettyServerHandlerCollection and I 
>>> can't replace it with the GzipHandler or any other HandlerWrapper without 
>>> issues/exceptions).
>>>
>>> I have a working solution, but it necessites some change in the 
>>> codebase. However, I suppose I am not the only one who want to use gzip and 
>>> paxweb, so I don't know if I am missing something :-)
>>>
>>> Le mercredi 16 janvier 2019 14:52:56 UTC+1, Grzegorz Grzybek a écrit : 
>>>>
>>>> Hello
>>>>
>>>> There are 40 unresolved issues in 
>>>> https://ops4j1.jira.com/projects/PAXWEB/summary/statistics - I didn't 
>>>> see any about gzip.
>>>> Could you refresh my memory? :)
>>>>
>>>> regards
>>>> Grzegorz Grzybek
>>>>
>>>> śr., 16 sty 2019 o 14:31 Jean-Baptiste Onofré  
>>>> napisał(a):
>>>>
>>>>> Not with recent 7.2.x version.
>>>>>
>>>>> I think it deserves a unit test ;)
>>>>>
>>>>> Regards
>>>>> JB
>>>>> On 16/01/2019 14:20, Jérémie Brébec wrote:
>>>>>
>>>>> Hello, 
>>>>>
>>>>> I reopen this old thread, but has anyone a working example of a 
>>>>> GzipHandler with PaxWeb (7.2.5) ?
>>>>>
>>>>> Thanks !
>>>>>
>>>>> Le mercredi 30 août 2017 06:20:23 UTC+2, Achim Nierbeck a écrit : 
>>>>>>
>>>>>> Hi,  
>>>>>>
>>>>>> if this is an issue for you please file a bug in our Jira. 
>>>>>>
>>>>>> Thanks, Achim 
>>>>>>
>>>>>> 2017-08-10 7:44 GMT+02:00 Eric Lessard :
>>>>>>
>>>>>>> Any update on this or work around available? We're running into a 
>>>>>>> similar problem and are looking at options to compress our static 
>>>>>>> content.
>>>>>>>
>>>>>>> Thanks!
>>>>>>>
>>>>>>> --
>>>>>>> --
>>>>>>> --
>>>>>>> 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.
>>>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> -- 
>>>>>>
>>>&g

Re: PaxWeb: Jetty and GZipHandler

[Jérémie Brébec]

I have attached the patch I use. With this patch, I can use the GzipHandler 
with this configuration :


 

 
   
 
   
 
   
 


Le mercredi 16 janvier 2019 15:39:49 UTC+1, Jérémie Brébec a écrit :
>
> I don't know if it's an issue in paxweb or just a configuration difficult 
> to write.
>
> I want to activate a GzipHandler in order to gzip contents served by my 
> servlets. The old Jetty GzipFilter is deprecated and do nothing.
>
> This Handler is a HandlerWrapper, it hooks the handler chain in order to 
> provider a wrapped response (which do the gzip encoding). I am not able to 
> configure such handlers in the jetty.xml (PaxWeb-Jetty assumes at several 
> location that the first handler is the JettyServerHandlerCollection and I 
> can't replace it with the GzipHandler or any other HandlerWrapper without 
> issues/exceptions).
>
> I have a working solution, but it necessites some change in the codebase. 
> However, I suppose I am not the only one who want to use gzip and paxweb, 
> so I don't know if I am missing something :-)
>
> Le mercredi 16 janvier 2019 14:52:56 UTC+1, Grzegorz Grzybek a écrit :
>>
>> Hello
>>
>> There are 40 unresolved issues in 
>> https://ops4j1.jira.com/projects/PAXWEB/summary/statistics - I didn't 
>> see any about gzip.
>> Could you refresh my memory? :)
>>
>> regards
>> Grzegorz Grzybek
>>
>> śr., 16 sty 2019 o 14:31 Jean-Baptiste Onofré  
>> napisał(a):
>>
>>> Not with recent 7.2.x version.
>>>
>>> I think it deserves a unit test ;)
>>>
>>> Regards
>>> JB
>>> On 16/01/2019 14:20, Jérémie Brébec wrote:
>>>
>>> Hello, 
>>>
>>> I reopen this old thread, but has anyone a working example of a 
>>> GzipHandler with PaxWeb (7.2.5) ?
>>>
>>> Thanks !
>>>
>>> Le mercredi 30 août 2017 06:20:23 UTC+2, Achim Nierbeck a écrit : 
>>>>
>>>> Hi,  
>>>>
>>>> if this is an issue for you please file a bug in our Jira. 
>>>>
>>>> Thanks, Achim 
>>>>
>>>> 2017-08-10 7:44 GMT+02:00 Eric Lessard :
>>>>
>>>>> Any update on this or work around available? We're running into a 
>>>>> similar problem and are looking at options to compress our static content.
>>>>>
>>>>> Thanks!
>>>>>
>>>>> --
>>>>> --
>>>>> --
>>>>> 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.
>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>
>>>>
>>>>
>>>>
>>>> -- 
>>>>
>>>> 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>
>>>>
>>>> Software Architect / Project Manager / Scrum Master 
>>>>
>>>> -- 
>>> -- 
>>> --
>>> 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.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>> -- 
>>> -- 
>>> --
>>> 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.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>

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

--- 
You received this message be

Re: PaxWeb: Jetty and GZipHandler

[Jérémie Brébec]

I don't know if it's an issue in paxweb or just a configuration difficult 
to write.

I want to activate a GzipHandler in order to gzip contents served by my 
servlets. The old Jetty GzipFilter is deprecated and do nothing.

This Handler is a HandlerWrapper, it hooks the handler chain in order to 
provider a wrapped response (which do the gzip encoding). I am not able to 
configure such handlers in the jetty.xml (PaxWeb-Jetty assumes at several 
location that the first handler is the JettyServerHandlerCollection and I 
can't replace it with the GzipHandler or any other HandlerWrapper without 
issues/exceptions).

I have a working solution, but it necessites some change in the codebase. 
However, I suppose I am not the only one who want to use gzip and paxweb, 
so I don't know if I am missing something :-)

Le mercredi 16 janvier 2019 14:52:56 UTC+1, Grzegorz Grzybek a écrit :
>
> Hello
>
> There are 40 unresolved issues in 
> https://ops4j1.jira.com/projects/PAXWEB/summary/statistics - I didn't see 
> any about gzip.
> Could you refresh my memory? :)
>
> regards
> Grzegorz Grzybek
>
> śr., 16 sty 2019 o 14:31 Jean-Baptiste Onofré  > napisał(a):
>
>> Not with recent 7.2.x version.
>>
>> I think it deserves a unit test ;)
>>
>> Regards
>> JB
>> On 16/01/2019 14:20, Jérémie Brébec wrote:
>>
>> Hello, 
>>
>> I reopen this old thread, but has anyone a working example of a 
>> GzipHandler with PaxWeb (7.2.5) ?
>>
>> Thanks !
>>
>> Le mercredi 30 août 2017 06:20:23 UTC+2, Achim Nierbeck a écrit : 
>>>
>>> Hi,  
>>>
>>> if this is an issue for you please file a bug in our Jira. 
>>>
>>> Thanks, Achim 
>>>
>>> 2017-08-10 7:44 GMT+02:00 Eric Lessard :
>>>
>>>> Any update on this or work around available? We're running into a 
>>>> similar problem and are looking at options to compress our static content.
>>>>
>>>> Thanks!
>>>>
>>>> --
>>>> --
>>>> --
>>>> 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.
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>
>>>
>>>
>>> -- 
>>>
>>> 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>
>>>
>>> Software Architect / Project Manager / Scrum Master 
>>>
>>> -- 
>> -- 
>> --
>> 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 .
>> For more options, visit https://groups.google.com/d/optout.
>>
>> -- 
>> -- 
>> --
>> 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 .
>> 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: PaxWeb: Jetty and GZipHandler

[Jérémie Brébec]

Hello,

I reopen this old thread, but has anyone a working example of a GzipHandler 
with PaxWeb (7.2.5) ?

Thanks !

Le mercredi 30 août 2017 06:20:23 UTC+2, Achim Nierbeck a écrit :
>
> Hi, 
>
> if this is an issue for you please file a bug in our Jira. 
>
> Thanks, Achim 
>
> 2017-08-10 7:44 GMT+02:00 Eric Lessard >
> :
>
>> Any update on this or work around available? We're running into a similar 
>> problem and are looking at options to compress our static content.
>>
>> Thanks!
>>
>> --
>> --
>> --
>> 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 .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
>
> Apache Member
> Apache Karaf  Committer & PMC
> OPS4J Pax Web  Committer & 
> Project Lead
> blog 
> Co-Author of Apache Karaf Cookbook 
>
> Software Architect / Project Manager / Scrum Master 
>
>

-- 
-- 
--
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: PaxLogging and Structured logs

[Jérémie Brébec]

Yes. For example I'd like to use a RoutingAppender configured with 
properties in my MapMessage, or generate structured JSON messages to an 
external logging system.

Le jeudi 10 janvier 2019 13:48:23 UTC+1, Jean-Baptiste Onofré a écrit :
>
> Hi Jérémis,
>
> You mean without marshalling to a "flat" log event ?
>
> Regards
> JB
> On 10/01/2019 13:44, Jérémie Brébec wrote:
>
> Hello, 
>
> I try to use a log4j2 logger to log some structured logs (like instances 
> of MapMessage). However, my message is lost and the appenders receive 
> instances of MutableLogEvent instead. In the execution trace, I can see a 
> Log4jv2Logger which discards my message by calling getFormattedMessage().
>
> Is this scenario supported by PaxLogging ? I have tested it with Karaf 
> 4.2.2.
>
> Regards,
> Jérémie
> -- 
> -- 
> --
> 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 .
> 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.

PaxLogging and Structured logs

[Jérémie Brébec]

Hello,

I try to use a log4j2 logger to log some structured logs (like instances of 
MapMessage). However, my message is lost and the appenders receive 
instances of MutableLogEvent instead. In the execution trace, I can see a 
Log4jv2Logger which discards my message by calling getFormattedMessage().

Is this scenario supported by PaxLogging ? I have tested it with Karaf 
4.2.2.

Regards,
Jérémie

-- 
-- 
--
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: How to make sure no processes are left over?

[Jérémie Brébec]

By experience, it's not rare to see on our production server "zombie" java 
processes with pax exam (4.11). Sometimes, osgi containers launched by pax 
exam are not killed properly.

Le mardi 10 octobre 2017 15:33:54 UTC+2, Christian Schneider a écrit :
>
> Pax exan starts a forked virtual machine. Additionally it is possible to 
> create more virtual machines using TestContainer.
>
> Does pax exam have any measures to make sure we do not leave any processes 
> running when something goes wrong?
>
> The background of my question is that a colleague of me created a small 
> wrapper for java processes that watches a liveliness file and that makes 
> sure the sub processes terminate if the main test process is killed. So I 
> wonder if such a thing already exists in pax exam or if maybe we can 
> improve it.
>
> Christian
>
> -- 
> -- 
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: PaxLogging: org.ops4j.pax.logging.log4jv2.Log4jv2LoggerContext cannot be cast to org.apache.logging.log4j.core.LoggerContext

[Jérémie Brébec]

Yes, that is the first thing I checked.

However LoggerContext.getContext() 
<https://github.com/apache/logging-log4j2/blob/master/log4j-core/src/main/java/org/apache/logging/log4j/core/LoggerContext.java#L169>
 try 
to cast the context into a org.apache.logging.log4j.core.LoggerContext and 
Log4jv2LoggerContext 
<https://github.com/ops4j/org.ops4j.pax.logging/blob/master/pax-logging-api/src/main/java/org/ops4j/pax/logging/log4jv2/Log4jv2LoggerContext.java>
 implements 
only org.apache.logging.log4j.spi.LoggerContext so it's doesn't seen to be 
related to osgi and classloader.

Le mercredi 9 août 2017 18:40:55 UTC+2, Achim Nierbeck a écrit :
>
> Hi, 
>
> it still might be a class-cast exception when you embed that class in your 
> own bundle. Maybe that is the case in your scenario. 
> I'd check that first. 
>
> regards, Achim 
>
>
> 2017-08-09 17:30 GMT+02:00 Jérémie Brébec  >:
>
>> Hello,
>>
>> I am using pax-logging 1.10.1 through Karaf 4.1.2 ;
>>
>> I am trying to integrate the log generated by my ElasticSearch bundle to 
>> the pax-logging implementation. However, this didn't work because a 
>> ClassCastException. I haven't see any "duplicate classloader issues", and 
>> when I check the code, the ClassCastException doesn't feel to be 
>> osgi-related. Is it a known issue or I am missing something ?
>>
>> Regards,
>> Jérémie
>>
>> java.lang.ClassCastException: 
>> org.ops4j.pax.logging.log4jv2.Log4jv2LoggerContext cannot be cast to 
>> org.apache.logging.log4j.core.LoggerContext
>> at 
>> org.apache.logging.log4j.core.LoggerContext.getContext(LoggerContext.java:190)
>>  
>> [6:org.ops4j.pax.logging.pax-logging-log4j2:1.10.1]
>> at 
>> org.apache.logging.log4j.core.config.Configurator.setLevel(Configurator.java:291)
>>  
>> [6:org.ops4j.pax.logging.pax-logging-log4j2:1.10.1]
>> at 
>> org.elasticsearch.common.logging.Loggers.setLevel(Loggers.java:149) 
>> [88:features.boss.elasticsearch.bundle:5.5.0]
>> at 
>> org.elasticsearch.common.logging.Loggers.setLevel(Loggers.java:144) 
>> [88:features.boss.elasticsearch.bundle:5.5.0]
>> at 
>> org.elasticsearch.index.SearchSlowLog.setLevel(SearchSlowLog.java:111) 
>> [88:features.boss.elasticsearch.bundle:5.5.0]
>> at 
>> org.elasticsearch.index.SearchSlowLog.(SearchSlowLog.java:106) 
>> [88:features.boss.elasticsearch.bundle:5.5.0]
>> at 
>> org.elasticsearch.index.IndexModule.(IndexModule.java:127) 
>> [88:features.boss.elasticsearch.bundle:5.5.0]
>> at 
>> org.elasticsearch.indices.IndicesService.createIndexService(IndicesService.java:441)
>>  
>> [88:features.boss.elasticsearch.bundle:5.5.0]
>> at 
>> org.elasticsearch.indices.IndicesService.createIndex(IndicesService.java:414)
>>  
>> [88:features.boss.elasticsearch.bundle:5.5.0]
>> at 
>> org.elasticsearch.cluster.metadata.MetaDataIndexTemplateService.validateAndAddTemplate(MetaDataIndexTemplateService.java:216)
>>  
>> [88:features.boss.elasticsearch.bundle:5.5.0]
>> at 
>> org.elasticsearch.cluster.metadata.MetaDataIndexTemplateService.access$200(MetaDataIndexTemplateService.java:63)
>>  
>> [88:features.boss.elasticsearch.bundle:5.5.0]
>> at 
>> org.elasticsearch.cluster.metadata.MetaDataIndexTemplateService$2.execute(MetaDataIndexTemplateService.java:172)
>>  
>> [88:features.boss.elasticsearch.bundle:5.5.0]
>> at 
>> org.elasticsearch.cluster.ClusterStateUpdateTask.execute(ClusterStateUpdateTask.java:45)
>>  
>> [88:features.boss.elasticsearch.bundle:5.5.0]
>> at 
>> org.elasticsearch.cluster.service.ClusterService.executeTasks(ClusterService.java:634)
>>  
>> [88:features.boss.elasticsearch.bundle:5.5.0]
>> at 
>> org.elasticsearch.cluster.service.ClusterService.calculateTaskOutputs(ClusterService.java:612)
>>  
>> [88:features.boss.elasticsearch.bundle:5.5.0]
>> at 
>> org.elasticsearch.cluster.service.ClusterService.runTasks(ClusterService.java:571)
>>  
>> [88:features.boss.elasticsearch.bundle:5.5.0]
>> at 
>> org.elasticsearch.cluster.service.ClusterService$ClusterServiceTaskBatcher.run(ClusterService.java:263)
>>  
>> [88:features.boss.elasticsearch.bundle:5.5.0]
>> at 
>> org.elasticsearch.cluster.service.TaskBatcher.runIfNotProcessed(TaskBatcher.java:150)
>>  
>> [88:features.boss.elasticsearch.bundl

PaxLogging: org.ops4j.pax.logging.log4jv2.Log4jv2LoggerContext cannot be cast to org.apache.logging.log4j.core.LoggerContext

[Jérémie Brébec]

Hello,

I am using pax-logging 1.10.1 through Karaf 4.1.2 ;

I am trying to integrate the log generated by my ElasticSearch bundle to 
the pax-logging implementation. However, this didn't work because a 
ClassCastException. I haven't see any "duplicate classloader issues", and 
when I check the code, the ClassCastException doesn't feel to be 
osgi-related. Is it a known issue or I am missing something ?

Regards,
Jérémie

java.lang.ClassCastException: 
org.ops4j.pax.logging.log4jv2.Log4jv2LoggerContext cannot be cast to 
org.apache.logging.log4j.core.LoggerContext
at 
org.apache.logging.log4j.core.LoggerContext.getContext(LoggerContext.java:190) 
[6:org.ops4j.pax.logging.pax-logging-log4j2:1.10.1]
at 
org.apache.logging.log4j.core.config.Configurator.setLevel(Configurator.java:291)
 
[6:org.ops4j.pax.logging.pax-logging-log4j2:1.10.1]
at 
org.elasticsearch.common.logging.Loggers.setLevel(Loggers.java:149) 
[88:features.boss.elasticsearch.bundle:5.5.0]
at 
org.elasticsearch.common.logging.Loggers.setLevel(Loggers.java:144) 
[88:features.boss.elasticsearch.bundle:5.5.0]
at 
org.elasticsearch.index.SearchSlowLog.setLevel(SearchSlowLog.java:111) 
[88:features.boss.elasticsearch.bundle:5.5.0]
at 
org.elasticsearch.index.SearchSlowLog.(SearchSlowLog.java:106) 
[88:features.boss.elasticsearch.bundle:5.5.0]
at org.elasticsearch.index.IndexModule.(IndexModule.java:127) 
[88:features.boss.elasticsearch.bundle:5.5.0]
at 
org.elasticsearch.indices.IndicesService.createIndexService(IndicesService.java:441)
 
[88:features.boss.elasticsearch.bundle:5.5.0]
at 
org.elasticsearch.indices.IndicesService.createIndex(IndicesService.java:414) 
[88:features.boss.elasticsearch.bundle:5.5.0]
at 
org.elasticsearch.cluster.metadata.MetaDataIndexTemplateService.validateAndAddTemplate(MetaDataIndexTemplateService.java:216)
 
[88:features.boss.elasticsearch.bundle:5.5.0]
at 
org.elasticsearch.cluster.metadata.MetaDataIndexTemplateService.access$200(MetaDataIndexTemplateService.java:63)
 
[88:features.boss.elasticsearch.bundle:5.5.0]
at 
org.elasticsearch.cluster.metadata.MetaDataIndexTemplateService$2.execute(MetaDataIndexTemplateService.java:172)
 
[88:features.boss.elasticsearch.bundle:5.5.0]
at 
org.elasticsearch.cluster.ClusterStateUpdateTask.execute(ClusterStateUpdateTask.java:45)
 
[88:features.boss.elasticsearch.bundle:5.5.0]
at 
org.elasticsearch.cluster.service.ClusterService.executeTasks(ClusterService.java:634)
 
[88:features.boss.elasticsearch.bundle:5.5.0]
at 
org.elasticsearch.cluster.service.ClusterService.calculateTaskOutputs(ClusterService.java:612)
 
[88:features.boss.elasticsearch.bundle:5.5.0]
at 
org.elasticsearch.cluster.service.ClusterService.runTasks(ClusterService.java:571)
 
[88:features.boss.elasticsearch.bundle:5.5.0]
at 
org.elasticsearch.cluster.service.ClusterService$ClusterServiceTaskBatcher.run(ClusterService.java:263)
 
[88:features.boss.elasticsearch.bundle:5.5.0]
at 
org.elasticsearch.cluster.service.TaskBatcher.runIfNotProcessed(TaskBatcher.java:150)
 
[88:features.boss.elasticsearch.bundle:5.5.0]
at 
org.elasticsearch.cluster.service.TaskBatcher$BatchedTask.run(TaskBatcher.java:188)
 
[88:features.boss.elasticsearch.bundle:5.5.0]
at 
org.elasticsearch.common.util.concurrent.ThreadContext$ContextPreservingRunnable.run(ThreadContext.java:569)
 
[88:features.boss.elasticsearch.bundle:5.5.0]
at 
org.elasticsearch.common.util.concurrent.PrioritizedEsThreadPoolExecutor$TieBreakingPrioritizedRunnable.runAndClean(PrioritizedEsThreadPoolExecutor.java:247)
 
[88:features.boss.elasticsearch.bundle:5.5.0]
at 
org.elasticsearch.common.util.concurrent.PrioritizedEsThreadPoolExecutor$TieBreakingPrioritizedRunnable.run(PrioritizedEsThreadPoolExecutor.java:210)
 
[88:features.boss.elasticsearch.bundle:5.5.0]
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) 
[?:?]
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
[?:?]

-- 
-- 
--
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.

PaxWeb: Whiteboard and compliance to the R6 specification

[Jérémie Brébec]

Hello,

I don't know if PaxWeb intends to be compliant to the whiteboard R6 
specification. However, the following items are not compliant :

- Every Whiteboard component which doesn't target a ServletContextHelper 
should use a default shared ServletContext (linked to a 
ServletContextHelper named "default"). Today, these elements doesn't share 
the same ServletContext
- It should be possible for a Whiteboard component to target multiple 
ServletContextHelper (the spec advises to use the "prototype" scope when 
implementing a whiteboard component) : the whiteboard implementation should 
instantiate (with ServiceObjects) a new instance for every target
- It should be possible to target a ServletContextHelper with an osgi 
filter : Today, PaxWeb assume the filter is only matching the name of the 
ServletContextHelper
- It should be possible to override any ServletContextHelper (including the 
"default" one)
- Every ServletContextHelper should be resolved in the context of the 
bundle of the whiteboard component using it (the spec advises to use the 
"prototype" scope when implementing a ServletContextHelper)
- Every Whiteboard component have a delegating "ServletContext", which 
delegate to the shared ServletContext, and the ServletContextHelper

Is there a planned roadmap on these items/jira issues ?

Regards,
Jérémie

-- 
-- 
--
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: PaxWeb: WebSocketTracker and Object

[Jérémie Brébec]

Thanks, this tracker breaks the laziness of most of my whiteboard extenders 
(jaxrs, spring mvc @controller/@configuration, etc..). I didn't find 
however any mention on WebSocket in the future R7 spec, neither on the 
felix/equinox implementation. 

The only reference I found was in an implementation on Liferay, which use 
properties under "org.osgi.http.websocket.endpoint.*" (imho, not a good 
choice to use "org.osgi" prefixes..)



Le lundi 7 août 2017 18:25:25 UTC+2, Achim Nierbeck a écrit :
>
> BTW, just created the following improvement: 
> https://ops4j1.jira.com/browse/PAXWEB-1119
>
> 2017-08-07 18:22 GMT+02:00 Achim Nierbeck  >:
>
>> Hi, 
>>
>> the problem I see with this is, if one registers a WebSocket as Service, 
>> it usually doesn't need to be of a special Interface ... 
>> I can see that a property might help. Will think about this a bit more. 
>>
>> Right now you can't disable it.
>>
>> regards, Achim 
>>
>>
>> 2017-08-07 14:00 GMT+02:00 Jérémie Brébec > >:
>>
>>> Hello,
>>>
>>> In pax web 6, a WebSocketTracker is created. This tracker "track" with a 
>>> ServiceTracker every registration of services with the class "Object". This 
>>> tracker resolves every service through bundleContext.getService().
>>> As a consequence, every component registered with "Object" are resolved, 
>>> breaking the Declaratives Services lazy properties.
>>>
>>> Is there a way to deactivate this tracker, or at least make it activate 
>>> only with the presence of a property ? This tracker is not precise enough, 
>>> imho, to systematically calls getService on every references.
>>>
>>> Regard,
>>> Jérémie
>>>
>>> -- 
>>> -- 
>>> --
>>> 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 .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> -- 
>>
>> 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>
>>
>> Software Architect / Project Manager / Scrum Master 
>>
>>
>
>
> -- 
>
> 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>
>
> Software Architect / Project Manager / Scrum Master 
>
>

-- 
-- 
--
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.

PaxWeb: WebSocketTracker and Object

[Jérémie Brébec]

Hello,

In pax web 6, a WebSocketTracker is created. This tracker "track" with a 
ServiceTracker every registration of services with the class "Object". This 
tracker resolves every service through bundleContext.getService().
As a consequence, every component registered with "Object" are resolved, 
breaking the Declaratives Services lazy properties.

Is there a way to deactivate this tracker, or at least make it activate 
only with the presence of a property ? This tracker is not precise enough, 
imho, to systematically calls getService on every references.

Regard,
Jérémie

-- 
-- 
--
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.

PaxWeb: Jetty and GZipHandler

[Jérémie Brébec]

Hi,

With Jetty v9.3 (with PaxWeb 6.0.3), the GZipFilter is marked as obsolete. 
As Jetty is really verbose about this deprecation, I am trying to upgrade 
my application to remove all registration of the GZipFilter and use instead 
a global GZipHandler.

However, I didn't succed to configure PaxWeb with this "HandlerWrapper" in 
jetty.xml :

   - The official way is to call "Server.insertHandler" which create a 
   chain of HandlerWrapper. However, PaxWeb seems to suppose that the first 
   handlerwrapper is his own "JettyServerHandlerCollection", and I have a lot 
   of exception ("java.lang.IllegalStateException: STARTED" on each 
   registratrion (cf [1]), and a ClassCastException when the bundle is stopped)
   - If I call "getHandler().addHandler(..)", this doesn't work either : 
   the GZiphandler is either not call or throw a NPE as it doesn't have a 
   child handler

How can I use this Handler with PaxWeb ? Moreover, is there an equivalent 
of the "jetty.xml" for undertow ?

Thanks !


[1] 
2017-06-28T18:03:58,102 | ERROR | Start Level: Equinox Container: 
052d47d4-8713-4018-89e6-d2027a5ad69f | WebApplication   | 
234 - org.ops4j.pax.web.pax-web-extender-whiteboard - 6.0.3 | Registration 
skipped for 
[ServletWebElement{mapping=DefaultServletMapping{httpContextId=null,urlPatterns=null,initParams={},servlet=xxx.web.redirect.RedirectServlet@5477a25b,
 
alias=/redirect, servletNameredirect}}] due to error during registration
java.lang.IllegalStateException: STARTED
at 
org.eclipse.jetty.server.handler.HandlerWrapper.setHandler(HandlerWrapper.java:85)
 
[206:org.eclipse.jetty.server:9.3.14.v20161028]
at 
org.eclipse.jetty.servlet.ServletContextHandler.(ServletContextHandler.java:166)
 
[207:org.eclipse.jetty.servlet:9.3.14.v20161028]
at 
org.eclipse.jetty.servlet.ServletContextHandler.(ServletContextHandler.java:128)
 
[207:org.eclipse.jetty.servlet:9.3.14.v20161028]
at 
org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.(HttpServiceContext.java:116)
 
[235:org.ops4j.pax.web.pax-web-jetty:6.0.3]
at 
org.ops4j.pax.web.service.jetty.internal.JettyServerWrapper.addContext(JettyServerWrapper.java:290)
 
[235:org.ops4j.pax.web.pax-web-jetty:6.0.3]
at 
org.ops4j.pax.web.service.jetty.internal.JettyServerWrapper.getOrCreateContext(JettyServerWrapper.java:209)
 
[235:org.ops4j.pax.web.pax-web-jetty:6.0.3]
at 
org.ops4j.pax.web.service.jetty.internal.JettyServerWrapper.getOrCreateContext(JettyServerWrapper.java:190)
 
[235:org.ops4j.pax.web.pax-web-jetty:6.0.3]
at 
org.ops4j.pax.web.service.jetty.internal.JettyServerImpl.addServlet(JettyServerImpl.java:324)
 
[235:org.ops4j.pax.web.pax-web-jetty:6.0.3]
at 
org.ops4j.pax.web.service.jetty.internal.ServerControllerImpl$Started.addServlet(ServerControllerImpl.java:289)
 
[235:org.ops4j.pax.web.pax-web-jetty:6.0.3]
at 
org.ops4j.pax.web.service.jetty.internal.ServerControllerImpl.addServlet(ServerControllerImpl.java:110)
 
[235:org.ops4j.pax.web.pax-web-jetty:6.0.3]
at 
org.ops4j.pax.web.service.internal.HttpServiceStarted.registerServlet(HttpServiceStarted.java:239)
 
[237:org.ops4j.pax.web.pax-web-runtime:6.0.3]

-- 
-- 
--
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: PaxWeb: Undertow and async filter/servlet

[Jérémie Brébec]

Thank you, I have created this issue 
: https://ops4j1.jira.com/browse/PAXWEB-1109

Le mercredi 28 juin 2017 22:02:31 UTC+2, Achim Nierbeck a écrit :
>
> Hi, 
>
> sounds like you found a bug. Care for opening a jira issue for that? 
> In case you don't have a Jira account yet, let me know so I can enable 
> that for you :) 
>
> regards, Achim 
>
>
> 2017-06-28 10:20 GMT+02:00 Jérémie Brébec  >:
>
>> Hi,
>>
>> I have an application using Karaf 4.1.1, PaxWeb and the jetty provider.
>>
>> For testing purpose, I am trying the new undertow provider of pax web 6 : 
>> Most of my application seems to work, exception for my notification 
>> servlet, using the Servlet3 "startAsync" API. Undertow fails with this 
>> exception :
>>
>> Caused by: java.lang.IllegalStateException: UT010026: Async is not 
>> supported for this request, as not all filters or Servlets were marked as 
>> supporting async
>> at 
>> io.undertow.servlet.spec.HttpServletRequestImpl.startAsync(HttpServletRequestImpl.java:948)
>>  
>> ~[?:?]
>> at 
>> javax.servlet.ServletRequestWrapper.startAsync(ServletRequestWrapper.java:432)
>>  
>> ~[104:javax.servlet-api:3.1.0]
>> at 
>> javax.servlet.ServletRequestWrapper.startAsync(ServletRequestWrapper.java:432)
>>  
>> ~[104:javax.servlet-api:3.1.0]
>> at 
>> .security.authentication.web.CookieBasedSecurityContextRepository$Servlet3RequestWrapper.startAsync(CookieBasedSecurityContextRepository.java:168)
>>  
>> ~[81:xxx.security-core:1.11.0.SNAPSHOT]
>> at 
>> javax.servlet.ServletRequestWrapper.startAsync(ServletRequestWrapper.java:432)
>>  
>> ~[104:javax.servlet-api:3.1.0]
>> at 
>> org.springframework.security.web.servletapi.HttpServlet3RequestFactory$Servlet3SecurityContextHolderAwareRequestWrapper.startAsync(HttpServlet3RequestFactory.java:167)
>>  
>> ~[?:?]
>>
>> This application is securised with a SpringSecurity Filter, which has 
>> been register as an osgi service, with the property 
>> "osgi.http.whiteboard.filter.asyncSupported" = "true", (and works fine with 
>> Jetty).
>>
>> Is there a configuration to add to use an async servlet with undertow ?
>>
>> Not sure about it, but after reading the code, it looks like the Undertow 
>> provider doesn't respect the FilterModel.isAsync(), and don't call the 
>> undertow FilterInfo.setAsyncSupported(..) [1]
>>
>> Regards, Jérémie
>>
>> [1] 
>> https://github.com/ops4j/org.ops4j.pax.web/blob/master/pax-web-undertow/src/main/java/org/ops4j/pax/web/service/undertow/internal/Context.java#L459
>>
>>
>> -- 
>> -- 
>> --
>> 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 .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
>
> 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>
>
> Software Architect / Project Manager / Scrum Master 
>
>

-- 
-- 
--
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.

PaxWeb: Undertow and async filter/servlet

[Jérémie Brébec]

Hi,

I have an application using Karaf 4.1.1, PaxWeb and the jetty provider.

For testing purpose, I am trying the new undertow provider of pax web 6 : 
Most of my application seems to work, exception for my notification 
servlet, using the Servlet3 "startAsync" API. Undertow fails with this 
exception :

Caused by: java.lang.IllegalStateException: UT010026: Async is not 
supported for this request, as not all filters or Servlets were marked as 
supporting async
at 
io.undertow.servlet.spec.HttpServletRequestImpl.startAsync(HttpServletRequestImpl.java:948)
 
~[?:?]
at 
javax.servlet.ServletRequestWrapper.startAsync(ServletRequestWrapper.java:432) 
~[104:javax.servlet-api:3.1.0]
at 
javax.servlet.ServletRequestWrapper.startAsync(ServletRequestWrapper.java:432) 
~[104:javax.servlet-api:3.1.0]
at 
.security.authentication.web.CookieBasedSecurityContextRepository$Servlet3RequestWrapper.startAsync(CookieBasedSecurityContextRepository.java:168)
 
~[81:xxx.security-core:1.11.0.SNAPSHOT]
at 
javax.servlet.ServletRequestWrapper.startAsync(ServletRequestWrapper.java:432) 
~[104:javax.servlet-api:3.1.0]
at 
org.springframework.security.web.servletapi.HttpServlet3RequestFactory$Servlet3SecurityContextHolderAwareRequestWrapper.startAsync(HttpServlet3RequestFactory.java:167)
 
~[?:?]

This application is securised with a SpringSecurity Filter, which has been 
register as an osgi service, with the property 
"osgi.http.whiteboard.filter.asyncSupported" = "true", (and works fine with 
Jetty).

Is there a configuration to add to use an async servlet with undertow ?

Not sure about it, but after reading the code, it looks like the Undertow 
provider doesn't respect the FilterModel.isAsync(), and don't call the 
undertow FilterInfo.setAsyncSupported(..) [1]

Regards, Jérémie

[1] 
https://github.com/ops4j/org.ops4j.pax.web/blob/master/pax-web-undertow/src/main/java/org/ops4j/pax/web/service/undertow/internal/Context.java#L459


-- 
-- 
--
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.