Hi all, A quick update: the PR removing the JDBC OSGi/Karaf support has now been merged:
https://github.com/apache/iotdb/pull/18719 Thank you, Zihan, for the detailed investigation, end-to-end verification, and review. Thanks everyone for the discussion and feedback. Best regards, Haonan Hou On 2026/09/28 08:09:56 Haonan Hou wrote: > 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 > > > > > >
