[JBoss JIRA] (JGRP-2253) FD_SOCK is not working in AWS environment
by Sibin Karnavar (JIRA)
[ https://issues.jboss.org/browse/JGRP-2253?page=com.atlassian.jira.plugin.... ]
Sibin Karnavar commented on JGRP-2253:
--------------------------------------
I have done below changes. I am attaching the logs below.
1) <TCP
external_addr="${ext-addr}"
bind_addr="match-interface:eth0"
.........../>
2) <FD_SOCK external_port="7804" external_addr="${ext-addr}" bind_addr="match-interface:eth0"/>
3) Added -Dext-addr as the IP address of the EC2 node
4)Enabled the Trace log for FD_SOCK.
You wil see that, socket connections break is not immediately detected after I kill one of the node.
> FD_SOCK is not working in AWS environment
> -----------------------------------------
>
> Key: JGRP-2253
> URL: https://issues.jboss.org/browse/JGRP-2253
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.10
> Environment: AWS - EC2
> Reporter: Sibin Karnavar
> Assignee: Bela Ban
>
> We have our failure detection defined like below.
> <FD_SOCK external_port="7804" />
> <FD timeout="3000" max_tries="3" />
> <VERIFY_SUSPECT timeout="3000" />
> Please note that we have used FD instead of FD_ALL in AWS. We will be changing it to FD_ALL later after detailed testing.
> In my local, this is working perfect. As soon as I kill my node, I was able to see that view change was happening immediately with FD_SOCK.
> We were not mentioning the external_port in the FD_SOCK but later I thought it may be an issue with the port and defined it as 7804 and added the same port to the security group that allows to access this port among all the nodes. So no issue with the port.
> Can you please let us know if we need any additional configurations to make FD_SOCK works well in AWS.
> Thanks,
> Sibin
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 7 months
[JBoss JIRA] (WFLY-9878) EclipseLink Entity Scanning broken in Wildfly 11
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-9878?page=com.atlassian.jira.plugin.... ]
Scott Marlow updated WFLY-9878:
-------------------------------
Fix Version/s: (was: 12.0.0.Final)
> EclipseLink Entity Scanning broken in Wildfly 11
> ------------------------------------------------
>
> Key: WFLY-9878
> URL: https://issues.jboss.org/browse/WFLY-9878
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 11.0.0.Final
> Environment: Enterprise Maven Project
> Wildfly 11
> Eclipse Link 2.7.1 (2.6.3 and 2.64 were also tested)
> Reporter: Alessandro Moscatelli
> Assignee: Scott Marlow
>
> Following :
> https://docs.jboss.org/author/display/WFLY/JPA+Reference+Guide#JPAReferen...
> When you try to persist ANY entity (located in ejb, or jar or anywhere you want) if such entity is not listed in persistence.xml you'll get a :
> Caused by: javax.ejb.EJBException: java.lang.IllegalArgumentException: Object: org.visiontech.optoplus.entity.Provider[ id=null ] is not a known Entity type
> If I list such entity in persistence.xml the error is gone and the entity is persisted.
> Inside standalone.xml I used :
> <system-properties>
> ...
> <property name="eclipselink.archive.factory" value="org.jipijapa.eclipselink.JBossArchiveFactoryImpl"/>
> </system-properties>
> Is this a problem related to the last version (11 Final) of jipijapa.eclipselink ?
> I found several topic stating that what I done worked with Wildfly 10 and older version of jipijapa.
> I tried several combination of older jipijapa and eclipselink versions without success.
> I have about 130 entities in my probject, I'd REALLY love not to enlist them all.
> My persistence.xml :
> <persistence-unit name="optoplus">
> <provider>org.eclipse.persistence.jpa.PersistenceProvider</provider>
> <jta-data-source>java:/jdbc/db_optoplus</jta-data-source>
> <exclude-unlisted-classes>false</exclude-unlisted-classes>
> </persistence-unit>
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 7 months
[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)
6 years, 7 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)
6 years, 7 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)
6 years, 7 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)
6 years, 7 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)
6 years, 7 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)
6 years, 7 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)
6 years, 7 months