Hi I know pretty well the issue as I'm working on a fix in camel-karaf.
That's assuming CXF would use HttpService. This should be an optional module updated to the latest HttpService spec (and Pax Web). My proposal here is more to start with core CXF and a simple transport (in OSGi) without using the HttpService. Regards JB On Mon, Dec 16, 2024 at 10:24 PM François DE PARSCAU <francois.depars...@qlik.com.invalid> wrote: > > Hello Jean Baptiste, > > Here are a few issues that we encountered when trying to setup a karaf 4.4.6 > + camel 4.8.1 + camel-karaf + cxf 4.1.0 > > * > The > org.osgi.service.http.HttpService<https://docs.osgi.org/specification/osgi.cmpn/7.0.0/service.http.html#org.osgi.service.http.HttpService> > interface does not exist anymore in the 8.1.0 version of the osgi interface. > Since it's how the servlet was dynamically registering, it's a problem. In > the > main-jakarta<https://github.com/ops4j/org.ops4j.pax.web/tree/main-jakarta> > branch of pax-web, this interface has been added back in a different package, > and allows the CXFServlet to be registered. Maybe a good solution would be > to use the whiteboard > specification<https://docs.osgi.org/specification/osgi.cmpn/8.1.0/service.servlet.html> > instead ? > In our current solution, there is a dependency to pax web > > * > Since cxf 4.1.0 did not contain the OSGI code anymore, the current choice was > to have all cxf-core feature shaded in the camel-cxf-all component, and all > blueprint classes in camel-cxf-blueprint, in camel-karaf repo. There were a > few things to fix because of the single bundle, but now the servlets are > accessible. > > Best regards, > > François > > > > ________________________________ > From: Andriy Redko <drr...@gmail.com> > Sent: Friday, December 13, 2024 8:34 PM > To: Jean-Baptiste Onofré <j...@nanthrax.net>; dev@cxf.apache.org > <dev@cxf.apache.org> > Subject: Re: [PROPOSAL] Create cxf-karaf repository > > CAUTION: This email originated from outside of the organization. Do not click > links or open attachments unless you recognize the sender and know the > content is safe. > > > > Hey JB, > > Thanks a lot for stepping in and offering your help here. We just recently > discussed > that exact same subject with Colm, which resulted in [1]. From my side, there > are few > questions: > - is OSGI ecosystem leveled up on Jakarta? (seems like not fully) > - do you need help from CXF folks? > > From CXF side, moving the OSGI / Karaf into the separate repo would reduce > the maintenance > burden for sure (leaving aside the fact that now cxf-karaf has to be > maintained). > > Thanks! > > [1] > https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FCXF-9086&data=05%7C02%7CFrancois.DEPARSCAU%40qlik.com%7Cd64d430756fd46a4f43008dd1bad640e%7Cc21eeb5ff5a644e8a997124f2f7a497c%7C0%7C0%7C638697153714292807%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=5erlOAFTFs7y%2Fy297vFqEJWHzslSvT6y8NHdWUwO73U%3D&reserved=0<https://issues.apache.org/jira/browse/CXF-9086> > > Best Regards, > Andriy Redko > > > Friday, December 13, 2024, 1:30:16 PM, you wrote: > > > Yes, no impact for users (exactly as I did on camel-karaf). > > > I’m ready to work on this if we have a consensus. > > > Regards > > JB > > > Le ven. 13 déc. 2024 à 19:15, Jamie G. <jamie.goody...@gmail.com> a écrit : > > >> For the users, having Camel & CXF 4.x lines available makes a lot of > >> sense - if splitting the work out to a repo to facilitate its > >> maintenance then that's ok. > > >> Will Apache Karaf by default pick up these two repos, making it > >> effectively seamless from the end user point of view? They'll just > >> install Camel and CXF features as per usual? > >> On Fri, Dec 13, 2024 at 12:18 PM Jean-Baptiste Onofré <j...@nanthrax.net> > >> wrote: > >>> Hi folks, > >>> CXF 4.x first removed the OSGi support (headers), and later re-add > >>> only the headers. > >>> We can consider the OSGi support non-operational in CXF as the > >>> blueprint extension, etc have been removed. > >>> Also, the Apache Karaf support has been removed (e.g. features.xml). > >>> I think it makes sense to remove this from the CXF "core". > >>> However, I received a bunch of requests from users who want CXF 4.x > >>> running in Karaf (they are "stuck" with CXF 3.x right now). > >>> In order to provide the best user experience, I would like to propose > >>> the following: > >>> - I propose to completely remove the OSGi support from CXF core > >>> (including the OSGi headers). The CXF modules would be "regular" jar > >>> files, not OSGi bundles > >>> - We can add the OSGi & Karaf support on top on CXF core like we did > >>> with camel-karaf e.g.: > >>> a. We add OSGi bundle "wrapper" > >>> b. We add OSGi extensions (blueprint, bus/endpoint as OSGi service, > >> ...) > >>> c. We add Karaf features repository (e.g. features.xml) > >>> To host that, I propose to create a cxf-karaf git repository (similar > >>> to > >>> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fcamel-karaf&data=05%7C02%7CFrancois.DEPARSCAU%40qlik.com%7Cd64d430756fd46a4f43008dd1bad640e%7Cc21eeb5ff5a644e8a997124f2f7a497c%7C0%7C0%7C638697153714319034%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=862lXnutbkf%2FIFUM3GkKsTvMviNh7ptkt3Hmw4juEjE%3D&reserved=0)<https://github.com/apache/camel-karaf> > >>> and use the > >>> org.apache.cxf.karaf Maven groupId coordinate). > >>> Thoughts ? > >>> Regards > >>> JB > > > The information transmitted is intended only for the person or entity to > which it is addressed and may contain confidential and/or privileged > material. Any review, retransmission, dissemination or other use of, or > taking of any action in reliance upon, this information by persons or > entities other than the intended recipient is prohibited. If you received > this in error, please contact the sender and delete the material from any > computer. Our Privacy & Cookie > Notice<https://www.qlik.com/us/legal/privacy-and-cookie-notice> describes how > we handle personal information. > QlikTech France SARL (Société à responsabilité limitée), registered in France > with number 499 265 940 R.C.S. Nanterre, and whose registered office is Tour > Initiale, 1 Terrasse Bellini 5th Floor 92919 La Defense, Cedex Paris, France
