[JBoss JIRA] (JGRP-2154) FRAG3: create full message up front
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2154?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-2154.
----------------------------
Resolution: Done
> FRAG3: create full message up front
> -----------------------------------
>
> Key: JGRP-2154
> URL: https://issues.jboss.org/browse/JGRP-2154
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Labels: CR2
> Fix For: 4.0
>
>
> In FRAG2, a full message to be passed up the stack is created when all fragments have been received. Say we send a 30K message and frag_size is 8000 bytes. On the sender side, FRAG2 will create the following fragments: {{1:8000 2:8000 3:8000 4:6000}}.
> When fragment 1 is received, it is added to a fragment list. When all 4 fragments have been received, a full message of 30K is created and the 4 fragments' buffers are copied into the full message's buffer.
> FRAG2's memory allocation is therefore:
> * T1: 8000 // fragment 1 has been received
> * T2: 16000 // fragment 2 has been received
> * T3: 24000 // fragment 3 has been received
> * T4: 30000 // fragment 4 has been received
> * T4: 30000 + 30000 // full message is created and all 4 fragments are still in the list
> * T4: 30000 // full message is being delivered up the stack, and fragments have been removed
> * T5: 0 // full message has been delivered and can be garbage collected
> In FRAG3, the full message of 30K is created on reception of the first fragment. Fragments are not stored in a fragment list, but directly copied into the full message as soon as they have been received. Each fragment carries its offset and length, and the size of the full message, so the full message can be created on reception of the first fragment.
> The advantage is that the fragment list does not need to be maintained and fragments can be discarded as soon as they've been copied into the full message.
> Also, instead of allocating 60K of memory, only 30K are allocated.
> The disadvantage is that the full message is created up front, and remains in memory until the last segment has been received and the message has been delivered to the application.
> FRAG3's memory allocation looks as follows:
> * T1: 30000 // the full message is created on reception of fragment 1, frag is copied into the full message
> * T2: 30000 // fragment 2 has been received, copied into the full message and discarded
> * T3: 30000 // fragment 3 has been received, copied into the full message and discarded
> * T4: 30000 // fragment 4 has been received, copied into the full message and discarded
> * T4: 30000 // full message is being delivered up the stack, and fragments have been removed
> * T5: 0 // full message has been delivered and can be garbage collected
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 3 months
[JBoss JIRA] (WFLY-7995) Packed deployment doesn't work
by Ray Lloy BISSIELOU NZAO (JIRA)
Ray Lloy BISSIELOU NZAO created WFLY-7995:
---------------------------------------------
Summary: Packed deployment doesn't work
Key: WFLY-7995
URL: https://issues.jboss.org/browse/WFLY-7995
Project: WildFly
Issue Type: Bug
Reporter: Ray Lloy BISSIELOU NZAO
Assignee: Jason Greene
Priority: Blocker
Hello,
I am new in Wildfly.
I try to migrate my application form *JBoss EAP 6* to *wildfly-10.1.0.Final*.
When I use a compressed archive wilth *JBoss EAP 6*, it works fine. But When I use the same compressed archive with *wildfly-10.1.0.Final*, I can't access to the index.jsp.
When I look in %JBOSS_HOME%\standalone\tmp\Myapplication.ear.Myapplication.war
there is nothing, my jsp are not compiled.
Is there a way to fix it ?
Thanks in advance.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 3 months
[JBoss JIRA] (WFLY-7994) Legacy Kerberos in management, EAP search for HTTPS/localhost ticket
by Martin Choma (JIRA)
Martin Choma created WFLY-7994:
----------------------------------
Summary: Legacy Kerberos in management, EAP search for HTTPS/localhost ticket
Key: WFLY-7994
URL: https://issues.jboss.org/browse/WFLY-7994
Project: WildFly
Issue Type: Bug
Components: Security
Reporter: Martin Choma
Assignee: Darran Lofthouse
Priority: Blocker
Accessing management interface secured by Kerberos + TLS causes EAP requests from KDC ticket HTTPS/localhost. Which was not necessary in EAP 7.0 and it worked fine with HTTP/localhost service name
{code:title=server.log}
14:20:19,321 TRACE [org.jboss.as.domain.management.security] (management task-7) No mapping for name 'https/localhost.localdomain' to KeytabService, attempting to use host only match.
14:20:19,322 TRACE [org.jboss.as.domain.management.security] (management task-7) Selected KeytabService with principal 'HTTP/localhost.localdomain(a)JBOSS.ORG' for host 'localhost.localdomain'
14:20:19,322 INFO [stdout] (management task-7) Found KeyTab /home/mchoma/workspace/git-repositories/tests-ldap-kerberos-eap7/eap7/target/krb/krb.2269988831769483313.keytab for HTTP/localhost.localdomain(a)JBOSS.ORG
14:20:19,323 INFO [stdout] (management task-7) Found KeyTab /home/mchoma/workspace/git-repositories/tests-ldap-kerberos-eap7/eap7/target/krb/krb.2269988831769483313.keytab for HTTP/localhost.localdomain(a)JBOSS.ORG
14:20:19,323 INFO [stdout] (management task-7) Found KeyTab /home/mchoma/workspace/git-repositories/tests-ldap-kerberos-eap7/eap7/target/krb/krb.2269988831769483313.keytab for HTTP/localhost.localdomain(a)JBOSS.ORG
14:20:19,323 INFO [stdout] (management task-7) Found KeyTab /home/mchoma/workspace/git-repositories/tests-ldap-kerberos-eap7/eap7/target/krb/krb.2269988831769483313.keytab for HTTP/localhost.localdomain(a)JBOSS.ORG
14:20:19,524 WARN [org.apache.directory.server.protocol.shared.kerberos.StoreUtils] (NioDatagramAcceptor-3) No server entry found for kerberos principal name HTTPS/localhost.localdomain(a)JBOSS.ORG
14:20:19,524 WARN [org.apache.directory.server.KERBEROS_LOG] (NioDatagramAcceptor-3) No server entry found for kerberos principal name HTTPS/localhost.localdomain(a)JBOSS.ORG
14:20:19,524 WARN [org.apache.directory.server.kerberos.protocol.KerberosProtocolHandler] (NioDatagramAcceptor-3) Server not found in Kerberos database (7)
14:20:19,525 WARN [org.apache.directory.server.KERBEROS_LOG] (NioDatagramAcceptor-3) Server not found in Kerberos database (7)
14:20:19,528 WARN [org.apache.http.impl.auth.HttpAuthenticator] (main) NEGOTIATE authentication error: No valid credentials provided (Mechanism level: No valid credentials provided (Mechanism level: Server not found in Kerberos database (7) - Server not found in Kerberos database))
14:20:19,532 TRACE [org.jboss.as.domain.management.security] (management task-9) No mapping for name 'https/localhost.localdomain' to KeytabService, attempting to use host only match.
14:20:19,532 TRACE [org.jboss.as.domain.management.security] (management task-9) Selected KeytabService with principal 'HTTP/localhost.localdomain(a)JBOSS.ORG' for host 'localhost.localdomain'
14:20:19,533 INFO [stdout] (management task-9) Found KeyTab /home/mchoma/workspace/git-repositories/tests-ldap-kerberos-eap7/eap7/target/krb/krb.2269988831769483313.keytab for HTTP/localhost.localdomain(a)JBOSS.ORG
14:20:19,533 INFO [stdout] (management task-9) Found KeyTab /home/mchoma/workspace/git-repositories/tests-ldap-kerberos-eap7/eap7/target/krb/krb.2269988831769483313.keytab for HTTP/localhost.localdomain(a)JBOSS.ORG
14:20:19,533 INFO [stdout] (management task-9) Found KeyTab /home/mchoma/workspace/git-repositories/tests-ldap-kerberos-eap7/eap7/target/krb/krb.2269988831769483313.keytab for HTTP/localhost.localdomain(a)JBOSS.ORG
14:20:19,533 INFO [stdout] (management task-9) Found KeyTab /home/mchoma/workspace/git-repositories/tests-ldap-kerberos-eap7/eap7/target/krb/krb.2269988831769483313.keytab for HTTP/localhost.localdomain(a)JBOSS.ORG
[Krb5LoginModule]: Entering logout
[Krb5LoginModule]: logged out Subject
{code}
Also see network dump krb_https_management.pcap in attachement, where TGS-REQ for HTTPS/localhost is captured.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 3 months
[JBoss JIRA] (WFLY-7993) Legacy Kerberos in management, unable to configure fallback authentication.
by Martin Choma (JIRA)
Martin Choma created WFLY-7993:
----------------------------------
Summary: Legacy Kerberos in management, unable to configure fallback authentication.
Key: WFLY-7993
URL: https://issues.jboss.org/browse/WFLY-7993
Project: WildFly
Issue Type: Bug
Components: Security
Reporter: Martin Choma
Assignee: Darran Lofthouse
Priority: Blocker
In EAP 7.0 there was possible to configure fallback (e.g. BASIC) authentication, if client does not support SPNEGO authentication. In EAP 7.1 this feature does not work anymore.
In EAP 7.0 server returns multiple chalanges (Negotiate/Basic) and client could choose which he will use.
{code:title=EAP 7.0}
HTTP/1.1 401 Unauthorized
Connection: keep-alive
WWW-Authenticate: Negotiate
WWW-Authenticate: Basic realm="FallBackKerberosRealm"
X-Frame-Options: SAMEORIGIN
Content-Length: 77
Content-Type: text/html
Date: Mon, 30 Jan 2017 11:02:45 GMT
<html><head><title>Error</title></head><body>401 - Unauthorized</body></html>
{code}
In EAP 7.1 (with same configuration) server returns only one chalange - Negotiate so client not supporting SPNEGO, can't fallback to Basic.
{code:title=EAP 7.1}
HTTP/1.1 401 Unauthorized
Connection: keep-alive
WWW-Authenticate: Negotiate
X-Frame-Options: SAMEORIGIN
Content-Length: 77
Content-Type: text/html
Date: Mon, 30 Jan 2017 11:01:28 GMT
<html><head><title>Error</title></head><body>401 - Unauthorized</body></html>
{code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 3 months
[JBoss JIRA] (WFLY-7992) Rework ClientCompatibilityUnitTestCase to use ClientCompatibilityUnitTestBase from core testsuite/share
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-7992?page=com.atlassian.jira.plugin.... ]
Kabir Khan updated WFLY-7992:
-----------------------------
Description:
WFCORE-2196 copies ClientCompatibilityUnitTestCase into core, and makes most of the code available in ClientCompatibilityUnitTestBase in testsuite/shared.
Once merged, WFLY's copy of ClientCompatibilityUnitTestCase should be adjusted to reuse the code from the shared class.
was:WFCORE-2196 copies
> Rework ClientCompatibilityUnitTestCase to use ClientCompatibilityUnitTestBase from core testsuite/share
> -------------------------------------------------------------------------------------------------------
>
> Key: WFLY-7992
> URL: https://issues.jboss.org/browse/WFLY-7992
> Project: WildFly
> Issue Type: Task
> Components: Domain Management
> Reporter: Kabir Khan
> Assignee: Kabir Khan
>
> WFCORE-2196 copies ClientCompatibilityUnitTestCase into core, and makes most of the code available in ClientCompatibilityUnitTestBase in testsuite/shared.
> Once merged, WFLY's copy of ClientCompatibilityUnitTestCase should be adjusted to reuse the code from the shared class.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 3 months
[JBoss JIRA] (WFLY-7992) Rework ClientCompatibilityUnitTestCase to use ClientCompatibilityUnitTestBase from core testsuite/share
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-7992?page=com.atlassian.jira.plugin.... ]
Kabir Khan moved WFCORE-2243 to WFLY-7992:
------------------------------------------
Project: WildFly (was: WildFly Core)
Key: WFLY-7992 (was: WFCORE-2243)
Component/s: Domain Management
(was: Domain Management)
> Rework ClientCompatibilityUnitTestCase to use ClientCompatibilityUnitTestBase from core testsuite/share
> -------------------------------------------------------------------------------------------------------
>
> Key: WFLY-7992
> URL: https://issues.jboss.org/browse/WFLY-7992
> Project: WildFly
> Issue Type: Task
> Components: Domain Management
> Reporter: Kabir Khan
> Assignee: Kabir Khan
>
> [3:44 PM] Kabir Khan: @DarranLofthouse I see this in the logs
> [3:44 PM] Kabir Khan: 2017-01-16 15:38:55,589 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC000001: Failed to start service org.wildfly.security.security-realm.ManagementRealm: org.jboss.msc.service.StartException in service org.wildfly.security.security-realm.ManagementRealm: Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1919)
> 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)
> Caused by: java.lang.NoSuchMethodError: org.wildfly.security.auth.realm.LegacyPropertiesSecurityRealm$Builder.setDefaultRealm(Ljava/lang/String;)Lorg/wildfly/security/auth/realm/LegacyPropertiesSecurityRealm$Builder;
> at org.wildfly.extension.elytron.PropertiesRealmDefinition$1$1.get(PropertiesRealmDefinition.java:187)
> at org.wildfly.extension.elytron.PropertiesRealmDefinition$1$1.get(PropertiesRealmDefinition.java:171)
> at org.wildfly.extension.elytron.TrivialService.start(TrivialService.java:53)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1963)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1896)
> ... 3 more
> [3:44 PM] Kabir Khan: @BrianStansberry perhaps ClientCompatibilityUnitTestCase should be in core rather than full?
> [3:47 PM] Darran Lofthouse: @KabirKhan do we have any error as to why it is not up?
> [3:47 PM] Kabir Khan: Yes, the NoSuchErrorException
> [3:48 PM] Kabir Khan: umm :)
> [3:48 PM] Kabir Khan: I invented a new class
> [3:48 PM] Kabir Khan: NoSuchMethodError
> [3:48 PM] Kabir Khan: I pasted it above my mention of Brian
> [3:49 PM] Kabir Khan: So PropertiesRealmDefinition is calling a non-existent setDefaultRealm() method on LegacyPropertiesSecurityRealm's builder
> [3:49 PM] Darran Lofthouse: @KabirKhan if the method doesn't exist that means the wrong Elytron version is being used
> [3:50 PM] Kabir Khan: Argh
> [3:50 PM] Kabir Khan: I released core without your PR merged
> [3:50 PM] Darran Lofthouse: LOL - that would explain how the wrong Elytron version is being used ;-)
> [3:51 PM] Kabir Khan: ok, I'll try again
> [3:53 PM] Brian Stansberry: @KabirKhan perhaps but I bet there was a reason we didn't move it
> [3:55 PM] Kabir Khan: On the positive side, it is not the night before the release
> [3:58 PM] Brian Stansberry: @KabirKhan if there is such a reason I don't see it in the code for that test
> [3:58 PM] Kabir Khan: yeah, me neither
> [3:59 PM] Kabir Khan: @BrianStansberry I'll rerelease core to fix my previous error
> [3:59 PM] Kabir Khan: but can look into this
> [3:59 PM] Kabir Khan: I'll create a Jira so I remember
> [3:59 PM] Brian Stansberry: @KabirKhan thanks
> [4:00 PM] Kabir Khan: although, I guess in this case it was a good thing
> [4:00 PM] Brian Stansberry: @KabirKhan tangent: do you recall if in the mixed domain tests we have the test driver invoke any ops against the legacy slave?
> [4:00 PM] Kabir Khan: this was what alerted e to the problem
> [4:00 PM] Kabir Khan: @BrianStansberry not off the top of my head, but I'd guess there should be at least some direct read-resource calls
> [4:00 PM] Brian Stansberry: @KabirKhan ah, you mean it was something in the full config that failed, that wouldn't be in core?
> [4:01 PM] Brian Stansberry: i'd say we shouldn't move that test but instead copy it
> [4:01 PM] Kabir Khan: @BrianStansberry there was an update to the elytron subsystem in full calling some stuff in Elytron
> [4:02 PM] Kabir Khan: that Elytron stuff wasn't there, because I had forgotten to merge the core PR that brought it in the Elytron upgrade
> [4:02 PM] Kabir Khan: so I saw NoSuchMethodErrors
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 3 months
[JBoss JIRA] (WFLY-7992) Rework ClientCompatibilityUnitTestCase to use ClientCompatibilityUnitTestBase from core testsuite/share
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-7992?page=com.atlassian.jira.plugin.... ]
Kabir Khan updated WFLY-7992:
-----------------------------
Description: WFCORE-2196 copies (was: [3:44 PM] Kabir Khan: @DarranLofthouse I see this in the logs
[3:44 PM] Kabir Khan: 2017-01-16 15:38:55,589 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC000001: Failed to start service org.wildfly.security.security-realm.ManagementRealm: org.jboss.msc.service.StartException in service org.wildfly.security.security-realm.ManagementRealm: Failed to start service
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1919)
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)
Caused by: java.lang.NoSuchMethodError: org.wildfly.security.auth.realm.LegacyPropertiesSecurityRealm$Builder.setDefaultRealm(Ljava/lang/String;)Lorg/wildfly/security/auth/realm/LegacyPropertiesSecurityRealm$Builder;
at org.wildfly.extension.elytron.PropertiesRealmDefinition$1$1.get(PropertiesRealmDefinition.java:187)
at org.wildfly.extension.elytron.PropertiesRealmDefinition$1$1.get(PropertiesRealmDefinition.java:171)
at org.wildfly.extension.elytron.TrivialService.start(TrivialService.java:53)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1963)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1896)
... 3 more
[3:44 PM] Kabir Khan: @BrianStansberry perhaps ClientCompatibilityUnitTestCase should be in core rather than full?
[3:47 PM] Darran Lofthouse: @KabirKhan do we have any error as to why it is not up?
[3:47 PM] Kabir Khan: Yes, the NoSuchErrorException
[3:48 PM] Kabir Khan: umm :)
[3:48 PM] Kabir Khan: I invented a new class
[3:48 PM] Kabir Khan: NoSuchMethodError
[3:48 PM] Kabir Khan: I pasted it above my mention of Brian
[3:49 PM] Kabir Khan: So PropertiesRealmDefinition is calling a non-existent setDefaultRealm() method on LegacyPropertiesSecurityRealm's builder
[3:49 PM] Darran Lofthouse: @KabirKhan if the method doesn't exist that means the wrong Elytron version is being used
[3:50 PM] Kabir Khan: Argh
[3:50 PM] Kabir Khan: I released core without your PR merged
[3:50 PM] Darran Lofthouse: LOL - that would explain how the wrong Elytron version is being used ;-)
[3:51 PM] Kabir Khan: ok, I'll try again
[3:53 PM] Brian Stansberry: @KabirKhan perhaps but I bet there was a reason we didn't move it
[3:55 PM] Kabir Khan: On the positive side, it is not the night before the release
[3:58 PM] Brian Stansberry: @KabirKhan if there is such a reason I don't see it in the code for that test
[3:58 PM] Kabir Khan: yeah, me neither
[3:59 PM] Kabir Khan: @BrianStansberry I'll rerelease core to fix my previous error
[3:59 PM] Kabir Khan: but can look into this
[3:59 PM] Kabir Khan: I'll create a Jira so I remember
[3:59 PM] Brian Stansberry: @KabirKhan thanks
[4:00 PM] Kabir Khan: although, I guess in this case it was a good thing
[4:00 PM] Brian Stansberry: @KabirKhan tangent: do you recall if in the mixed domain tests we have the test driver invoke any ops against the legacy slave?
[4:00 PM] Kabir Khan: this was what alerted e to the problem
[4:00 PM] Kabir Khan: @BrianStansberry not off the top of my head, but I'd guess there should be at least some direct read-resource calls
[4:00 PM] Brian Stansberry: @KabirKhan ah, you mean it was something in the full config that failed, that wouldn't be in core?
[4:01 PM] Brian Stansberry: i'd say we shouldn't move that test but instead copy it
[4:01 PM] Kabir Khan: @BrianStansberry there was an update to the elytron subsystem in full calling some stuff in Elytron
[4:02 PM] Kabir Khan: that Elytron stuff wasn't there, because I had forgotten to merge the core PR that brought it in the Elytron upgrade
[4:02 PM] Kabir Khan: so I saw NoSuchMethodErrors)
> Rework ClientCompatibilityUnitTestCase to use ClientCompatibilityUnitTestBase from core testsuite/share
> -------------------------------------------------------------------------------------------------------
>
> Key: WFLY-7992
> URL: https://issues.jboss.org/browse/WFLY-7992
> Project: WildFly
> Issue Type: Task
> Components: Domain Management
> Reporter: Kabir Khan
> Assignee: Kabir Khan
>
> WFCORE-2196 copies
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 3 months
[JBoss JIRA] (WFCORE-2243) Rework ClientCompatibilityUnitTestCase to use ClientCompatibilityUnitTestBase from core testsuite/share
by Kabir Khan (JIRA)
Kabir Khan created WFCORE-2243:
----------------------------------
Summary: Rework ClientCompatibilityUnitTestCase to use ClientCompatibilityUnitTestBase from core testsuite/share
Key: WFCORE-2243
URL: https://issues.jboss.org/browse/WFCORE-2243
Project: WildFly Core
Issue Type: Task
Components: Domain Management
Reporter: Kabir Khan
Assignee: Kabir Khan
[3:44 PM] Kabir Khan: @DarranLofthouse I see this in the logs
[3:44 PM] Kabir Khan: 2017-01-16 15:38:55,589 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC000001: Failed to start service org.wildfly.security.security-realm.ManagementRealm: org.jboss.msc.service.StartException in service org.wildfly.security.security-realm.ManagementRealm: Failed to start service
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1919)
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)
Caused by: java.lang.NoSuchMethodError: org.wildfly.security.auth.realm.LegacyPropertiesSecurityRealm$Builder.setDefaultRealm(Ljava/lang/String;)Lorg/wildfly/security/auth/realm/LegacyPropertiesSecurityRealm$Builder;
at org.wildfly.extension.elytron.PropertiesRealmDefinition$1$1.get(PropertiesRealmDefinition.java:187)
at org.wildfly.extension.elytron.PropertiesRealmDefinition$1$1.get(PropertiesRealmDefinition.java:171)
at org.wildfly.extension.elytron.TrivialService.start(TrivialService.java:53)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1963)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1896)
... 3 more
[3:44 PM] Kabir Khan: @BrianStansberry perhaps ClientCompatibilityUnitTestCase should be in core rather than full?
[3:47 PM] Darran Lofthouse: @KabirKhan do we have any error as to why it is not up?
[3:47 PM] Kabir Khan: Yes, the NoSuchErrorException
[3:48 PM] Kabir Khan: umm :)
[3:48 PM] Kabir Khan: I invented a new class
[3:48 PM] Kabir Khan: NoSuchMethodError
[3:48 PM] Kabir Khan: I pasted it above my mention of Brian
[3:49 PM] Kabir Khan: So PropertiesRealmDefinition is calling a non-existent setDefaultRealm() method on LegacyPropertiesSecurityRealm's builder
[3:49 PM] Darran Lofthouse: @KabirKhan if the method doesn't exist that means the wrong Elytron version is being used
[3:50 PM] Kabir Khan: Argh
[3:50 PM] Kabir Khan: I released core without your PR merged
[3:50 PM] Darran Lofthouse: LOL - that would explain how the wrong Elytron version is being used ;-)
[3:51 PM] Kabir Khan: ok, I'll try again
[3:53 PM] Brian Stansberry: @KabirKhan perhaps but I bet there was a reason we didn't move it
[3:55 PM] Kabir Khan: On the positive side, it is not the night before the release
[3:58 PM] Brian Stansberry: @KabirKhan if there is such a reason I don't see it in the code for that test
[3:58 PM] Kabir Khan: yeah, me neither
[3:59 PM] Kabir Khan: @BrianStansberry I'll rerelease core to fix my previous error
[3:59 PM] Kabir Khan: but can look into this
[3:59 PM] Kabir Khan: I'll create a Jira so I remember
[3:59 PM] Brian Stansberry: @KabirKhan thanks
[4:00 PM] Kabir Khan: although, I guess in this case it was a good thing
[4:00 PM] Brian Stansberry: @KabirKhan tangent: do you recall if in the mixed domain tests we have the test driver invoke any ops against the legacy slave?
[4:00 PM] Kabir Khan: this was what alerted e to the problem
[4:00 PM] Kabir Khan: @BrianStansberry not off the top of my head, but I'd guess there should be at least some direct read-resource calls
[4:00 PM] Brian Stansberry: @KabirKhan ah, you mean it was something in the full config that failed, that wouldn't be in core?
[4:01 PM] Brian Stansberry: i'd say we shouldn't move that test but instead copy it
[4:01 PM] Kabir Khan: @BrianStansberry there was an update to the elytron subsystem in full calling some stuff in Elytron
[4:02 PM] Kabir Khan: that Elytron stuff wasn't there, because I had forgotten to merge the core PR that brought it in the Elytron upgrade
[4:02 PM] Kabir Khan: so I saw NoSuchMethodErrors
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 3 months
[JBoss JIRA] (WFCORE-2242) Broken logout from Web console when is used Elytron subsystem
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2242?page=com.atlassian.jira.plugi... ]
Darran Lofthouse updated WFCORE-2242:
-------------------------------------
Description:
When we use EAP with Elytron (standalone-elytron.xml configuration file) we aren't able to logout from Web console.
With legacy security realms everything is ok.
*How to reproduce*
* start EAP *standalone.sh -c=standalone-elytron.xml*
* log in to Web console on http://localhost:9990
* invoke logout
You will get this url http://localhost:9990/logout
{code}
404 - Not Found
{code}
was:
When we use EAP with Elytron (standalone-elytron.xml configuration file) we aren't able to logout from Web console.
With PicketBox is everything ok.
*How to reproduce*
* start EAP *standalone.sh -c=standalone-elytron.xml*
* log in to Web console on http://localhost:9990
* invoke logout
You will get this url http://localhost:9990/logout
{code}
404 - Not Found
{code}
> Broken logout from Web console when is used Elytron subsystem
> -------------------------------------------------------------
>
> Key: WFCORE-2242
> URL: https://issues.jboss.org/browse/WFCORE-2242
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Hynek Švábek
> Assignee: Darran Lofthouse
> Priority: Critical
>
> When we use EAP with Elytron (standalone-elytron.xml configuration file) we aren't able to logout from Web console.
> With legacy security realms everything is ok.
> *How to reproduce*
> * start EAP *standalone.sh -c=standalone-elytron.xml*
> * log in to Web console on http://localhost:9990
> * invoke logout
> You will get this url http://localhost:9990/logout
> {code}
> 404 - Not Found
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 3 months