[JBoss JIRA] (WFLY-6600) NPE thrown during EAR deployment
by jaikiran pai (JIRA)
[ https://issues.jboss.org/browse/WFLY-6600?page=com.atlassian.jira.plugin.... ]
jaikiran pai reassigned WFLY-6600:
----------------------------------
Fix Version/s: 10.1.0.Final
Assignee: jaikiran pai
Resolution: Done
> NPE thrown during EAR deployment
> --------------------------------
>
> Key: WFLY-6600
> URL: https://issues.jboss.org/browse/WFLY-6600
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 10.0.0.Final
> Reporter: Matthew Casperson
> Assignee: jaikiran pai
> Fix For: 10.1.0.Final
>
>
> We deploy an EAR file to a Wildfly domain with two slaves. On one slave, we'll frequently see this exception:
> {code}
> [Server:main-server] 2016-05-08 16:06:13+1000 INFO [[org.jboss.as.server]] [[ServerService Thread Pool -- 359]] WFLYSRV0016: Replaced deployment "services.war" with deployment "services.war"
> [Server:main-server] 2016-05-09 06:05:08+1000 ERROR [[org.jboss.as.controller.management-operation]] [[ServerService Thread Pool -- 384]] WFLYCTL0013: Operation ("read-attribute") failed - address: ([
> [Server:main-server] ("deployment" => "OnlineSystemsApplications.ear"),
> [Server:main-server] ("subdeployment" => "systemcheck.war"),
> [Server:main-server] ("subsystem" => "undertow"),
> [Server:main-server] ("servlet" => "javax.ws.rs.core.Application")
> [Server:main-server] ]): java.lang.NullPointerException
> [Server:main-server] at org.wildfly.extension.undertow.DeploymentServletDefinition$AbstractMetricsHandler.execute(DeploymentServletDefinition.java:125)
> [Server:main-server] at org.jboss.as.controller.operations.global.ReadAttributeHandler.doExecuteInternal(ReadAttributeHandler.java:174)
> [Server:main-server] at org.jboss.as.controller.operations.global.ReadAttributeHandler.doExecute(ReadAttributeHandler.java:137)
> [Server:main-server] at org.jboss.as.controller.operations.global.GlobalOperationHandlers$AbstractMultiTargetHandler.execute(GlobalOperationHandlers.java:263)
> [Server:main-server] at org.jboss.as.controller.operations.global.GlobalOperationHandlers$AvailableResponseWrapper.execute(GlobalOperationHandlers.java:933)
> [Server:main-server] at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:890)
> [Server:main-server] at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:659)
> [Server:main-server] at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370)
> [Server:main-server] at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1344)
> [Server:main-server] at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:392)
> [Server:main-server] at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:217)
> [Server:main-server] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler.internalExecute(TransactionalProtocolOperationHandler.java:247)
> [Server:main-server] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler.doExecute(TransactionalProtocolOperationHandler.java:185)
> [Server:main-server] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$1.run(TransactionalProtocolOperationHandler.java:138)
> [Server:main-server] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$1.run(TransactionalProtocolOperationHandler.java:134)
> [Server:main-server] at java.security.AccessController.doPrivileged(Native Method)
> [Server:main-server] at javax.security.auth.Subject.doAs(Subject.java:360)
> [Server:main-server] at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:81)
> [Server:main-server] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2$1.run(TransactionalProtocolOperationHandler.java:157)
> [Server:main-server] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2$1.run(TransactionalProtocolOperationHandler.java:153)
> [Server:main-server] at java.security.AccessController.doPrivileged(Native Method)
> [Server:main-server] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2.execute(TransactionalProtocolOperationHandler.java:153)
> [Server:main-server] at org.jboss.as.protocol.mgmt.AbstractMessageHandler$ManagementRequestContextImpl$1.doExecute(AbstractMessageHandler.java:363)
> [Server:main-server] at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:472)
> [Server:main-server] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [Server:main-server] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [Server:main-server] at java.lang.Thread.run(Thread.java:745)
> [Server:main-server] at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {code}
> At the same time we'll see this on the second node
> {code}
> [Server:main-server] 2016-05-06 16:17:59+1000 ERROR [[org.jboss.as.controller.management-operation]] [[ServerService Thread Pool -- 276]] WFLYCTL0190: Step handler org.jboss.as.server.deployment.DeploymentHandlerUtil$4@14bd8919 for operation {"operation" => "full-replace-deployment","name" => "OnlineSystemsApplications.ear","enabled" => true,"content" => [{"hash" => bytes { 0x73, 0xec, 0x83, 0x82, 0xb6, 0x67, 0x2d, 0x92, 0x36, 0x7a, 0xb7, 0x7c, 0x7a, 0x4e, 0xc4, 0x93, 0x00, 0xc1, 0xf3, 0xc3 }}],"operation-headers" => {"access-mechanism" => "NATIVE","domain-uuid" => "76dbe681-46d0-4f2e-a4c7-82f615919ff0"},"address" => [],"runtime-name" => undefined,"persistent" => true,"owner" => undefined} at address [] failed handling operation rollback -- java.util.NoSuchElementException: No child 'name' exists: java.util.NoSuchElementException: No child 'name' exists
> [Server:main-server] at org.jboss.dmr.ModelValue.requireChild(ModelValue.java:377)
> [Server:main-server] at org.jboss.dmr.ObjectModelValue.requireChild(ObjectModelValue.java:299)
> [Server:main-server] at org.jboss.dmr.ModelNode.require(ModelNode.java:870)
> [Server:main-server] at org.jboss.as.server.deployment.DeploymentHandlerUtil$4$1.handleResult(DeploymentHandlerUtil.java:277)
> [Server:main-server] at org.jboss.as.controller.AbstractOperationContext$Step.invokeResultHandler(AbstractOperationContext.java:1384)
> [Server:main-server] at org.jboss.as.controller.AbstractOperationContext$Step.handleResult(AbstractOperationContext.java:1366)
> [Server:main-server] at org.jboss.as.controller.AbstractOperationContext$Step.finalizeInternal(AbstractOperationContext.java:1328)
> [Server:main-server] at org.jboss.as.controller.AbstractOperationContext$Step.finalizeStep(AbstractOperationContext.java:1311)
> [Server:main-server] at org.jboss.as.controller.AbstractOperationContext$Step.access$300(AbstractOperationContext.java:1185)
> [Server:main-server] at org.jboss.as.controller.AbstractOperationContext.executeResultHandlerPhase(AbstractOperationContext.java:767)
> [Server:main-server] at org.jboss.as.controller.AbstractOperationContext.executeDoneStage(AbstractOperationContext.java:753)
> [Server:main-server] at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:680)
> [Server:main-server] at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370)
> [Server:main-server] at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1344)
> [Server:main-server] at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:392)
> [Server:main-server] at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:217)
> [Server:main-server] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler.internalExecute(TransactionalProtocolOperationHandler.java:247)
> [Server:main-server] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler.doExecute(TransactionalProtocolOperationHandler.java:185)
> [Server:main-server] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$1.run(TransactionalProtocolOperationHandler.java:138)
> [Server:main-server] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$1.run(TransactionalProtocolOperationHandler.java:134)
> [Server:main-server] at java.security.AccessController.doPrivileged(Native Method)
> [Server:main-server] at javax.security.auth.Subject.doAs(Subject.java:360)
> [Server:main-server] at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:81)
> [Server:main-server] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2$1.run(TransactionalProtocolOperationHandler.java:157)
> [Server:main-server] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2$1.run(TransactionalProtocolOperationHandler.java:153)
> [Server:main-server] at java.security.AccessController.doPrivileged(Native Method)
> [Server:main-server] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2.execute(TransactionalProtocolOperationHandler.java:153)
> [Server:main-server] at org.jboss.as.protocol.mgmt.AbstractMessageHandler$ManagementRequestContextImpl$1.doExecute(AbstractMessageHandler.java:363)
> [Server:main-server] at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:472)
> [Server:main-server] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [Server:main-server] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [Server:main-server] at java.lang.Thread.run(Thread.java:745)
> [Server:main-server] at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {code}
> The WAR file in question doesn't actually use JAX-RS, so I'm not sure why javax.ws.rs.core.Application would be causing any issues.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (JBASMP-77) ConcurrentModificationException in deploy-artifact
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/JBASMP-77?page=com.atlassian.jira.plugin.... ]
James Perkins commented on JBASMP-77:
-------------------------------------
Just an FYI 7.8.Final has been released.
> ConcurrentModificationException in deploy-artifact
> --------------------------------------------------
>
> Key: JBASMP-77
> URL: https://issues.jboss.org/browse/JBASMP-77
> Project: JBoss AS Maven Plugins
> Issue Type: Bug
> Components: deploy
> Affects Versions: 7.7.Final
> Reporter: Daniele Gaffuri
> Assignee: Tomas Remes
> Fix For: 7.8.Final
>
>
> In the same situation of JBASMP-57 deploy-artifact throws the following exception:
> {code}
> [ERROR] Failed to execute goal org.jboss.as.plugins:jboss-as-maven-plugin:7.7.SCE:deploy-artifact (deploy) on project sideup-integration: Could not execute goal deploy-artifact on null. Reason: null: ConcurrentModificationException -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.jboss.as.plugins:jboss-as-maven-plugin:7.7.SCE:deploy-artifact (deploy) on project sideup-integration: Could not execute goal deploy-artifact on null. Reason: null
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:217)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
> at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
> Caused by: org.apache.maven.plugin.MojoExecutionException: Could not execute goal deploy-artifact on null. Reason: null
> at org.jboss.as.plugin.deployment.AbstractDeployment.doExecute(AbstractDeployment.java:159)
> at org.jboss.as.plugin.deployment.AbstractDeployment.execute(AbstractDeployment.java:112)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
> ... 19 more
> Caused by: java.util.ConcurrentModificationException
> at java.util.LinkedHashMap$LinkedHashIterator.nextEntry(LinkedHashMap.java:394)
> at java.util.LinkedHashMap$KeyIterator.next(LinkedHashMap.java:405)
> at java.util.AbstractCollection.addAll(AbstractCollection.java:341)
> at org.jboss.as.plugin.deployment.DeployArtifact.validate(DeployArtifact.java:84)
> at org.jboss.as.plugin.deployment.AbstractDeployment.doExecute(AbstractDeployment.java:136)
> ... 22 more
> {code}
> This is probably due to changes in related commit [37bc2c1], causing both deploy and undeploy validate methods to add the set of dependencies to itself:
> {code}
> final Set<Artifact> dependencies = project.getDependencyArtifacts();
> // Allows provided dependencies to be seen
> dependencies.addAll(project.getDependencyArtifacts());
> {code}
> {code}
> final Set<Artifact> dependencies = project.getDependencyArtifacts();
> dependencies.addAll(this.project.getDependencyArtifacts());
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (JBASMP-81) PackageType doesn't ignore any types
by James Perkins (JIRA)
James Perkins created JBASMP-81:
-----------------------------------
Summary: PackageType doesn't ignore any types
Key: JBASMP-81
URL: https://issues.jboss.org/browse/JBASMP-81
Project: JBoss AS Maven Plugins
Issue Type: Bug
Reporter: James Perkins
Assignee: James Perkins
The {{PackageType.isIgnored()}} always returns {{false}} even for pom and maven-plugin types. This should return {{true}} for these types.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (JBASMP-80) PackageType doesn't ignore any types
by James Perkins (JIRA)
James Perkins created JBASMP-80:
-----------------------------------
Summary: PackageType doesn't ignore any types
Key: JBASMP-80
URL: https://issues.jboss.org/browse/JBASMP-80
Project: JBoss AS Maven Plugins
Issue Type: Bug
Reporter: James Perkins
Assignee: James Perkins
The {{PackageType.isIgnored()}} always returns {{false}} even for pom and maven-plugin types. This should return {{true}} for these types.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (JBASMP-68) execute-commands does not work for module command
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/JBASMP-68?page=com.atlassian.jira.plugin.... ]
James Perkins closed JBASMP-68.
-------------------------------
Resolution: Won't Fix
I don't think this is going to be fixable for this plugin. It's fixed in the wildfly-maven-plugin and in WildFly Core as part of https://issues.jboss.org/browse/WFCORE-599.
> execute-commands does not work for module command
> -------------------------------------------------
>
> Key: JBASMP-68
> URL: https://issues.jboss.org/browse/JBASMP-68
> Project: JBoss AS Maven Plugins
> Issue Type: Bug
> Affects Versions: 7.6.Final
> Reporter: Alfio Gloria
>
> I'm trying to remove a jboss module by means of maven.
> {code:xml}
> <configuration>
> <jbossHome>${project.build.directory}/server/jboss72</jbossHome>
> <execute-commands>
> <commands>
> <command>module remove --slot=main --name=system.layers.base.org.jboss.weld.core</command>
> </commands>
> </execute-commands>
> </configuration>
> {code}
> execute-commands fails with the following stack trace:
> {code}
> Failed to execute goal org.jboss.as.plugins:jboss-as-maven-plugin:7.5.Final:execute-commands (install-patched-weld) on project tools: Execution install-patched-weld of goal org.jboss.as.plugins:jboss-as-maven-plugin:7.5.Final:execute-commands failed: Command execution failed for command 'module remove --slot=main --name=system.layers.base.org.jboss.weld.core'. JBOSS_HOME environment variable is not set. -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.jboss.as.plugins:jboss-as-maven-plugin:7.5.Final:execute-commands (install-patched-weld) on project tools: Execution install-patched-weld of goal org.jboss.as.plugins:jboss-as-maven-plugin:7.5.Final:execute-commands failed: Command execution failed for command 'module remove --slot=main --name=system.layers.base.org.jboss.weld.core'. JBOSS_HOME environment variable is not set.
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:224)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
> at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:317)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:152)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:555)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:158)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:483)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution install-patched-weld of goal org.jboss.as.plugins:jboss-as-maven-plugin:7.5.Final:execute-commands failed: Command execution failed for command 'module remove --slot=main --name=system.layers.base.org.jboss.weld.core'. JBOSS_HOME environment variable is not set.
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:115)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> ... 19 more
> Caused by: java.lang.IllegalArgumentException: Command execution failed for command 'module remove --slot=main --name=system.layers.base.org.jboss.weld.core'. JBOSS_HOME environment variable is not set.
> at org.jboss.as.plugin.cli.Commands.executeCommands(Commands.java:180)
> at org.jboss.as.plugin.cli.Commands.execute(Commands.java:134)
> at org.jboss.as.plugin.cli.ExecuteCommands.execute(ExecuteCommands.java:71)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:106)
> ... 20 more
> Caused by: org.jboss.as.cli.CommandLineException: JBOSS_HOME environment variable is not set.
> at org.jboss.as.cli.handlers.module.ASModuleHandler.getModulesDir(ASModuleHandler.java:362)
> at org.jboss.as.cli.handlers.module.ASModuleHandler.removeModule(ASModuleHandler.java:326)
> at org.jboss.as.cli.handlers.module.ASModuleHandler.doHandle(ASModuleHandler.java:214)
> at org.jboss.as.cli.handlers.CommandHandlerWithHelp.handle(CommandHandlerWithHelp.java:86)
> at org.jboss.as.cli.impl.CommandContextImpl.handle(CommandContextImpl.java:581)
> at org.jboss.as.plugin.cli.Commands.executeCommands(Commands.java:176)
> ... 23 more
> {code}
> (tested with the last snapshot too)
> The problem comes from jboss-as-cli that needs the JBOSS_HOME to be set in order to add or remove modules. This is not a requirement for other commands such as deploy.
> There are some points of confusion:
> # JBOSS_HOME is set in .bashrc but IDEs do not read .bashrc, thereby it can work in some cases but not in others;
> # usually there are more than one installation or jboss-as-maven-plugin can download the server;
> # jbossHome config parameter is not take into account;
> # what if I want to make operations on more the one server at the same time?
> At the moment I solved by patching jboss-as-cli using a system property instead of environment variable. I don't know how to solve without touching jboss-as-cli.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (ELY-558) Introduce generalized support for authentication timeout of mechanisms
by Farah Juma (JIRA)
[ https://issues.jboss.org/browse/ELY-558?page=com.atlassian.jira.plugin.sy... ]
Farah Juma reassigned ELY-558:
------------------------------
Assignee: Farah Juma
> Introduce generalized support for authentication timeout of mechanisms
> ----------------------------------------------------------------------
>
> Key: ELY-558
> URL: https://issues.jboss.org/browse/ELY-558
> Project: WildFly Elytron
> Issue Type: Enhancement
> Components: Authentication Mechanisms, Utils
> Reporter: David Lloyd
> Assignee: Farah Juma
> Fix For: 1.1.0.Beta6
>
>
> Paraphrasing from HipChat discussion.
> Generic mechanism wrappers for handling authentication timeout will not only support OTP-style credential read-modify-write authentication mechanisms, but generally avoid certain DoS conditions and failure states that would be associated with long locking of credentials (even in the read case).
> This issue is to implement a wrapping mechanism factory (for at least SASL and possibly HTTP as well, eventually) which supports authentication timeout by judicious usage of concurrency primitives and timed executors. It is important to guarantee thread-safe access to the underlying mechanism, which are generally concurrency-unsafe.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months