Recently, in my machine, every time I try to load a java project with Liquibase I get the error
Caused by: liquibase.exception.UnexpectedLiquibaseException: Cannot find ChangeLogHistoryService for oracle
at liquibase.changelog.ChangeLogHistoryServiceFactory.getChangeLogService(ChangeLogHistoryServiceFactory.java:73)
at liquibase.Liquibase.checkLiquibaseTables(Liquibase.java:724)
I can't find any information on this, beyond the source file.
All I know is that the same project, with the same source code seems to work on other computers. As far as I can tell, all configs are the same.
Any idea on what might cause this issue in the first place?
It means that one of the tables that Liquibase expects to find in the database (liquibasechangelog or liquibasechangeloglock) has been removed. If it is working on other machines it probably means that the database you are connecting to is also different. It sounds like you might be trying to connect to the database on localhost, which would explain the difference.
The error looks more like a classloader issue. Liquibase has a plug-in system that relies on finding class implementations in the classpath, including the built-in classes. Liquibase is looking for an implementation of ChangeLogHistoryService that support oracle and it isn't finding the liquibase.changelog.StandardChangeLogHistoryService class that it should be.
Are there any earlier errors you are seeing? If you run liquibase with logLevel=DEBUG it may also output better clues as to the cause of the unfound class.
I updated the liquibase version (from 3.1.1) to 3.2.0 and the problem went away.
I did have to fix SOME of the checksome codes in DATABASECHANGELOG table (3 records in 16). The fact that it wasn´t all of them may point to a possible origin for the problem? maybe?
For now everything works fine with the new version. If the problem comes up again in the future I will look into this again.
Thank you all for your support.
Related
I am developing an application, and I don't want people decompiling it and stealing the code. Everything converts fine in ProGuard, but one problem I have is that when I try use it when it's obfuscated, the MySQL connection fails. This application relies heavily on MySQL for security reasons.
I took a little bit of time to debug, and ran it with a .bat file, and I got this error:
java.sql.SQLException: defaultAuthenticationPlugin 'com.mysql.jdbc.authentication.MysqlNativePasswordPlugin' is not listed in "authenticationPlugins" nor it is one of the built-in plugins.
To make a long story short, the MySQL works when it isn't obfuscated but it doesn't work when it is. Please help!
Thanks in advance,
Luaq
The problem might be happening because
the classes that implement com.mysql.jdbc.AuthenticationPlugin and which will be used for authentication
are being obfuscated, and MySQL cannot find them anymore due to the name changes. Try keeping the classes that MySQL uses and only obfuscate the fields and methods that are not used directly by MySQL in them.
I'm currently learning to use maven, I understood how to create a maven project using dependencies from maven repository - and now I have the following question:
If I have an application which uses a database access, for example via Hibernate, then I need to add a dependency representing the corresponding database driver, for example mysql-connector-java for MySql, ojdbc for Oracle and so on.
But what if I want the program to run on a different machine and I don't know what database engine it uses? What is the common way to solve this? Just import all possible drivers as dependencies? Or is there a more elegant way?
Using a ORM (Object Relational Mapping) like Hibernate is the best solution since you write Java code that will be interpreted by Hibernate and translated into SQL queries.
At some point, you will have to decide which database are you going to use, then you will have to add the driver.
Another solution can be making configurations for different environments using maven: https://maven.apache.org/guides/mini/guide-building-for-different-environments.html
The problem is not particularly maven bound. Whenever you move to a new database, the administrator would have to use the correct JDBC driver according to DB, and yes, it requires different jar files.
The thing is, that you don't want to bundle the database jar file with your code. It may already exist (e.g. in the application server) or you may specify a path to drop it during installation.
Assuming you are creating a webapp. If you bundle a war-file with maven, it will include all dependencies inside the war file, so you must specify that the dependency is there during compilation and testing, but not in any package. The way to do so, is by specifying it as provided
<dependency>
<groupId>some.db</groupId>
<artifactId>jdbc-driver<artifactId>
<scope>provided</scope>
</dependency>
This means that the jar file will exist on the target platform, and hence, should not be packaged in a any bundle.
So the assumption I make is really, is this a web-app? Or is it standalone? Anyway, hope it helps.
You don't need a dependency at all. What you need is a driver to be available at runtime. It's true that one way to do this is with a dependency, but if you don't know the database you can't really bundle everything in there. You could stick some most common drivers, but then as said there would be licensing issues.
If you're talking about a web application, you could just tell the user to get the appropriate driver and configure a JNDI datasource that the software uses. This is/was a standard from back in the days, but it assumes that the application is a webapp and the end user knows how to configure things (although if he doesn't, he probably shouldn't be setting up the system in the first place).
For a standalone program using a local database, you have the easy choice of using an in memory database like H2 and not allowing any other databases. Naturally this case doesn't work for everything, but I'm including it as an example. In any case it would boil down to the same as with a webapp. Have the end user get the correct driver. If they're running a database server and your app, they should be able to find the right driver too. Then you just need to make sure it's included in the runtime classpath, which might be a bit harder.
The way this is done by SquirrelSQL for example, is by explicitly selecting the drivers as shown in the below picture. This of course again means the user needs to understand what he's doing.
I assume that you want everything to happen automagically and you're not too eager to instruct each user/machine admin how to configure system to have your app working. I am afraid it is not possible in the way you might have hoped.
The standalone database solution that Kayaman suggested might be the best solution in your case but hard to say without knowing further.
However here are some aspects regarding using maven and possible difficulties with some notes.
If I have an application which uses a database access, for example via
Hibernate, then I need to add a dependency representing the
corresponding database driver, for example mysql-connector-java for
MySql, ojdbc for Oracle and so on.
Yes. And you also would need to tell hibernate about this Driver and perhaps other stuff related. It is not just adding dependency but also filtering some prop file or persistence.xml. That might be a job for maven and some of its plugins. But still it would require knowledge about all the possible db alternatives and maven profiles for each of those to handle them.
But what if I want the program to run on a different machine and I
don't know what databse it uses? What is the common way to solve this?
What options do I have? Just import all possible drivers as
dependencies? Is there a more elegant way?
All programs have dependencies. Was it related to DB or not. In a sense as other answers suggest this is not maven specific (but quite related still! ) thing. You need to be aware of the requirements of any environment if you really want to develop on the level of JDBC drivers.
This specific question of yours is something that - I believe - is the motivation to develop things like:
ODBC
JNDI
NOTE 1 even similar naming ODBC & JDBC are totally in different level (I mean how JDBC drivers are found which actually might be the main problem...)
NOTE 2 JNDI is not restricted to DataSources
However maven can be a great help depending on what you need and finally decide to do. But not in so big role if you can use ODBC / JNDI.
I'm trying to do some crawling with Nutch and I'd like to test out Cassandra as a backend, however using the latest version of nutch and its dependencies Cassandra throws a variety of errors as you move through the inject, generate, fetch, etc. process.
The errors are all related to actual problems in code, not out of memory or configuration. I've fixed some of them by modifying code within gora-cassandra, but it's still not functional.
My question is, does a working version of these 2 projects exist? By working i mean you can run through inject, generate, fech, parse, updatedb on at least a small set of urls, without error.
Here's an example of one of the classes giving an error during fetch:
java.lang.NullPointerException
at org.apache.gora.cassandra.query.CassandraSuperColumn.getUnionIndex
I have used HBase as the backend and that just works, although HBase itself is a monster to manage so that's why i'd like to test out Cassandra. However, i'm about to give up on this as I don't think I should be having to modify gora-cassandra code just to get a basic example to run.
Thanks
According to this link it's just broken, which is about 3 months old http://lucene.472066.n3.nabble.com/Re-user-Digest-3-Jun-2017-19-27-20-0000-Issue-2758-td4339060.html
Its unclear why backends that do not work are even documented.
HBase is most widely used, followed by MongoDB... on the other end of
the spectrum, Cassandra is least used and broken. It has not been
maintained for quite some time... and yes this is reflected by use of
Super Columns. We are currently re-writing the backend as part of a
GSoC project.
I would agree with the guy making the original statement, Its unclear why backends that do not work are even documented.
Really tired of this project and its lack usable documentation.
I'm working on a small REST application server and I'm trying to be able to save a Java bean using DataNucleus JDO with MySQL.
My only problem is that I can't find any examples of any application that uses DataNucleus JDO and is built using Gradle.
I'm new to using Java and I have essentially no idea how to go about doing this. At this moment I'm just considering going with Hibernate JPA instead but I feel like JDO would be better for me in the long run. I would really appreciate any help pointing me in the right direction.
I followed Adrian's solution I found here with a minor edit: I modified the task to depend on processResources instead of compileJava and made classes depend on datanucleusEnhance, otherwise it didn't work for me.
I would normally tell you the error I got but I couldn't see the enhancer's error output.
The solution essentially calls an ant task to enhance the classes instead of using Gradle only. It's not the most elegant but it worked.
I can't be the only person who has this problem so I am looking for suggestions.
We run our apps on Oracle but our integration tests use h2 for speedy in-memory testing, the database being built from DDL scripts at the start of testing.
The problem is that the use/syntax of some DDL commands differs between Oracle and h2/hsqldb. For example today I spent some time before I realised that 'grant select on ...' works on sequences in Oracle but only on tables in h2.
In a previous project we had an adapter to remove/translate such erroneous commands, which meant that our test database ran quite different code to that we implement to prod. While everything is very thoroughly acceptance tested it means that certain problems might not be spotted until quite late on in the dev cycle.
On my latest project I sense I am going down the same path - so surely others must also have trodden it.
Any suggestions? We're using java/maven so appropriate soutions welcome!
There isn't such an adapter to my knowledge.
Anyway, I'd say that you're not going to achieve your goals with such an adapter. For one, the feature set of Oracle is not easily found in any other solution ( not that that's necessarily an advantage for Oracle).