-
Notifications
You must be signed in to change notification settings - Fork 1.9k
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
HikariCP and c3po dependencies are in the compile scope #294
Comments
Hi @markkolich Thanks for reporting this issue. We added HikariCP-java6 to quartz-2.2.x series because we needed JDK6 compatible library. The quartz-2.3.x should have upgraded to HikariCP-java7 since that branch is required JDK7. But unfortunately quartz-2.3.0 was released without this fix. To resolve your issue, you can try 2 options:
Zemian |
Fixed in e0a1c79 |
Hi @markkolich , sorry I posted the wrong commit. It should be b194911 That's the commit that I added hikaricp JDK8 compatible on quartz-2.4.x branch, which is the option#2 solution I mentioned above. As I also mentioned in previous comment with option#1, you do have workaround to even use older release. |
@zemian thanks for the correction. I see that you upgraded HikariCP to However, I think my original concern still stands: HikariCP and c3p0 are still in the In other words, if I don't intend to use these features of Quartz (to interact with a database), do I still need these dependencies at all? Yes, I can add an exclusion in my pom, but that pushes the problem onto the user/consumer of Quartz. I think a much cleaner solution is to tell the users of this library "if you need to interact with a database, then you should add HikariCP to your pom". Or, "add c3p0 to your pom". Then in the Quartz pom, put these database dependencies in the <dependency>
<groupId>com.zaxxer</groupId>
<artifactId>HikariCP</artifactId>
<version>[2.3.0)</version>
<scope>provided</scope>
</dependency> In short, with this approach, if I want to use Quartz and I need Quartz to interact with a database, in my pom I will provide a compatible version of either HikariCP or c3p0. |
Hi @markkolich yes you are correct and the suggestion is good one too. I created a separate issue #306 as feature request for this. As it stand, the current Quartz made a conciseness choice (or in past) that coupled the two DB pool impl as static compile dependence. For convenience purpose I am sure. Not much we can do with those released artifacts. Maybe we can try to improve it in future. |
Hi @zemian, Thanks for all the information you provided. I am still facing an issue regarding this setup. I am using the following versions: My quartz.properties file looks like: My queries are:
Error creating bean with name 'schedulerFactoryBean' defined in ServletContext resource [/WEB-INF/servlet.xml]: Invocation of init method failed; nested exception is org.quartz.SchedulerException: ConnectionProvider class 'org.quartz.utils.HikariCpPoolingConnectionProvider' could not be instantiated. [See nested exception: java.lang.InstantiationException: org.quartz.utils.HikariCpPoolingConnectionProvider] Kindly Suggest. |
For me, it is solved by following this comment #126 (comment) |
I upgraded my project from Quartz 2.2.3 to 2.3.0 and suddenly started seeing this build failure from the Maven duplicate finder plugin, complaining of duplicate HikariCP classes on my classpath:
My Java 11 project directly uses
com.zaxxer:HikariCP:3.2.0
and I was surprised that a dependency was transitively pulling incom.zaxxer:HikariCP-java6:2.3.13
.With a little digging, it looks like @jhouserizer added a hard compile time dependency on
com.zaxxer:HikariCP-java6
under #126 which is the source of the duplicate classes:I could be wrong, but is
com.zaxxer:HikariCP-java6
(and the others) really required to use the Quartz scheduler? These dependencies appear to only be required if you intend to use a Quartz data source backed by an SQL database. For applications that are not using these features of Quartz, aren't these dependencies unnecessary?If so, shouldn't Quartz declare these "optional" run-time dependencies in the Maven
provided
oroptional
scope? Placing them in thecompile
scope forces consumers of Quartz to add exclusions in order to keep such conflicts out of the classpath. I would expect that if Quartz consumers need to use a DB data source in conjunction with a scheduler, then it should be on them to explicitly "provide" a compatible version of HikariCP (or c3p0 for that matter).E.g., from https://maven.apache.org/pom.html#Dependency_Version_Requirement_Specification perhaps
quartz-core/pom.xml
should have declared such dependencies as:Fwiw, @enwired had the same concern documented here #126 (comment).
The text was updated successfully, but these errors were encountered: