date:20080211

[jira] Commented: (SUREFIRE-453) unable to run spring/jpa/dao test with derby starting with surefire 2.4.x

2008-02-11 Thread Dan Fabulich (JIRA)


[ 
http://jira.codehaus.org/browse/SUREFIRE-453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_123292
 ] 

Dan Fabulich commented on SUREFIRE-453:
---

Repro'd.

> 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.ac12564092x0117xc31cx8752x0020b5f01.
>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

[jira] Updated: (SUREFIRE-443) Provide option to merge test classpath into one directory

2008-02-11 Thread Dan Fabulich (JIRA)

[
http://jira.codehaus.org/browse/SUREFIRE-443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Dan Fabulich updated SUREFIRE-443:
--

Description:
Please provide an option for the test classpath to be merged into one directory.

Maven sets up the class files as follows:
{noformat}
|-- target/test-classes
| `-- Unit Test classes
|-- target/classes
`-- Classes to be tested
{noformat}

When running unit tests, the desired outcome is for any file in the
"target/test-classes" tree to override those in the "target/classes".
Specifically that any file in classes is ignored and overridden by the file in
test-classes for the tests to work as expected.
(In a sense a union on these two file trees in the order specified)

The problem arises when using a container such as Embedded JBoss to test which
treats each directory as a separate scope for classloading.
Reading the ejb-3_0-fr-spec-persistence.pdf section "6.2.2 Persistence Unit
Scope" spells it out quite clearly (a very short one page read) that if the
"target/test-classes" and "target/classes" are each treated as a separate
ejb-jar, then the runtime environment is not going to work due to these scoping
rules.

I have an ugly hack in place as follows which has the desired effect, but it
would be more preferable if instead Maven Surefire provided an option to merge
the directories together and have just one directory in the test classpath.

{noformat}

...

maven-antrun-plugin

setupTestClasspath
test-compile

run

restoreTestClasspath
test

run

...
{noformat}

was:
Please provide an option for the test classpath to be merged into one directory.

Maven sets up the class files as follows:
{noformat}
|-- target/test-classes
| `-- Unit Test classes
|-- target/classes
`-- Classes to be tested
{noformat}

50 matches

Mail list logo