Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

It would be very nice if derby could be updated #364

Open
steinarb opened this issue Apr 6, 2024 · 4 comments
Open

It would be very nice if derby could be updated #364

steinarb opened this issue Apr 6, 2024 · 4 comments

Comments

@steinarb
Copy link

steinarb commented Apr 6, 2024

It would be nice if derby could be updated from the now 6 year old 10.14.2.0.

I did a quick search through the closed issues and found this (JDK 8 compatibility keeps derby at 10.: #351 (comment)

And I had already guessed from the release notes that JDK 8 was the reason for staying with ths version

But the derby version is 6 years old now. Maybe it is time to let JDK 8 compatibility go? Are there many people requesting and requiring it?

My problem: I use pax jdbc-config to provide me with a Datasource from config and has used this to run my applications with PostgreSQL as the production database, and using in-memory derby with dummy data for testing in local karaf and in pax exam integraion tests.

However, with a liquibase upgrade a while back my pax exam tests started breaking: liquibase/liquibase#5357

Funnily enough using derby in real karaf (rather than pax exam karaf) worked fine, so it wasn't possible to debug this. I suspect a race condition somewhere.

A fix was introduced in liquibase and the above issue was closed, but the fix wasn't consistent (testing with liquibase 4.26.0 it worked one time out of 5 tries, I think...?) and with 4.27.0 the problem has starting breaking the pax exam tests not just of the liquibase karaf feature, but of my web applications using liquibase as well.

My workaround for the liquibase karaf feature pax exam test was to throw out derby and replace it with h2 (at least for the pax exam test).

@grgrzybek
Copy link
Member

Thanks for the report and some nice arguments.

Actually we should be able to preserve JDK8 compatibility where possible and simply highlight that some Karaf features (and JDBC drivers) require newer JDK. maven-compiler-plugin can stay at JDK8 (because we have no reason to upgrade Java source code to newer features), but drivers should be upgraded. No need to stay at ancient Derby version...

Please give me some time to think and prepare an update.

@steinarb
Copy link
Author

steinarb commented Apr 10, 2024

A note on using derby Use derby 10.16.1.1 (which is the current version for Java 17): it has a completely broken OSGi support

  1. Compared to 10.14.2.0 the 10.16.1.1 has been split up into multiple jar files
  2. artifactId derby is an OSGi bundle with an Activator, but what that Actvator does I'm unsure about (looks like it registers a Driver with some static class, but that won't work in OSGi unless that class is part of the JRE...), no DataSource or DataSourceFactory in this class
  3. The DataSourceFactory for embedded derby resides in the jar file with artifactId derbytools, this jar file isn't a bundle so if you want something from here you will need to slurp the class files into the bundle
  4. The embedded DataSourceFactory relies on stuff from package org.apache.derby.client
  5. The org.apache.derby.client package resides in the jar file with artifactId derbyclient, however the derbyclient is a bundle, but one that doesn't export the packages it contains (it exports package org.apache.derby.jdbc, which it does not contain)

So in conclusion: derby has OSGi support that is thoroughly broken.

Only way to fix it is to pull everything into the jar creating the DataSourceFactory, or rebundle the derby jars (or create an issue with derby and provide a fix for OSGi bundling everything).

But the problem with providing a fix was that I couldn't make heads or tails of the build system of derby. There was an and build and there was a maven build in a completely separate place to the source code

Oh well!

@grgrzybek
Copy link
Member

But the problem with providing a fix was that I couldn't make heads or tails of the build system of derby.

Still ANT-based? :)

@steinarb
Copy link
Author

steinarb commented Apr 11, 2024 via email

odl-github pushed a commit to opendaylight/odlparent that referenced this issue Aug 27, 2024
Drop FIXME for ODLPARENT-311 because its not feasible for us to adapt
new derby version:
- Even current main branch of pax-jdb (1.5.8-SNAPSHOT) supports Java 8
and uses derby version 10.14.2.0
- In addition, it seems that OSGi support in derby in recent versions
is "broken": see ops4j/org.ops4j.pax.jdbc#364

In addition, we have concluded to remove not-needed dependencies in
ODLPARENT-309.

JIRA: ODLPARENT-311
Change-Id: I964170899cdf8303e556a274556ada116c515cb0
Signed-off-by: Ivan Hrasko <[email protected]>
odl-github pushed a commit to opendaylight/odlparent that referenced this issue Aug 28, 2024
Drop FIXME for ODLPARENT-311 because its not feasible for us to adapt
new derby version:
- Even current main branch of pax-jdb (1.5.8-SNAPSHOT) supports Java 8
and uses derby version 10.14.2.0
- In addition, it seems that OSGi support in derby in recent versions
is "broken": see ops4j/org.ops4j.pax.jdbc#364

In addition, we have concluded to remove not-needed dependencies in
ODLPARENT-309.

JIRA: ODLPARENT-311
Change-Id: I964170899cdf8303e556a274556ada116c515cb0
Signed-off-by: Ivan Hrasko <[email protected]>
(cherry picked from commit a5298cb)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants