javalite | cohesive collection of frameworks | Web Framework library

Unfortunately, there was a defective snapshot published for a few hours. That snapshot v 3.0-SNAPSHOT had a bug where PostgreSQL syntax was accidentally made default for MySQL. It seems that it caused a problem for you. The JDBC connection pool has nothing to do with this. We are careful with snapshots, but things like this happens (once in a few years). You got unlucky by getting right in the middle of the update.

How to fix this is to blow away all your Maven caches:

First, if getting the metadata from your database takes 15 - 30 seconds per table, there must be something very wrong with that database. ActiveJDBC uses dynamic discovery in order to be in sync with the database on each start. This is the default behavior.

However, if you want, you can use the Static Metadata Generation. Using this method, all database metadata will be collected during a build time and will be packaged into your jar as a file. ActiveJDBC will then start instantly on all other environments because it will read metadata from this file rather than a database.

Obviously, you must ensure that the database at the build time has exactly the same schema as your other databases. If not, you will experience some mapping issues.

While the Static Metadata Generation will solve your startup performance issue, you still have a problem with your database, and I strongly suggest that you investigate that.

Note: the first implementation of ActiveJDBC was in 2009 for Humana and we used an Oracle database as well. Our schema at the time was about 120 tables, and ActiveJDBC always started lightning fast.

I created an example to test exactly the scenario you have. Fortunately, the JavaLite Migrator is working as expected.

Here is the link to the example: https://github.com/javalite/javalite-examples/tree/master/postgresql-example

No matter how many times you run the migrator, it works as expected every time:

Looks like the path of proto file is not correcttly. Try to move proto files to src/main/resouces/proto or set path in protobuf plugin configuration.

This is works well with kotlin DSL.

I loaded JavaLite into my IDE and reproduced some failures for the AsyncSpec test you linked. Here are my observations...

One thing that I noticed is that it's possible for some of your tests to leak brokers. Any test that has an assertion before the broker is stopped can leak if that assertion fails because the test will terminate without stopping the broker. This will negatively impact any tests that follow. You should stop your brokers in a finally block or perhaps in the @After method. In any case, you need to make absolutely sure that no matter what happens in the test the broker is stopped.

Your tests also leak journals. You create the embedded broker's journal directory using this:

Try to use the older Firebase library version. I had the same issue and it disappeared after I downgraded the Firebase version.

This is a perfect time asking this question. The release 2.4-j8 is in progress now, and will be available on Maven Central shortly. The release notes are here: https://github.com/javalite/javalite/releases, but the Releases page, JavaDoc and the blog will be updated later this week.

Here are some of the big things:

• https://javalite.io/validations
• https://javalite.io/processing_web_requests_implicit_conversion
• https://javalite.io/processing_web_requests_with_validation

There is a number of other smaller features and bugs there.

The version number dropped one number, with a previous release moving from 2.3.2-j8 to 2.4-j8.

Track the site for a blog later this week: https://javalite.io/blog

This release is for Java 8 only.

I just found a solution. It might not be optimal, but it works.

In my gradle file, I'm implementing those two:

I found a solution. I have created a third library with generator only and add it as a dependency to my libA and libB. This is not quite the correct architectural solution, but so far it works. I will work on the best solution.