L'entité de lancement JBoss 7 n'est pas mappée lorsque vous utilisez @PersIncecontext
Question
J'utilise le printemps / jpa / hibernate 3 dans une application que fonctionne tout simplement bien dans Tomcat 7 mais échoue à JBoss comme 7. J'utilise l'annotation @Persistencecontext pour injecter mon gestionnaire d'entitéDans les Daos, mais je reçois l'entité <jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.0">
<deployment>
<exclusions>
<module name="org.hibernate"/>
</exclusions>
</deployment>
</jboss-deployment-structure>
Cela ne fonctionne toujours pas.Quelle est la cause de cette exception?Pourquoi Jboss essaie-t-il toujours de gérer mon contexte de persistance?
P.s.: Par défaut, je reçois une définition étrange PU (l'URL racine PU n'est pas ma guerre!)
(MSC service thread 1-3) insurance-module 17:51:41.456 [MSC service thread 1-3] DEBUG org.hibernate.ejb.Ejb3Configuration - Processing PersistenceUnitInfo [
17:51:41,456 INFO [stdout] (MSC service thread 1-3) name: default
17:51:41,456 INFO [stdout] (MSC service thread 1-3) persistence provider classname: null
17:51:41,456 INFO [stdout] (MSC service thread 1-3) classloader: ModuleClassLoader for Module "deployment.insurance-module-0.1-SNAPSHOT.war:main" from Service Module Loader
17:51:41,457 INFO [stdout] (MSC service thread 1-3) Temporary classloader: org.springframework.instrument.classloading.SimpleThrowawayClassLoader@13acaabd
17:51:41,457 INFO [stdout] (MSC service thread 1-3) excludeUnlistedClasses: true
17:51:41,457 INFO [stdout] (MSC service thread 1-3) JTA datasource: null
17:51:41,457 INFO [stdout] (MSC service thread 1-3) Non JTA datasource: com.mchange.v2.c3p0.ComboPooledDataSource [ acquireIncrement -> 3, acquireRetryAttempts -> 30, acquireRetryDelay -> 1000, autoCommitOnClose -> false, automaticTestTable -> null, breakAfterAcquireFailure -> false, checkoutTimeout -> 0, connectionCustomizerClassName -> null, connectionTesterClassName -> com.mchange.v2.c3p0.impl.DefaultConnectionTester, dataSourceName -> z8kfsx8l1ikdpo61c3bmxu|6b5638a, debugUnreturnedConnectionStackTraces -> false, description -> null, driverClass -> com.mysql.jdbc.Driver, factoryClassLocation -> null, forceIgnoreUnresolvedTransactions -> false, identityToken -> z8kfsx8l1ikdpo61c3bmxu|6b5638a, idleConnectionTestPeriod -> 60, initialPoolSize -> 3, jdbcUrl -> jdbc:mysql://localhost:3306/insurance, maxAdministrativeTaskTime -> 0, maxConnectionAge -> 0, maxIdleTime -> 60, maxIdleTimeExcessConnections -> 0, maxPoolSize -> 5, maxStatements -> 0, maxStatementsPerConnection -> 0, minPoolSize -> 1, numHelperThreads -> 3, numThreadsAwaitingCheckoutDefaultUser -> 0, preferredTestQuery -> select 1, properties -> {user=******, password=******}, propertyCycle -> 0, testConnectionOnCheckin -> false, testConnectionOnCheckout -> false, unreturnedConnectionTimeout -> 0, usesTraditionalReflectiveProxies -> false ]
17:51:41,457 INFO [stdout] (MSC service thread 1-3) Transaction type: RESOURCE_LOCAL
17:51:41,457 INFO [stdout] (MSC service thread 1-3) PU root URL: file:/home/mircea/jboss-as-7.0.2.Final/modules/sun/jdk/main/service-loader-resources/
17:51:41,457 INFO [stdout] (MSC service thread 1-3) Shared Cache Mode: UNSPECIFIED
17:51:41,457 INFO [stdout] (MSC service thread 1-3) Validation Mode: AUTO
17:51:41,457 INFO [stdout] (MSC service thread 1-3) Jar files URLs []
17:51:41,457 INFO [stdout] (MSC service thread 1-3) Managed classes names []
17:51:41,457 INFO [stdout] (MSC service thread 1-3) Mapping files names []
17:51:41,457 INFO [stdout] (MSC service thread 1-3) Properties []
17:51:41,459 INFO [stdout] (MSC service thread 1-3) insurance-module 17:51:41.459 [MSC service thread 1-3] DEBUG org.hibernate.ejb.Ejb3Configuration - Detect class: true; detect hbm: true
17:51:41,462 INFO [stdout] (MSC service thread 1-3) insurance-module 17:51:41.462 [MSC service thread 1-3] DEBUG o.h.ejb.packaging.AbstractJarVisitor - Searching mapped entities in jar/par: file:/home/mircea/jboss-as-7.0.2.Final/modules/sun/jdk/main/service-loader-resources/
La solution
Si le packagestoscan ne pointe pas les paquets appropriés, tout fonctionne très bien à Tomcat 7, mais lors du déploiement de JBoss, il échoue comme décrit dans la question.