[JBoss JIRA] (WFCORE-1047) Rollback of undeploy and deployment remove will fail
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1047?page=com.atlassian.jira.plugi... ]
RH Bugzilla Integration commented on WFCORE-1047:
-------------------------------------------------
Petr Penicka <ppenicka(a)redhat.com> changed the Status of [bug 1409644|https://bugzilla.redhat.com/show_bug.cgi?id=1409644] from VERIFIED to CLOSED
> Rollback of undeploy and deployment remove will fail
> ----------------------------------------------------
>
> Key: WFCORE-1047
> URL: https://issues.jboss.org/browse/WFCORE-1047
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 1.0.0.Final, 2.0.0.CR6
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Priority: Critical
> Fix For: 2.0.0.CR7
>
>
> This looks like a problem that's been around since Sept 2012.
> The rollback handling in DeploymentHandlerUtil.undeploy and in DeploymentRemoveHandler both try to read the deployment's management name from the deployment resource, but since [1] it hasn't been stored there. So rollback will fail with something like this:
> {code}
> [Server:main-one] 15:58:54,894 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 2) WFLYCTL0190: Step handler org.jboss.as.server.deployment.DeploymentHandlerUtil$5@2a0a9f3f for operation {"operation" => "undeploy","address" => [("deployment" => "broken.jar")],"operation-headers" => {}} at address [("deployment" => "broken.jar")] failed handling operation rollback -- java.util.NoSuchElementException: No child 'name' exists: java.util.NoSuchElementException: No child 'name' exists
> [Server:main-one] at org.jboss.dmr.ModelValue.requireChild(ModelValue.java:377) [jboss-dmr-1.3.0.Final.jar:1.3.0.Final]
> [Server:main-one] at org.jboss.dmr.ObjectModelValue.requireChild(ObjectModelValue.java:299) [jboss-dmr-1.3.0.Final.jar:1.3.0.Final]
> [Server:main-one] at org.jboss.dmr.ModelNode.require(ModelNode.java:870) [jboss-dmr-1.3.0.Final.jar:1.3.0.Final]
> [Server:main-one] at org.jboss.as.server.deployment.DeploymentHandlerUtil$5$1.handleResult(DeploymentHandlerUtil.java:331) [wildfly-server-2.0.0.CR7-SNAPSHOT.jar:2.0.0.CR7-SNAPSHOT]
> [Server:main-one] at org.jboss.as.controller.AbstractOperationContext$Step.invokeResultHandler(AbstractOperationContext.java:1384) [wildfly-controller-2.0.0.CR7-SNAPSHOT.jar:2.0.0.CR7-SNAPSHOT]
> [Server:main-one] at org.jboss.as.controller.AbstractOperationContext$Step.handleResult(AbstractOperationContext.java:1366) [wildfly-controller-2.0.0.CR7-SNAPSHOT.jar:2.0.0.CR7-SNAPSHOT]
> [Server:main-one] at org.jboss.as.controller.AbstractOperationContext$Step.finalizeInternal(AbstractOperationContext.java:1328) [wildfly-controller-2.0.0.CR7-SNAPSHOT.jar:2.0.0.CR7-SNAPSHOT]
> [Server:main-one] at org.jboss.as.controller.AbstractOperationContext$Step.finalizeStep(AbstractOperationContext.java:1311) [wildfly-controller-2.0.0.CR7-SNAPSHOT.jar:2.0.0.CR7-SNAPSHOT]
> [Server:main-one] at org.jboss.as.controller.AbstractOperationContext$Step.access$300(AbstractOperationContext.java:1185) [wildfly-controller-2.0.0.CR7-SNAPSHOT.jar:2.0.0.CR7-SNAPSHOT]
> [Server:main-one] at org.jboss.as.controller.AbstractOperationContext.executeResultHandlerPhase(AbstractOperationContext.java:767) [wildfly-controller-2.0.0.CR7-SNAPSHOT.jar:2.0.0.CR7-SNAPSHOT]
> [Server:main-one] at org.jboss.as.controller.AbstractOperationContext.executeDoneStage(AbstractOperationContext.java:753) [wildfly-controller-2.0.0.CR7-SNAPSHOT.jar:2.0.0.CR7-SNAPSHOT]
> [Server:main-one] at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:680) [wildfly-controller-2.0.0.CR7-SNAPSHOT.jar:2.0.0.CR7-SNAPSHOT]
> [Server:main-one] at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370) [wildfly-controller-2.0.0.CR7-SNAPSHOT.jar:2.0.0.CR7-SNAPSHOT]
> [Server:main-one] at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1336) [wildfly-controller-2.0.0.CR7-SNAPSHOT.jar:2.0.0.CR7-SNAPSHOT]
> [Server:main-one] at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:392) [wildfly-controller-2.0.0.CR7-SNAPSHOT.jar:2.0.0.CR7-SNAPSHOT]
> [Server:main-one] at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:217) [wildfly-controller-2.0.0.CR7-SNAPSHOT.jar:2.0.0.CR7-SNAPSHOT]
> [Server:main-one] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler.internalExecute(TransactionalProtocolOperationHandler.java:234) [wildfly-controller-2.0.0.CR7-SNAPSHOT.jar:2.0.0.CR7-SNAPSHOT]
> [Server:main-one] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler.doExecute(TransactionalProtocolOperationHandler.java:173) [wildfly-controller-2.0.0.CR7-SNAPSHOT.jar:2.0.0.CR7-SNAPSHOT]
> [Server:main-one] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$1.run(TransactionalProtocolOperationHandler.java:136) [wildfly-controller-2.0.0.CR7-SNAPSHOT.jar:2.0.0.CR7-SNAPSHOT]
> [Server:main-one] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$1.run(TransactionalProtocolOperationHandler.java:132) [wildfly-controller-2.0.0.CR7-SNAPSHOT.jar:2.0.0.CR7-SNAPSHOT]
> [Server:main-one] at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.8.0_45]
> [Server:main-one] at javax.security.auth.Subject.doAs(Subject.java:360) [rt.jar:1.8.0_45]
> [Server:main-one] at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:81) [wildfly-controller-2.0.0.CR7-SNAPSHOT.jar:2.0.0.CR7-SNAPSHOT]
> [Server:main-one] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2$1.run(TransactionalProtocolOperationHandler.java:152) [wildfly-controller-2.0.0.CR7-SNAPSHOT.jar:2.0.0.CR7-SNAPSHOT]
> [Server:main-one] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2$1.run(TransactionalProtocolOperationHandler.java:148) [wildfly-controller-2.0.0.CR7-SNAPSHOT.jar:2.0.0.CR7-SNAPSHOT]
> [Server:main-one] at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.8.0_45]
> [Server:main-one] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2.execute(TransactionalProtocolOperationHandler.java:148) [wildfly-controller-2.0.0.CR7-SNAPSHOT.jar:2.0.0.CR7-SNAPSHOT]
> [Server:main-one] at org.jboss.as.protocol.mgmt.AbstractMessageHandler$ManagementRequestContextImpl$1.doExecute(AbstractMessageHandler.java:364) [wildfly-protocol-2.0.0.CR7-SNAPSHOT.jar:2.0.0.CR7-SNAPSHOT]
> [Server:main-one] at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:466) [wildfly-protocol-2.0.0.CR7-SNAPSHOT.jar:2.0.0.CR7-SNAPSHOT]
> [Server:main-one] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_45]
> [Server:main-one] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_45]
> [Server:main-one] at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_45]
> [Server:main-one] at org.jboss.threads.JBossThread.run(JBossThread.java:320) [jboss-threads-2.2.1.Final.jar:2.2.1.Final]
> {code}
> [1] https://github.com/wildfly/wildfly-core/commit/f38b37#diff-2dbd1fc9261de7...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (DROOLS-1492) typeRef allowed values check for DT input and output clauses, and InputData
by Matteo Mortari (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1492?page=com.atlassian.jira.plugi... ]
Matteo Mortari updated DROOLS-1492:
-----------------------------------
Summary: typeRef allowed values check for DT input and output clauses, and InputData (was: DecisionTable to perform typeRef allowed values check for input and output clause)
> typeRef allowed values check for DT input and output clauses, and InputData
> ---------------------------------------------------------------------------
>
> Key: DROOLS-1492
> URL: https://issues.jboss.org/browse/DROOLS-1492
> Project: Drools
> Issue Type: Feature Request
> Components: dmn engine
> Reporter: Matteo Mortari
> Assignee: Matteo Mortari
>
> Example model
> {code:xml}
> <definitions id="definitions" ...
> <itemDefinition label="MyType" name="MyType">
> <typeRef>feel:string</typeRef>
> <allowedValues constraintsType="enumeration">
> <text>"a","b","c"</text>
> </allowedValues>
> </itemDefinition>
> <inputData id="_3d560678-a126-4654-a686-bc6d941fe40b" name="MyInput">
> <variable id="_053333df-1777-45f1-a6c7-56562fbdfdae" name="MyInput" typeRef="kie:MyType"/>
> </inputData>
> <decision id="_497a5306-b2e8-4945-b8b5-82af2e2b99b5" name="MyDecision">
> <variable id="_514d6d8d-5329-44fa-af91-a7e7addbadd8" name="MyDecision" typeRef="feel:string"/>
> <informationRequirement>
> <requiredInput href="#_3d560678-a126-4654-a686-bc6d941fe40b"/>
> </informationRequirement>
> <decisionTable hitPolicy="UNIQUE" id="_fff2b82e-2850-4826-adc9-4b1570d6fa91" outputLabel="MyDecision">
> <input id="_e0471736-9a71-40c7-b5ca-bf367c6a3af9" label="MyInput">
> <inputExpression typeRef="kie:MyType">
> <text>MyInput</text>
> </inputExpression>
> </input>
> <output id="_01796218-0d50-4ebe-bd2b-b4509318e334"/>
> <rule id="_fd1835b6-5fe1-4fd9-a8e4-39b4f7083b24">
> <inputEntry expressionLanguage="http://www.omg.org/spec/FEEL/20140401" id="_1c8b24c7-e722-40d7-8661-f03d402688d2">
> <text>-</text>
> </inputEntry>
> <outputEntry id="_0b9d04fe-032b-4753-84dd-9838f6cdef53">
> <text>"Decision taken"</text>
> </outputEntry>
> </rule>
> </decisionTable>
> </decision>
> </definitions>
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (SECURITY-930) A security-domain can only load login-modules from a single JBoss module
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/SECURITY-930?page=com.atlassian.jira.plug... ]
RH Bugzilla Integration commented on SECURITY-930:
--------------------------------------------------
Petr Penicka <ppenicka(a)redhat.com> changed the Status of [bug 1280512|https://bugzilla.redhat.com/show_bug.cgi?id=1280512] from VERIFIED to CLOSED
> A security-domain can only load login-modules from a single JBoss module
> --------------------------------------------------------------------------
>
> Key: SECURITY-930
> URL: https://issues.jboss.org/browse/SECURITY-930
> Project: PicketBox
> Issue Type: Bug
> Components: JBossSX, Security-SPI
> Reporter: Derek Horton
> Assignee: Stefan Guilhen
> Fix For: PicketBox_5_0_0.Beta1
>
>
> A security-domain can only load login-modules from a single JBoss module. Even though the security-domain configuration will allow each login module defined within a single security-domain to have a "module" attribute, the only module that is used to load the login-modules is the last "module" attribute that the parsing system locates.
> For example, with the following configuration, it looks like "org.jboss.example.CustomLoginModule" should be loaded from the "org.jboss.example" jboss-module and "org.jboss.example.CustomBaseCertLoginModule" should be loaded from the "org.jboss.another.example" jboss-module:
> <security-domain name="jmx-console" cache-type="default">
> <authentication>
> <login-module code="org.jboss.example.CustomLoginModule" module="org.jboss.example" flag="required">
> <module-option name="usersProperties" value="${jboss.server.config.dir}/users.properties"/>
> <module-option name="rolesProperties" value="${jboss.server.config.dir}/roles.properties"/>
> </login-module>
> <login-module code="org.jboss.example.CustomBaseCertLoginModule" module="org.jboss.another.example" flag="required">
> <module-option name="usersProperties" value="${jboss.server.config.dir}/users.properties"/>
> <module-option name="rolesProperties" value="${jboss.server.config.dir}/roles.properties"/>
> </login-module>
> </authentication>
> </security-domain>
> Unfortunately, it does not work like this. Only the "org.jboss.another.example" jboss-module is used to load the custom login modules.
> There seems to be two issues. 1) The security subsystem code only "remembers" the last module that is defined within a single security domain. 2) I think issue #1 is happening because the JBoss authentication code (org.jboss.security.authentication.JBossCachedAuthenticationManager.authenticate()) defers to the JVM's login module handling code. The JVM appears to treat the login modules as one atomic until and so a single classloader is set and then the JVM login module code is invoked to handle the authentication requests.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (WFCORE-2163) Server does not start when Elytron authentication + legacy SSL is used in HTTP management interface
by Ondrej Lukas (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2163?page=com.atlassian.jira.plugi... ]
Ondrej Lukas updated WFCORE-2163:
---------------------------------
Priority: Blocker (was: Critical)
> Server does not start when Elytron authentication + legacy SSL is used in HTTP management interface
> ---------------------------------------------------------------------------------------------------
>
> Key: WFCORE-2163
> URL: https://issues.jboss.org/browse/WFCORE-2163
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Ondrej Lukas
> Assignee: ehsavoie Hugonnet
> Priority: Blocker
> Fix For: 3.0.0.Beta11
>
>
> In case when legacy security-realm for SSL is used together with Elytron authentication in HTTP management interface then server is not started.
> I am using following configuration for HTTP management interface (see Steps to Reproduce for more details):
> {code}
> <http-interface http-authentication-factory="management-http-authentication" security-realm="ManagementRealmHTTPS">
> <http-upgrade enabled="true" sasl-authentication-factory="management-sasl-authentication"/>
> <socket-binding http="management-http" https="management-https"/>
> </http-interface>
> {code}
> Server is not started and following errors occur in log:
> {code}
> ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service org.wildfly.management.http.extensible: org.jboss.msc.service.StartException in service org.wildfly.management.http.extensible: WFLYSRV0083: Failed to start the http-interface service
> at org.jboss.as.server.mgmt.UndertowHttpManagementService.start(UndertowHttpManagementService.java:330)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1963)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1896)
> 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.IllegalStateException: WFLYDMHTTP0015: No SecurityRealm or SSLContext has been provided.
> at org.jboss.as.domain.http.server.ManagementHttpServer.getSSLContext(ManagementHttpServer.java:225)
> at org.jboss.as.domain.http.server.ManagementHttpServer.create(ManagementHttpServer.java:254)
> at org.jboss.as.domain.http.server.ManagementHttpServer.access$2400(ManagementHttpServer.java:107)
> at org.jboss.as.domain.http.server.ManagementHttpServer$Builder.build(ManagementHttpServer.java:589)
> at org.jboss.as.server.mgmt.UndertowHttpManagementService.start(UndertowHttpManagementService.java:292)
> ... 5 more
> {code}
> and
> {code}
> ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
> ("core-service" => "management"),
> ("management-interface" => "http-interface")
> ]) - failure description: {
> "WFLYCTL0080: Failed services" => {"org.wildfly.management.http.extensible" => "org.jboss.msc.service.StartException in service org.wildfly.management.http.extensible: WFLYSRV0083: Failed to start the http-interface service
> Caused by: java.lang.IllegalStateException: WFLYDMHTTP0015: No SecurityRealm or SSLContext has been provided."},
> "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.management.http.extensible"],
> "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined
> }
> ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
> ("core-service" => "management"),
> ("management-interface" => "http-interface")
> ]) - failure description: {
> "WFLYCTL0080: Failed services" => {"org.wildfly.management.http.extensible" => "org.jboss.msc.service.StartException in service org.wildfly.management.http.extensible: WFLYSRV0083: Failed to start the http-interface service
> Caused by: java.lang.IllegalStateException: WFLYDMHTTP0015: No SecurityRealm or SSLContext has been provided."},
> "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.management.http.extensible"],
> "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined
> }
> {code}
> According to comments in EAP7-545 Analysis document [1], when security-realm and http-authentication-factory are specified but no ssl-context is used then it should lead to use legacy security-realm for SSL configuration and http-authentication-factory for authentication.
> [1] https://docs.google.com/document/d/1LsS-CGUJSDwGcFUva0g-BF9ZIq0jwx__1e_oJ...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (WFCORE-2163) Server does not start when Elytron authentication + legacy SSL is used in HTTP management interface
by Ondrej Lukas (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2163?page=com.atlassian.jira.plugi... ]
Ondrej Lukas commented on WFCORE-2163:
--------------------------------------
Increasing priority to blocker since valid configuration causes that server does not start.
> Server does not start when Elytron authentication + legacy SSL is used in HTTP management interface
> ---------------------------------------------------------------------------------------------------
>
> Key: WFCORE-2163
> URL: https://issues.jboss.org/browse/WFCORE-2163
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Ondrej Lukas
> Assignee: ehsavoie Hugonnet
> Priority: Blocker
> Fix For: 3.0.0.Beta11
>
>
> In case when legacy security-realm for SSL is used together with Elytron authentication in HTTP management interface then server is not started.
> I am using following configuration for HTTP management interface (see Steps to Reproduce for more details):
> {code}
> <http-interface http-authentication-factory="management-http-authentication" security-realm="ManagementRealmHTTPS">
> <http-upgrade enabled="true" sasl-authentication-factory="management-sasl-authentication"/>
> <socket-binding http="management-http" https="management-https"/>
> </http-interface>
> {code}
> Server is not started and following errors occur in log:
> {code}
> ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service org.wildfly.management.http.extensible: org.jboss.msc.service.StartException in service org.wildfly.management.http.extensible: WFLYSRV0083: Failed to start the http-interface service
> at org.jboss.as.server.mgmt.UndertowHttpManagementService.start(UndertowHttpManagementService.java:330)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1963)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1896)
> 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.IllegalStateException: WFLYDMHTTP0015: No SecurityRealm or SSLContext has been provided.
> at org.jboss.as.domain.http.server.ManagementHttpServer.getSSLContext(ManagementHttpServer.java:225)
> at org.jboss.as.domain.http.server.ManagementHttpServer.create(ManagementHttpServer.java:254)
> at org.jboss.as.domain.http.server.ManagementHttpServer.access$2400(ManagementHttpServer.java:107)
> at org.jboss.as.domain.http.server.ManagementHttpServer$Builder.build(ManagementHttpServer.java:589)
> at org.jboss.as.server.mgmt.UndertowHttpManagementService.start(UndertowHttpManagementService.java:292)
> ... 5 more
> {code}
> and
> {code}
> ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
> ("core-service" => "management"),
> ("management-interface" => "http-interface")
> ]) - failure description: {
> "WFLYCTL0080: Failed services" => {"org.wildfly.management.http.extensible" => "org.jboss.msc.service.StartException in service org.wildfly.management.http.extensible: WFLYSRV0083: Failed to start the http-interface service
> Caused by: java.lang.IllegalStateException: WFLYDMHTTP0015: No SecurityRealm or SSLContext has been provided."},
> "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.management.http.extensible"],
> "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined
> }
> ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
> ("core-service" => "management"),
> ("management-interface" => "http-interface")
> ]) - failure description: {
> "WFLYCTL0080: Failed services" => {"org.wildfly.management.http.extensible" => "org.jboss.msc.service.StartException in service org.wildfly.management.http.extensible: WFLYSRV0083: Failed to start the http-interface service
> Caused by: java.lang.IllegalStateException: WFLYDMHTTP0015: No SecurityRealm or SSLContext has been provided."},
> "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.management.http.extensible"],
> "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined
> }
> {code}
> According to comments in EAP7-545 Analysis document [1], when security-realm and http-authentication-factory are specified but no ssl-context is used then it should lead to use legacy security-realm for SSL configuration and http-authentication-factory for authentication.
> [1] https://docs.google.com/document/d/1LsS-CGUJSDwGcFUva0g-BF9ZIq0jwx__1e_oJ...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (WFLY-7885) Persistent calendar timer force logging for each invocation if the deployed-class has changed
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-7885?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-7885:
-----------------------------------------------
Petr Penicka <ppenicka(a)redhat.com> changed the Status of [bug 1413033|https://bugzilla.redhat.com/show_bug.cgi?id=1413033] from VERIFIED to CLOSED
> Persistent calendar timer force logging for each invocation if the deployed-class has changed
> ---------------------------------------------------------------------------------------------
>
> Key: WFLY-7885
> URL: https://issues.jboss.org/browse/WFLY-7885
> Project: WildFly
> Issue Type: Enhancement
> Components: EJB
> Reporter: Wolf-Dieter Fink
> Assignee: Ingo Weiss
> Priority: Minor
> Labels: ejb, ejb3.1, timers, timerservice
> Fix For: 11.0.0.Alpha1
>
>
> It will be common to change classes which contains @Schedule timer methods.
> In case such methods are removed or renamed (for persistent calendar timers) the server will log the following warning forever for each invocation.
> WARN [org.jboss.as.ejb3.timer] (EJB default - 1) WFLYEJB0161: Failed to reinstate timer 'ejb31-timer.ejb31-timer.SimpleScheduleSingletonTimerBean' (id=1a419372-d807-43d8-ac77-5be6696b022d) from its persistent state
> As this is intentional there should be a WARN message at (first) deployment time and the timer should be removed from the persistence.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month