[JBoss JIRA] (WFLY-7255) Creating LDAP security realm fails with cryptic error message
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFLY-7255?page=com.atlassian.jira.plugin.... ]
Jan Kalina updated WFLY-7255:
-----------------------------
Component/s: Security
> Creating LDAP security realm fails with cryptic error message
> -------------------------------------------------------------
>
> Key: WFLY-7255
> URL: https://issues.jboss.org/browse/WFLY-7255
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Zach Rhoads
> Assignee: Jan Kalina
>
> When creating an LDAP security realm via CLI, setup fails with cryptic error message.
> For example, creating a dir-context works fine:
> /subsystem=elytron/dir-context=exampleDC:add(url="ldap://127.0.0.1:10389",principal="uid=admin,ou=system",credential="secret")
> But when creating an ldap-realm:
> /subsystem=elytron/ldap-realm=exampleLR:add(dir-context=exampleDC,identity-mapping={search-base-dn="ou=Users,dc=jboss,dc=org",rdn-identifier="uid",user-password-mapper={from="userPassword"}})
> It fails:
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalArgumentException",
> "rolled-back" => true
> }
> Full log in wildfly:
> 14:11:03,368 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "elytron"),
> ("ldap-realm" => "exampleLR")
> ]): java.lang.IllegalArgumentException
> at org.jboss.dmr.ModelValue.asBoolean(ModelValue.java:69)
> at org.jboss.dmr.ModelNode.asBoolean(ModelNode.java:267)
> at org.wildfly.extension.elytron.LdapRealmDefinition$UserPasswordCredentialMappingObjectDefinition.configure(LdapRealmDefinition.java:163)
> at org.wildfly.extension.elytron.LdapRealmDefinition$RealmAddHandler.configureIdentityMapping(LdapRealmDefinition.java:420)
> at org.wildfly.extension.elytron.LdapRealmDefinition$RealmAddHandler.performRuntime(LdapRealmDefinition.java:375)
> at org.jboss.as.controller.AbstractAddStepHandler.performRuntime(AbstractAddStepHandler.java:337)
> at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:151)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:940)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:683)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:382)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1363)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:410)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:232)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:213)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:136)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:153)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:422)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:149)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153)
> at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70)
> at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160)
> 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)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (ELY-644) Creating LDAP security realm fails with cryptic error message
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-644?page=com.atlassian.jira.plugin.sy... ]
Jan Kalina commented on ELY-644:
--------------------------------
Problem is the LdapRealm obtain value of "writable" attribute directly from query, fail instead of using default.
> Creating LDAP security realm fails with cryptic error message
> -------------------------------------------------------------
>
> Key: ELY-644
> URL: https://issues.jboss.org/browse/ELY-644
> Project: WildFly Elytron
> Issue Type: Bug
> Reporter: Zach Rhoads
> Assignee: Jan Kalina
>
> When creating an LDAP security realm via CLI, setup fails with cryptic error message.
> For example, creating a dir-context works fine:
> /subsystem=elytron/dir-context=exampleDC:add(url="ldap://127.0.0.1:10389",principal="uid=admin,ou=system",credential="secret")
> But when creating an ldap-realm:
> /subsystem=elytron/ldap-realm=exampleLR:add(dir-context=exampleDC,identity-mapping={search-base-dn="ou=Users,dc=jboss,dc=org",rdn-identifier="uid",user-password-mapper={from="userPassword"}})
> It fails:
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalArgumentException",
> "rolled-back" => true
> }
> Full log in wildfly:
> 14:11:03,368 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "elytron"),
> ("ldap-realm" => "exampleLR")
> ]): java.lang.IllegalArgumentException
> at org.jboss.dmr.ModelValue.asBoolean(ModelValue.java:69)
> at org.jboss.dmr.ModelNode.asBoolean(ModelNode.java:267)
> at org.wildfly.extension.elytron.LdapRealmDefinition$UserPasswordCredentialMappingObjectDefinition.configure(LdapRealmDefinition.java:163)
> at org.wildfly.extension.elytron.LdapRealmDefinition$RealmAddHandler.configureIdentityMapping(LdapRealmDefinition.java:420)
> at org.wildfly.extension.elytron.LdapRealmDefinition$RealmAddHandler.performRuntime(LdapRealmDefinition.java:375)
> at org.jboss.as.controller.AbstractAddStepHandler.performRuntime(AbstractAddStepHandler.java:337)
> at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:151)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:940)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:683)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:382)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1363)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:410)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:232)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:213)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:136)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:153)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:422)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:149)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153)
> at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70)
> at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160)
> 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)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (WFLY-7254) pattern-filter disappears if predefined-filter is used for configurable-sasl-server-factory in Elytron subsystem
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-7254?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse updated WFLY-7254:
-----------------------------------
Affects Version/s: (was: 11.0.0.Alpha1)
> pattern-filter disappears if predefined-filter is used for configurable-sasl-server-factory in Elytron subsystem
> ----------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-7254
> URL: https://issues.jboss.org/browse/WFLY-7254
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Ondrej Lukas
> Assignee: Darran Lofthouse
> Fix For: 11.0.0.Alpha1
>
>
> In case when configurable-sasl-server-factory is created through CLI with filter which uses both pattern-filter and predefined-filter, then only predefined-filter is stored into configuration (pattern-filter disappears).
> Suggestion:
> In case when usage of both filters is unsupported option, then it should be denied by CLI. In case when it is supported option, then both of them should be stored in configuration.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (WFLY-7254) pattern-filter disappears if predefined-filter is used for configurable-sasl-server-factory in Elytron subsystem
by Ondrej Lukas (JIRA)
Ondrej Lukas created WFLY-7254:
----------------------------------
Summary: pattern-filter disappears if predefined-filter is used for configurable-sasl-server-factory in Elytron subsystem
Key: WFLY-7254
URL: https://issues.jboss.org/browse/WFLY-7254
Project: WildFly
Issue Type: Bug
Components: Security
Reporter: Ondrej Lukas
Assignee: Darran Lofthouse
In case when configurable-sasl-server-factory is created through CLI with filter which uses both pattern-filter and predefined-filter, then only predefined-filter is stored into configuration (pattern-filter disappears).
Suggestion:
In case when usage of both filters is unsupported option, then it should be denied by CLI. In case when it is supported option, then both of them should be stored in configuration.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (WFLY-6942) Add a forget operation to the transaction subsystem tooling
by Michael Musgrove (JIRA)
[ https://issues.jboss.org/browse/WFLY-6942?page=com.atlassian.jira.plugin.... ]
Michael Musgrove resolved WFLY-6942.
------------------------------------
Release Notes Text: The transactions tooling operation to remove heuristically completed XA resource participants from transaction logs previously (to this release) did not invoke the forget operation on the resource. This call is useful since it facilitates clean up. In this release the forget operation is called when removing such participants. However, by default the result of the forget call is ignored and even if it fails the log is still removed. To override this behaviour the administrator can set a system property called ignoreMBeanHeuristics to the value false. With this value set participants will not be removed from the log if the forget call is unsuccessful.
Fix Version/s: 11.0.0.Alpha1
Resolution: Done
This operaton is fixed in WFLY-7241 (Upgrade Narayana to 5.3.5.Final).
Only the docs/release notes update for how to trigger the forget operation is pending.
> Add a forget operation to the transaction subsystem tooling
> -----------------------------------------------------------
>
> Key: WFLY-6942
> URL: https://issues.jboss.org/browse/WFLY-6942
> Project: WildFly
> Issue Type: Feature Request
> Components: Transactions
> Affects Versions: 10.1.0.CR1
> Reporter: Michael Musgrove
> Assignee: Michael Musgrove
> Fix For: 11.0.0.Alpha1
>
>
> The CLI tooling provides two features for dealing with heuristic participants:
> * a recover command that will move it back into the prepared state if the admin thinks a second prepare attempt is likely to succeed;
> * a delete operation if the admin thinks it safe to do so;
> In the case of XA resources we also need a forget operation which will trigger the resource adaptor to clean up its end instead of relying on the admin to use tooling provided by the RA to clean up.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (WFLY-7252) war bean not visible for injection
by Teresa Miyar (JIRA)
[ https://issues.jboss.org/browse/WFLY-7252?page=com.atlassian.jira.plugin.... ]
Teresa Miyar updated WFLY-7252:
-------------------------------
Description:
In an ear file 2 wars and one shared lib, warA provides implementation for shared lib, warB cannot see warA implementation even though our documentation on chapter 12 states:
Chapter 12. Packaging and dep...
• In an application deployed as an ear, the container searches every bean archive bundled with
or referenced by the ear, including bean archives bundled with or referenced by wars, EJB jars
and rars contained in the ear. The bean archives might be library jars, EJB jars or war WEB-
INF/classes directories.
Then we have this:
See also the "5.1. Modularity",
http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#selection:
"A bean packaged in a certain module is available for injection, lookup and EL resolution to classes and JSP/JSF pages packaged in some other module if and only if the bean class of the bean is required to be accessible to the other module by the class accessibility requirements of the module architecture."
"In the Java EE module architecture, a bean class is accessible in a module if and only if it is required to be accessible according to the class loading requirements defined by the Java EE platform specification."
But the JavaEE spec states it "may" have access... it did have access on EAP6, does not have access on EAP7.
was:
In an ear file 2 wars and one shared lib, warA provides implementation for shared lib, warB cannot see warA implementation even though our documentation on chapter 12 states:
Chapter 12. Packaging and dep...
• In an application deployed as an ear, the container searches every bean archive bundled with
or referenced by the ear, including bean archives bundled with or referenced by wars, EJB jars
and rars contained in the ear. The bean archives might be library jars, EJB jars or war WEB-
INF/classes directories.
> war bean not visible for injection
> ----------------------------------
>
> Key: WFLY-7252
> URL: https://issues.jboss.org/browse/WFLY-7252
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 10.0.0.Final, 10.1.0.Final
> Reporter: Teresa Miyar
> Assignee: Stuart Douglas
> Priority: Critical
> Attachments: DemoProjects.zip
>
>
> In an ear file 2 wars and one shared lib, warA provides implementation for shared lib, warB cannot see warA implementation even though our documentation on chapter 12 states:
> Chapter 12. Packaging and dep...
> • In an application deployed as an ear, the container searches every bean archive bundled with
> or referenced by the ear, including bean archives bundled with or referenced by wars, EJB jars
> and rars contained in the ear. The bean archives might be library jars, EJB jars or war WEB-
> INF/classes directories.
> Then we have this:
> See also the "5.1. Modularity",
> http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#selection:
> "A bean packaged in a certain module is available for injection, lookup and EL resolution to classes and JSP/JSF pages packaged in some other module if and only if the bean class of the bean is required to be accessible to the other module by the class accessibility requirements of the module architecture."
> "In the Java EE module architecture, a bean class is accessible in a module if and only if it is required to be accessible according to the class loading requirements defined by the Java EE platform specification."
> But the JavaEE spec states it "may" have access... it did have access on EAP6, does not have access on EAP7.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (WFCORE-1846) WFLYSRV0153 error after attempting to explode archived subdeployments of archived deployments
by ehsavoie Hugonnet (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1846?page=com.atlassian.jira.plugi... ]
ehsavoie Hugonnet moved JBEAP-6275 to WFCORE-1846:
--------------------------------------------------
Project: WildFly Core (was: JBoss Enterprise Application Platform)
Key: WFCORE-1846 (was: JBEAP-6275)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Domain Management
(was: Domain Management)
Affects Version/s: 3.0.0.Alpha9
(was: 7.1.0.DR5)
> WFLYSRV0153 error after attempting to explode archived subdeployments of archived deployments
> ---------------------------------------------------------------------------------------------
>
> Key: WFCORE-1846
> URL: https://issues.jboss.org/browse/WFCORE-1846
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 3.0.0.Alpha9
> Reporter: ehsavoie Hugonnet
> Assignee: ehsavoie Hugonnet
>
> In archived deployments with archived subdeployments, the {{explode}} operation with {{path}} parameter defined to point at archived subdeployment causes the removal of whole deployment from the content repository.
> This operation is illegal, but the server should produce formed warning message with operation failing gracefully instead of throwing stack trace in this case.
> server.log:
> {code}09:05:07,664 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 29) WFLYUT0022: Unregistered web context: /subdeployment-test-web
> 09:05:07,701 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 2) WFLYCLINF0003: Stopped client-mappings cache from ejb container
> 09:05:07,719 INFO [org.jboss.as.server.deployment] (MSC service thread 1-7) WFLYSRV0208: Stopped subdeployment (runtime-name: subdeployment-test-ejb.jar) in 65ms
> 09:05:07,719 INFO [org.jboss.as.server.deployment] (MSC service thread 1-6) WFLYSRV0208: Stopped subdeployment (runtime-name: subdeployment-test-web.war) in 66ms
> 09:05:07,722 INFO [org.jboss.as.server.deployment] (MSC service thread 1-1) WFLYSRV0028: Stopped deployment subdeployment-test.ear (runtime-name: subdeployment-test.ear) in 69ms
> 09:05:07,732 INFO [org.jboss.as.server] (management-handler-thread - 1) WFLYSRV0009: Undeployed "subdeployment-test.ear" (runtime-name: "subdeployment-test.ear")
> 09:05:07,754 INFO [org.jboss.as.repository] (management-handler-thread - 2) WFLYDR0002: Content removed from location /home/mjurc/testing/wildfly/testsuite/integration/basic/target/jbossas/standalone/data/content/13/5a0425d908539149b62eb99b63710c67b13466/content
> 09:05:07,762 INFO [org.jboss.as.server.deployment] (MSC service thread 1-5) WFLYSRV0027: Starting deployment of "subdeployment-test.ear" (runtime-name: "subdeployment-test.ear")
> [0m[31m09:05:07,763 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC000001: Failed to start service jboss.deployment.unit."subdeployment-test.ear".STRUCTURE: org.jboss.msc.service.StartException in service jboss.deployment.unit."subdeployment-test.ear".STRUCTURE: WFLYSRV0153: Failed to process phase STRUCTURE of deployment "subdeployment-test.ear"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:154)
> 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: org.jboss.as.server.deployment.DeploymentUnitProcessingException: WFLYSRV0160: Failed to mount deployment content
> at org.jboss.as.server.deployment.module.DeploymentRootMountProcessor.deploy(DeploymentRootMountProcessor.java:95)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:147)
> ... 5 more
> Caused by: java.io.FileNotFoundException: /home/mjurc/testing/wildfly/testsuite/integration/basic/target/jbossas/standalone/data/managed-exploded/subdeployment-test.ear (No such file or directory)
> at java.io.FileInputStream.open0(Native Method)
> at java.io.FileInputStream.open(FileInputStream.java:195)
> at java.io.FileInputStream.<init>(FileInputStream.java:138)
> at org.jboss.vfs.spi.RootFileSystem.openInputStream(RootFileSystem.java:51)
> at org.jboss.vfs.VirtualFile.openStream(VirtualFile.java:318)
> at org.jboss.vfs.VFS.mountZipExpanded(VFS.java:533)
> at org.jboss.as.server.deployment.DeploymentMountProvider$Factory$ServerDeploymentRepositoryImpl.mountDeploymentContent(DeploymentMountProvider.java:108)
> at org.jboss.as.server.deployment.module.DeploymentRootMountProcessor.deploy(DeploymentRootMountProcessor.java:91)
> ... 6 more
> [0m[31m09:05:07,765 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 3) WFLYCTL0013: Operation ("deploy") failed - address: (("deployment" => "subdeployment-test.ear")) - failure description: {
> "WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"subdeployment-test.ear\".STRUCTURE" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"subdeployment-test.ear\".STRUCTURE: WFLYSRV0153: Failed to process phase STRUCTURE of deployment \"subdeployment-test.ear\"
> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: WFLYSRV0160: Failed to mount deployment content
> Caused by: java.io.FileNotFoundException: /home/mjurc/testing/wildfly/testsuite/integration/basic/target/jbossas/standalone/data/managed-exploded/subdeployment-test.ear (No such file or directory)"},
> "WFLYCTL0412: Required services that are not installed:" => ["jboss.deployment.unit.\"subdeployment-test.ear\".STRUCTURE"],
> "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined
> }
> 09:05:07,767 ERROR [org.jboss.as.server] (management-handler-thread - 3) WFLYSRV0021: Deploy of deployment "subdeployment-test.ear" was rolled back with the following failure message:
> {
> "WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"subdeployment-test.ear\".STRUCTURE" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"subdeployment-test.ear\".STRUCTURE: WFLYSRV0153: Failed to process phase STRUCTURE of deployment \"subdeployment-test.ear\"
> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: WFLYSRV0160: Failed to mount deployment content
> Caused by: java.io.FileNotFoundException: /home/mjurc/testing/wildfly/testsuite/integration/basic/target/jbossas/standalone/data/managed-exploded/subdeployment-test.ear (No such file or directory)"},
> "WFLYCTL0412: Required services that are not installed:" => ["jboss.deployment.unit.\"subdeployment-test.ear\".STRUCTURE"],
> "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined
> }
> 09:05:07,768 INFO [org.jboss.as.server.deployment] (MSC service thread 1-8) WFLYSRV0028: Stopped deployment subdeployment-test.ear (runtime-name: subdeployment-test.ear) in 1ms
> 09:05:07,770 INFO [org.jboss.as.controller] (management-handler-thread - 3) WFLYCTL0183: Service status report
> WFLYCTL0186: Services which failed to start: service jboss.deployment.unit."subdeployment-test.ear".STRUCTURE{code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months