That's true, and that's why it's opinionated :) The purpose is really to match 90% of the use cases. I think some features are interesting but require a lot of effort/maintenance for only a limited use.
Regards JB On Thu, Jun 20, 2024 at 9:47 AM Grzegorz Grzybek <gr.grzy...@gmail.com> wrote: > > 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 > > > > >>>>>> > > > > > > > > > >
