Re: Using GitHub Issues and Pages
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?
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
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: ALPN configuration
Hello again
How time flies...
Only now I'm deep in pax web code in order to do some pax-web 8
refactoring. My main goal is to make all 3 runtimes as similar (in terms of
configuration and features) as possible. For Jetty, I found
https://www.eclipse.org/jetty/documentation/current/alpn-chapter.html#alpn-jdk9
and was quite surprised that JDK9+ has support for HTTP/2.
Normally my work is about fixing nasty deadlocks and memory leaks, so I
rather don't have time checking what's new.
But because JDK14 is going to be released in <1 month, I think it's time to
admit that world doesn't end on JDK8.
I'll look more at HTTP/2 support - also in Undertow and Tomcat, but I can't
promise any particular date when it's done.
As Jean-Baptiste said, your PR has been moved to
https://github.com/ops4j/org.ops4j.pax.web/pull/277. Please let me finish
the refactoring and I'll take care of consistent HTTP/2 support (with
tests).
regards
Grzegorz Grzybek
wt., 12 lis 2019 o 18:08 Stéphane Vaucher
napisał(a):
> Hi Grzegorz,
>
> Comments inline
>
> I'm usually lagging behind, cleaning some rooms after party's over. I
>> joined many hypes when they stopped being a hype and I quite enjoy it.
>>
>
> I don't exactly know the specific use-cases where http2 is better. From my
> limited/theoretical understanding, it can help with certain loads (probably
> unoptimized loads like images).
>
>
>> [...]
>> you said:
>>
>> I managed to get things working after upgrading to Java11
>>>
>>
>> Do you think it's required to use Java11?
>>
>
> The change is not Java11-specific. I had many moving parts, and I got
> everything running after doing my upgrade to Java 11. It's only Java 11
> tested. For execution on Java 8, it should be a matter of following the
> steps to configure the bundles correctly. These steps are documented
> outside pax-web (on the jetty web site).
>
> > If not, then if you have PR + some test showing how to configure/use
> http2 with different containers (Jetty, Tomcat, Undertow) it'd be great to
> see it. If you checked only Jetty - that's still good.
>
> I only changed the JettyFactoryImpl class, so, unless Tomcat and Undertow
> use that class, it won't work. I didn't see any existing automated tests
> for HTTP1.1 vs HTTP2 support. That actually why I was suspecting that HTTP2
> wasn't supported correctly. I ran my tests using curl as detailed in my
> previous message. I'm on equinox, so my runtime infrastructure is likely
> different than yours.
>
> For now, I can only say - please send the PR, I'll be happy to merge it.
>>
>
> https://github.com/ops4j/org.ops4j.pax.web/pull/272
>
> Regards,
> Stephane
>
> regards
>> Grzegorz Grzybek
>>
>>
>> pt., 8 lis 2019 o 21:23 Stéphane Vaucher <
>> svauc...@benchmarkconsulting.com> napisał(a):
>>
>>> Hi everyone,
>>>
>>> I managed to get things working after upgrading to Java11, but I needed
>>> to apply a few changes to JettyFactoryImpl. I'm unsure how alpn/h2 support
>>> is functional for others with the current state of the code.
>>>
>>> When we find ALPN classes (alpnClassesAvailable), the main thing is that
>>> SSLConnectionFactory will lead to *alpn* and not to *h2* following
>>> (significant changes are in bold):
>>>
>>> //SAME
>>> Class comparatorClass =
>>> bundle.loadClass("org.eclipse.jetty.http2.HTTP2Cipher");
>>>
>>> Comparator cipherComparator = (Comparator)
>>> FieldUtils.readDeclaredStaticField(comparatorClass, "COMPARATOR");
>>> sslContextFactory.setCipherComparator(cipherComparator);
>>>
>>> // Say that SSL should support *alpn*, not h2
>>> sslFactory = new SslConnectionFactory(sslContextFactory, *"alpn"*);
>>> // was sslFactory = new SslConnectionFactory(sslContextFactory, "h2");
>>>
>>> connectionFactories.add(sslFactory);
>>>
>>> Class loadClass =
>>> bundle.loadClass("org.eclipse.jetty.http2.server.HTTP2ServerConnectionFactory");
>>> http2Factory = (AbstractConnectionFactory)
>>> ConstructorUtils.invokeConstructor(loadClass, httpsConfig);
>>> connectionFactories.add(http2Factory);
>>>
>>> //Explicitely configure ALPN
>>> * loadClass =
>>> bundle.loadClass("org.eclipse.jetty.alpn.server.ALPNServerConnectionFactory");*
>>> * alpnFactory = (NegotiatingServerConnectionFactory)
>>> ConstructorUtils.invokeConstructor(loadClass, (Object) new String[] {"ssl",
>>> "h2", "http/1.1"});*
>>> * alpnFactory.setDefaultProtocol("h2");*
>>> connectionFactories.add(alpnFactory);
>>>
>>> This leads the server to serve up h2 requests unless we explicitely
>>> requested http1.1.
>>>
>>> Do these changes make sense to you?
>>>
>>> The negociation process succeeds with both:
>>> curl -v for all requests lists:
>>> * ALPN, offering h2
>>> * ALPN, offering http/1.1
>>>
>>> $ curl -k *--http1.1* https://localhost:9443
>>> * ALPN, server accepted to use http/1.1
>>>
>>> $ curl -k *--http2* https://localhost:9443
>>>
>>> -v lists: * * ALPN, server accepted to use h2
>>>
>>> Please let me know if these changes make sense. If so, let me know if
>>> you want a PR.
>>>
>>> Regards,
Re: Using GitHub Issues and Pages
Hello I ... have never think about it. Maybe it is a good idea? Confluence is quite good, but the content there is quite dated. JIRA is great software, but it's of course subjective and lots of projects do their at GH. I don't know (I wasn't here at that time) what are the terms on which Atlassian runs Ops4J space (jira, confluence). Would be great to read feedback from others. regards Grzegorz Grzybek śr., 19 lut 2020 o 00:43 Oliver Lietz napisał(a): > 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/CAAdXmhqOv%2BVQMt5zOgmpRmZC_nS%3DFtfNMzqnM7Jdna6n%2BxnS-g%40mail.gmail.com.
Using GitHub Issues and Pages
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.
[PAX EXAM] Release 4.13.2
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.
Re: [PAX EXAM] 5 – status?
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.
Re: [PAX EXAM] 5 – status?
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.
[PAX EXAM] 5 – status?
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.
Re: [PAX WEB] Url Pattern is auto-generated from Alias and how to register exact url pattern
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;
> }
>
>
> 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
>
Re: [PAX WEB] Url Pattern is auto-generated from Alias and how to register exact url pattern
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;
}
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
