[JBoss JIRA] (WFLY-5549) org.dom4j.DocumentFactory cannot be cast to org.dom4j.DocumentFactory
by Paul Orozco (JIRA)
[ https://issues.jboss.org/browse/WFLY-5549?page=com.atlassian.jira.plugin.... ]
Paul Orozco commented on WFLY-5549:
-----------------------------------
Thor Lange
You saved my day, I had the exact same problem, and I copied the file into my EAR and it worked
Thank you !
> 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 E. Feria Vila
> 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
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFCORE-3640) CLI, non interactive execution swallows output if user prompting required
by Jean-Francois Denise (JIRA)
Jean-Francois Denise created WFCORE-3640:
--------------------------------------------
Summary: CLI, non interactive execution swallows output if user prompting required
Key: WFCORE-3640
URL: https://issues.jboss.org/browse/WFCORE-3640
Project: WildFly Core
Issue Type: Bug
Components: CLI
Reporter: Jean-Francois Denise
Assignee: Jean-Francois Denise
Priority: Critical
A script contains:
connect
ls -l
CLI launched: boss-cli.sh --file=script
If the connect command implies some userName and password, then from this point the output is collected internally but not printed.
That is a regression. The work around it to establish the connection outside the script.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFCORE-3639) Elytron error message less comprehensive in jdk9 compared to jdk8
by Martin Choma (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3639?page=com.atlassian.jira.plugi... ]
Martin Choma moved ELY-1524 to WFCORE-3639:
-------------------------------------------
Project: WildFly Core (was: WildFly Elytron)
Key: WFCORE-3639 (was: ELY-1524)
Component/s: CLI
(was: Authentication Mechanisms)
Affects Version/s: 4.0.0.Beta1
(was: 1.2.0.Final)
> Elytron error message less comprehensive in jdk9 compared to jdk8
> -----------------------------------------------------------------
>
> Key: WFCORE-3639
> URL: https://issues.jboss.org/browse/WFCORE-3639
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Affects Versions: 4.0.0.Beta1
> Reporter: Martin Choma
>
> I like jdk8 error message where there is obvious GS2-KRB5 has been attempted but failed for some reason, PLAIN has been attempted, but failed for some reason.
> {code:title=jdk8}
> Failed to connect to the controller: Unable to authenticate against controller at localhost:9993: Authentication failed: all available authentication mechanisms failed:
> GS2-KRB5: javax.security.sasl.SaslException: GS2-KRB5: Server rejected authentication
> PLAIN: javax.security.sasl.SaslException: ELY05053: Callback handler failed for unknown reason [Caused by java.io.IOException: Failed to read username: Invalid Usage. Prompt attempted in non-interactive mode. Please check commands or change CLI mode.]
> {code}
> Whereas in jdk9 error message hides the fact GS2-KRB5 was attempted and just prints error for PLAIN mechanism, but does not mention explicitely it is PLAIN mechanism
> {code:title=jdk9}
> Failed to connect to the controller: Unable to authenticate against controller at localhost:9993: Cannot get password: Failed to read username: Invalid Usage. Prompt attempted in non-interactive mode. Please check commands or change CLI mode.
> {code}
> This is general question, but I have hit this with this specific use case:
> 1. server is configured to use GS2-KRB5 and PLAIN
> 2. server is configured with TLS
> 3. client is configured to use GS2-KRB5
> 4. expectation is authentication should be not successful because channel binding GS2-KRB5-PLUS should be used.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFCORE-3639) Elytron error message less comprehensive in jdk9 compared to jdk8
by Martin Choma (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3639?page=com.atlassian.jira.plugi... ]
Martin Choma updated WFCORE-3639:
---------------------------------
Need Info from: (was: David Lloyd, Farah Juma)
> Elytron error message less comprehensive in jdk9 compared to jdk8
> -----------------------------------------------------------------
>
> Key: WFCORE-3639
> URL: https://issues.jboss.org/browse/WFCORE-3639
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Affects Versions: 4.0.0.Beta1
> Reporter: Martin Choma
>
> I like jdk8 error message where there is obvious GS2-KRB5 has been attempted but failed for some reason, PLAIN has been attempted, but failed for some reason.
> {code:title=jdk8}
> Failed to connect to the controller: Unable to authenticate against controller at localhost:9993: Authentication failed: all available authentication mechanisms failed:
> GS2-KRB5: javax.security.sasl.SaslException: GS2-KRB5: Server rejected authentication
> PLAIN: javax.security.sasl.SaslException: ELY05053: Callback handler failed for unknown reason [Caused by java.io.IOException: Failed to read username: Invalid Usage. Prompt attempted in non-interactive mode. Please check commands or change CLI mode.]
> {code}
> Whereas in jdk9 error message hides the fact GS2-KRB5 was attempted and just prints error for PLAIN mechanism, but does not mention explicitely it is PLAIN mechanism
> {code:title=jdk9}
> Failed to connect to the controller: Unable to authenticate against controller at localhost:9993: Cannot get password: Failed to read username: Invalid Usage. Prompt attempted in non-interactive mode. Please check commands or change CLI mode.
> {code}
> This is general question, but I have hit this with this specific use case:
> 1. server is configured to use GS2-KRB5 and PLAIN
> 2. server is configured with TLS
> 3. client is configured to use GS2-KRB5
> 4. expectation is authentication should be not successful because channel binding GS2-KRB5-PLUS should be used.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (ELY-1524) Elytron error message less comprehensive in jdk9 compared to jdk8
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/ELY-1524?page=com.atlassian.jira.plugin.s... ]
Jean-Francois Denise commented on ELY-1524:
-------------------------------------------
I suspect that a different exception causes chaine is present in JDK9 and that the CLI doesn't recognise it. You can move the issue to CLI and WF-CORE.
> Elytron error message less comprehensive in jdk9 compared to jdk8
> -----------------------------------------------------------------
>
> Key: ELY-1524
> URL: https://issues.jboss.org/browse/ELY-1524
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Authentication Mechanisms
> Affects Versions: 1.2.0.Final
> Reporter: Martin Choma
>
> I like jdk8 error message where there is obvious GS2-KRB5 has been attempted but failed for some reason, PLAIN has been attempted, but failed for some reason.
> {code:title=jdk8}
> Failed to connect to the controller: Unable to authenticate against controller at localhost:9993: Authentication failed: all available authentication mechanisms failed:
> GS2-KRB5: javax.security.sasl.SaslException: GS2-KRB5: Server rejected authentication
> PLAIN: javax.security.sasl.SaslException: ELY05053: Callback handler failed for unknown reason [Caused by java.io.IOException: Failed to read username: Invalid Usage. Prompt attempted in non-interactive mode. Please check commands or change CLI mode.]
> {code}
> Whereas in jdk9 error message hides the fact GS2-KRB5 was attempted and just prints error for PLAIN mechanism, but does not mention explicitely it is PLAIN mechanism
> {code:title=jdk9}
> Failed to connect to the controller: Unable to authenticate against controller at localhost:9993: Cannot get password: Failed to read username: Invalid Usage. Prompt attempted in non-interactive mode. Please check commands or change CLI mode.
> {code}
> This is general question, but I have hit this with this specific use case:
> 1. server is configured to use GS2-KRB5 and PLAIN
> 2. server is configured with TLS
> 3. client is configured to use GS2-KRB5
> 4. expectation is authentication should be not successful because channel binding GS2-KRB5-PLUS should be used.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (ELY-1524) Elytron error message less comprehensive in jdk9 compared to jdk8
by Martin Choma (JIRA)
[ https://issues.jboss.org/browse/ELY-1524?page=com.atlassian.jira.plugin.s... ]
Martin Choma commented on ELY-1524:
-----------------------------------
Yes, it was used in both cases jdk8 and jdk9. Could that cause jdk9 error message to be less comprehensive?
> Elytron error message less comprehensive in jdk9 compared to jdk8
> -----------------------------------------------------------------
>
> Key: ELY-1524
> URL: https://issues.jboss.org/browse/ELY-1524
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Authentication Mechanisms
> Affects Versions: 1.2.0.Final
> Reporter: Martin Choma
>
> I like jdk8 error message where there is obvious GS2-KRB5 has been attempted but failed for some reason, PLAIN has been attempted, but failed for some reason.
> {code:title=jdk8}
> Failed to connect to the controller: Unable to authenticate against controller at localhost:9993: Authentication failed: all available authentication mechanisms failed:
> GS2-KRB5: javax.security.sasl.SaslException: GS2-KRB5: Server rejected authentication
> PLAIN: javax.security.sasl.SaslException: ELY05053: Callback handler failed for unknown reason [Caused by java.io.IOException: Failed to read username: Invalid Usage. Prompt attempted in non-interactive mode. Please check commands or change CLI mode.]
> {code}
> Whereas in jdk9 error message hides the fact GS2-KRB5 was attempted and just prints error for PLAIN mechanism, but does not mention explicitely it is PLAIN mechanism
> {code:title=jdk9}
> Failed to connect to the controller: Unable to authenticate against controller at localhost:9993: Cannot get password: Failed to read username: Invalid Usage. Prompt attempted in non-interactive mode. Please check commands or change CLI mode.
> {code}
> This is general question, but I have hit this with this specific use case:
> 1. server is configured to use GS2-KRB5 and PLAIN
> 2. server is configured with TLS
> 3. client is configured to use GS2-KRB5
> 4. expectation is authentication should be not successful because channel binding GS2-KRB5-PLUS should be used.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (ELY-1524) Elytron error message less comprehensive in jdk9 compared to jdk8
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/ELY-1524?page=com.atlassian.jira.plugin.s... ]
Jean-Francois Denise commented on ELY-1524:
-------------------------------------------
[~mchoma] it seems that option --error-on-interact has been passed to CLI. is it the case?
> Elytron error message less comprehensive in jdk9 compared to jdk8
> -----------------------------------------------------------------
>
> Key: ELY-1524
> URL: https://issues.jboss.org/browse/ELY-1524
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Authentication Mechanisms
> Affects Versions: 1.2.0.Final
> Reporter: Martin Choma
>
> I like jdk8 error message where there is obvious GS2-KRB5 has been attempted but failed for some reason, PLAIN has been attempted, but failed for some reason.
> {code:title=jdk8}
> Failed to connect to the controller: Unable to authenticate against controller at localhost:9993: Authentication failed: all available authentication mechanisms failed:
> GS2-KRB5: javax.security.sasl.SaslException: GS2-KRB5: Server rejected authentication
> PLAIN: javax.security.sasl.SaslException: ELY05053: Callback handler failed for unknown reason [Caused by java.io.IOException: Failed to read username: Invalid Usage. Prompt attempted in non-interactive mode. Please check commands or change CLI mode.]
> {code}
> Whereas in jdk9 error message hides the fact GS2-KRB5 was attempted and just prints error for PLAIN mechanism, but does not mention explicitely it is PLAIN mechanism
> {code:title=jdk9}
> Failed to connect to the controller: Unable to authenticate against controller at localhost:9993: Cannot get password: Failed to read username: Invalid Usage. Prompt attempted in non-interactive mode. Please check commands or change CLI mode.
> {code}
> This is general question, but I have hit this with this specific use case:
> 1. server is configured to use GS2-KRB5 and PLAIN
> 2. server is configured with TLS
> 3. client is configured to use GS2-KRB5
> 4. expectation is authentication should be not successful because channel binding GS2-KRB5-PLUS should be used.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-9884) WeldResourceInjectionServices runs into NoSuchElementException when deploying multiple EJBs
by Jacob Ilsø (JIRA)
[ https://issues.jboss.org/browse/WFLY-9884?page=com.atlassian.jira.plugin.... ]
Jacob Ilsø commented on WFLY-9884:
----------------------------------
I have tested the most recent PR and still cannot reproduce the issue, so it looks good to me. :)
> WeldResourceInjectionServices runs into NoSuchElementException when deploying multiple EJBs
> -------------------------------------------------------------------------------------------
>
> Key: WFLY-9884
> URL: https://issues.jboss.org/browse/WFLY-9884
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 11.0.0.Final, 12.0.0.Beta1
> Environment: Windows 8.1 Enterprise.
> Reporter: Jacob Ilsø
> Assignee: Jason Greene
> Attachments: log.txt
>
>
> I have an EAR file with several "@Singleton @Startup" beans. Each bean having a number of @Inject and @Resource fields. When I deploy the EAR in WildFly 11 it sometimes fails with a NoSuchElementException (see [^log.txt] for a full stacktrace).
> I cannot reproduce it consistently but it seems to only happen on a "clean" WildFly installation. I haven't seen this on earlier versions of WildFly.
> Let me know if you want me to try to build an EAR for reproducing this.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months