I am trying to Upgrade my Spring 1.9 Application to Spring 4 and therefore I also have to upgrade Hibernate. As database I am using Oracle.
When starting the application everything is fine until I am using Clobs, then the following Exception is thrown:
java.lang.AbstractMethodError:org.jboss.resource.adapter.jdbc.jdk5.WrappedPreparedStatementJDK5.setCharacterStream(ILjava/io/Reader;J)V
I also already upgradet my JDBC driver, does anyone have hint, what else to try?
The problem is the jboss-common-jdbc-wrapper.jar located under ${JBOSS_HOME}\common\lib obviously it was implemented against an Interface which was created in a version which is less then JDK_1.6. Therefore the method was never implemented though.
After replacing this Jar, with the same vom a JBoss AS 6.1 everything is working fine.
BR
Related
I am porting an old IBM Process Server application to IBM WebSphere Liberty. It contains a lot of code based on Service Data Objects (SDO). I have some good working code, running as standalone Java, using JDK8. I am using eclipselink 2.7.7, specifically 2 jar files;
eclipselink.jar
commonj.sdo_2.1.1v20111051852.jar
I have built this code into a Servlet to handle SOAP requests, and packaged it, along with other code, into an EAR file, which I deployed under IBM WebSphere Liberty 20. It doesn't work. There seems to be a clash with the Liberty version of EclipseLink.
If I deploy the code as a WAR file, and add a classloader of "PARENT_LAST", the code works fine.
However, if I try to deploy the code in an EAR file, and set a classloader of "PARENT_LAST" for the ear file, I get this error;
[ERROR ] CWWKZ0106E: Could not start web application S21.
[ERROR ] CWWKZ0002E: An exception occurred while starting the application S21. The exception message was: com.ibm.ws.container.service.state.StateChangeException: java.lang.LinkageError: loader constraint violation in interface itable initialization: when resolving method "org.eclipse.persistence.jpa.PersistenceProvider.getProviderUtil()Ljavax/persistence/spi/ProviderUtil;" the class loader (instance of com/ibm/ws/classloading/internal/ParentLastClassLoader) of the current class, org/eclipse/persistence/jpa/PersistenceProvider, and the class loader (instance of org/eclipse/osgi/internal/loader/EquinoxClassLoader) for interface javax/persistence/spi/PersistenceProvider have different Class objects for the type javax/persistence/spi/ProviderUtil used in the signature
Does anyone know whether I can replace the IBM Liberty implementation of EclipseLink with my version 2.7.7 version?
My application also uses JPA, which is working fine under Liberty, so I don't want to break that.
Any help / guidance appreciated... it's been a very long saturday.
PS:
I tried running the java code using only the SDO library (commonj.sdo_2.1.1v20111051852.jar), and relying on the WebSphere Liberty runtime jars to provide Eclipselink functionality, and I got the following errors, which is why I then moved to adding the "matching pair" of Eclipselink / SDO jars mentioned above;
Caught Exception : org.eclipse.persistence.internal.security.PrivilegedAccessHelper.getSystemPropertyBoolean(Ljava/lang/String;Z)Z
java.lang.NoSuchMethodError: org.eclipse.persistence.internal.security.PrivilegedAccessHelper.getSystemPropertyBoolean(Ljava/lang/String;Z)Z
at org.eclipse.persistence.sdo.helper.SDOHelperContext.<init>(SDOHelperContext.java:93)
at org.eclipse.persistence.sdo.helper.SDOHelperContext$DefaultHelperContextResolver.getHelperContext(SDOHelperContext.java:1432)
at org.eclipse.persistence.sdo.helper.SDOHelperContext.getHelperContext(SDOHelperContext.java:492)
at org.eclipse.persistence.sdo.helper.SDOHelperContext.getHelperContext(SDOHelperContext.java:471)
at org.eclipse.persistence.sdo.helper.SDOHelperContext.getHelperContext(SDOHelperContext.java:456)
at org.eclipse.persistence.sdo.helper.delegates.SDOXMLHelperDelegator.getXMLHelperDelegate(SDOXMLHelperDelegator.java:178)
at org.eclipse.persistence.sdo.helper.delegates.SDOXMLHelperDelegator.load(SDOXMLHelperDelegator.java:78)
at com.ebs.solas2021.port.adapter.ui.SOAPRequestHandler.main(SOAPRequestHandler.java:237)
It's amazing what you find whgen you re-read the documentation in the cold light of a new day. It turns out that it's possible to install a JPA 2.2 Container on Liberty, while supplying one's own implementation of EclipseLink. Works like a charm.
Documented here: https://openliberty.io/blog/2018/06/29/full_java_ee_8_liberty_18002.html
I've upgraded my application to use Spring Core version 5.0.8 (previously it was using version 4.3.6).
My app uses Postgresql 10.4 with JDBC driver version 42.2.5 and C3p0 version 0.9.5.2.
After the Spring Core upgrade, the application started throwing the following exception when trying to set the value of a CLOB column:
Method org.postgresql.jdbc.PgPreparedStatement.setClob(int, Reader, long) is not yet implemented.; nested exception is java.sql.SQLFeatureNotSupportedException: Method org.postgresql.jdbc.PgPreparedStatement.setClob(int, Reader, long) is not yet implemented
I saw that the method setValue of spring class org.springframework.jdbc.core.StatementCreatorUtils changed on latest versions and now it is not catching the exception SQLFeatureNotSupportedException and using a fallback method anymore, as it did on previous versions.
I've seen several answers related to workarounds when using JPA/Hibernate but it is not my case, the application does not use Hibernate at all.
What could I do to solve this issue? Any help is really appreciated.
Thanks,
Mariana
The database group recently upgraded the database to Oracle12c. I am currently using Hibernate 4.3.9. When I try to deploy the application, WebLogic throws an exception:
weblogic.application.ModuleException: org.hibernate.HibernateException: Unable to determine dialect to use [name=Oracle, majorVersion=12]; user must register resolver or explicitly set 'hibernate.dialect'.
HibernateUtil has
props.setProperty("hibernate.dialect", "utilities.OracleDialectExtended");
Where OracleDialectExtended extends Oracle10gDialect in order to register a Double as a float. HibernateUtil is being used to set the properties rather than in hibernate.cfg.xml.
Everything I have read indicates that using Oracle10gDialect should be OK. In fact, when I use the same set up in a batch type mode (not using WebLogic) I am able to connect with and work with Oracle without a problem.
Does anyone know how to resolve this? Or is this a WebLogic problem that needs to be addressed by a WebLogic admin.
Thanks.
Try with this:
props.setProperty("hibernate.dialect","org.hibernate.dialect.OracleDialect");
Just to follow up - in the end I upgraded Hibernate from 4.3.9 to 5.1.2 and things started working again.
Not the most ideal solution since a database upgrade shouldn't break an application but it was the fastest way to get things up and running again.
I have a Maven jersey-quickstart-webapp Project I am developing in Eclipse. The project is a JERSEY REST backend with angularjs javascript frontend.
I would like to know how to check what version of EclipseLink my project is using.
Where can I find this property? I've searched high and low but I can't find it - I know that I did stumble across it before, so it definitely exists....
This question is trying to get to the bottom of the following question I posed months ago about a problem with eclipselink and Jersey REST, that still hasn't been fixed: Class not found when using JAX-RS with Eclipse and Glassfish
This should be fixed with jersey 2.22.1 and eclipselink 2.6.1, but I think somewhere in my setup, eclipselink 2.6.0 is still hanging around and screwing the whole thing up. Highly frustrating!
I know that eclipselink is being used in this project, because the following code returns 2.6.1 when the project is running. However, previously I saw that even though this was saying 2.6.1, that the eclipselink configuration somewhere(I can't remember where - doh!) was still saying version 2.6.0.
//This helps us tell what version of eclipse link we are using
Class<?> myClass = Class.forName("org.eclipse.persistence.Version");
Method myMethod = myClass.getMethod("getVersion");
String version = myMethod.invoke(null).toString();
System.out.println("version = " + version);
Here is what the Maven dependency hierarchy looks like - as you can see it has no eclipselink stuff in there:
All help highly appreciated...
The eclipselink you're running is provided by the Glassfish server. Look in the glassfish/modules directory and find the org.eclipse.persistence.core.jar file. Inside it will be a readme.html. Open that and the version of eclipselink that is installed in Glassfish will be there.
Mine says, for glassfish 4 (somewhat old) is:
<B>EclipseLink 2.5 Read Me</B>
Duplicated! Refer this
There is a static class and static method to get this information.
Example: How to print in java code
AbstractSessionLog.getLog().log(SessionLog.INFO, DatabaseLogin.getVersion());
we have a WAR packaged web application which works on a development machine. It consists of Java EE 5 + Seam 2.2.1 + Hibernate 3.3.1. It uses an Oracle 10g XE database and runs on the latest Tomcat 6 using JDK 1.6.0_24. The system is a 64bit Windows 7 Pro and uses Firefox 6.
Now, we tried to migrate the application to Oracle WebLogic 10.3.5. We followed the Seam manual for specifying the datasource, deploying the JSF lib and configuring the necessary xml-Files. In parallel to that, we verified that a newly seam-gen generated application using the same datasource and having the xml files configured as stated works fine.
But if we try our own application on WebLogic, allthough the deployment works fine, when trying to open the web application in the browser, it shows that endless redirection occured. We don't see any stacktrace or log error, even when configuring log4j in WebLogic. When analyzing the request with Firebug, we see the get request to "login.seam" and then 20 times a get request for "error.seam" (or "debug.seam when setting debug mode) with the response "302 Moved Temporarily".
I worked on that all week now, trying to compare all configurations and couldn't solve it - so I hope to get any ideas what could cause that problem and how to solve it!
I could pin down the problem to starting a transaction on the JTA persistence context.
I still don't understand why I didn't see any log message or stacktrace and why this also happens on the debug/error page (that's why the endless redirect occured).
I ended up using RESOURCE_LOCAL so far, but I'm not sure if this is the right thing to do.
The alternative is disabling the seam transaction setting, but then it didn't work together with the development build which still runs on Tomcat.