maven-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dan Fabulich (JIRA)" <>
Subject [jira] Closed: (SUREFIRE-453) unable to run spring/jpa/dao test with derby starting with surefire 2.4.x
Date Mon, 11 Feb 2008 19:08:29 GMT


Dan Fabulich closed SUREFIRE-453.

    Resolution: Won't Fix

The problem with this test has to do with the useSystemClassLoader configuration parameter.
 When I use Surefire 2.4.1 and -Dsurefire.useSystemClassLoader=false, the test passes; with
=true (the default), the test fails.

One of the changes from Surefire 2.3 and Surefire 2.4 was to make useSystemClassLoader=true
the default; previously the default was false.  "useSystemClassLoader" sounds fancy, but it's
really just the normal default way of launching java: your classes and dependencies are added
to the classpath in an ordinary way.

When we don't use the system classloader, we do fancy stuff with "isolated" custom classloaders;
this frequently had a destabilizing effect on the classes as they attempted to access the
system classloader using java.lang.ClassLoader.getSystemClassLoader().  There are a bunch
of bugs marked "Won't Fix" for 2.3 because the workaround is just to set useSystemClassLoader=true.

Since the system classloader mechanism is the "normal" way of launching code, we have to wonder:
why does this test fail when launched in the "ordinary" way, but pass when launched in a special
isolated classloader?  I have no idea why, and I think it's beyond me to find out.  There's
more than a dozen dependencies in this project and a lot of tricky interactions possible between
spring, hibernate, derby, and aspectj; to figure out what's wrong would require a way more
detailed debugging effort than I'm prepared to do right now.

For now, I'm going to have to mark this "Won't Fix", there's a reasonable workaround available
(useSystemClassLoader=false) and because I believe the current default behavior is the right
choice (the default can't satisfy everyone).

If there's something else we can do besides changing the default setting, I'd be curious to
know of it; in that case, feel free to reopen this bug or file a new one.

> unable to run spring/jpa/dao test with derby starting with surefire 2.4.x
> -------------------------------------------------------------------------
>                 Key: SUREFIRE-453
>                 URL:
>             Project: Maven Surefire
>          Issue Type: Bug
>          Components: plugin
>    Affects Versions: 2.4
>            Reporter: Dan Tran
>         Attachments: mytest-sources-2.jar, mytest-sources.jar
> here is the description reported on user list
> This may not be a blocking bug but It is a regresion since 2.4 where
> my Spring JpaDao with embedded Derby  test fails . Other databases are fine.
> The exception is producable with 2.5-SNAPSHOT ( build from source ),
> 2.4.1-SNAPSHOT( at apache snapshot repo).
> surefire 2.3 and 2.3.1 are fine.
> Any one else encounter this issue?
> -D
> -------------------------------------------------------------------------------
> Test set: com.iplocks.user.dao.UserDaoJpaTest
> -------------------------------------------------------------------------------
> Tests run: 7, Failures: 0, Errors: 6, Skipped: 0, Time elapsed: 14.111
> sec <<< FAILURE!
> testNamedConstraint(com.iplocks.user.dao.UserDaoJpaTest)  Time
> elapsed: 0.281 sec  <<< ERROR!
> javax.persistence.PersistenceException:
> org.hibernate.exception.GenericJDBCException: could not execute query
>        at org.hibernate.ejb.AbstractEntityManagerImpl.throwPersistenceException(
>        at org.hibernate.ejb.QueryImpl.getResultList(
>        at com.iplocks.jpa.GenericNameDaoJpa.getByName(
>        at com.iplocks.user.dao.UserDaoJpaTest.createUser(
>        at com.iplocks.user.dao.UserDaoJpaTest.createDefaultUser(
>        at com.iplocks.user.dao.UserDaoJpaTest.testNamedConstraint(
> Caused by: org.hibernate.exception.GenericJDBCException: could not execute query
>        at org.hibernate.exception.SQLStateConverter.handledNonSpecificException(
>        at org.hibernate.exception.SQLStateConverter.convert(
>        at org.hibernate.exception.JDBCExceptionHelper.convert(
>        at org.hibernate.loader.Loader.doList(
>        at org.hibernate.loader.Loader.listIgnoreQueryCache(
>        at org.hibernate.loader.Loader.list(
>        at org.hibernate.loader.hql.QueryLoader.list(
>        at org.hibernate.hql.ast.QueryTranslatorImpl.list(
>        at org.hibernate.engine.query.HQLQueryPlan.performList(
>        at org.hibernate.impl.SessionImpl.list(
>        at org.hibernate.impl.QueryImpl.list(
>        at org.hibernate.ejb.QueryImpl.getResultList(
>        ... 38 more
> Caused by: java.sql.SQLException: Cannot create an instance of
> generated class
> org.apache.derby.exe.ac12564092x0117xc31cx8752x00000020b5f01.
>        at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown
> Please run mvn test using the attached maven project.  to run with different db, change accordingly

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:


View raw message