[
http://jira.codehaus.org/browse/SUREFIRE-453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
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: http://jira.codehaus.org/browse/SUREFIRE-453
> 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(AbstractEntityManagerImpl.java:630)
> at org.hibernate.ejb.QueryImpl.getResultList(QueryImpl.java:75)
> at
> com.iplocks.jpa.GenericNameDaoJpa.getByName(GenericNameDaoJpa.java:54)
> at
> com.iplocks.user.dao.UserDaoJpaTest.createUser(UserDaoJpaTest.java:35)
> at
> com.iplocks.user.dao.UserDaoJpaTest.createDefaultUser(UserDaoJpaTest.java:56)
> at
> com.iplocks.user.dao.UserDaoJpaTest.testNamedConstraint(UserDaoJpaTest.java:77)
> Caused by: org.hibernate.exception.GenericJDBCException: could not execute
> query
> at
> org.hibernate.exception.SQLStateConverter.handledNonSpecificException(SQLStateConverter.java:103)
> at
> org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:91)
> at
> org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:43)
> at org.hibernate.loader.Loader.doList(Loader.java:2223)
> at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2104)
> at org.hibernate.loader.Loader.list(Loader.java:2099)
> at org.hibernate.loader.hql.QueryLoader.list(QueryLoader.java:378)
> at
> org.hibernate.hql.ast.QueryTranslatorImpl.list(QueryTranslatorImpl.java:338)
> at
> org.hibernate.engine.query.HQLQueryPlan.performList(HQLQueryPlan.java:172)
> at org.hibernate.impl.SessionImpl.list(SessionImpl.java:1121)
> at org.hibernate.impl.QueryImpl.list(QueryImpl.java:79)
> at org.hibernate.ejb.QueryImpl.getResultList(QueryImpl.java:66)
> ... 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 resources.properties accordingly
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
