Thanks for clarification JB! Just one more comment about:
Tomcat for the Karaf Web service yes (not strong opinion here, it > would be Jetty). And as state earlier, only Servlet/Filter service > registration package will be supported. That's quite arbitrary distinction TBH :) You know - we rarely write servlets these days and rather have some kind of dispatcher servlet (yes, this is spring...) which delegates to different views/controllers/handlers etc. However the point is that even if you DO write servlets, then: - servlets have access to ServletContext - ServletContext gives you access to context attributes - context attributes are either taken from web.xml (<context-param>) or are setup in ServletContextListeners - ServletContextListeners are 3rd "big thing" (next to servlets and filters) that constitute web applications - so you have to allow them too - but ServletContextListeners allow you to dynamically register additional servlets (that's what most SCIs do too - JSF, JSP, ...) dynamically with dynamic mapping - also servlets and filters may be protected - in web.xml you can have <login-config> and <security-constraint> elements... I could continue (I've already mentioned JSPs, SCIs, ...) getting closer and closer to full Servlet API specification... The point is that if you want servlets + filters only, you'd need full implementation based on particular runtime (whether Tomcat, Jetty or Undertow) to deal with its specifics (like Jetty's ServletContextHandler, Tomcat's StandardContext or Undertow's DeploymentInfo). You also have to deal with contexts (implementations of jakarta.servlet.ServletContext interface) to separate servlets. Though Felix-Http has one "dispatcher servlet" registered in single context and moves "context" concept from the runtime to this servlet... Anyway - a lot of work ;) regards Grzegorz Grzybek czw., 20 cze 2024 o 08:51 Jean-Baptiste Onofré <j...@nanthrax.net> napisał(a): > Hi Grzegorz > > Thanks for your message, it's highly appreciated. > > See my comments inline: > > > 1. What exactly are "Karaf services"? Are these OSGi services? > (registered > > with BundleContext.registerService(iface, object, properties)?) If not > then > > what are the aspects that make them "services" - discoverability, > > interface, registration method (through annotations and build time > > processing? /META-INF/services? other?)? > > It's OSGi services. > > > > > 2. Removing Pax + hiding OSGi seems complementary, but is OSGi going to > be > > implementation detail of Karaf 5? or just deployment method (Minho / > Felix > > Atomos?) If you say that pax-web will still be available, it means it > needs > > full OSGi runtime (Felix, Equinox) underneath. Mind that the biggest > > obstacle when refactoring Pax Web 7 into Pax Web 8 was this entire > > "discoverability" mechanism, which allows you to scan > > bundles/fragments/wires looking for annotated web elements, SCIs and > > web-fragment.xml files... So if you hide OSGi under "Karaf services" and > at > > the same time keep OSGi for those who want it, it'd be (sorry for > analogy) > > like hiding an elephant under a napkin... :) > > Fair comment. The purpose of Karaf Services is to simplify and focus > only on what matters for the users in the Karaf context. > For instance, why not just supporting Servlet OSGi services listening, > not need to support annotation web elements or web-fragments.xml. > If a user wants these features, then it will use Pax Web. > But, if the user just need a simple webcontainer for servlet and Karaf > webconsole, then Karaf Web service would be enough. > > > > > 3. Pax URL and Pax Web accept configuration via ConfigAdmin. So again - > you > > can't remove, you have to hide it (see #2). > > I'm not too concerned about ConfigAdmin: it will stay there. > > > > > 4. Also for Pax Web - it required a lot of effort to make it > "restartable". > > I mean even Tomcat/Jetty/Undertow itself keep each webapp in separate > > classloader, so you can kind of get rid of the webapp (undeploy) if you > > like. Pax Web pushes this to the extreme with whiteboard, where you can > > have filters from different bundles filtering access to servlets from > > different bundles and sending events to listeners from yet different > > bundles and everything is (should be) classloader-safe. Hinding it under > > non-hierarchical classloader may not be possible... > > Same here: restartable could be Pax Web feature. > > > > > 5. You've mentioned "main focus on Tomcat", but roughly speaking, Tomcat > > operates on entire webapps. It's only Pax Web (or Felix HTTP with Jetty) > > that make it possible to operate on the level of single > > servlet/filter/listener/SCI/... - how could such "Karaf web service for > > Tomcat" look like if you, say, wanted to register a servlet + filter? How > > would you package and register such servlet + filter? > > Tomcat for the Karaf Web service yes (not strong opinion here, it > would be Jetty). And as state earlier, only Servlet/Filter service > registration package will be supported. > > The purpose is not to remove Pax * projects, it's more to have very > simple "native" Karaf services. > > Regards > JB > > > > > Not that I don't approve the plans (I like how you think about the > future), > > or maybe simply my mind went numb after working for few weeks with > > rollup.js and typescript, but I don't feel like I can provide any > > constructive feedback besides asking for clarification... > > > > kind regards > > Grzegorz Grzybek > > > > wt., 11 cze 2024 o 16:20 Matt Pavlovich <mattr...@gmail.com> napisał(a): > > > > > Hi JB- > > > > > > Makes sense, I figured I’d make the pitch for the pax-* merger in that > > > there is a lot of good use cases, stability and performance scenarios > > > already handled there. > > > > > > I look forward to assisting with the new karaf-* services. > > > > > > Thanks, > > > Matt Pavlovich > > > > > > > On Jun 11, 2024, at 3:45 AM, Jean-Baptiste Onofré <j...@nanthrax.net> > > > wrote: > > > > > > > > Hi all, > > > > > > > > I would like to clarify the PAX * questions. It would be still > > > > possible to use PAX * projects in Karaf 5.x, via the features (as > > > > today), but optional (not boot features anymore). > > > > > > > > As an alternative, we will have opinionated Karaf services features. > > > > > > > > For instance, pax-web will still be available (if people want to use > > > > it), but Karaf will provide a web feature (as alternative). > > > > > > > > For URL and logging, Karaf will provide simplified mvn and wrap url > > > > handlers, and opinionated Karaf logging service (only supporting > slf4j > > > > and log4j2). If users still want to use Pax URL and Pax Logging, they > > > > will still be able to do so via custom distribution. > > > > > > > > The reasons to provide Karaf opinionated services are: > > > > 1. Karaf services are governed by the ASF rule, as Karaf, which is > not > > > > the case for Pax > > > > 2. Pax * projects are great as "generic" OSGi services. On the other > > > > hand, it brings some complexity to be abstract enough for OSGi use > > > > cases and compliant with the OSGi specs. Karaf services will really > be > > > > Karaf centric, not necessarily respecting the OSGi specs, but > focusing > > > > on users' needs. > > > > 3. Facilitate Karaf tooling around to improve the developer > experience. > > > > > > > > Regards > > > > JB > > > > > > > > On Tue, Jun 11, 2024 at 8:48 AM Francois Papon > > > > <francois.pa...@openobject.fr> wrote: > > > >> > > > >> Hi Serge, > > > >> > > > >> You can already build a static Karaf custom definition ready to > start > > > >> without downloading all the dependencies at startup and create a > docker > > > >> image with that. > > > >> > > > >> The most complex part with GraalVM in our case is all the 3rd party > > > >> dependencies and the OSGi framework. I'm afraid that it will not be > > > >> possible to be GraalVM compatible. > > > >> > > > >> I'm not sure to understand your thoughts about "full OSGi for dev", > what > > > >> to you mean? > > > >> > > > >> regards, > > > >> > > > >> François > > > >> > > > >> On 08/06/2024 08:31, Serge Huber wrote: > > > >>> Hi François, > > > >>> > > > >>> I understand not everything has to be native, but for example for > > > Apache > > > >>> Unomi the default deployment is now mostly in containers, and > > > extensions > > > >>> are usually deployed mostly in development environments and then > > > statically > > > >>> packaged for production deployments. > > > >>> > > > >>> Having the option to then use Karaf 5 to leverage the benefits of > > > GraalVM > > > >>> Native Image would be very interesting I believe. I think other > > > >>> applications might be interested in these types of scenarios: full > > > OSGi for > > > >>> development, maybe pre-production and testing, and possibility to > have > > > a > > > >>> more « static » deployment for production that could be compatible > with > > > >>> native image. > > > >>> > > > >>> WDYT ? > > > >>> > > > >>> Regards, > > > >>> Serge… > > > >>> > > > >>> Le jeu. 6 juin 2024 à 11:09, Francois Papon < > > > francois.pa...@openobject.fr> > > > >>> a écrit : > > > >>> > > > >>>> Hi Serge, > > > >>>> > > > >>>> I don't think there is a benefit about GraalVM for long running > > > process > > > >>>> like Karaf. All java things doesn't need to be GraalVM native :) > > > >>>> > > > >>>> Another problem is that the community edition of GraalVM doesn't > bring > > > >>>> all the improvement as the commercial one (GC, PGO...) > > > >>>> > > > >>>> regards, > > > >>>> > > > >>>> François > > > >>>> > > > >>>> On 05/06/2024 15:13, Serge Huber wrote: > > > >>>>> Hi JB thanks for the proposal, > > > >>>>> > > > >>>>> Sounds great to me. For me Karaf 5 should really be a natural > fit for > > > >>>>> containerized deployments, making it super easy to package > > > applications > > > >>>>> that can then easily be scaled up (and down), so making it more > > > >>>> predictable > > > >>>>> and possibly more static can be a good thing. > > > >>>>> > > > >>>>> Is a goal also to make it compatible with GraalVM Native Image ? > > > >>>>> > > > >>>>> Best regards, > > > >>>>> Serge. > > > >>>>> > > > >>>>> On Tue, Jun 4, 2024 at 11:18 AM Jean-Baptiste Onofré < > > > j...@nanthrax.net> > > > >>>>> wrote: > > > >>>>> > > > >>>>>> Hi folks, > > > >>>>>> > > > >>>>>> I think it's time to prepare a new milestone for the project :) > > > >>>>>> > > > >>>>>> Short term (and first step) is to prepare the coming release: > > > >>>>>> > > > >>>>>> 1. Apache Karaf 4.4.7 will be submitted to vote next week. It > will > > > >>>> include: > > > >>>>>> * Improvement on the spring features repository (providing > both > > > >>>>>> Spring 5 and Spring 6 features) > > > >>>>>> * Dependencies updates and minor fixes found on the 4.4.6 > > > release > > > >>>>>> > > > >>>>>> 2. Apache Karaf 4.5.0 will be submitted to vote by the end of > the > > > >>>>>> month. It will include (mainly): > > > >>>>>> * New spec features repository with Jakarta specs > > > >>>>>> * Bigger fixes for 4.5.0 > > > >>>>>> > > > >>>>>> 3. Apache Karaf 5.0.0 > > > >>>>>> That's the big milestone, and I propose to have big and > > > opinionated > > > >>>>>> changes here. OSGi is an implementation detail of the runtime, > still > > > >>>>>> exposed to the experimented users. > > > >>>>>> Be opinionated means that I propose to remove PAX * > dependencies, > > > >>>>>> and provide Karaf services instead, very simple and opinionated > (for > > > >>>>>> instance, instead of PAX Web, a simple Tomcat based service, > instead > > > >>>>>> of PAX Logging, a simple slf4j/log4j only service, Pax Exam > replaced > > > >>>>>> by JUnit 5 simple extensions, etc). > > > >>>>>> Another goal of Karaf 5 is to bring new tooling to improve > dev > > > >>>>>> experience (annotation based distributions generation, etc). > > > >>>>>> Also, users will be able to smoothly deploy Spring powered or > > > >>>>>> Servlet applications without knowing/leveraging OSGi > (especially the > > > >>>>>> import/export pattern). > > > >>>>>> > > > >>>>>> Thoughts ? > > > >>>>>> > > > >>>>>> Regards > > > >>>>>> JB > > > >>>>>> > > > > > > >
