Hi Zihan, Thank you for the detailed investigation and for verifying the integration in a current Karaf environment.
Given the long-standing packaging and dependency issues, as well as the lack of known active users, I have opened a PR to remove the JDBC OSGi/Karaf support: https://github.com/apache/iotdb/pull/18719 The standard JDBC driver registration and usage remain unchanged. Reviews and comments are very welcome. If anyone is still relying on this integration, please also let us know. Best regards, Haonan On 2026/09/28 07:19:50 Zh D wrote: > Hi Haonan, > > On whether the feature still works in a current OSGi/Karaf environment: > I tried it, and it does not. All of the failures are in packaging, > though. Once they are worked around, the driver itself works. The > details are below in case they help with choosing an option. > > Setup: Apache Karaf 4.4.11 on Java 17, an empty local Maven repository, > and the 2.0.11 artifacts from Maven Central. > > 1. The published feature cannot be installed > -------------------------------------------- > > "feature:repo-add mvn:org.apache.iotdb/iotdb-jdbc/2.0.11/xml/features" > succeeds. "feature:install iotdb-feature" then fails for every IoTDB > bundle with > > Error downloading ...iotdb-jdbc-2.0.11.jar${project.version} > > The published iotdb-jdbc-2.0.11-features.xml still contains the literal > ${project.version}. This began in 2.0.8. The files for 2.0.7 and > earlier have the version filled in. The cause is two changes from > September 2025 that met each other. #16484 moved the filtered copy to > target/classes/feature, so it now ships inside the jar, correctly > filtered. #16487 then attached src/main/feature/feature.xml, the > unfiltered source, as the "features" artifact. > > Separately, the last release of org.apache.iotdb:tsfile on Central is > 1.3.2, and the last of hadoop-tsfile is 2.0.3. So since 1.3.3 the > feature has pointed to at least one artifact that does not exist. That > matches what you found about the coordinates. > > 2. With correct coordinates, the bundles still do not resolve > ------------------------------------------------------------- > > I installed the bundles one by one: tsfile 2.4.0 from org.apache.tsfile, > libthrift 0.23.0, and service-rpc, iotdb-thrift and iotdb-jdbc 2.0.11. > Resolution fails in three places: > > - service-rpc imports org.apache.thrift.transport.layered, for > TFramedTransport. libthrift does not export that package. The > classes are in the jar, but thrift's Export-Package is a > hand-written list in lib/java/gradle/sourceConfiguration.gradle > and "layered" is missing from it. THRIFT-5400 fixed the same kind > of omission for .annotation. None of the 14 libthrift releases > from 0.14.0 to 0.24.0 export it. Every service-rpc release since > 0.12.1, the first one built on Thrift 0.14, imports it. So against > the libthrift jar on Central, the JDBC bundle could not resolve in > any release since 0.12.1 (June 2021). > > - tsfile 2.4.0 has a mandatory import of com.sun.management, which > Karaf does not export by default. lz4-java 1.10.1 (at.yawk.lz4) > has no Export-Package at all. > > - iotdb-thrift-commons and pax-jdbc-common 1.5.6 are plain jars and > have to be installed with wrap:. > > 3. With those worked around, the driver works > --------------------------------------------- > > I added com.sun.management to org.osgi.framework.system.packages.extra. > I re-wrapped libthrift and lz4-java so that they export their packages, > and wrapped the two plain jars. After that, every bundle starts. > iotdb-jdbc registers its DataSourceFactory ("jdbc:ds-factories" lists > "iotdb"). I then created a data source with "jdbc:ds-create" against a > 2.0.11 standalone server. Through it, "show version", an insert and a > select all worked, and the release CLI read back the same row. > > So the Java side (Activator, IoTDBDataSourceFactory) is fine. What stops > it from working is our packaging plus the manifests of two third-party > jars. > > History > ------- > > The integration came from #952 in April 2020. Its author, Etienne > Robinet, was running Camel routes inside Karaf. His companion IoTDB > module for pax-jdbc (ops4j/org.ops4j.pax.jdbc#57) is still open and was > never merged. Cesar Garcia also used the driver from the Karaf console > in 2020, as his posts on this list show. I found no report about OSGi > or Karaf in JIRA or in GitHub issues, and no one on dev@ has written > about running it since 2020. > > My view > ------- > > +1 to option 2 as the immediate step. For five years no release could > resolve against the libthrift jar on Central, and nobody reported it. > Given that, I think it is reasonable to follow with option 3. If someone > does want to keep the integration, the list above is roughly the work. > We would need to fix the attached features file and its coordinates, > and deal with libthrift (either re-wrap it in the feature or get > Thrift to export the package). The tsfile and lz4 imports would also > need handling. I am happy to help with whichever direction is chosen. > > Thanks, > Zihan Dai > > On Thu, Sep 24, 2026 02:34 AM, Haonan Hou <[email protected]> wrote: > > > Hi all, > > > > While reviewing third-party dependencies included in the IoTDB binary > > distribution, I noticed that the CLI package brings in the following > > dependencies transitively through iotdb-jdbc: > > > > - org.osgi:osgi.core > > - org.osgi:osgi.cmpn > > - org.ops4j.pax.jdbc:pax-jdbc-common > > > > These dependencies are used by the OSGi integration in the JDBC module, > > mainly through: > > > > - org.apache.iotdb.jdbc.Activator > > - org.apache.iotdb.jdbc.IoTDBDataSourceFactory > > - the OSGi Declarative Services annotation on IoTDBDriver > > - the Karaf feature descriptor under > > iotdb-client/jdbc/src/main/feature/feature.xml > > > > The regular CLI does not use the OSGi service. It loads IoTDBDriver > > through Class.forName() and obtains connections through DriverManager. > > > > As a local check, I removed the three OSGi/Pax jars from the all-in-one > > distribution and verified that the CLI could still load the JDBC driver, > > print its help output, and enter the normal connection path without > > class-loading errors. > > > > During the investigation, I also found some signs that the OSGi/Karaf > > support may no longer be actively maintained: > > > > 1. The Karaf feature descriptor refers to artifacts such as: > > > > mvn:org.apache.iotdb/tsfile/${project.version} > > mvn:org.apache.iotdb/hadoop-tsfile/${project.version} > > > > These coordinates do not appear to match the current module and > > dependency structure. In particular, TsFile now uses the org.apache.tsfile > > group ID. > > > > 2. The feature descriptor uses pax-jdbc-common 1.4.5, while the current > > Maven dependency is 1.5.6. Some other dependency versions in the descriptor > > also appear outdated. > > > > 3. I could not find tests that start an OSGi framework, install the JDBC > > bundle or Karaf feature, and verify that the JDBC DataSourceFactory service > > is registered and usable. > > > > Therefore, the source code and OSGi metadata are still present, but it is > > unclear whether the feature works in a current OSGi/Karaf environment or > > whether there are still users relying on it. > > > > I would like to discuss which direction we should take: > > > > 1. Continue maintaining OSGi support > > > > Update the Karaf feature descriptor, verify all bundle dependencies and > > package imports, and add an integration test that installs and starts the > > JDBC bundle and checks the registered JDBC services. > > > > 2. Keep it, but separate it from the regular distribution > > > > Preserve OSGi support in the JDBC artifact, but exclude the OSGi/Pax > > runtime jars from the CLI and all-in-one distributions. OSGi users would > > obtain the required dependencies through their OSGi/Karaf environment. > > > > 3. Deprecate and eventually remove it > > > > Mark the OSGi-specific API and packaging as deprecated, ask users to > > provide feedback during a deprecation period, and remove the Activator, > > DataSourceFactory integration, Karaf feature descriptor, and related > > dependencies in a later release. > > > > My initial preference is option 2 as an immediate, low-risk cleanup: the > > CLI does not need these dependencies, while the published JDBC artifact can > > retain its existing OSGi metadata. > > > > In parallel, if no active users or maintainers can be identified, we could > > consider deprecating the OSGi integration before removing it in a future > > release. > > > > Does anyone know of current deployments using the IoTDB JDBC driver > > through OSGi, Apache Karaf, or Pax JDBC? Is anyone interested in > > maintaining and testing this integration? > > > > Any feedback or historical context would be appreciated. > > > > Best regards, > > Haonan Hou > > >
