Re: [X-Mas Gift] Panel discussion about Karaf 5
Thanks a lot guys for all your interest and positive feedback ! I will send an invite soon. Thanks ! Regards JB > Le 15 déc. 2020 à 18:32, Jean-Baptiste Onofre a écrit : > > Hi guys, > > Maybe some of you know that I started to work on Karaf 5. > > I have something that it’s almost "usable". > > Before sending a global discussion thread on the mailing list, I would like > to evaluate the ideas & big changes I did. > > I would like to know if some of you would be interested by a panel discussion > call to introduce Karaf 5 (limited audience at first step). > > The agenda of this call would be: > 1. Pros/Cons about Karaf as it is today > 2. Concepts in Karaf 5 (module, extension, …) > 3. Building & running > 4. Live demo > > It could be recorded/webinar style (not necessary live call) for about 20 > people at first step (both Karaf developers and users). > The purpose is to evaluate the direction. > > Thoughts ? > Who would be interested ? > > Thanks, > Regards > JB
Re: [X-Mas Gift] Panel discussion about Karaf 5
Hi JB, Please count me in. Paul Fraser On 16/12/2020 4:32 am, Jean-Baptiste Onofre wrote: Hi guys, Maybe some of you know that I started to work on Karaf 5. I have something that it’s almost "usable". Before sending a global discussion thread on the mailing list, I would like to evaluate the ideas & big changes I did. I would like to know if some of you would be interested by a panel discussion call to introduce Karaf 5 (limited audience at first step). The agenda of this call would be: 1. Pros/Cons about Karaf as it is today 2. Concepts in Karaf 5 (module, extension, …) 3. Building & running 4. Live demo It could be recorded/webinar style (not necessary live call) for about 20 people at first step (both Karaf developers and users). The purpose is to evaluate the direction. Thoughts ? Who would be interested ? Thanks, Regards JB
Re: [X-Mas Gift] Panel discussion about Karaf 5
Yep! This would be great, please include me on the invite. > On Dec 15, 2020, at 11:32 AM, Jean-Baptiste Onofre wrote: > > Hi guys, > > Maybe some of you know that I started to work on Karaf 5. > > I have something that it’s almost "usable". > > Before sending a global discussion thread on the mailing list, I would like > to evaluate the ideas & big changes I did. > > I would like to know if some of you would be interested by a panel discussion > call to introduce Karaf 5 (limited audience at first step). > > The agenda of this call would be: > 1. Pros/Cons about Karaf as it is today > 2. Concepts in Karaf 5 (module, extension, …) > 3. Building & running > 4. Live demo > > It could be recorded/webinar style (not necessary live call) for about 20 > people at first step (both Karaf developers and users). > The purpose is to evaluate the direction. > > Thoughts ? > Who would be interested ? > > Thanks, > Regards > JB
[PAX-WEB 8] Another obstacle - WABs and virtual hosts
Hello I'm progressing well with simplification/stabilization of WAB support in Pax Web 8. Here's a draft schema of how it works now with Pax Web 7 1) Bundles with Web-ContextPath manifest header are "tracked" as "web apps" 2) web.xml parsing (if such descriptor is available) is performed in the thread that activates the bundle - so it's usually FelixStartLevel thread ( *bad!*) 3) a WebApp with web.xml started is returned as "extension", which is "started" in one of 3 (*hardcoded number!*) threads, but before it is started, it is associated with a ServiceTracker for HttpService services and when such tracker is notified, WebAppDependencyHolder service is registered 4) when "starting", it is determined whether the bundle's "context name" and "virtual hosts list" are non-conflicting to prevent tracking two WARs with same context (that's fine). *But this doesn't involve verification with contexts created using Whiteboard or HttpService!* 5) non-conflicting bundle is "published", but this only means registration of service listener for WebAppDependencyHolder services for given bundle - such service becomes available when HttpService is available 6) so when WebAppDependencyHolder is passed to a service listener, we finally have a) parsed WebApp, b) HttpService (WebContainer) instance, we can now "register" such WebApp 7) "registration" is performed in various threads - depending on what was first - HttpService or the WebApp 8) "registration" involves passing a registration visitor to WebApp.accept() method and consists of interaction with HttpService/WebContainer to register servlets, filters, etc. in WebContainer As you can see this is a pattern where entities are synchronized using service trackers/listeners and OSGi services being registered with no reason - for example IMO there should be no need to register WebAppDependencyHolder OSGi service, as it contains only a reference to bundle-scoped HttpService and one (one!) ServletContainerInitializer - no idea who could use such OSGi service. The bigger problem is VHost → contextName → List mapping: 1) it's not consistent with conflict-prevention where Whiteboard and HttpService contexts are involved 2) there's a way to "alter" a web context created by WAR extender using Whiteboard registration of additional elements (like filters) to the same context - but there's no implementation of the scenario, where WAR is uninstalled - what should be done with the additional filters? 3) virtual host handling is totally inconsistent between runtimes. in Tomcat, a virtual host is separate entity - "above the context", while in Jetty it's a "property of the context" that allows/rejects a request for given context when VHost (Host: header) doesn't match. In Undertow it's just yet another handler that accepts/rejects a request (similar behavior to Jetty). So please give me some more time ;) regards Grzregorz Grzybek
