|
|
|
[
Permlink
| « Hide
]
Matt Raible - 29/Mar/07 01:23 PM
It appears this happens because the Hibernate3 Plugins scans JARs when using "jpaannotations". It finds a META-INF/persistence.xml in the warpath JARs and tries to use it. I'm going to exclude META-INF/persistence.xml from being included in "installed" AppFuse WARs so this problem doesn't happen for others.
Solved by excluding META-INF/persistence.xml from any WARs. The Hibernate3 Plugin scans JARs and doesn't exclude these even though they're excluded in the WarPath plugin. META-INF is included in child WARs so tests will pass. However, they're excluded when creating a skinny WAR. If we find that this is not necessary, it should be easy enough to back out this change since the src/main/resources/META-INF directory in jsf, spring, struts and tapestry is linked to web/common/src/main/resources/META-INF using svn:externals.
As persistence.xml is stored below META-INF, the exclude for the warpath plugin must be written as **/persistence.xml or META-INF/persistence.xml.
With the full-source, and maven.test.skip set to false, I'm still seeing this issue with the APPFUSE-2.0 tag when using the JSF Modular archetype. Searching through the configuration files, I don't find a reference to excluding persistence.xml from anything, and I just see the addition of the test skip value in the core/pom.xml file. Am I missing something here? I can get it to work if I skip the tests, but I'd really like to be able to have the tests pass if you know what I mean ;)
I believe this is caused by
rm -r core/src/test/resources/META-INF rm web/src/main/resources/META-INF I have the same issue even after the above rm commands. I am using Modular Spring MVC archetype and JPA. After mvn appfuse:full-source the issue occurs.
Did you run "mvn clean" from the top level after running the following?
rm -r core/src/test/resources/META-INF rm -r web/src/main/resources/META-INF After that I am getting other exceptions. It looks to me like there is a problem with Java 1.6. I tried with another computer with Java 1.5 and it works. But even after doing everything from beginning mvn always produces something like below. Is there a problem with Modular Spring MVC+JPA+Java 1.6? (Hibernate with Java 1.6 is working)
WARN [main] DefaultNamespaceHandlerResolver.initHandlerMappings(133) | Ignoring namespace handler [org.springmodules.validation.bean.conf.namespace.ValidatorNamespaceHandler]: problem with handler class file or dependent class java.lang.NoClassDefFoundError: Could not initialize class org.springmodules.validation.util.LibraryUtils at org.springmodules.validation.bean.conf.namespace.ValidatorNamespaceHandler.init(ValidatorNamespaceHandler.java:51) at org.springframework.beans.factory.xml.DefaultNamespaceHandlerResolver.initHandlerMappings(DefaultNamespaceHandlerResolver.java:123) at org.springframework.beans.factory.xml.DefaultNamespaceHandlerResolver.<init>(DefaultNamespaceHandlerResolver.java:96) at org.springframework.beans.factory.xml.DefaultNamespaceHandlerResolver.<init>(DefaultNamespaceHandlerResolver.java:82) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.createDefa WARN [main] DefaultNamespaceHandlerResolver.initHandlerMappings(133) | Ignoring namespace handler [org.springmodules.validation.bean.conf.namespace.ValidatorNamespaceHandler]: problem with handler class file or dependent class java.lang.NoSuchFieldError: IS_JAVA_1_6 at org.springmodules.validation.util.LibraryUtils.<clinit>(LibraryUtils.java:40) at org.springmodules.validation.bean.conf.namespace.ValidatorNamespaceHandler.init(ValidatorNamespaceHandler.java:51) at org.springframework.beans.factory.xml.DefaultNamespaceHandlerResolver.initHandlerMappings(DefaultNamespaceHandlerResolver.java:123) at org.springframework.beans.factory.xml.DefaultNamespaceHandlerResolver.<init>(DefaultNamespaceHandlerResolver.java:96) It looks like Spring Modules is unable to handle Java 1.6.
FYI, I was getting this NoSuchFieldError: IS_JAVA_1_6 on another project. I found this:
http://www.nabble.com/bean-validator-issue-in-jdk-6-t3245736.html which indicates that the solution/workaround is to use commons-lang 2.3. I added an explicit dependency or commons-lang version 2.3 in my pom.xml and voilla -- the problem goes away. I already have this in my top level pom.xml:
<commons.lang.version>2.3</commons.lang.version> Is there something I can still do? |
||||||||||||||||||||||||||||||||||||||||