I am using Hibernate 3.5.6 with Oracle 10g. I am seeing the below exception during initialization but the application itself is working fine. What is the cause for this exception? and how it can be corrected?
Exception
Disabling contextual LOB creation as createClob() method threw error : java.lang.reflect.InvocationTargetException
Info
Oracle version: Oracle Database 10g Enterprise Edition Release 10.2.0.4.0
JDBC driver: Oracle JDBC driver, version: 11.1.0.7.0
Disable this warning by adding property below.
For Spring application:
spring.jpa.properties.hibernate.temp.use_jdbc_metadata_defaults=false
Normal JPA:
hibernate.temp.use_jdbc_metadata_defaults=false
As you noticed, this exception isn't a real problem. It happens during the boot, when Hibernate tries to retrieve some meta information from the database. If this annoys you, you can disable it:
hibernate.temp.use_jdbc_metadata_defaults false
Looking at the comments in the source:
Basically here we are simply checking
whether we can call the
java.sql.Connection methods for LOB
creation added in JDBC 4. We not only
check whether the java.sql.Connection
declares these methods, but also
whether the actual java.sql.Connection
instance implements them (i.e. can be
called without simply throwing an
exception).
So, it's trying to determine if it can use some new JDBC 4 methods. I guess your driver may not support the new LOB creation method.
In order to hide the exception:
For Hibernate 5.2 (and Spring Boot 2.0), you can either use the use_jdbc_metadata_defaults property that the others pointed out:
# Meant to hide HHH000424: Disabling contextual LOB creation as createClob() method threw error
spring.jpa.properties.hibernate.temp.use_jdbc_metadata_defaults: false
Or, if you want to not have any side effects from the above setting (there's a comment warning us about some Oracle side effects, I don't know if it's valid or not), you can just disable the logging of the exception like this:
logging:
level:
# Hides HHH000424: Disabling contextual LOB creation as createClob() method threw error
org.hibernate.engine.jdbc.env.internal.LobCreatorBuilderImpl: WARN
To get rid of the exception
INFO - HHH000424: Disabling contextual LOB creation as createClob() method threw error :java.lang.reflect.InvocationTargetException
In hibernate.cfg.xml file Add below property
<property name="hibernate.temp.use_jdbc_metadata_defaults">false</property>
Update to this for using Hibernate 4.3.x / 5.0.x - you could just set this property to true:
<prop key="hibernate.jdbc.lob.non_contextual_creation">true</prop>
to get rid of that error message. Same effect but without the "threw exception" detail.
See LobCreatorBuilder source for details.
Just add below line in application.properties
spring.jpa.properties.hibernate.temp.use_jdbc_metadata_defaults: false
As mentioned in other comments using
hibernate.temp.use_jdbc_metadata_defaults = false
...will fix the annoying message, but can lead to many other surprising problems. Better solution is just to disable contextual LOB creation with this:
hibernate.jdbc.lob.non_contextual_creation = true
This will cause Hibernate (in my case, its 5.3.10.Final) to skip probing the JDBC driver and just output following message:
HHH000421: Disabling contextual LOB creation as hibernate.jdbc.lob.non_contextual_creation is true
So far it looks like this setting doesn't cause any problems.
Updating JDBC driver to the lastest version removed the nasty error message.
You can download it from here:
http://www.oracle.com/technetwork/database/enterprise-edition/jdbc-112010-090769.html
Free registration is required though.
If you set:
hibernate.temp.use_jdbc_metadata_defaults: false
it can cause you troubles with PostgreSQL when your table name contains reserved word like user. After insert it will try to find id sequence with:
select currval('"user"_id_seq');
which will obviously fail. This at least with Hibernate 5.2.13 and Spring Boot 2.0.0.RC1. Haven't found other way to prevent this message so now just ignoring it.
When working with Spring boot 2.1.x this warning message appears when starting up the application.
As indicated here, maybe this problem didn't show up in earlier versions because the related property was set to true by default and now it is false:
https://github.com/spring-projects/spring-boot/issues/12007
In consequence, solving this is as simple as adding the following property to the spring application.property file.
spring.jpa.properties.hibernate.jdbc.lob.non_contextual_creation = true
The problem occurs because of you didn't choose the appropriate JDBC. Just download and use the JDBC for oracle 10g rather than 11g.
I am using hibernate 5.3.17 and it works fine by adding given properties
hibernate.default_entity_mode=dynamic-map
hibernate.temp.use_jdbc_metadata_defaults=true
hibernate.jdbc.lob.non_contextual_creation = true
Thanks
I hit this error when my web app was started in Linux by user logged in with insufficient access rights. This error
org.hibernate.engine.jdbc.internal.LobCreatorBuilder - HHH000424:
Disabling contextual LOB creation as createClob() method threw error :
java.lang.reflect.InvocationTargetException
usually preceded by other errors / exceptions, especially from your application server i.e
for Tomcat:
org.apache.catalina.LifecycleException: Failed to initialize component ...
or
java.lang.UnsatisfiedLinkError: ... cannot open shared object file: No such file or directory
Solution:
Stop your web apps current instance.
Login with super user or those with sufficient access rights i.e root
Restart your web app or call previous function again.
For anyone who is facing this problem with Spring Boot 2
by default spring boot was using hibernate 5.3.x version, I have added following property in my pom.xml
<hibernate.version>5.4.2.Final</hibernate.version>
and error was gone. Reason for error is already explained in posts above
As mentioned by Jacek Prucia, setting the hibernate.temp.use_jdbc_metadata_defaults=false, will bring other "surprising problems", one of them is the batch inserts will stop working..
Remove #Temporal annotations if you use it with java.sql.* classes.
Check if you are not on a VPN. I had the same issue but realized the db I was connecting to remote!
Related
I am trying to upgrade to Hibernate 6, but this causes a huge amount of log spam. For every query with my database I get a warning in my console logs:
WARN deprecation:44 - HHH90000021:
Encountered deprecated setting [javax.persistence.lock.timeout], use [jakarta.persistence.lock.timeout] instead
Our code base does not reference javax.persistence.lock.timeout and setting the jakarta property into the peristence.xml file does nothing.
This issue doesn't seem to be documented on the internet, I could only find a single reference to this in a hibernate bug report team, but there are no details.
If its relevant, we are connecting to Postgres on AWS RDS, via the C3P0 connection pool.
This warning continues to appear after removing C3P0 from the server so I don't think this default is coming from there.
Should I just suppress this log source in my log properties file or are there alternatives others are following?
I also experienced the same issue. And it seems not to be fixed yet(in 6.0.1).
At least I see in https://github.com/hibernate/hibernate-orm/blob/c18e611ed6786fd62a6bf2d17c39589c2452fe35/hibernate-core/src/main/java/org/hibernate/internal/FastSessionServices.java that old (and deprecated) javax.* properties are still set and then logged by LegacySpecHelper:
p.putIfAbsent( AvailableSettings.FLUSH_MODE, FlushMode.AUTO.name() );
p.putIfAbsent( JPA_LOCK_SCOPE, PessimisticLockScope.EXTENDED.name() );
p.putIfAbsent( JAKARTA_LOCK_SCOPE, PessimisticLockScope.EXTENDED.name() );
p.putIfAbsent( JPA_LOCK_TIMEOUT, LockOptions.WAIT_FOREVER );
According to HHH-15768 it is going to be fixed in Hibernate 6.1.7.
A temporary workaround is to set the property explicitly (accepted modes are defined here):
spring.jpa.properties.jakarta.persistence.sharedCache.mode=ENABLE_SELECTIVE
More on the problem and the workaround - here
I hava a JavaEE application running on Payara 5 (initial release) and I'm trying to configure the fetch size of the Oracle JDBC driver (version 12.1.0.1.0). I can change the fetch size for individual queries with a query hint, however, I'm at a loss as to how I would set a default fetch size value for the whole application. According to the Oracle documentation it can be achieved by setting the defaultRowPrefetch JDBC property, but I don't see a way to set this from the domain.xml or persistence.xml. The following did not work:
configuring a property eclipselink.jdbc.property.defaultRowPrefetch in the persistence.xml has no effect
configuring a connectionAttributes property with a value of ;defaultRowPrefetch=100 or :100 on the connection pool also has no effect
configuring a connectionProperties property on the pool causes various exceptions on startup - I tried different syntax from various SO answers for the property value but that only changed what type of exception I got
What would be the correct way to configure the default fetch size?
According to this page [1] it does not work only by configuration.
You cannot set defaultRowPrefetch as a JVM property. It would have to be named
oracle.jdbc.defaultRowPrefetch for that to work. You can only use this property
by loading it into a Properties object in the code and then calling
getConnection with the Properties object.
Reason:
defaultRowPrefetch is a property of the connection and not of the
datasource
Maybe if you found the right place in the source code in Payara that does call getConnection() you can check whether there is the possibility to pass this via the domain.xml.
[1] https://www.ibm.com/support/pages/configuring-defaultrowprefetch-oracle-jdbc-driver
I'm trying to deploy an application to my GlassFish Server environment. I've set it up so that GlassFish creates a connection pool to a postgreSQL database on another server (not localhost) where the database is located. I test the connection and then try to deploy the application. It fails with a java.lang.RuntimeException: EJB Container initialization error, and my error log contains the following: http://ideone.com/UlZXut (put it here due to its size). There were other warnings above these, but they only referred to tables already existing.
As according to this, I thought that the required sun-cmp-mappings.xml file (the one I assume would be necessary for this correct mapping) would be automatically generated upon deployment, but it seems I was wrong. Could anyone shed some light on this situation?
My apologies if this is not the absolute best part of SE to post this, but it is related to development tools and I did see a number of related posts.
Your error log indicates that you are trying to create table(s) with DOUBLE as a datatype. In Postgresql, that datatype is actually called "double precision". What happens if you revise the table definition to use "double precision" instead?
on startup Glassfish tries to create the DB tables for your java code. It fails to do that and it fails to startup.
Check the configuration of your ORM mapper.
I am facing a peculiar issue. Below is the stack trace of what error i am getting.Please help.
Exception [TOPLINK-7001] (Oracle TopLink - 11g Release 1 (11.1.1.1.0) (Build 090527)): oracle.toplink.exceptions.ValidationException
Exception Description: You must login to the ServerSession before acquiring ClientSessions.
at oracle.toplink.exceptions.ValidationException.loginBeforeAllocatingClientSessions(ValidationException.java:1155)
at oracle.toplink.threetier.ServerSession.acquireClientSession(ServerSession.java:313)
at oracle.toplink.threetier.ServerSession.acquireClientSession(ServerSession.java:303)
at com.ofss.elcm.domain.Session.fetchClientSession(Session.java:113)
at com.ofss.elcm.domain.Session.acquireUnitOfWork(Session.java:132)
EclipseLink has the facility to check for classloader changes in cases of application redeployment. This can cause issues when calling into the SessionManager for a particular session from both a Web container and a EJB container.
Ensure that you are using the API getSession(null, sessionName, classLoader, true, false) or the same method with the longer signature to disable this classLoader checking. If you wish to construct a XMLSessionConfigLoader directly you can disable the classloader checking directly though xmlSessionConfigLoader.setShouldCheckClassLoader(false).
Did you try using the sessionmanager from a singleton object? That way, you should always get the same manager-instance and there should be no classloader-issues.
I'm getting the following exception when starting a Tomcat instance with my web app after upgrading to Hibernate 3.5.0:
org.hibernate.annotations.common.AssertionFailure: Fail to process type argument in a generic declaration. Type: class sun.reflect.generics.reflectiveObjects.ParameterizedTypeImpl
at org.hibernate.ejb.metamodel.AttributeFactory$PluralAttributeMetadataImpl.getClassFromGenericArgument(AttributeFactory.java:836)
at org.hibernate.ejb.metamodel.AttributeFactory$PluralAttributeMetadataImpl.getClassFromGenericArgument(AttributeFactory.java:833)
at org.hibernate.ejb.metamodel.AttributeFactory$PluralAttributeMetadataImpl.<init>(AttributeFactory.java:748)
at org.hibernate.ejb.metamodel.AttributeFactory$PluralAttributeMetadataImpl.<init>(AttributeFactory.java:723)
at org.hibernate.ejb.metamodel.AttributeFactory.determineAttributeMetadata(AttributeFactory.java:518)
at org.hibernate.ejb.metamodel.AttributeFactory.buildAttribute(AttributeFactory.java:93)
As this happens on Tomcat startup, I have no idea where to look in my code to prevent that :-(
Putting that error message into google would have shown you any number of explanations, including this JIRA issue:
http://opensource.atlassian.com/projects/hibernate/browse/HHH-5098