[JBoss JIRA] (WFLY-6137) org.dom4j.DocumentFactory cannot be cast to org.dom4j.DocumentFactory
by Karl Nicholas (JIRA)
[ https://issues.jboss.org/browse/WFLY-6137?page=com.atlassian.jira.plugin.... ]
Karl Nicholas updated WFLY-6137:
--------------------------------
Description: Including hibernate-entitymanager (up to version 5.0.7.Final) into a project causes dom4j-1.6.1.jar to be included which causes the application to fail to deploy in Wildfly 10.0.0.Final. (was: Including hibernate-entitymanager (up to version 5.0.7.Final) into a project causes dom4j-1.6.1.jar which causes the application to fail to deploy in Wildfly 10.0.0.Final.)
> org.dom4j.DocumentFactory cannot be cast to org.dom4j.DocumentFactory
> ---------------------------------------------------------------------
>
> Key: WFLY-6137
> URL: https://issues.jboss.org/browse/WFLY-6137
> Project: WildFly
> Issue Type: Bug
> Components: Application Client, EE, JPA / Hibernate, Server
> Affects Versions: 10.0.0.Final
> Reporter: Karl Nicholas
> Assignee: Stuart Douglas
>
> Including hibernate-entitymanager (up to version 5.0.7.Final) into a project causes dom4j-1.6.1.jar to be included which causes the application to fail to deploy in Wildfly 10.0.0.Final.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFLY-6137) org.dom4j.DocumentFactory cannot be cast to org.dom4j.DocumentFactory
by Karl Nicholas (JIRA)
[ https://issues.jboss.org/browse/WFLY-6137?page=com.atlassian.jira.plugin.... ]
Karl Nicholas commented on WFLY-6137:
-------------------------------------
The reason that dom4j.jar ended up in my .war file is that I included hibernate-entitymanager, version 5.0.7.Final in my pom.xml. I didn't even need it because I took the class that was using it out of the application and rebuilt everything.
Background, I started with a new Java EE Web project, from Jboss developer tools (9.1.0.Beta2). I was created a class in my project to generate the database schema, which it seems reasonable to do. So, for that needed hibernate-entitymanger.jar, and that pulls in the dom4j-1.6.1.jar.
Total jar file list when including, and only including without needing, hibernate-entitymanager.jar in my project pom.xml is as follows. Without including it I can build an application without any in the WEB-INF/lib directory.
antlr-2.7.7.jar
dom4j-1.6.1.jar
geronimo-jta_1.1_spec-1.1.1.jar
hibernate-commons-annotations-5.0.1.Final.jar
hibernate-core-5.0.7.Final.jar
hibernate-entitymanager-5.0.7.Final.jar
hibernate-jpa-2.1-api-1.0.0.Final.jar
jandex-2.0.0.Final.jar
javaassist-3.18.1-GA.jar
jboss-logging-3.3.0.Final.jar
xml-apis-1.0.b2.jar
Stack trace:
Caused by: java.lang.ClassCastException: org.dom4j.DocumentFactory cannot be cast to org.dom4j.DocumentFactory
at org.dom4j.DocumentFactory.getInstance(DocumentFactory.java:97)
at org.hibernate.internal.util.xml.XMLHelper$1.doWork(XMLHelper.java:33)
at org.hibernate.internal.util.xml.XMLHelper$1.doWork(XMLHelper.java:27)
at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.workWithClassLoader(ClassLoaderServiceImpl.java:342)
at org.hibernate.internal.util.xml.XMLHelper.<init>(XMLHelper.java:26)
at org.hibernate.envers.boot.internal.EnversServiceImpl.initialize(EnversServiceImpl.java:115)
at org.hibernate.envers.boot.internal.AdditionalJaxbMappingProducerImpl.produceAdditionalMappings(AdditionalJaxbMappingProducerImpl.java:99)
at org.hibernate.boot.model.process.spi.MetadataBuildingProcess.complete(MetadataBuildingProcess.java:288)
at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.metadata(EntityManagerFactoryBuilderImpl.java:847)
at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:874)
at org.jboss.as.jpa.hibernate5.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44)
at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:154)
... 7 more
Hope this helps.
> org.dom4j.DocumentFactory cannot be cast to org.dom4j.DocumentFactory
> ---------------------------------------------------------------------
>
> Key: WFLY-6137
> URL: https://issues.jboss.org/browse/WFLY-6137
> Project: WildFly
> Issue Type: Feature Request
> Components: Application Client, EE, JPA / Hibernate, Server
> Affects Versions: 10.0.0.Final
> Reporter: Karl Nicholas
> Assignee: Stuart Douglas
>
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFLY-5549) org.dom4j.DocumentFactory cannot be cast to org.dom4j.DocumentFactory
by Karl Nicholas (JIRA)
[ https://issues.jboss.org/browse/WFLY-5549?page=com.atlassian.jira.plugin.... ]
Karl Nicholas commented on WFLY-5549:
-------------------------------------
I came to report this error. The reason the DOM jar ended up in my .war file is that I included hibernate-entitymanager, version 5.0.7.Final in my pom.xml. I didn't even need it because I took the class that was using it out of the application and rebuilt everything.
Background, I started with a new Java EE Web project, from Jboss developer tools (9.1.0.Beta2) I was including a class in my project to generate the database schema, which seems common to do. So, that needed hibernate-entitymanger.jar, and that pulls in the dom4j-1.6.1.jar.
Total jar file list when including, and only including without needing hibernate-entitymanager.jar
antlr-2.7.7.jar
dom4j-1.6.1.jar
geronimo-jta_1.1_spec-1.1.1.jar
hibernate-commons-annotations-5.0.1.Final.jar
hibernate-core-5.0.7.Final.jar
hibernate-entitymanager-5.0.7.Final.jar
hibernate-jpa-2.1-api-1.0.0.Final.jar
jandex-2.0.0.Final.jar
javaassist-3.18.1-GA.jar
jboss-logging-3.3.0.Final.jar
xml-apis-1.0.b2.jar
Hope this helps.
> org.dom4j.DocumentFactory cannot be cast to org.dom4j.DocumentFactory
> ---------------------------------------------------------------------
>
> Key: WFLY-5549
> URL: https://issues.jboss.org/browse/WFLY-5549
> Project: WildFly
> Issue Type: Feature Request
> Components: JPA / Hibernate
> Reporter: carlos feria
> Assignee: Scott Marlow
>
> 10:06:35,545 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 61) MSC000001: Failed to start service jboss.persistenceunit."********": org.jboss.msc.service.StartException in service jboss.persistenceunit."*******": java.lang.ClassCastException: org.dom4j.DocumentFactory cannot be cast to org.dom4j.DocumentFactory
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:172)
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:117)
> at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:667)
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:182)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> Caused by: java.lang.ClassCastException: org.dom4j.DocumentFactory cannot be cast to org.dom4j.DocumentFactory
> at org.dom4j.DocumentFactory.getInstance(DocumentFactory.java:97)
> at org.hibernate.internal.util.xml.XMLHelper$1.doWork(XMLHelper.java:33)
> at org.hibernate.internal.util.xml.XMLHelper$1.doWork(XMLHelper.java:27)
> at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.workWithClassLoader(ClassLoaderServiceImpl.java:342)
> at org.hibernate.internal.util.xml.XMLHelper.<init>(XMLHelper.java:26)
> at org.hibernate.envers.boot.internal.EnversServiceImpl.initialize(EnversServiceImpl.java:115)
> at org.hibernate.envers.boot.internal.AdditionalJaxbMappingProducerImpl.produceAdditionalMappings(AdditionalJaxbMappingProducerImpl.java:99)
> at org.hibernate.boot.model.process.spi.MetadataBuildingProcess.complete(MetadataBuildingProcess.java:288)
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.metadata(EntityManagerFactoryBuilderImpl.java:770)
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:797)
> at org.jboss.as.jpa.hibernate5.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44)
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:154)
> ... 7 more
> 10:06:35,552 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 2) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "cooperativa-1.0.0.Final.war")]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.persistenceunit.\"cooperativa-1.0.0.Final.war#CooperativaPU\"" => "org.jboss.msc.service.StartException in service jboss.persistenceunit.\"cooperativa-1.0.0.Final.war#CooperativaPU\": java.lang.ClassCastException: org.dom4j.DocumentFactory cannot be cast to org.dom4j.DocumentFactory
> Caused by: java.lang.ClassCastException: org.dom4j.DocumentFactory cannot be cast to org.dom4j.DocumentFactory"}}
> 10:06:35,732 INFO [org.jboss.as.server] (DeploymentScanner-threads - 2) WFLYSRV0010: Deployed "cooperativa-1.0.0.Final.war" (runtime-name : "cooperativa-1.0.0.Final.war")
> 10:06:35,733 INFO [org.jboss.as.controller] (DeploymentScanner-threads - 2) WFLYCTL0183: Service status report
> WFLYCTL0186: Services which failed to start: service jboss.persistenceunit."cooperativa-1.0.0.Final.war#CooperativaPU": org.jboss.msc.service.StartException in service jboss.persistenceunit."cooperativa-1.0.0.Final.war#CooperativaPU": java.lang.ClassCastException: org.dom4j.DocumentFactory cannot be cast to org.dom4j.DocumentFactory
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFLY-6136) Wildfly 10.0.0.Final duplitates contents of <jsp-config><include-prelude> or <include-coda> directives in web.xml
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-6136?page=com.atlassian.jira.plugin.... ]
Stuart Douglas reassigned WFLY-6136:
------------------------------------
Assignee: Stuart Douglas (was: Jason Greene)
> Wildfly 10.0.0.Final duplitates contents of <jsp-config><include-prelude> or <include-coda> directives in web.xml
> -----------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-6136
> URL: https://issues.jboss.org/browse/WFLY-6136
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 10.0.0.Final
> Environment: Ubuntu Linux 14.04 amd64
> Reporter: Juanm Manuel Enrique Muñido
> Assignee: Stuart Douglas
>
> I have been successfully deploying an application on WildFly 8.2.1 and WildFly 9.0.2 versions with the following <jsp-config> directives in web.xml deployment descriptor:
> <jsp-config>
> <jsp-property-group>
> <description>header and footer settings</description>
> <url-pattern>/WEB-INF/view/*</url-pattern>
> <url-pattern>/WEB-INF/error/*</url-pattern>
> <include-prelude>/WEB-INF/jspf/header.jspf</include-prelude>
> <include-coda>/WEB-INF/jspf/footer.jspf</include-coda>
> </jsp-property-group>
> </jsp-config>
> This code fragment includes the contents of /WEB-INF/jspf/header.jspf at the beginning of each .jsp file and <include-coda>/WEB-INF/jspf/footer.jspf</include-coda> at the end of each .jsp file that matches the <url-pattern>.
> But when I try to deploy this application with the same deployment descriptor in WildFly 10.0.0.Final, the contents of /WEB-INF/jspf/header.jspf and /WEB-INF/jspf/footer.jspf are included twice in each .jsp file that matches the <url-pattern>.
> If I add another <url-pattern> line, then the contents of /WEB-INF/jspf/header.jspf and /WEB-INF/jspf/footer.jspf are included three times, and so on.
> Any suggestion about this issue?
> Is this a deployment descriptor issue or a configuration issue in the standalone.xml of WildFly 10.0.0.Final version?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFLY-6136) Wildfly 10.0.0.Final duplitates contents of <jsp-config><include-prelude> or <include-coda> directives in web.xml
by Juanm Manuel Enrique Muñido (JIRA)
[ https://issues.jboss.org/browse/WFLY-6136?page=com.atlassian.jira.plugin.... ]
Juanm Manuel Enrique Muñido updated WFLY-6136:
----------------------------------------------
Description:
I have been successfully deploying an application on WildFly 8.2.1 and WildFly 9.0.2 versions with the following <jsp-config> directives in web.xml deployment descriptor:
<jsp-config>
<jsp-property-group>
<description>header and footer settings</description>
<url-pattern>/WEB-INF/view/*</url-pattern>
<url-pattern>/WEB-INF/error/*</url-pattern>
<include-prelude>/WEB-INF/jspf/header.jspf</include-prelude>
<include-coda>/WEB-INF/jspf/footer.jspf</include-coda>
</jsp-property-group>
</jsp-config>
This code fragment includes the contents of /WEB-INF/jspf/header.jspf at the beginning of each .jsp file and <include-coda>/WEB-INF/jspf/footer.jspf</include-coda> at the end of each .jsp file that matches the <url-pattern>.
But when I try to deploy this application with the same deployment descriptor in WildFly 10.0.0.Final, the contents of /WEB-INF/jspf/header.jspf and /WEB-INF/jspf/footer.jspf are included twice in each .jsp file that matches the <url-pattern>.
If I add another <url-pattern> line, then the contents of /WEB-INF/jspf/header.jspf and /WEB-INF/jspf/footer.jspf are included three times, and so on.
Any suggestion about this issue?
Is this a deployment descriptor issue or a configuration issue in the standalone.xml of WildFly 10.0.0.Final version?
was:
I have been successfully deploying an application on WildFly 8.2.1 and WildFly 9.0.2 versions with the following <jsp-config> directives in web.xml deployment descriptor:
<jsp-config>
<jsp-property-group>
<description>header and footer settings</description>
<url-pattern>/WEB-INF/view/*</url-pattern>
<url-pattern>/WEB-INF/error/*</url-pattern>
<include-prelude>/WEB-INF/jspf/header.jspf</include-prelude>
<include-coda>/WEB-INF/jspf/footer.jspf</include-coda>
</jsp-property-group>
</jsp-config>
This code fragment includes the contents of /WEB-INF/jspf/header.jspf at the beginning of each .jsp file and <include-coda>/WEB-INF/jspf/footer.jspf</include-coda> at the end of each .jsp file that matches the <url-pattern>.
But when I try to deploy this application with the same deployment descriptor in WildFly 10.0.0.Final, the contents of /WEB-INF/jspf/header.jspf and /WEB-INF/jspf/footer.jspf are included twice in each .jsp file that matches the <url-pattern>.
If I add another <url-pattern> line, then the contents of /WEB-INF/jspf/header.jspf and /WEB-INF/jspf/footer.jspf are included three times, and so on.
Any suggestion about this issue?
Is this a deployment descriptor issue or a configuration issue in the standalone.xml of WildFly 10.0.0.Final version?
Summary: Wildfly 10.0.0.Final duplitates contents of <jsp-config><include-prelude> or <include-coda> directives in web.xml (was: Wildfly 10.0.0.Final duplitates contents of <jsp-config><include-prelude> or <include-coda> directives un web.xml)
> Wildfly 10.0.0.Final duplitates contents of <jsp-config><include-prelude> or <include-coda> directives in web.xml
> -----------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-6136
> URL: https://issues.jboss.org/browse/WFLY-6136
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 10.0.0.Final
> Environment: Ubuntu Linux 14.04 amd64
> Reporter: Juanm Manuel Enrique Muñido
> Assignee: Jason Greene
>
> I have been successfully deploying an application on WildFly 8.2.1 and WildFly 9.0.2 versions with the following <jsp-config> directives in web.xml deployment descriptor:
> <jsp-config>
> <jsp-property-group>
> <description>header and footer settings</description>
> <url-pattern>/WEB-INF/view/*</url-pattern>
> <url-pattern>/WEB-INF/error/*</url-pattern>
> <include-prelude>/WEB-INF/jspf/header.jspf</include-prelude>
> <include-coda>/WEB-INF/jspf/footer.jspf</include-coda>
> </jsp-property-group>
> </jsp-config>
> This code fragment includes the contents of /WEB-INF/jspf/header.jspf at the beginning of each .jsp file and <include-coda>/WEB-INF/jspf/footer.jspf</include-coda> at the end of each .jsp file that matches the <url-pattern>.
> But when I try to deploy this application with the same deployment descriptor in WildFly 10.0.0.Final, the contents of /WEB-INF/jspf/header.jspf and /WEB-INF/jspf/footer.jspf are included twice in each .jsp file that matches the <url-pattern>.
> If I add another <url-pattern> line, then the contents of /WEB-INF/jspf/header.jspf and /WEB-INF/jspf/footer.jspf are included three times, and so on.
> Any suggestion about this issue?
> Is this a deployment descriptor issue or a configuration issue in the standalone.xml of WildFly 10.0.0.Final version?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFLY-6136) Wildfly 10.0.0.Final duplitates contents of <jsp-config><include-prelude> or <include-coda> directives un web.xml
by Juanm Manuel Enrique Muñido (JIRA)
Juanm Manuel Enrique Muñido created WFLY-6136:
-------------------------------------------------
Summary: Wildfly 10.0.0.Final duplitates contents of <jsp-config><include-prelude> or <include-coda> directives un web.xml
Key: WFLY-6136
URL: https://issues.jboss.org/browse/WFLY-6136
Project: WildFly
Issue Type: Bug
Affects Versions: 10.0.0.Final
Environment: Ubuntu Linux 14.04 amd64
Reporter: Juanm Manuel Enrique Muñido
Assignee: Jason Greene
I have been successfully deploying an application on WildFly 8.2.1 and WildFly 9.0.2 versions with the following <jsp-config> directives in web.xml deployment descriptor:
<jsp-config>
<jsp-property-group>
<description>header and footer settings</description>
<url-pattern>/WEB-INF/view/*</url-pattern>
<url-pattern>/WEB-INF/error/*</url-pattern>
<include-prelude>/WEB-INF/jspf/header.jspf</include-prelude>
<include-coda>/WEB-INF/jspf/footer.jspf</include-coda>
</jsp-property-group>
</jsp-config>
This code fragment includes the contents of /WEB-INF/jspf/header.jspf at the beginning of each .jsp file and <include-coda>/WEB-INF/jspf/footer.jspf</include-coda> at the end of each .jsp file that matches the <url-pattern>.
But when I try to deploy this application with the same deployment descriptor in WildFly 10.0.0.Final, the contents of /WEB-INF/jspf/header.jspf and /WEB-INF/jspf/footer.jspf are included twice in each .jsp file that matches the <url-pattern>.
If I add another <url-pattern> line, then the contents of /WEB-INF/jspf/header.jspf and /WEB-INF/jspf/footer.jspf are included three times, and so on.
Any suggestion about this issue?
Is this a deployment descriptor issue or a configuration issue in the standalone.xml of WildFly 10.0.0.Final version?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFLY-6127) Throw IllegalStateException if JTA tx has an unsynchronized persistence context and the target is synchronized persistence context
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-6127?page=com.atlassian.jira.plugin.... ]
Scott Marlow commented on WFLY-6127:
------------------------------------
I pushed a better version of the fix to https://github.com/scottmarlow/wildfly/tree/WFLY-6127 and squashed the commits (so previous concern mentioned about the downside is address). With the new change, we only introduce a little more overhead for unsynchronized persistence contexts.
> Throw IllegalStateException if JTA tx has an unsynchronized persistence context and the target is synchronized persistence context
> ----------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-6127
> URL: https://issues.jboss.org/browse/WFLY-6127
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 9.0.2.Final
> Reporter: Mazen Mahmoud
> Assignee: Scott Marlow
> Priority: Minor
> Fix For: 10.1.0.Final
>
> Attachments: server-log.txt
>
>
> SPEC: If a component is called and the JTA transaction is propagated into that component:
> If there is a persistence context of type SynchronizationType.UNSYNCHRONIZED
> associated with the JTA transaction and the target component specifies a persistence context of type SynchronizationType.SYNCHRONIZED, the IllegalStateException is thrown by the container
> We have a stateful session bean (SFB1) / PC: TRANSACTION/UNSYNCHRONIZED)
> stateful session bean (SFB2) / PC: TRANSACTION/SYNCHRONIZED)
> SFB1 method M1 (REQUIRED) calls SFB2 Method 2 (REQUIRED):
> PC is propagated from SFB1 to SFB2 without any exception.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months