That's my point: I'm not comfortable to depend on Pax / Aries inactive projects. I think it's easier and more "visible" to maintain in Karaf.
We can always re-add these projects later once they will be updated. If we wait all projects to migrate to Jakarta namespace, we will release Karaf 4.5.0 in 6 months :) So, I propose to cleanup for now for Karaf 4.5.0 and re-add the third-party projects when they are ready. Regards JB On Wed, Mar 25, 2026 at 8:30 PM Grzegorz Grzybek <[email protected]> wrote: > Good evening! > > One more thing - Pax JMS was a JMS equivalent of Pax JDBC. However, while > Pax JDBC is actual implementation of > https://docs.osgi.org/specification/osgi.cmpn/8.0.0/service.jdbc.html, > there's no related "standard" specification for JMS... So another reason to > not maintain Pax JMS... > > Pax JMS is also related to Pax Transx (even lower level, but for > transactions, which were hit even harder by javax → jakarta transition)... > And Pax Transx depends on Geronimo TM and Aries TM which are not very > active... > There are some outstanding PRs related to this migration: > > - https://github.com/ops4j/org.ops4j.pax.jms/pull/72 > - https://github.com/ops4j/org.ops4j.pax.transx/pull/74 > - https://github.com/apache/aries/pull/790 > > kind regards > Grzegorz Grzybek > > śr., 25 mar 2026 o 19:01 Jean-Baptiste Onofré <[email protected]> > napisał(a): > >> By the way, while working on https://github.com/apache/karaf/pull/2476 >> (migrating from javax to jakarta), I just realized that Pax JMS is JMS 1.x >> only for now. >> >> Honestly, as Pax CDI, I'm not sure it makes sense to still use/maintain >> Pax JMS. >> I would rather suggest using a service provider (custom): I'm updating >> the examples as part of the PR. >> >> Also, we can add a new Karaf service (easier to maintain) dealing with >> JMS ConnectionFactories (similar to Karaf URL service). >> >> Regards >> JB >> >> On Wed, Mar 25, 2026 at 12:57 PM Grzegorz Grzybek <[email protected]> >> wrote: >> >>> >>> >>> śr., 25 mar 2026 o 12:42 Ephemeris Lappis <[email protected]> >>> napisał(a): >>> >>>> Hello again. >>>> >>>> Just to be sure : pax jms uses the provider to create the actual >>>> connection factory, and in our case it's >>>> "org.apache.activelmq.ActiveMQConnectionFactory", and this implementation >>>> doesn't provide a "close" method, right ? >>>> >>> >>> Yes, correct... >>> >>> >>>> >>>> So,with no help from pw jms itself, how can we handle this, even if >>>> it's just a workaround ? I suppose we could code something to close >>>> connections, but how can we get reference on the pool or the connection >>>> factory ? >>>> >>> >>> You'd have to use OSGi service tracking to get a service of class >>> javax.jmx.ConnectionFactory - using "standard" OSGi ServiceTracker. Then >>> you'd have to do (I think) some reflection code to get the pool >>> details........ >>> >>> ~Grzegorz Grzybek >>> >>> >>>> >>>> Thanks again. >>>> >>>> >>>> Le mer. 25 mars 2026 à 12:22, Grzegorz Grzybek <[email protected]> >>>> a écrit : >>>> >>>>> Hello >>>>> >>>>> śr., 25 mar 2026 o 12:12 Ephemeris Lappis <[email protected]> >>>>> napisał(a): >>>>> >>>>>> Hello. >>>>>> >>>>>> Thanks for your answer... >>>>>> >>>>>> I don't actually understand when you say that application are in >>>>>> charge of closing connections : in ou world, application are Camel routes >>>>>> in feature that are all uninstalled when the pax jms itself is removing, >>>>>> and logs show clearly how routes are stopped and removed when each Camel >>>>>> feature is uninstalled. >>>>>> >>>>> >>>>> This is just a typical case - even with Camel - JMS connection is >>>>> taken from the pool, used and "closed" (which with the pool usually means >>>>> returning to the pool without closing it). >>>>> And I see that it may be a problem, because Pax JMS creates the pool >>>>> based on JMS provider specific implementation of >>>>> javax.jms.ConnectionFactory, but there's no "close" method on the >>>>> factory... >>>>> >>>>> I'm afraid this scenario would require extending generic Pax JMS >>>>> support for dynamic reconfiguration... >>>>> >>>>> regards >>>>> Grzegorz Grzybek >>>>> >>>>> >>>>>> >>>>>> When the pax-jms-config feature is removed, we expect that it delete >>>>>> the pool, and thus close any remaining connection, but in some random >>>>>> case, >>>>>> it doesn't do it, and when all the features are installed back, a new >>>>>> pool >>>>>> is created, and 256 connections are potentially added on the broker, >>>>>> until >>>>>> it fails... >>>>>> >>>>>> Thanks again. >>>>>> >>>>>> Le mer. 25 mars 2026 à 11:22, Grzegorz Grzybek <[email protected]> >>>>>> a écrit : >>>>>> >>>>>>> Hello >>>>>>> >>>>>>> While I was involved in maintenance of Pax JMS library I don't >>>>>>> remember any issues related to hanging connections... >>>>>>> >>>>>>> To be honest this project is in kind of awaiting state, almost >>>>>>> killed by the unnecessary move from "javax" to "jakarta"... There's >>>>>>> still >>>>>>> no jakarta.jmx version of this library (would require similar change in >>>>>>> Pax >>>>>>> Transx project..). >>>>>>> >>>>>>> I see that Pax JMS does some special treatment if the implementation >>>>>>> of javax.jms.ConnectionFactory is AutoCloseable, >>>>>>> but org.apache.activemq.ActiveMQConnectionFactory is not. >>>>>>> So it's the responsibility of the application to properly close the >>>>>>> connections... >>>>>>> >>>>>>> That's all I can help with ;( >>>>>>> >>>>>>> kind regards >>>>>>> Grzegorz Grzybek >>>>>>> >>>>>>> śr., 25 mar 2026 o 10:45 Ephemeris Lappis < >>>>>>> [email protected]> napisał(a): >>>>>>> >>>>>>>> Hello. >>>>>>>> >>>>>>>> We use pax-jms-config to manage JMS (ActiveMQ) connection >>>>>>>> factories. It basically works as expected, but we've recently observed >>>>>>>> a >>>>>>>> critical issue : it seems that with some unidentified conditions, when >>>>>>>> the >>>>>>>> features are installed/uninstalled, or connection factories cfg files >>>>>>>> updated, the current connections are not closed, and new ones are >>>>>>>> created. >>>>>>>> We can see the corresponding sockets on both Karaf and ActiveMQ (or in >>>>>>>> activemq console). When the maximum configured connection count is >>>>>>>> exceeded, all the system (including other JMS clients) fails. >>>>>>>> >>>>>>>> Is it a known issue ? If not, is there any way to force the jms >>>>>>>> pool to be cleaned ? >>>>>>>> >>>>>>>> Below are our feature structure and configuration file... >>>>>>>> Thanks again. >>>>>>>> >>>>>>>> Best regards. >>>>>>>> >>>>>>>> <?xml version="1.0" encoding="UTF-8" standalone="yes"?> >>>>>>>> >>>>>>>> <features >>>>>>>> >>>>>>>> xmlns="http://karaf.apache.org/xmlns/features/v1.6.0"; >>>>>>>> >>>>>>>> name="${project.artifactId}"> >>>>>>>> >>>>>>>> >>>>>>>> <repository> >>>>>>>> mvn:org.apache.activemq/activemq-karaf/${version.of.activemq}/xml/features >>>>>>>> </repository> >>>>>>>> >>>>>>>> >>>>>>>> <feature >>>>>>>> >>>>>>>> name="${project.artifactId}" >>>>>>>> >>>>>>>> version="${project.version}"> >>>>>>>> >>>>>>>> <feature prerequisite="true" version="${version.of.activemq}"> >>>>>>>> activemq-client</feature> >>>>>>>> >>>>>>>> <feature prerequisite="true">base-system</feature> >>>>>>>> >>>>>>>> <feature prerequisite="true">pax-jms-activemq</feature> >>>>>>>> >>>>>>>> <feature prerequisite="true">pax-jms-pool-pooledjms</feature> >>>>>>>> >>>>>>>> <feature prerequisite="true">pax-jms-config</feature> >>>>>>>> >>>>>>>> </feature> >>>>>>>> >>>>>>>> >>>>>>>> </features> >>>>>>>> >>>>>>>> >>>>>>>> # Connection configuration >>>>>>>> type=activemq >>>>>>>> connectionFactoryType=ConnectionFactory >>>>>>>> >>>>>>>> # Names >>>>>>>> name=xxx-jmsosgi.jndi.service.name=jms/xxx >>>>>>>> >>>>>>>> # Connection factory properties >>>>>>>> jms.url=tcp://amq-service:61616 >>>>>>>> jms.user=application >>>>>>>> jms.password=secret >>>>>>>> jms.clientIDPrefix=ID >>>>>>>> >>>>>>>> # Set XA transaction >>>>>>>> xa=false >>>>>>>> >>>>>>>> # Connection pooling >>>>>>>> pool=pooledjms >>>>>>>> pool.maxConnections=256 >>>>>>>> >>>>>>>>
