| org.eclipse.persistence.exceptions.ValidationException thrown due to NegativeArraySizeException [message #540635] |
Wed, 16 June 2010 19:01  |
 Tim
Messages: 21
Registered: June 2010 |
Junior Member |
|
|
We are seeing NegativeArraySizeExceptions happening on a regular basis when running our app using the JPA interface to Eclipselink 2.0.2. Specifically, the stack trace has:
org.springframework.transaction.CannotCreateTransactionException: Could not open JPA EntityManager for transaction; nested exception is Exception [EclipseLink-7107] (Eclipse Persistence Services - 2.0.2.v20100323-r6872): org.eclipse.persistence.exceptions.ValidationException
Exception Description: Error encountered during string decryption.
Internal Exception: java.lang.NegativeArraySizeException
org.springframework.orm.jpa.JpaTransactionManager.doBegin(JpaTransactionManager.java:382)
org.springframework.transaction.support.AbstractPlatformTransactionManager.getTransaction(AbstractPlatformTransactionManager.java:371)
org.springframework.transaction.interceptor.TransactionAspectSupport.createTransactionIfNecessary(TransactionAspectSupport.java:317)
org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:105)
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
org.springframework.aop.framework.Cglib2AopProxy$DynamicAdvisedInterceptor.intercept(Cglib2AopProxy.java:625)
.
.
.
root cause
Exception [EclipseLink-7107] (Eclipse Persistence Services - 2.0.2.v20100323-r6872): org.eclipse.persistence.exceptions.ValidationException
Exception Description: Error encountered during string decryption.
Internal Exception: java.lang.NegativeArraySizeException
org.eclipse.persistence.exceptions.ValidationException.errorDecryptingPassword(ValidationException.java:849)
org.eclipse.persistence.internal.security.JCEEncryptor.decryptPassword(JCEEncryptor.java:102)
org.eclipse.persistence.sessions.DatasourceLogin.prepareProperties(DatasourceLogin.java:323)
org.eclipse.persistence.sessions.DatasourceLogin.connectToDatasource(DatasourceLogin.java:162)
org.eclipse.persistence.internal.databaseaccess.DatasourceAccessor.connectInternal(DatasourceAccessor.java:327)
org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor.connectInternal(DatabaseAccessor.java:295)
org.eclipse.persistence.internal.databaseaccess.DatasourceAccessor.reconnect(DatasourceAccessor.java:558)
org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor.reconnect(DatabaseAccessor.java:1436)
org.eclipse.persistence.internal.databaseaccess.DatasourceAccessor.incrementCallCount(DatasourceAccessor.java:302)
org.eclipse.persistence.internal.databaseaccess.DatasourceAccessor.beginTransaction(DatasourceAccessor.java:235)
org.eclipse.persistence.internal.sessions.AbstractSession.basicBeginTransaction(AbstractSession.java:424)
org.eclipse.persistence.internal.sessions.AbstractSession.basicBeginTransaction(AbstractSession.java:413)
org.eclipse.persistence.sessions.server.ClientSession.basicBeginTransaction(ClientSession.java:134)
org.eclipse.persistence.internal.sessions.AbstractSession.beginTransaction(AbstractSession.java:580)
org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.beginTransaction(UnitOfWorkImpl.java:554)
org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.beginEarlyTransaction(UnitOfWorkImpl.java:544)
org.springframework.orm.jpa.vendor.EclipseLinkJpaDialect.beginTransaction(EclipseLinkJpaDialect.java:90)
org.springframework.orm.jpa.JpaTransactionManager.doBegin(JpaTransactionManager.java:332)
org.springframework.transaction.support.AbstractPlatformTransactionManager.getTransaction(AbstractPlatformTransactionManager.java
It doesn't happen every time, but happens with reasonable frequency.
I've set up break points in JCEEncryptor and have been able to catch the exception in action. The confusing part (to me at least) is that the calls to the method seem to be the same as previous calls which return a valid value. In our case, the method is being called with "5C4C6924B1B14E16", which is the encrypted form of "". We are using Tomcat with a JNDI datasource, so there is no password in this instance (which makes me wonder why this code is called at all). If I use a JPA defined datasource, I don't see the exceptions happen, though it is hard to say this is definitive, since I'm unable able to explicitly reproduce the error and generally just need to hit the server with requests for a while to trigger it.
I saw something similar in this thread, but there didn't seem to be a solution.
We are using org.springframework.orm.jpa.persistenceunit.PersistenceUnitP ostProcessor to set up the JNDI datasource.
Anyone have any idea what might be happening and how to prevent it? If not, any further debugging information which I can provide to help track down the issue? Like I said, I can trigger it on occasion and have done so in the debugger. I just honestly can't figure out why some calls with the same arg to JCEEncryptor work while others throw an exception.
Thanks.
--Tim
|
|
|
|
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.43993 seconds
] 
Search
Help
Register
Login
Home
