[JBoss JIRA] (WFCORE-3872) Upgrade to WildFly Galleon plugins 1.0.0.CR11 and fork embedded in the build
by Alexey Loubyansky (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3872?page=com.atlassian.jira.plugi... ]
Alexey Loubyansky updated WFCORE-3872:
--------------------------------------
Description: 1.0.0.CR11 significantly reduces the classpath prepared by the plugins to launch the embedded server and also adds an option to execute the embedded in a separate process to avoid FD leaks in jboss-modules. (was: 1.0.0.CR10 significantly reduces the classpath prepared by the plugins to launch the embedded server and also adds an option to execute the embedded in a separate process to avoid FD leaks in jboss-modules.)
Summary: Upgrade to WildFly Galleon plugins 1.0.0.CR11 and fork embedded in the build (was: Upgrade to WildFly Galleon plugins 1.0.0.CR10 and fork embedded in the build)
> Upgrade to WildFly Galleon plugins 1.0.0.CR11 and fork embedded in the build
> ----------------------------------------------------------------------------
>
> Key: WFCORE-3872
> URL: https://issues.jboss.org/browse/WFCORE-3872
> Project: WildFly Core
> Issue Type: Component Upgrade
> Components: Build System
> Reporter: Alexey Loubyansky
> Assignee: Alexey Loubyansky
>
> 1.0.0.CR11 significantly reduces the classpath prepared by the plugins to launch the embedded server and also adds an option to execute the embedded in a separate process to avoid FD leaks in jboss-modules.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFCORE-3884) Securing EJB with legacy ldap realm does not work
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3884?page=com.atlassian.jira.plugi... ]
Darran Lofthouse updated WFCORE-3884:
-------------------------------------
Fix Version/s: 5.0.0.Beta5
> Securing EJB with legacy ldap realm does not work
> -------------------------------------------------
>
> Key: WFCORE-3884
> URL: https://issues.jboss.org/browse/WFCORE-3884
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Affects Versions: 3.1.0.Final
> Reporter: Martin Choma
> Assignee: Darran Lofthouse
> Priority: Blocker
> Fix For: 5.0.0.Beta5
>
>
> Use Case: securing EJB with legacy ldap realm
> {code}
> javax.naming.NamingException: WFLYNAM0027: Failed instantiate InitialContextFactory com.sun.jndi.ldap.LdapCtxFactory from classloader ModuleClassLoader for Module "org.wildfly.extension.io" version 5.0.0.Final-redhat-20180517 from local module loader @2ea6137 (finder: local module finder @41ee392b (roots: /home/mchoma/Repos/tests-ldap-kerberos/tests/target/dist/jboss-eap/modules,/home/mchoma/Repos/tests-ldap-kerberos/tests/target/dist/jboss-eap/modules/system/layers/base)) [Root exception is java.lang.ClassNotFoundException: com.sun.jndi.ldap.LdapCtxFactory from [Module "org.wildfly.extension.io" version 5.0.0.Final-redhat-20180517 from local module loader @2ea6137 (finder: local module finder @41ee392b (roots: /home/mchoma/Repos/tests-ldap-kerberos/tests/target/dist/jboss-eap/modules,/home/mchoma/Repos/tests-ldap-kerberos/tests/target/dist/jboss-eap/modules/system/layers/base))]]
> {code}
> from
> {code}
> Thread [default task-1] (Suspended)
> owns: AuthenticationTimeoutSaslServerFactory$DelegatingTimeoutSaslServer (id=500)
> UserLdapCallbackHandler.lambda$getPrincipalMapper$0(Principal) line: 143
> 2024198162.apply(Object) line: not available
> 712660640(Function<T,R>).lambda$andThen$1(Function, Object) line: 88
> 1508181426.apply(Object) line: not available
> ServerAuthenticationContext.rewriteAll(Principal, Function<Principal,Principal>, Function<Principal,Principal>, Function<Principal,Principal>) line: 1114
> ServerAuthenticationContext.assignName(SecurityIdentity, MechanismConfiguration, MechanismRealmConfiguration, Principal, Evidence, IdentityCredentials, IdentityCredentials, boolean) line: 1144
> ServerAuthenticationContext$InitialState(ServerAuthenticationContext$UnassignedState).setPrincipal(Principal, boolean) line: 1691
> ServerAuthenticationContext.setAuthenticationPrincipal(Principal, boolean) line: 408
> ServerAuthenticationContext.setAuthenticationName(String, boolean) line: 382
> ServerAuthenticationContext.setAuthenticationName(String) line: 366
> ServerAuthenticationContext$1.handleOne(Callback[], int) line: 898
> ServerAuthenticationContext$1.handle(Callback[]) line: 839
> TrustManagerSaslServerFactory.lambda$createSaslServer$0(CallbackHandler, Callback[]) line: 96
> 1848118324.handle(Callback[]) line: not available
> PlainSaslServer.evaluateResponse(byte[]) line: 117
> AuthenticationCompleteCallbackSaslServerFactory$1.evaluateResponse(byte[]) line: 58
> AuthenticationTimeoutSaslServerFactory$DelegatingTimeoutSaslServer.evaluateResponse(byte[]) line: 106
> SecurityIdentitySaslServerFactory$1.evaluateResponse(byte[]) line: 59
> SaslUtils.evaluateResponse(SaslServer, ByteBuffer) line: 245
> SaslUtils.evaluateResponse(SaslServer, ByteBuffer, ByteBuffer) line: 217
> ServerConnectionOpenListener$AuthStepRunnable.run() line: 486
> EndpointImpl$TrackingExecutor.lambda$execute$0(Runnable) line: 926
> 1160617561.run() line: not available
> ContextClassLoaderSavingRunnable.run() line: 35
> EnhancedQueueExecutor.safeRun(Runnable) line: 1985
> EnhancedQueueExecutor$ThreadBody.doRunTask(Runnable) line: 1487
> EnhancedQueueExecutor$ThreadBody.run() line: 1349
> Thread.run() line: 748
> {code}
> Please also log somewhere this exception. It was very hard to find out.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFCORE-3884) Securing EJB with legacy ldap realm does not work
by Martin Choma (JIRA)
Martin Choma created WFCORE-3884:
------------------------------------
Summary: Securing EJB with legacy ldap realm does not work
Key: WFCORE-3884
URL: https://issues.jboss.org/browse/WFCORE-3884
Project: WildFly Core
Issue Type: Bug
Components: Security
Affects Versions: 3.1.0.Final
Reporter: Martin Choma
Assignee: Darran Lofthouse
Priority: Blocker
Use Case: securing EJB with legacy ldap realm
{code}
javax.naming.NamingException: WFLYNAM0027: Failed instantiate InitialContextFactory com.sun.jndi.ldap.LdapCtxFactory from classloader ModuleClassLoader for Module "org.wildfly.extension.io" version 5.0.0.Final-redhat-20180517 from local module loader @2ea6137 (finder: local module finder @41ee392b (roots: /home/mchoma/Repos/tests-ldap-kerberos/tests/target/dist/jboss-eap/modules,/home/mchoma/Repos/tests-ldap-kerberos/tests/target/dist/jboss-eap/modules/system/layers/base)) [Root exception is java.lang.ClassNotFoundException: com.sun.jndi.ldap.LdapCtxFactory from [Module "org.wildfly.extension.io" version 5.0.0.Final-redhat-20180517 from local module loader @2ea6137 (finder: local module finder @41ee392b (roots: /home/mchoma/Repos/tests-ldap-kerberos/tests/target/dist/jboss-eap/modules,/home/mchoma/Repos/tests-ldap-kerberos/tests/target/dist/jboss-eap/modules/system/layers/base))]]
{code}
from
{code}
Thread [default task-1] (Suspended)
owns: AuthenticationTimeoutSaslServerFactory$DelegatingTimeoutSaslServer (id=500)
UserLdapCallbackHandler.lambda$getPrincipalMapper$0(Principal) line: 143
2024198162.apply(Object) line: not available
712660640(Function<T,R>).lambda$andThen$1(Function, Object) line: 88
1508181426.apply(Object) line: not available
ServerAuthenticationContext.rewriteAll(Principal, Function<Principal,Principal>, Function<Principal,Principal>, Function<Principal,Principal>) line: 1114
ServerAuthenticationContext.assignName(SecurityIdentity, MechanismConfiguration, MechanismRealmConfiguration, Principal, Evidence, IdentityCredentials, IdentityCredentials, boolean) line: 1144
ServerAuthenticationContext$InitialState(ServerAuthenticationContext$UnassignedState).setPrincipal(Principal, boolean) line: 1691
ServerAuthenticationContext.setAuthenticationPrincipal(Principal, boolean) line: 408
ServerAuthenticationContext.setAuthenticationName(String, boolean) line: 382
ServerAuthenticationContext.setAuthenticationName(String) line: 366
ServerAuthenticationContext$1.handleOne(Callback[], int) line: 898
ServerAuthenticationContext$1.handle(Callback[]) line: 839
TrustManagerSaslServerFactory.lambda$createSaslServer$0(CallbackHandler, Callback[]) line: 96
1848118324.handle(Callback[]) line: not available
PlainSaslServer.evaluateResponse(byte[]) line: 117
AuthenticationCompleteCallbackSaslServerFactory$1.evaluateResponse(byte[]) line: 58
AuthenticationTimeoutSaslServerFactory$DelegatingTimeoutSaslServer.evaluateResponse(byte[]) line: 106
SecurityIdentitySaslServerFactory$1.evaluateResponse(byte[]) line: 59
SaslUtils.evaluateResponse(SaslServer, ByteBuffer) line: 245
SaslUtils.evaluateResponse(SaslServer, ByteBuffer, ByteBuffer) line: 217
ServerConnectionOpenListener$AuthStepRunnable.run() line: 486
EndpointImpl$TrackingExecutor.lambda$execute$0(Runnable) line: 926
1160617561.run() line: not available
ContextClassLoaderSavingRunnable.run() line: 35
EnhancedQueueExecutor.safeRun(Runnable) line: 1985
EnhancedQueueExecutor$ThreadBody.doRunTask(Runnable) line: 1487
EnhancedQueueExecutor$ThreadBody.run() line: 1349
Thread.run() line: 748
{code}
Please also log somewhere this exception. It was very hard to find out.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFLY-10404) Review/revise 2lc caching design
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-10404?page=com.atlassian.jira.plugin... ]
Scott Marlow updated WFLY-10404:
--------------------------------
Description:
Review cache isolation, cache region factories, override ISPN default behavior to handle more efficient names, updates to infinispan-hibernate-cache-spi, app configuration choices for choosing different strategies.
* Avoid the ByteString byte length limitation of 255 ([https://github.com/infinispan/infinispan/commit/046517fc0829bb0a1768169e5...]) in region name prefix + region name as cache key. Also see [https://issues.jboss.org/browse/ISPN-9206].
* Enhance the org.jboss.as.jpa.hibernate5.service.WildFlyCustomRegionFactoryInitiator to improve caching for:
** container managed persistence units
** non-container-managed persistence unit (e.g. native Hibernate or app calls into javax.persistence.Persistence.createEntityManagerFactory())
** WildFlyCustomRegionFactoryInitiator cannot start an Infinispan cache by default, should we offer an API/SPI that Spring could implement for specifying the cache (service) to be used for a particular persistence unit? The application could specify the custom API/SPI implementation class via a persistence unit property.
*** Currently, Hibernate defaults the 2lc on but that fails when the Infinispan cache is not automatically started, so WildFlyCustomRegionFactoryInitiator defaults caching off.
*** If this is not possible, then keep the current WildFlyCustomRegionFactoryInitiator logic to default Hibernate caching off, unless the app requests caching via configuration settings.
was:
Review cache isolation, cache region factories, override ISPN default behavior to handle more efficient names, updates to infinispan-hibernate-cache-spi, app configuration choices for choosing different strategies.
* Avoid the ByteString byte length limitation of 255 ([https://github.com/infinispan/infinispan/commit/046517fc0829bb0a1768169e5...]) in region name prefix + region name as cache key. Also see [https://issues.jboss.org/browse/ISPN-9206].
* Enhance the org.jboss.as.jpa.hibernate5.service.WildFlyCustomRegionFactoryInitiator to improve caching for:
** container managed persistence units
** non-container-managed persistence unit (e.g. native Hibernate or app calls into javax.persistence.Persistence.createEntityManagerFactory())
** Update WildFlyCustomRegionFactoryInitiator to start an Infinispan cache by default (e.g. if no other caching config props are specified) that works with clustering/standalone WF use.
*** Currently, Hibernate defaults the 2lc on but that fails when the Infinispan cache is not automatically started, so WildFlyCustomRegionFactoryInitiator defaults caching off.
*** If this is not possible, then keep the current WildFlyCustomRegionFactoryInitiator logic to default Hibernate caching off, unless the app requests caching via configuration settings.
> Review/revise 2lc caching design
> --------------------------------
>
> Key: WFLY-10404
> URL: https://issues.jboss.org/browse/WFLY-10404
> Project: WildFly
> Issue Type: Feature Request
> Components: Clustering, JPA / Hibernate
> Affects Versions: 13.0.0.Beta1
> Reporter: Scott Marlow
> Assignee: Paul Ferraro
> Fix For: 14.0.0.CR1
>
>
> Review cache isolation, cache region factories, override ISPN default behavior to handle more efficient names, updates to infinispan-hibernate-cache-spi, app configuration choices for choosing different strategies.
> * Avoid the ByteString byte length limitation of 255 ([https://github.com/infinispan/infinispan/commit/046517fc0829bb0a1768169e5...]) in region name prefix + region name as cache key. Also see [https://issues.jboss.org/browse/ISPN-9206].
> * Enhance the org.jboss.as.jpa.hibernate5.service.WildFlyCustomRegionFactoryInitiator to improve caching for:
> ** container managed persistence units
> ** non-container-managed persistence unit (e.g. native Hibernate or app calls into javax.persistence.Persistence.createEntityManagerFactory())
> ** WildFlyCustomRegionFactoryInitiator cannot start an Infinispan cache by default, should we offer an API/SPI that Spring could implement for specifying the cache (service) to be used for a particular persistence unit? The application could specify the custom API/SPI implementation class via a persistence unit property.
> *** Currently, Hibernate defaults the 2lc on but that fails when the Infinispan cache is not automatically started, so WildFlyCustomRegionFactoryInitiator defaults caching off.
> *** If this is not possible, then keep the current WildFlyCustomRegionFactoryInitiator logic to default Hibernate caching off, unless the app requests caching via configuration settings.
>
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFLY-10404) Review/revise 2lc caching design
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-10404?page=com.atlassian.jira.plugin... ]
Scott Marlow updated WFLY-10404:
--------------------------------
Description:
Review cache isolation, cache region factories, override ISPN default behavior to handle more efficient names, updates to infinispan-hibernate-cache-spi, app configuration choices for choosing different strategies.
* Avoid the ByteString byte length limitation of 255 ([https://github.com/infinispan/infinispan/commit/046517fc0829bb0a1768169e5...]) in region name prefix + region name as cache key. Also see [https://issues.jboss.org/browse/ISPN-9206].
* Enhance the org.jboss.as.jpa.hibernate5.service.WildFlyCustomRegionFactoryInitiator to improve caching for:
** container managed persistence units
** non-container-managed persistence unit (e.g. native Hibernate or app calls into javax.persistence.Persistence.createEntityManagerFactory())
** Update WildFlyCustomRegionFactoryInitiator to start an Infinispan cache by default (e.g. if no other caching config props are specified) that works with clustering/standalone WF use.
*** Currently, Hibernate defaults the 2lc on but that fails when the Infinispan cache is not automatically started, so WildFlyCustomRegionFactoryInitiator defaults caching off.
*** If this is not possible, then keep the current WildFlyCustomRegionFactoryInitiator logic to default Hibernate caching off, unless the app requests caching via configuration settings.
was:
Review cache isolation, cache region factories, override ISPN default behavior to handle more efficient names, updates to infinispan-hibernate-cache-spi, app configuration choices for choosing different strategies.
* Avoid the ByteString byte length limitation of 255 ([https://github.com/infinispan/infinispan/commit/046517fc0829bb0a1768169e5...]) in region name prefix + region name as cache key.
* Enhance the org.jboss.as.jpa.hibernate5.service.WildFlyCustomRegionFactoryInitiator to improve caching for:
** container managed persistence units
** non-container-managed persistence unit (e.g. native Hibernate or app calls into javax.persistence.Persistence.createEntityManagerFactory())
** Update WildFlyCustomRegionFactoryInitiator to start an Infinispan cache by default (e.g. if no other caching config props are specified) that works with clustering/standalone WF use.
*** Currently, Hibernate defaults the 2lc on but that fails when the Infinispan cache is not automatically started, so WildFlyCustomRegionFactoryInitiator defaults caching off.
*** If this is not possible, then keep the current WildFlyCustomRegionFactoryInitiator logic to default Hibernate caching off, unless the app requests caching via configuration settings.
> Review/revise 2lc caching design
> --------------------------------
>
> Key: WFLY-10404
> URL: https://issues.jboss.org/browse/WFLY-10404
> Project: WildFly
> Issue Type: Feature Request
> Components: Clustering, JPA / Hibernate
> Affects Versions: 13.0.0.Beta1
> Reporter: Scott Marlow
> Assignee: Paul Ferraro
> Fix For: 14.0.0.CR1
>
>
> Review cache isolation, cache region factories, override ISPN default behavior to handle more efficient names, updates to infinispan-hibernate-cache-spi, app configuration choices for choosing different strategies.
> * Avoid the ByteString byte length limitation of 255 ([https://github.com/infinispan/infinispan/commit/046517fc0829bb0a1768169e5...]) in region name prefix + region name as cache key. Also see [https://issues.jboss.org/browse/ISPN-9206].
> * Enhance the org.jboss.as.jpa.hibernate5.service.WildFlyCustomRegionFactoryInitiator to improve caching for:
> ** container managed persistence units
> ** non-container-managed persistence unit (e.g. native Hibernate or app calls into javax.persistence.Persistence.createEntityManagerFactory())
> ** Update WildFlyCustomRegionFactoryInitiator to start an Infinispan cache by default (e.g. if no other caching config props are specified) that works with clustering/standalone WF use.
> *** Currently, Hibernate defaults the 2lc on but that fails when the Infinispan cache is not automatically started, so WildFlyCustomRegionFactoryInitiator defaults caching off.
> *** If this is not possible, then keep the current WildFlyCustomRegionFactoryInitiator logic to default Hibernate caching off, unless the app requests caching via configuration settings.
>
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFLY-10438) Create a regression mixed-domain test for a missing host-exclude
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-10438?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFLY-10438:
------------------------------------
Description:
We need a simple domain mode smoke test that will fail if a new extension is added without corresponding adjustments to the domain.xml host-exclude resources.
I had a complicated slow approach in mind that I wrote here before; it's stricken out below.
Much simpler approach:
Add a test to testsuite domain that uses a DC running the standard domain.xml. Read from the DC all the extensions. Work through the host-exclude resources. For each host-exclude, take a copy of the set of extensions, remove those listed in the host-exclude and compare the result to a known correct set of extensions for that version.
If we add a new extension and don't host-exclude it, this will fail. This really is all that's needed to avoid completely skipping the host-excludes.
If we add a new host-exclude and don't add the correct set of extensions to the test, the test will fail. This will help ensure the test isn't completely unmaintained.
It doesn't cover people forgetting to add a new legacy version host-exclude when adding the first extension in a new version, but that can be tracked via code review or just being reasonably careful.
Original complicated approach:
-We need a simple test that a slave running the version before the current one can boot and run a minimal server. Basically to catch the need for a fix like WFLY-10396 whenever we add a new extension.
Something like:
Base domain config must be the standard one we ship. It will include all extensions.
Test adds a minimal profile -- bare bones logging subsystem or perhaps no subsystem at all, can only have config that has been legal from the beginning -- and a server group using that profile. The server-group is added to the 'active-server-groups' attribute in the host-exclude resource for the slave's version.
Slave host.xml has 1 server only, and in that server group.
Launch the DC using the current release and the slave using the legacy release. Prove the slave server can start.-
was:
We need a simple test that a slave running the version before the current one can boot and run a minimal server. Basically to catch the need for a fix like WFLY-10396 whenever we add a new extension.
Something like:
Base domain config must be the standard one we ship. It will include all extensions.
Test adds a minimal profile -- bare bones logging subsystem or perhaps no subsystem at all, can only have config that has been legal from the beginning -- and a server group using that profile. The server-group is added to the 'active-server-groups' attribute in the host-exclude resource for the slave's version.
Slave host.xml has 1 server only, and in that server group.
Launch the DC using the current release and the slave using the legacy release. Prove the slave server can start.
> Create a regression mixed-domain test for a missing host-exclude
> ----------------------------------------------------------------
>
> Key: WFLY-10438
> URL: https://issues.jboss.org/browse/WFLY-10438
> Project: WildFly
> Issue Type: Task
> Components: Management, Test Suite
> Reporter: Brian Stansberry
> Assignee: Jeff Mesnil
>
> We need a simple domain mode smoke test that will fail if a new extension is added without corresponding adjustments to the domain.xml host-exclude resources.
> I had a complicated slow approach in mind that I wrote here before; it's stricken out below.
> Much simpler approach:
> Add a test to testsuite domain that uses a DC running the standard domain.xml. Read from the DC all the extensions. Work through the host-exclude resources. For each host-exclude, take a copy of the set of extensions, remove those listed in the host-exclude and compare the result to a known correct set of extensions for that version.
> If we add a new extension and don't host-exclude it, this will fail. This really is all that's needed to avoid completely skipping the host-excludes.
> If we add a new host-exclude and don't add the correct set of extensions to the test, the test will fail. This will help ensure the test isn't completely unmaintained.
> It doesn't cover people forgetting to add a new legacy version host-exclude when adding the first extension in a new version, but that can be tracked via code review or just being reasonably careful.
> Original complicated approach:
> -We need a simple test that a slave running the version before the current one can boot and run a minimal server. Basically to catch the need for a fix like WFLY-10396 whenever we add a new extension.
> Something like:
> Base domain config must be the standard one we ship. It will include all extensions.
> Test adds a minimal profile -- bare bones logging subsystem or perhaps no subsystem at all, can only have config that has been legal from the beginning -- and a server group using that profile. The server-group is added to the 'active-server-groups' attribute in the host-exclude resource for the slave's version.
> Slave host.xml has 1 server only, and in that server group.
> Launch the DC using the current release and the slave using the legacy release. Prove the slave server can start.-
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFLY-10438) Create a domain testsuite smoke test for a missing host-exclude
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-10438?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFLY-10438:
------------------------------------
Summary: Create a domain testsuite smoke test for a missing host-exclude (was: Create a regression mixed-domain test for a missing host-exclude)
> Create a domain testsuite smoke test for a missing host-exclude
> ---------------------------------------------------------------
>
> Key: WFLY-10438
> URL: https://issues.jboss.org/browse/WFLY-10438
> Project: WildFly
> Issue Type: Task
> Components: Management, Test Suite
> Reporter: Brian Stansberry
> Assignee: Jeff Mesnil
>
> We need a simple domain mode smoke test that will fail if a new extension is added without corresponding adjustments to the domain.xml host-exclude resources.
> I had a complicated slow approach in mind that I wrote here before; it's stricken out below.
> Much simpler approach:
> Add a test to testsuite domain that uses a DC running the standard domain.xml. Read from the DC all the extensions. Work through the host-exclude resources. For each host-exclude, take a copy of the set of extensions, remove those listed in the host-exclude and compare the result to a known correct set of extensions for that version.
> If we add a new extension and don't host-exclude it, this will fail. This really is all that's needed to avoid completely skipping the host-excludes.
> If we add a new host-exclude and don't add the correct set of extensions to the test, the test will fail. This will help ensure the test isn't completely unmaintained.
> It doesn't cover people forgetting to add a new legacy version host-exclude when adding the first extension in a new version, but that can be tracked via code review or just being reasonably careful.
> Original complicated approach:
> -We need a simple test that a slave running the version before the current one can boot and run a minimal server. Basically to catch the need for a fix like WFLY-10396 whenever we add a new extension.
> Something like:
> Base domain config must be the standard one we ship. It will include all extensions.
> Test adds a minimal profile -- bare bones logging subsystem or perhaps no subsystem at all, can only have config that has been legal from the beginning -- and a server group using that profile. The server-group is added to the 'active-server-groups' attribute in the host-exclude resource for the slave's version.
> Slave host.xml has 1 server only, and in that server group.
> Launch the DC using the current release and the slave using the legacy release. Prove the slave server can start.-
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFLY-10417) Security API - Soteria - Jaspic - Error getting ServerAuthContext
by Alessandro Moscatelli (JIRA)
[ https://issues.jboss.org/browse/WFLY-10417?page=com.atlassian.jira.plugin... ]
Alessandro Moscatelli updated WFLY-10417:
-----------------------------------------
Steps to Reproduce:
Create an EAR Application with two WAR Web Application inside.
Create a jboss-app.xml for the EAR or/and two jboss-web.xml for the WARs declaring the security domain.
Create an implementation of HttpAuthenticationMechanism interface where you want (inside an Ejb module or in both the WARs Application).
Any combination of the above will trigger the problem anyway.
Now build and deploy on Wildfly 13 Beta 1, restart Wildfly.
Only one of the two Web Application will be able to obtain the ServerAuthContext after the restart.
was:
Create an EAR Application with two WAR Web Application inside.
Create a jboss-app.xml for the EAR or/and two jboss-web.xml for the WARs declaring the security domain.
Create an implementation of HttpAuthenticationMechanism interface where you want (inside an Ejb module or in both the WARs Application).
Any combination of the above will trigger the problem anyway.
Now build and deploy on Wildfly 13 Beta 1, restart Wildfly.
Only one of the two Web Application will be able to obtain the ServerAuthContext.
> Security API - Soteria - Jaspic - Error getting ServerAuthContext
> -----------------------------------------------------------------
>
> Key: WFLY-10417
> URL: https://issues.jboss.org/browse/WFLY-10417
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 13.0.0.Beta1
> Environment: Wildfly 13.0.0.Beta1 and an EAR Application using JavaEE 8 Security API
> Reporter: Alessandro Moscatelli
> Assignee: Darran Lofthouse
> Priority: Critical
> Fix For: 13.0.0.CR1
>
> Attachments: image-2018-05-24-13-41-05-322.png, soteria.zip
>
>
> I am testing the new Wildfly release and the new Java EE8 Security API.
> I noticed this serious (I truly believe) bug, and it also accours almost randomly.
>
> The deployed application is an EAR.
>
> If I deploy the EAR with a started Wildfly 13.0.0.Beta1 everything is fine.
> Then if I stop and start / restart the application server, I can see the startup and the EAR is redeployed but sometimes (like 50% of time) the bug/error accours.
> Usually after a couple of times (stop/start/restart) I can reproduce the issue.
> Before the bug accours every call to pages and APIs works correctly. After the bug accours every call triggers the AuthException.
> After the bug accours, if I redeploy the SAME EAR everything is fine again 100% of times.
> This seems like Wildfly does something different when redeploying an application on startup and when being already startup up and then processing an application deploy.
>
> I can provide my EAR if you want, but I would prefer not to if this is not necessary.
> The security domain as defined as suggested :
>
> <security-domain name="auth" cache-type="default">
> <authentication-jaspi>
> <login-module-stack name="dummy">
> <login-module code="Dummy" flag="optional"/>
> </login-module-stack>
> <auth-module code="Dummy"/>
> </authentication-jaspi>
> </security-domain>
>
> META-INF/jboss-app.xml inside the EAR :
>
> <?xml version="1.0" encoding="UTF-8"?>
> <jboss-app>
> <security-domain>auth</security-domain>
> </jboss-app>
>
> META-INF/jboss-web.xml inside the WAR inside the EAR :
>
> <?xml version="1.0" encoding="UTF-8"?>
> <jboss-web>
> <security-domain>auth</security-domain>
> </jboss-web>
>
> Log :
>
> 17:04:18,556 ERROR [org.jboss.security] (default task-1) PBOX00374: Error getting ServerAuthContext for authContextId default-host /optoplus-services-web and security domain auth: javax.security.auth.message.AuthException
> at org.jboss.security.auth.message.config.JBossServerAuthConfig.getAuthContext(JBossServerAuthConfig.java:187)
> at org.jboss.security.plugins.auth.JASPIServerAuthenticationManager.isValid(JASPIServerAuthenticationManager.java:99)
> at org.wildfly.extension.undertow.security.jaspi.JASPICAuthenticationMechanism.authenticate(JASPICAuthenticationMechanism.java:123)
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:245)
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$100(SecurityContextImpl.java:231)
> at io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:125)
> at io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:99)
> at io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:92)
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55)
> at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53)
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59)
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.security.jaspi.JASPICSecureResponseHandler.handleRequest(JASPICSecureResponseHandler.java:48)
> at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1514)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1514)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1514)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1514)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1514)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:360)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:830)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
> at java.lang.Thread.run(Thread.java:748)
> UPDATE !!
> Now I finally got WHY it was random !!
> The problem is related to EAR containing multiple WAR registering different contexts :
> 13:29:37,661 INFO [org.glassfish.soteria.servlet.SamRegistrationInstaller] (ServerService Thread Pool -- 80) Initializing Soteria 1.0 for context '/soteria-web2'
> 13:29:37,661 INFO [org.glassfish.soteria.servlet.SamRegistrationInstaller] (ServerService Thread Pool -- 76) Initializing Soteria 1.0 for context '/soteria-web'
> 13:29:37,738 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 80) WFLYUT0021: Registered web context: '/soteria-web2' for server 'default-server'
> 13:29:37,745 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 76) WFLYUT0021: Registered web context: '/soteria-web' for server 'default-server'
> 13:29:37,781 INFO [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0010: Deployed "soteria-ear-1.0.0.ear" (runtime-name : "soteria-ear-1.0.0.ear")
> 13:29:37,908 INFO [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0212: Resuming server
> 13:29:37,910 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://0.0.0.0:9990/management
> 13:29:37,910 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://0.0.0.0:9990
> 13:29:37,910 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Full 13.0.0.Beta1 (WildFly Core 5.0.0.Beta3) started in 10500ms - Started 707 of 931 services (430 services are lazy, passive or on-demand)
> 13:30:09,195 ERROR [org.jboss.security] (default task-1) PBOX00374: Error getting ServerAuthContext for authContextId default-host /soteria-web and security domain auth: javax.security.auth.message.AuthException
> *+In case of a reboot (or stop and start) of Wildfly, only ONE of the TWO contexts manages to get the ServerAuthContext !+*
> I attached an example project you can use to reproduce and detailed steps !
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month