I've downloaded the drivers via Maven Central (org.apache.derby).
derby-10.15.1.3.jar
derbyclient-10.15.1.3.jar
derbynet-10.15.1.3.jar
derbyshared-10.15.1.3.jar
So what am I missing ? None of these JARs contains the package "org.apache.derby.jdbc", which used to contain the ClientDriver and EmbeddedDriver in the past?
Indeed, to use the Derby client driver with Derby 10.15, you now need all three of: derbyclient.jar, derbyshared.jar, and derbytools.jar. This is (weakly) documented here:
A new jar file (derbyshared.jar) has been added. All Derby
configurations require it. In addition, the derbytools.jar library is
now required when running the network server and/or when using Derby
DataSources.
Since you are running the network server, you now require derbytools.jar (as well as the new derbyshared.jar when running the client software.
I think it would be worth suggesting to the Derby community that the release note could make this stand out more clearly (you could file an improvement request with the Derby project, e.g.)
It looks like derbytools depends on derbyshared, so you don't have to list derbyshared as a dependency in your pom.xml (just derbytools).
However, this seems to work counter to how every other jdbc client works for every other database. Rather than updating documentation to say you have to include extra dependencies, Derby should make the derbyclient stand alone (better solution) or have the maven derbyclient depend on derbytools (so that when this dependency problem is fixed, people won't have to go back and update their pom.xmls to remove unneeded dependencies).
Related
I'm creating a Liferay 7.1 OSGi bundle, which has some external dependencies in it. In consideration of time, we opted to embed the external JAR in our OSGi Bundle. I've managed to create a bnd file, which includes all of the ElasticSearch dependencies, and put them on the bundle classpath. I've used the source-code from github (https://github.com/liferay/liferay-portal/blob/master/modules/apps/portal-search-elasticsearch6/portal-search-elasticsearch6-impl/build.gradle) and the bnd.bnd file, to check what's imported.
When activating the bundle, an exception is thrown:
The activate method has thrown an exception
java.util.ServiceConfigurationError: org.elasticsearch.common.xcontent.XContentBuilderExtension: Provider org.elasticsearch.common.xcontent.XContentElasticsearchExtension not a subtype
at java.util.ServiceLoader.fail(ServiceLoader.java:239)
at java.util.ServiceLoader.access$300(ServiceLoader.java:185)
at java.util.ServiceLoader$LazyIterator.nextService(ServiceLoader.java:376)
at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:404)
at java.util.ServiceLoader$1.next(ServiceLoader.java:480)
at org.elasticsearch.common.xcontent.XContentBuilder.<clinit>(XContentBuilder.java:118)
at org.elasticsearch.common.settings.Setting.arrayToParsableString(Setting.java:1257)
The XContentBuilderExtension is from the elasticsearch-x-content-6.5.0.jar,
the XContentElasticsearchExtension class, is included in the elasticsearch-6.5.0.jar. Both are Included Resources, and have been put on the classpath.
The Activate-method initializes a TransportClient in my other jar, hence it happens on activation ;).
Edit:
I've noticed that this error does NOT occur when installing this the first time, or when the portal restarts. So it only occurs when I uninstall and reinstall the bundle. (This is functionality I really prefer to have!). Maybe a stupid thought.. But could it be that there is some 'hanging thread'? That the bundle is not correctly installed, or that the TransportClient still is alive? I'm checking this out. Any hints are welcome!
Edit 2:
I'm fearing this is an incompatibility between SPI and OSGi? I've checked: The High Level Rest Client has the same issue. (But then with another Extension). I'm going to try the Low-Level Rest Client. This should work, as there are minimal dependencies, I'm guessing. I'm still very curious on why the incompatibility is there. I'm certainly no expert on OSGi, neither on SPI. (Time to learn new stuff!)
Seems like a case where OSGi uses your bundle to solve a dependency from another bundle, probably one that used your bundle to solve a package when the system started.
Looking at the symptoms: it does not occur when booting or restarts. Also it is not a subtype.
When OSGi uses that bundle to solve a dependency, it will keep a copy around, even when you remove it. When the bundle comes back a package that was previously used by another bundle may still be around and you can have the situation where a class used has two version of itself, from different classloaders, meaning they are not the same class and therefore, not a subtype.
Expose only the necessary to minimize the effects of this. Import only if needs importing. If you are using Liferay Gradle configuration to include the bundle inside, stop - it's a terrible way to include as it exposes a lot. If using the bnd file to include a resource and create an entry for the adicional classpath location, do not expose if not necessary. If you have several bundles using one as dependency, make sure about the version they use and if the exchange objects from the problematic class, if they do, than extra care is required.
PS: you can include attributes when exporting and/or importing in order to be more specific and avoid using packages from the wrong origin.
You can have 2 elastic search connections inside one Java app and Liferay is by default not exposing the connection that it holds.
A way around it is to rebuild the Liferay ES connector. It's not a big deal because you don't need to change the code only the OSGi descriptor to expose more services.
I did it in one POC project and worked fine. The tricky thing is to rebuild the Liferay jar but that was explained by Pettry by his google like search blog posts. https://community.liferay.com/blogs/-/blogs/creating-a-google-like-search (it is a series but it's kind of hard to navigate in the new Liferay blogs but Google will probably help) Either way it is all nicely documented here https://github.com/peerkar/liferay-gsearch
the only thing then what needs to be done is to add org.elasticsearch.* in the bnd.bnd file in the export section. You will then be able to work with the native elastic API.
I am not able to connect to my HSQLDB database from RazorSQL. I am only having this issue when I am running in Server mode and when I am attempting to connect from RazorSQL.
Using the same URL from Eclipse Data Source Explorer, and from the application itself (which is a Hibernate 5.2.7 application), I am able to successfully connect to my database at the URL "jdbc:hsqldb:hsql://localhost/SudokuHibernate". Since I am running it in Server mode, I am able to connect concurrently.
(Note: I don't have to have multiple concurrent connections, but it make debugging easier). The database is being run in Server mode from the command line via ...
java -cp ../libs/hsqldb-2.3.4/hsqldb/lib/hsqldb.jar org.hsqldb.server.Server --database.0 file:/Users/arick/src/databases/SudokuHibernate --dbname.0 SudokuHibernate
When attempting to connect from RazorSQL, the database console shows the error message. "org.hsqldb.HsqlException: Client driver version greater than '2.1.0.0' is required. The HSQLDB server version is '2.3.4'".
Note: This is a different question then a similar StackOverflow question, as all of my own configuration files are explicitly referencing the same JDBC driver, from the same jar file. However, as pointed out by Fred T, the reference to '2.1.0.0', by HSQLDB, is somewhat misleading. It is really just saying that the client and the server have two different versions of the JDBC driver.
At the same time that the database is throwing a mismatched version error, RazorSQL displays a dialog box with the error message:
ERROR: An error occurred while trying to make a connection to the database:
JDBC URL: jdbc:hsqldb:hsql://localhost/SudokuHibernate
connection exception: connection failure: java.io.EOFException
Below is my RazorSQL connection profile.
RazorSQL Profile
Driver Location: /Users/arick/src/libs/hsqldb-2.3.4/hsqldb/lib/hsqldb.jar
JDBC URL: jdbc:hsqldb:hsql://localhost/SudokuHibernate
As was inferred by Mark Rotteveel, the answer is similar to a related question about how to get Eclipse and Maven to talk to a HSQLDB server that is running in standalone server mode.
In that case, Fred Toussi, the lead on the HSQLDB project, pointed out the answer was to modify the configuration file, that is used in Eclipse and Maven, to pull in the appropriate version of the HSQLDB JDBC jar file, and also to make sure the jar file didn't appear anywhere else on the classpath. Maven uses a pom.xml file for configuration; so what was needed was make sure that the correct version of the HSQLDB was defined in the project's pom.xml file.
In my situation, the RazorSQL product that I was using, just happens to use HSQLDB as the embedded database for itself. If I had been using any other Java database, I may not have had this problem. But, since the RazorSQL product had already loaded its own version of the HSQLDB jar file, it didn't matter what I specified in my configuration for the database connection. It wasn't going to work.
No matter how I changed my driver profile, or my connection profile, the only version of the HSQLDB jar file that was going to get loaded, was the original jar file, that was already in use by RazorSQL, and that came with RazorSQL. (Note: This is true, unless RazorSQL gets fancy, and it decides to use a different classloader, and some of the other tricks that are commonly used by Java applications servers to solve these problems).
As per suggestion from Dan Richardson, from RazorSQL, the actual answer was not by modifying my configurations, but by changing the contents of the RazorSQL distribution itself. I needed to replace the jar file that is used by the RazorSQL application. This jar file is in Mac application folder for RazorSQL. This location is typically at /Applications/RazorSQL.app/Contents/Java/drivers/hsqldb.
(Note: If you are not familiar with how to open a Mac app folder, you just right-click on the RazorSQL folder name in the /Applications directory and use the "Show Package Contents" menu option). In my case, I renamed the original hsqldb.jar file to be hsqldb_2.3.2.jar file, and then I copied in the last distribution of the hsqldb.jar.
This link explains the new things about WildFly. Under the Migrating The Database Connection -> JDBC Driver the article explains about two ways of using jdbc drivers for the applications. I tried with installing it as a module and it works fine. The problem is which way is better and when it is better, whether deploy it as any other application package or install it as a module?
(I noted that install it as a module is necessary for clustered environment. I am looking for, are there any other reasons?)
I think the correct link to the article you are referencing is this one : http://wildfly.org/news/2014/02/06/GlassFish-to-WildFly-migration/
(The other one does not seem to point to the article you are mentioning)
Below is the interesting part from "Migrating The Database Connection" section you are referencing:
On WildFly, you have two ways of installing the JDBC driver: whether
you deploy it as any other application package or you install it as a
module. You can always choose to deploy the driver, but it’s specially
recommend when you have a cluster environment, since the deployments
are automatically propagated in the server groups.
You may have issues with the deployment if the driver is not
JDBC4-compliant. In this case, installing the driver as a module
solves those issues. The advantage of the JDBC driver as a module is
the possibility of creating a custom WildFly bundle for your
organization. This way, you can repeat exactly the same installation
throughout several machines, preserving the same configuration. This
is perfect for the development environment.
So in this section, the author describes the following advantage:
You may have issues with the deployment if the driver is not JDBC4-compliant. In this case, installing the driver as a module solves those issues.
The following Wildfly documentation describes this also:
Any JDBC 4-compliant driver will automatically be recognized and installed into the system by name and version. A JDBC JAR is identified using the Java service provider mechanism. Such JARs will contain a text a file named META-INF/services/java.sql.Driver, which contains the name of the class(es) of the Drivers which exist in that JAR. If your JDBC driver JAR is not JDBC 4-compliant, it can be made deployable in one of a few ways. (...)
Thus, deploying your driver as a module is easier than deploying it as any other application package in case it is not JDBC-4 compliant. (Because you would have to modify and rebuild your JDBC-4 not compliant jar to deploy it as any other application package)
I am using Netbeans as my IDE, currently developing an Web app using:
Spring 3
Hibernate 3
MySQL
I'm relying on netbeans to build the project(in contrast to others using maven). On deployment, the console shows this error:
...noClassDefFoundError: com/mchange/v2/c3p0/DataSources
I've already added the jar file to the Hibernate library.
(And oh, this is my first time asking here. Needed 10 points to post the screenshot.)
So I'm confused why would it need THAT class. (whatever that class does.)
Ideas why did this happen?
I've finally manage to solve the problem. The c3p0 distribution has 3 .jar files on the lib directory. I initially added the "c3p0*.jar" only. Which in turn produces the error.
It needs the OTHER jar file, mchange-commons*.jar in the directory. Hope this helps to others stuck in here.
Download this jar mchange-commons-java-0.2.3.4.jar. This helps me to resolve the issue.
C3P0 is used to support connection pooling. See http://www.mchange.com/projects/c3p0/ for further information on C3P0 and https://community.jboss.org/wiki/HowToConfigureTheC3P0ConnectionPool for information on configuring C3P0 with Hibernate.
Add this jar file "c3p0-0.9.2.1.jar" to library
If you are still getting the error, you need to remove and add again Hibernate library because this "c3p0-0.9.2.1.jar" is conflict version with c3p0 in Hibernate library
I have a Maven 3 project that uses Hibernate 3. In the Hibernate properties file, there is an entry for hibernate.connection.provider_class with the class corresponding to the C3P0 connection provider (org.hibernate.connection.C3P0ConnectionProvider). Obviously, this class is only used at runtime, so I don't need to add the corresponding dependency in my POM with the compile scope. Now, I want to give the possibility to use any connection pooling framework desired, so I also don't add a runtime dependency to the POM.
What is the best practice?
I thought about adding an entry to the classpath corresponding to the runtime dependency (in this case, hibernate-c3p0) when the application is run (for example, using the command line). But, I don't know if it's possible.
This is almost (maybe exactly) the same problem as with SLF4J. I don't know if Hibernate also uses the facade pattern for connection pooling.
Thanks
Since your code doesn't depend on the connection pooling (neither the main code nor the tests need it), there is no point to mention the dependency anywhere.
If anyone should mention it, then that would be Hibernate because Hibernate offers this feature in its config.
But you can add it to your POM with optional: true to indicate:
I support this feature
If you use it, then I recommend this framework and this version
That will make life slightly more simple for consumers of your project.
But overall, you should not mention features provided/needed by other projects unless they have some impact on your code (like when you offer a more simple way to configure connection pooling for Hibernate).
[EDIT] Your main concern is probably how to configure the project for QA. The technical term for this new movement is "DevOps" - instead of producing a dump WAR which the customer (QA) has to configure painstakingly, configuration is part of the development process just like everything else. What you pass on is a completely configured, ready-to-run setup.
To implement this, create another Maven module called "project-qa" which depends on your project and everything else you need to turn the dead code into a running application (so it will depend on DBCP plus it will contain all the necessary config files).
Maven supports overlayed WARs which will allow you to implement this painlessly.
You can mark your dependency as optional. In this case it will not be packaged into archives. In this case you have to ensure that your container provides required library.
You could use a different profile for each connection provider. In each profile you put the runtime dependency that correspond to the connection provider you want to use and change the hibernate.connection.provider_class property accordingly.
For more details about how to configure dependencies in profiles, see Different dependencies for different build profiles in maven.
To see how to change the value of the hibernate.connection.provider_class property see How can I change a .properties file in maven depending on my profile?