[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jetty-users] TLS ALPN ACME Lets Encrypt challange
|
Simone,
my suspicion is that the Jetty XML being declarative and thus not
directly handled by the OSGi runtime, is causing the timing troubles.
But I am right about the staging of the ACME challenge I have to perform
in order to get a new Lets Encypt SSL certificate?
https://letsencrypt.org/how-it-works/
Did not get to a test because Pax Web uses the org.mortbay.jetty.alpn
dependency instead of the org.eclipse.jetty.alpn one, building a
fragment for that one now.
On 24/11/2022 15:44, Simone Bordet wrote:
Hi,
On Thu, Nov 24, 2022 at 3:37 PM Info <info@xxxxxxxxxx> wrote:
Hi, Simone,
I do need to create my own ALPNServerConnectionFactory because on
startup of the OSGi environment the SPI FLY might be too early detecting
ALPN processors.
My ALPNServerConnectionFactory implementation now has a OSGi
ServiceTracker for ALPN processors dealing with the OSGi livecycle and
initializing and adding any ALPNProcessor.Server services found.
The bundle implementing the ALPNServerConnectionFactory and the
ALPNServerConnection is set on pax-web-jetty as a bundle fragment to
expand its classpath so pax-web can execute the jetty.xml:
That's new.
AFAICT, other OSGi users do not need to do this.
We run OSGi tests without any "special" setup for ALPN.
