Without the information I gleaned from the error message, I could not have solved the problem.

Generaly speaking, cranking up logging (at which point you would see much more detail about the problem) should generally be a first step in trying to track down problems.

We do log it. You just aren't happy with the level. But put the shoe on the other foot - say you are in an environment where there are 3 JPA providers present. Further, say Hibernate is the first one tried. But this condition happens. But say another provider can build the EMF. This is exactly the way JPA expects this to happen. But now, if we increased this logging to ERROR, this user would also start seeing ERROR messages, even though clearly its not an "error" for them.

I'm using this call because I need to override some of the connection properties set in the persistence.xml file.

At the end of the day, all of these calls route to some Hibernate-specific calls. Obviously if you can do something through the JPA APIs you can accomplish the same through Hibernate's APIs as well. E.g., you could use on of the overloaded org.hibernate.jpa.boot.spi.Bootstrap#getEntityManagerFactoryBuilder methods to use the Hibernate specific calls and get exactly what you want.