[JBoss JIRA] (WFLY-11259) Wildfly 11.0.0.Final org.dom4j.DocumentFactory cannot be cast to org.dom4j.DocumentFactory
by Adam Bialas (Jira)
[ https://issues.jboss.org/browse/WFLY-11259?page=com.atlassian.jira.plugin... ]
Adam Bialas commented on WFLY-11259:
------------------------------------
Stacktrace:
20:48:56,043 INFO [org.hibernate.envers.boot.internal.EnversServiceImpl] (ServerService Thread Pool -- 71) Envers integration enabled? : true
20:49:12,554 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 71) MSC000001: Failed to start service jboss.persistenceunit."aaa.ear/bbb.war#bbb-default": org.jboss.msc.service.StartException in service jboss.persistenceunit."aaa.ear/bbb.war#bbb-default": 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:195)
at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:125)
at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:640)
at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:209)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
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:358)
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:848)
at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:875)
at org.jboss.as.jpa.hibernate5.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44)
at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:167)
... 7 more
> Wildfly 11.0.0.Final org.dom4j.DocumentFactory cannot be cast to org.dom4j.DocumentFactory
> ------------------------------------------------------------------------------------------
>
> Key: WFLY-11259
> URL: https://issues.jboss.org/browse/WFLY-11259
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 11.0.0.Final
> Reporter: Adam Bialas
> Assignee: Scott Marlow
> Priority: Major
>
> I have an ear file which I want to deploy to the Wildfly 11.0.0.Final. In this ear file in the lib folder I have dom4j-2.0.1.jar. One of the sub deployments (war) uses JPA (no dependencies to hibernate, just to javax.javaee-api as compile only). This sub deployment contains of course the persistence.xml file. I see in the logs that when the application server starts and loads this file the following exception is thrown:
> org.dom4j.DocumentFactory cannot be cast to org.dom4j.DocumentFactory
> and the application fails to deploy.
> I checked many posts and forums on the net and as far as I understand I must exclude the dom4j provided by the application server so the jar located in the lib folder of ear can be used.
> I created jboss-deployment-structure:
> <?xml version="1.0" encoding="UTF-8"?>
> <jboss-deployment-structure>
> <deployment>
> <exclusions>
> <module name="org.dom4j"/>
> </exclusions>
> </deployment>
> </jboss-deployment-structure>
> Even though I get the same exception so I suppose both jars are loaded and cause problems.
> I checked how class loading works on Wildfly 11.0.0 in comparison to JBoss EAP 7.1. In both cases this class is first loaded from provided 1.6.1 jar. JBoss does not load the newer version. However, Wildfly does and here is the problem.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (JBEE-159) PropertyNotFoundException when the property is a JDK8 defender method
by Karsten Wutzke (Jira)
[ https://issues.jboss.org/browse/JBEE-159?page=com.atlassian.jira.plugin.s... ]
Karsten Wutzke commented on JBEE-159:
-------------------------------------
My original SO question is here:
https://stackoverflow.com/questions/53111221/java-8-default-method-throws...
It was marked as a duplicate of:
https://stackoverflow.com/questions/37205642/java-8-default-interface-met...
The workaround described there is to use methods as-is, calling #{blaBean.getPassword()} instead of the property #{blaBean.password}.
Please fix nonetheless...
> PropertyNotFoundException when the property is a JDK8 defender method
> ---------------------------------------------------------------------
>
> Key: JBEE-159
> URL: https://issues.jboss.org/browse/JBEE-159
> Project: JBoss JavaEE Spec APIs
> Issue Type: Enhancement
> Components: jboss-el-api
> Affects Versions: jboss-el-api_3.0_spec-1.0.2.Final
> Reporter: Rich DiCroce
> Assignee: Scott Marlow
> Priority: Minor
> Labels: java8
>
> I have a class that implements an interface that uses Java 8's new defender methods feature. Some getters on the interface have default implementations, and the concrete classes don't override them.
> If I try to refer to one of these getters as a property like so:
> {code:xml}
> value="#{cc.filter.filter.valueChoices}"
> {code}
> Then I get this exception:
> {noformat}
> Caused by: javax.el.PropertyNotFoundException: The class 'com.lapis.jsf.framework.dao.search.DefaultEntityFilter' does not have the property 'valueChoices'.
> at javax.el.BeanELResolver.getBeanProperty(BeanELResolver.java:731) [jboss-el-api_3.0_spec-1.0.3.Final.jar:1.0.3.Final]
> at javax.el.BeanELResolver.getValue(BeanELResolver.java:351) [jboss-el-api_3.0_spec-1.0.3.Final.jar:1.0.3.Final]
> at com.sun.faces.el.DemuxCompositeELResolver._getValue(DemuxCompositeELResolver.java:176) [jsf-impl-2.2.6-jbossorg-4.jar:]
> at com.sun.faces.el.DemuxCompositeELResolver.getValue(DemuxCompositeELResolver.java:203) [jsf-impl-2.2.6-jbossorg-4.jar:]
> at com.sun.el.parser.AstValue.getValue(AstValue.java:140) [javax.el-3.0.0.jar:]
> at com.sun.el.parser.AstValue.getValue(AstValue.java:204) [javax.el-3.0.0.jar:]
> at com.sun.el.parser.AstEmpty.getValue(AstEmpty.java:66) [javax.el-3.0.0.jar:]
> at com.sun.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:226) [javax.el-3.0.0.jar:]
> at org.jboss.weld.el.WeldValueExpression.getValue(WeldValueExpression.java:50) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
> at org.jboss.weld.el.WeldValueExpression.getValue(WeldValueExpression.java:50) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
> at com.sun.faces.facelets.el.ContextualCompositeValueExpression.getValue(ContextualCompositeValueExpression.java:158) [jsf-impl-2.2.6-jbossorg-4.jar:]
> at com.sun.faces.facelets.el.TagValueExpression.getValue(TagValueExpression.java:109) [jsf-impl-2.2.6-jbossorg-4.jar:]
> ... 68 more
> {noformat}
> Two workarounds exist. One: you can override the default method in a concrete class and have it just call the default super method. Two: you can call the getter using a method expression instead of a value expression.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (JBEE-159) PropertyNotFoundException when the property is a JDK8 defender method
by Karsten Wutzke (Jira)
[ https://issues.jboss.org/browse/JBEE-159?page=com.atlassian.jira.plugin.s... ]
Karsten Wutzke commented on JBEE-159:
-------------------------------------
Still a problem on Wildfly 14.
I think the priority is obsolete. Maybe it used to be not as important, but three years later it should be considered Major - at least.
Its really being a problem creating a Java 8 business architecture initially and then having to fallback to pre Java 8.
Please vote.
> PropertyNotFoundException when the property is a JDK8 defender method
> ---------------------------------------------------------------------
>
> Key: JBEE-159
> URL: https://issues.jboss.org/browse/JBEE-159
> Project: JBoss JavaEE Spec APIs
> Issue Type: Enhancement
> Components: jboss-el-api
> Affects Versions: jboss-el-api_3.0_spec-1.0.2.Final
> Reporter: Rich DiCroce
> Assignee: Scott Marlow
> Priority: Minor
> Labels: java8
>
> I have a class that implements an interface that uses Java 8's new defender methods feature. Some getters on the interface have default implementations, and the concrete classes don't override them.
> If I try to refer to one of these getters as a property like so:
> {code:xml}
> value="#{cc.filter.filter.valueChoices}"
> {code}
> Then I get this exception:
> {noformat}
> Caused by: javax.el.PropertyNotFoundException: The class 'com.lapis.jsf.framework.dao.search.DefaultEntityFilter' does not have the property 'valueChoices'.
> at javax.el.BeanELResolver.getBeanProperty(BeanELResolver.java:731) [jboss-el-api_3.0_spec-1.0.3.Final.jar:1.0.3.Final]
> at javax.el.BeanELResolver.getValue(BeanELResolver.java:351) [jboss-el-api_3.0_spec-1.0.3.Final.jar:1.0.3.Final]
> at com.sun.faces.el.DemuxCompositeELResolver._getValue(DemuxCompositeELResolver.java:176) [jsf-impl-2.2.6-jbossorg-4.jar:]
> at com.sun.faces.el.DemuxCompositeELResolver.getValue(DemuxCompositeELResolver.java:203) [jsf-impl-2.2.6-jbossorg-4.jar:]
> at com.sun.el.parser.AstValue.getValue(AstValue.java:140) [javax.el-3.0.0.jar:]
> at com.sun.el.parser.AstValue.getValue(AstValue.java:204) [javax.el-3.0.0.jar:]
> at com.sun.el.parser.AstEmpty.getValue(AstEmpty.java:66) [javax.el-3.0.0.jar:]
> at com.sun.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:226) [javax.el-3.0.0.jar:]
> at org.jboss.weld.el.WeldValueExpression.getValue(WeldValueExpression.java:50) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
> at org.jboss.weld.el.WeldValueExpression.getValue(WeldValueExpression.java:50) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
> at com.sun.faces.facelets.el.ContextualCompositeValueExpression.getValue(ContextualCompositeValueExpression.java:158) [jsf-impl-2.2.6-jbossorg-4.jar:]
> at com.sun.faces.facelets.el.TagValueExpression.getValue(TagValueExpression.java:109) [jsf-impl-2.2.6-jbossorg-4.jar:]
> ... 68 more
> {noformat}
> Two workarounds exist. One: you can override the default method in a concrete class and have it just call the default super method. Two: you can call the getter using a method expression instead of a value expression.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (WFLY-11278) Management Console Replace Deployment file chooser doesn't select file
by Ian Roskam (Jira)
Ian Roskam created WFLY-11278:
---------------------------------
Summary: Management Console Replace Deployment file chooser doesn't select file
Key: WFLY-11278
URL: https://issues.jboss.org/browse/WFLY-11278
Project: WildFly
Issue Type: Bug
Components: Management
Affects Versions: 14.0.0.Final
Environment: Server on Solaris 11.3
User on Windows 10 Chrome 69.0.3497.92 (Official Build) (64-bit)
Reporter: Ian Roskam
Assignee: Jeff Mesnil
When clicking "Choose a file or drag it here" in the Replace Deployment dialog the OS file chooser appears. The selected file does not get set in the Replace Deployment dialog. Dragging the file into the dialog does work.
To reproduce:
Deployments tab
Choose to Replace a deployment
Click "Choose a file or drag it here" link in the Replace Deployment dialog.
Select war to deploy in OS file chooser.
Press OK.
Expected result:
File is set in dialog so replacement can proceed.
Actual result:
File is +not+ set in dialog and replacement cannot proceed.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months