[JBoss JIRA] (WFLY-10350) Duplicated packages in artemis modules
by Erich Duda (JIRA)
[ https://issues.jboss.org/browse/WFLY-10350?page=com.atlassian.jira.plugin... ]
Erich Duda updated WFLY-10350:
------------------------------
Description:
As you can see in the following report, some Artemis packages are present in multiple jars which are parts of different modules. {{artemis-core-client}} jar is located in main module and {{artemis-commons}} jar is located in {{journal}} module. This is problem for Jigsaw.
Based on the discussion with [~dmlloyd] This can be solved by adding {{filter}} subelement to the artemis-commons to filter out duplicated packages.
{code}
142) [Package org.apache.activemq.artemis.api.core is present in multiple jars [artemis-commons-1.5.5.jbossorg-010.jar, artemis-core-client-1.5.5.jbossorg-010.jar]]
144) [Package org.apache.activemq.artemis.core.buffers.impl is present in multiple jars [artemis-commons-1.5.5.jbossorg-010.jar, artemis-core-client-1.5.5.jbossorg-010.jar]]
./org/apache/activemq/artemis/main/artemis-core-client-1.5.5.jbossorg-010.jar
./org/apache/activemq/artemis/journal/main/artemis-commons-1.5.5.jbossorg-010.jar
{code}
was:
As you can see in the following report, some Artemis packages are present in multiple jars which are parts of different modules. {{artemis-core-client}} jar is located in main module and {{artemis-commons}} jar is located in {{journal}} module. This is problem for Jigsaw.
Based on the discussion with [~dmlloyd] This can be solved by adding {{filter}} subelement to the artemis-commons to filter duplicated packages.
{code}
142) [Package org.apache.activemq.artemis.api.core is present in multiple jars [artemis-commons-1.5.5.jbossorg-010.jar, artemis-core-client-1.5.5.jbossorg-010.jar]]
144) [Package org.apache.activemq.artemis.core.buffers.impl is present in multiple jars [artemis-commons-1.5.5.jbossorg-010.jar, artemis-core-client-1.5.5.jbossorg-010.jar]]
./org/apache/activemq/artemis/main/artemis-core-client-1.5.5.jbossorg-010.jar
./org/apache/activemq/artemis/journal/main/artemis-commons-1.5.5.jbossorg-010.jar
{code}
> Duplicated packages in artemis modules
> --------------------------------------
>
> Key: WFLY-10350
> URL: https://issues.jboss.org/browse/WFLY-10350
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 12.0.0.Final
> Reporter: Erich Duda
> Assignee: Jeff Mesnil
>
> As you can see in the following report, some Artemis packages are present in multiple jars which are parts of different modules. {{artemis-core-client}} jar is located in main module and {{artemis-commons}} jar is located in {{journal}} module. This is problem for Jigsaw.
> Based on the discussion with [~dmlloyd] This can be solved by adding {{filter}} subelement to the artemis-commons to filter out duplicated packages.
> {code}
> 142) [Package org.apache.activemq.artemis.api.core is present in multiple jars [artemis-commons-1.5.5.jbossorg-010.jar, artemis-core-client-1.5.5.jbossorg-010.jar]]
> 144) [Package org.apache.activemq.artemis.core.buffers.impl is present in multiple jars [artemis-commons-1.5.5.jbossorg-010.jar, artemis-core-client-1.5.5.jbossorg-010.jar]]
> ./org/apache/activemq/artemis/main/artemis-core-client-1.5.5.jbossorg-010.jar
> ./org/apache/activemq/artemis/journal/main/artemis-commons-1.5.5.jbossorg-010.jar
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-10350) Duplicated packages in artemis modules
by Erich Duda (JIRA)
Erich Duda created WFLY-10350:
---------------------------------
Summary: Duplicated packages in artemis modules
Key: WFLY-10350
URL: https://issues.jboss.org/browse/WFLY-10350
Project: WildFly
Issue Type: Bug
Components: JMS
Affects Versions: 12.0.0.Final
Reporter: Erich Duda
Assignee: Jeff Mesnil
As you can see in the following report, some Artemis packages are present in multiple jars which are parts of different modules. {{artemis-core-client}} jar is located in main module and {{artemis-commons}} jar is located in {{journal}} module. This is problem for Jigsaw.
Based on the discussion with [~dmlloyd] This can be solved by adding {{filter}} subelement to the artemis-commons to filter duplicated packages.
{code}
142) [Package org.apache.activemq.artemis.api.core is present in multiple jars [artemis-commons-1.5.5.jbossorg-010.jar, artemis-core-client-1.5.5.jbossorg-010.jar]]
144) [Package org.apache.activemq.artemis.core.buffers.impl is present in multiple jars [artemis-commons-1.5.5.jbossorg-010.jar, artemis-core-client-1.5.5.jbossorg-010.jar]]
./org/apache/activemq/artemis/main/artemis-core-client-1.5.5.jbossorg-010.jar
./org/apache/activemq/artemis/journal/main/artemis-commons-1.5.5.jbossorg-010.jar
{code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-10260) NullPointerException when read deployment with jpa
by Claudio Miranda (JIRA)
[ https://issues.jboss.org/browse/WFLY-10260?page=com.atlassian.jira.plugin... ]
Claudio Miranda commented on WFLY-10260:
----------------------------------------
Do you think this fix will make it to WF 13 ?
> NullPointerException when read deployment with jpa
> --------------------------------------------------
>
> Key: WFLY-10260
> URL: https://issues.jboss.org/browse/WFLY-10260
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Reporter: Claudio Miranda
> Assignee: Gail Badner
> Fix For: 13.0.0.Beta1
>
> Attachments: wildfly-kitchensink.war
>
>
> There is a bug when reading deployment information with runtime and recursive.
> Looks like this is a regression from an older bug WFLY-1753
> {code}
> /host=master/server=server-three/deployment=kitchensink.war/subsystem=jpa:read-resource(include-runtime,recursive)
> {code}
> {code}
> [Server:server-three] 12:16:11,551 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 75) WFLYCTL0013: Operation ("read-attribute") failed - address: ([
> [Server:server-three] ("deployment" => "kitchensink.war"),
> [Server:server-three] ("subsystem" => "jpa"),
> [Server:server-three] ("hibernate-persistence-unit" => "kitchensink.war#primary"),
> [Server:server-three] ("entity-cache" => "org.jboss.as.quickstarts.kitchensink.model.Member")
> [Server:server-three] ]): java.lang.NullPointerException
> [Server:server-three] at org.hibernate.internal.CacheImpl.getSecondLevelCacheRegion(CacheImpl.java:376)
> [Server:server-three] at org.hibernate.internal.SessionFactoryImpl.getSecondLevelCacheRegion(SessionFactoryImpl.java:1171)
> [Server:server-three] at org.hibernate.stat.internal.ConcurrentStatisticsImpl.getSecondLevelCacheStatistics(ConcurrentStatisticsImpl.java:334)
> [Server:server-three] at org.jboss.as.jpa.hibernate5.management.HibernateEntityCacheStatistics.getStatistics(HibernateEntityCacheStatistics.java:94)
> [Server:server-three] at org.jboss.as.jpa.hibernate5.management.HibernateEntityCacheStatistics$4.invoke(HibernateEntityCacheStatistics.java:126)
> [Server:server-three] at org.jboss.as.jpa.hibernate5.management.HibernateAbstractStatistics.getValue(HibernateAbstractStatistics.java:99)
> [Server:server-three] at org.jboss.as.jpa.management.ManagementResourceDefinition$1.handle(ManagementResourceDefinition.java:130)
> [Server:server-three] at org.jboss.as.jpa.management.ManagementResourceDefinition$AbstractMetricsHandler.executeRuntimeStep(ManagementResourceDefinition.java:268)
> [Server:server-three] at org.jboss.as.controller.AbstractRuntimeOnlyHandler$1.execute(AbstractRuntimeOnlyHandler.java:59)
> [Server:server-three] at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:982)
> [Server:server-three] at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:726)
> [Server:server-three] at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:450)
> [Server:server-three] at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1408)
> [Server:server-three] at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:423)
> [Server:server-three] at org.jboss.as.controller.ModelControllerImpl.lambda$execute$1(ModelControllerImpl.java:243)
> [Server:server-three] at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:263)
> [Server:server-three] at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:229)
> [Server:server-three] at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:243)
> [Server:server-three] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler.internalExecute(TransactionalProtocolOperationHandler.java:249)
> [Server:server-three] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler.doExecute(TransactionalProtocolOperationHandler.java:190)
> [Server:server-three] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$1.run(TransactionalProtocolOperationHandler.java:143)
> [Server:server-three] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$1.run(TransactionalProtocolOperationHandler.java:139)
> [Server:server-three] at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:263)
> [Server:server-three] at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:229)
> [Server:server-three] at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:198)
> [Server:server-three] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2$1.run(TransactionalProtocolOperationHandler.java:162)
> [Server:server-three] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2$1.run(TransactionalProtocolOperationHandler.java:158)
> [Server:server-three] at java.security.AccessController.doPrivileged(Native Method)
> [Server:server-three] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2.execute(TransactionalProtocolOperationHandler.java:158)
> [Server:server-three] at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70)
> [Server:server-three] at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160)
> [Server:server-three] at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> [Server:server-three] at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> [Server:server-three] at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> [Server:server-three] at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
> [Server:server-three] at java.lang.Thread.run(Thread.java:748)
> [Server:server-three] at org.jboss.threads.JBossThread.run(JBossThread.java:485)
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFCORE-3799) FIPS mode is not detected correctly on JDK 8
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3799?page=com.atlassian.jira.plugi... ]
Darran Lofthouse updated WFCORE-3799:
-------------------------------------
Description:
Trying SSL in FIPS mode I get "KeyManagementException: FIPS mode: only SunJSSE KeyManagers may be used"
{code}
17:45:32,678 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service org.wildfly.security.ssl-context.server-ssl-context: org.jboss.msc.service.StartException in service org.wildfly.security.ssl-context.server-ssl-context: java.security.KeyManagementException: FIPS mode: only SunJSSE KeyManagers may be used
at org.wildfly.extension.elytron.SSLDefinitions$6.lambda$getValueSupplier$1(SSLDefinitions.java:926)
at org.wildfly.extension.elytron.TrivialService.start(TrivialService.java:53)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1714)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1693)
at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1540)
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)
Caused by: java.security.KeyManagementException: FIPS mode: only SunJSSE KeyManagers may be used
at sun.security.ssl.SSLContextImpl.chooseKeyManager(SSLContextImpl.java:149)
at sun.security.ssl.SSLContextImpl.engineInit(SSLContextImpl.java:66)
at javax.net.ssl.SSLContext.init(SSLContext.java:282)
at org.wildfly.security.ssl.SSLContextBuilder.lambda$build$0(SSLContextBuilder.java:372)
at org.wildfly.security.OneTimeSecurityFactory.create(OneTimeSecurityFactory.java:53)
at org.wildfly.extension.elytron.SSLDefinitions$6.lambda$getValueSupplier$1(SSLDefinitions.java:924)
... 9 more
17:45:32,686 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0013: Operation ("add") failed - address: ([
("subsystem" => "elytron"),
("server-ssl-context" => "server-ssl-context")
]) - failure description: {"WFLYCTL0080: Failed services" => {"org.wildfly.security.ssl-context.server-ssl-context" => "java.security.KeyManagementException: FIPS mode: only SunJSSE KeyManagers may be used
Caused by: java.security.KeyManagementException: FIPS mode: only SunJSSE KeyManagers may be used"}}
{code}
https://github.com/wildfly/wildfly-core/blob/02e2de734c68e23e0bae81fc12d7...
Debugging revealed problem is in this call
{code:java|title=SSLDefinitions.java}
final Class<?> providerClazz = SSLDefinitions.class.getClassLoader().loadClass("com.sun.net.ssl.internal.ssl.Provider");
{code}
which ends with ClassNotFoundException
{code}
java.lang.ClassNotFoundException: com.sun.net.ssl.internal.ssl.Provider from [Module "org.wildfly.extension.elytron" version 5.0.0.Alpha-redhat-20180502 from local module loader @41ee392b (finder: local module finder @1e67a849 (roots: /home/mchoma/Repos/tests-security/fips/target/dist/jboss-eap/modules,/home/mchoma/Repos/tests-security/fips/target/dist/jboss-eap/modules/system/layers/base))]
{code}
was:
Trying SSL in FIPS mode I get "KeyManagementException: FIPS mode: only SunJSSE KeyManagers may be used"
{code}
17:45:32,678 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service org.wildfly.security.ssl-context.server-ssl-context: org.jboss.msc.service.StartException in service org.wildfly.security.ssl-context.server-ssl-context: java.security.KeyManagementException: FIPS mode: only SunJSSE KeyManagers may be used
at org.wildfly.extension.elytron.SSLDefinitions$6.lambda$getValueSupplier$1(SSLDefinitions.java:926)
at org.wildfly.extension.elytron.TrivialService.start(TrivialService.java:53)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1714)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1693)
at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1540)
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)
Caused by: java.security.KeyManagementException: FIPS mode: only SunJSSE KeyManagers may be used
at sun.security.ssl.SSLContextImpl.chooseKeyManager(SSLContextImpl.java:149)
at sun.security.ssl.SSLContextImpl.engineInit(SSLContextImpl.java:66)
at javax.net.ssl.SSLContext.init(SSLContext.java:282)
at org.wildfly.security.ssl.SSLContextBuilder.lambda$build$0(SSLContextBuilder.java:372)
at org.wildfly.security.OneTimeSecurityFactory.create(OneTimeSecurityFactory.java:53)
at org.wildfly.extension.elytron.SSLDefinitions$6.lambda$getValueSupplier$1(SSLDefinitions.java:924)
... 9 more
17:45:32,686 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0013: Operation ("add") failed - address: ([
("subsystem" => "elytron"),
("server-ssl-context" => "server-ssl-context")
]) - failure description: {"WFLYCTL0080: Failed services" => {"org.wildfly.security.ssl-context.server-ssl-context" => "java.security.KeyManagementException: FIPS mode: only SunJSSE KeyManagers may be used
Caused by: java.security.KeyManagementException: FIPS mode: only SunJSSE KeyManagers may be used"}}
{code}
Debugging revealed problem is in this call
{code:java|title=SSLDefinitions.java}
final Class<?> providerClazz = SSLDefinitions.class.getClassLoader().loadClass("com.sun.net.ssl.internal.ssl.Provider");
{code}
which ends with ClassNotFoundException
{code}
java.lang.ClassNotFoundException: com.sun.net.ssl.internal.ssl.Provider from [Module "org.wildfly.extension.elytron" version 5.0.0.Alpha-redhat-20180502 from local module loader @41ee392b (finder: local module finder @1e67a849 (roots: /home/mchoma/Repos/tests-security/fips/target/dist/jboss-eap/modules,/home/mchoma/Repos/tests-security/fips/target/dist/jboss-eap/modules/system/layers/base))]
{code}
> FIPS mode is not detected correctly on JDK 8
> --------------------------------------------
>
> Key: WFCORE-3799
> URL: https://issues.jboss.org/browse/WFCORE-3799
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Affects Versions: 5.0.0.Alpha4
> Environment: jdk 8
> Reporter: Martin Choma
> Assignee: Darran Lofthouse
> Priority: Blocker
>
> Trying SSL in FIPS mode I get "KeyManagementException: FIPS mode: only SunJSSE KeyManagers may be used"
> {code}
> 17:45:32,678 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service org.wildfly.security.ssl-context.server-ssl-context: org.jboss.msc.service.StartException in service org.wildfly.security.ssl-context.server-ssl-context: java.security.KeyManagementException: FIPS mode: only SunJSSE KeyManagers may be used
> at org.wildfly.extension.elytron.SSLDefinitions$6.lambda$getValueSupplier$1(SSLDefinitions.java:926)
> at org.wildfly.extension.elytron.TrivialService.start(TrivialService.java:53)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1714)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1693)
> at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1540)
> 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)
> Caused by: java.security.KeyManagementException: FIPS mode: only SunJSSE KeyManagers may be used
> at sun.security.ssl.SSLContextImpl.chooseKeyManager(SSLContextImpl.java:149)
> at sun.security.ssl.SSLContextImpl.engineInit(SSLContextImpl.java:66)
> at javax.net.ssl.SSLContext.init(SSLContext.java:282)
> at org.wildfly.security.ssl.SSLContextBuilder.lambda$build$0(SSLContextBuilder.java:372)
> at org.wildfly.security.OneTimeSecurityFactory.create(OneTimeSecurityFactory.java:53)
> at org.wildfly.extension.elytron.SSLDefinitions$6.lambda$getValueSupplier$1(SSLDefinitions.java:924)
> ... 9 more
> 17:45:32,686 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "elytron"),
> ("server-ssl-context" => "server-ssl-context")
> ]) - failure description: {"WFLYCTL0080: Failed services" => {"org.wildfly.security.ssl-context.server-ssl-context" => "java.security.KeyManagementException: FIPS mode: only SunJSSE KeyManagers may be used
> Caused by: java.security.KeyManagementException: FIPS mode: only SunJSSE KeyManagers may be used"}}
> {code}
> https://github.com/wildfly/wildfly-core/blob/02e2de734c68e23e0bae81fc12d7...
> Debugging revealed problem is in this call
> {code:java|title=SSLDefinitions.java}
> final Class<?> providerClazz = SSLDefinitions.class.getClassLoader().loadClass("com.sun.net.ssl.internal.ssl.Provider");
> {code}
> which ends with ClassNotFoundException
> {code}
> java.lang.ClassNotFoundException: com.sun.net.ssl.internal.ssl.Provider from [Module "org.wildfly.extension.elytron" version 5.0.0.Alpha-redhat-20180502 from local module loader @41ee392b (finder: local module finder @1e67a849 (roots: /home/mchoma/Repos/tests-security/fips/target/dist/jboss-eap/modules,/home/mchoma/Repos/tests-security/fips/target/dist/jboss-eap/modules/system/layers/base))]
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-10322) Instructions for removing welcome content don't work
by Rich DiCroce (JIRA)
[ https://issues.jboss.org/browse/WFLY-10322?page=com.atlassian.jira.plugin... ]
Rich DiCroce resolved WFLY-10322.
---------------------------------
Resolution: Explained
> Instructions for removing welcome content don't work
> ----------------------------------------------------
>
> Key: WFLY-10322
> URL: https://issues.jboss.org/browse/WFLY-10322
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 12.0.0.Final
> Reporter: Rich DiCroce
> Assignee: Chao Wang
>
> The welcome page in WildFly 12 says:
> {quote}
> To replace this page simply deploy your own war with / as its context path.
> To disable it, remove the "welcome-content" handler for location / in the undertow subsystem.
> {quote}
> But after removing the handler, the welcome content still appears. This is true even though I also have default-web-module set. A similar configuration worked correctly on WildFly 11, so this appears to be a relatively recent regression.
> WildFly 12 Undertow subsystem config:
> {code}
> <subsystem xmlns="urn:jboss:domain:undertow:5.0">
> <buffer-cache name="default"/>
> <server name="default-server">
> <http-listener name="default" socket-binding="http"/>
> <host name="default-host" alias="localhost" default-web-module="report-server.war">
> <filter-ref name="server-header"/>
> <filter-ref name="x-powered-by-header"/>
> <http-invoker http-authentication-factory="application-http-authentication"/>
> </host>
> </server>
> <servlet-container name="default">
> <jsp-config/>
> <websockets/>
> <session-cookie name="SQERS_SESSION_ID"/>
> </servlet-container>
> <filters>
> <response-header name="server-header" header-value="WildFly/12" header-name="Server"/>
> <response-header name="x-powered-by-header" header-value="Undertow/1" header-name="X-Powered-By"/>
> </filters>
> </subsystem>
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-10322) Instructions for removing welcome content don't work
by Rich DiCroce (JIRA)
[ https://issues.jboss.org/browse/WFLY-10322?page=com.atlassian.jira.plugin... ]
Rich DiCroce commented on WFLY-10322:
-------------------------------------
You're right, it turned out to be a caching issue.
> Instructions for removing welcome content don't work
> ----------------------------------------------------
>
> Key: WFLY-10322
> URL: https://issues.jboss.org/browse/WFLY-10322
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 12.0.0.Final
> Reporter: Rich DiCroce
> Assignee: Chao Wang
>
> The welcome page in WildFly 12 says:
> {quote}
> To replace this page simply deploy your own war with / as its context path.
> To disable it, remove the "welcome-content" handler for location / in the undertow subsystem.
> {quote}
> But after removing the handler, the welcome content still appears. This is true even though I also have default-web-module set. A similar configuration worked correctly on WildFly 11, so this appears to be a relatively recent regression.
> WildFly 12 Undertow subsystem config:
> {code}
> <subsystem xmlns="urn:jboss:domain:undertow:5.0">
> <buffer-cache name="default"/>
> <server name="default-server">
> <http-listener name="default" socket-binding="http"/>
> <host name="default-host" alias="localhost" default-web-module="report-server.war">
> <filter-ref name="server-header"/>
> <filter-ref name="x-powered-by-header"/>
> <http-invoker http-authentication-factory="application-http-authentication"/>
> </host>
> </server>
> <servlet-container name="default">
> <jsp-config/>
> <websockets/>
> <session-cookie name="SQERS_SESSION_ID"/>
> </servlet-container>
> <filters>
> <response-header name="server-header" header-value="WildFly/12" header-name="Server"/>
> <response-header name="x-powered-by-header" header-value="Undertow/1" header-name="X-Powered-By"/>
> </filters>
> </subsystem>
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (ELY-1418) CLIENT_CERT without users certificates database
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-1418?page=com.atlassian.jira.plugin.s... ]
Jan Kalina updated ELY-1418:
----------------------------
Description:
CLIENT_CERT http-authentication-mechanism currently requires to provide security-realm, which will contain identity for given certificate and will verify X509Evidence for it. This does not provide replacement for legacy truststore auth, which allows to use only CA certificate to authenticate users by certificates signed by CA, without any database of them.
As client cetificate is already checked by SSLContext, certificate verification in CLIENT-CERT HTTP mechanism should be made optional. (Need to be enabled by default for backward compatibility.)
Analysis document:
https://developer.jboss.org/wiki/AnalysisDesign-CLIENTCERTWithoutUsersCer...
was:
CLIENT_CERT http-authentication-mechanism currently requires to provide security-realm, which will contain identity for given certificate and will verify X509Evidence for it. This does not provide replacement for legacy truststore auth, which allows to use only CA certificate to authenticate users by certificates signed by CA, without any database of them.
Analysis document:
https://developer.jboss.org/wiki/AnalysisDesign-CLIENTCERTWithoutUsersCer...
> CLIENT_CERT without users certificates database
> -----------------------------------------------
>
> Key: ELY-1418
> URL: https://issues.jboss.org/browse/ELY-1418
> Project: WildFly Elytron
> Issue Type: Feature Request
> Components: HTTP
> Affects Versions: 1.2.0.Beta7
> Reporter: Jan Kalina
> Assignee: Jan Kalina
>
> CLIENT_CERT http-authentication-mechanism currently requires to provide security-realm, which will contain identity for given certificate and will verify X509Evidence for it. This does not provide replacement for legacy truststore auth, which allows to use only CA certificate to authenticate users by certificates signed by CA, without any database of them.
> As client cetificate is already checked by SSLContext, certificate verification in CLIENT-CERT HTTP mechanism should be made optional. (Need to be enabled by default for backward compatibility.)
> Analysis document:
> https://developer.jboss.org/wiki/AnalysisDesign-CLIENTCERTWithoutUsersCer...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months