[JBoss JIRA] (WFLY-3048) "Local" authentication fails when LDAP is used for ManagementRealm
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-3048?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-3048:
-----------------------------------------------
Darran Lofthouse <darran.lofthouse(a)redhat.com> changed the Status of [bug 1043667|https://bugzilla.redhat.com/show_bug.cgi?id=1043667] from ASSIGNED to POST
> "Local" authentication fails when LDAP is used for ManagementRealm
> ------------------------------------------------------------------
>
> Key: WFLY-3048
> URL: https://issues.jboss.org/browse/WFLY-3048
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Security
> Affects Versions: 8.0.0.Final
> Environment: Ubuntu 13.04, Xeon-based VPS
> Reporter: Matt Jensen
> Assignee: Darran Lofthouse
> Fix For: 8.0.1.Final
>
>
> When LDAP is used for authentication in ManagementRealm, "local" authentication, which is enabled in configuration for the realm, appears to stop working.
> I have configured my ManagementRealm to use LDAP for authentication of remote clients. However, I also need to allow local authentication without a username and password, for when jboss-cli is invoked from the command line on the server. This is needed in order for the wildfly-init-debian.sh script to shut down the server. I have configured the ManagementRealm as follows:
> <security-realm name="ManagementRealm">
> <authentication>
> <local default-user="$local" />
> <ldap connection="..." base-dn="ou=accounts,dc=..." recursive="false">
> ...
> </ldap>
> </authentication>
> <authorization map-groups-to-roles="false">
> <ldap connection="...">
> ...
> </ldap>
> </authorization>
> </security-realm>
> I left out most of the LDAP configuration because I don't think it is important for this issue. LDAP authentication works fine for remote clients. In fact, it works fine for local clients as well--when I invoke jboss-cli with LDAP authentication enabled, it prompts for a username and password; if I enter a valid combination from the LDAP directory, jboss-cli connects successfully and executes its command.
> The problem is that I need it to NOT prompt for a username and password when jboss-cli is invoked locally. Which, I believe, is how things are supposed to work when "local" authentication is also enabled; it just doesn't work that way when LDAP is enabled for the same realm.
> If I comment out the <ldap .../> element in <authentication> for the realm, local authentication starts working again. I can invoke jboss-cli locally and the command is carried out without a username and password prompt. Re-enable LDAP, with no other configuration changes, and again it flips back to requiring a username and password.
> I have tried replacing "$local" in the @default-user element of the <local> element with a valid name from the LDAP directory, both as a simple username and as a full DN, and jboss-cli still prompts for a username and password.
> The modification date on the [tmp/auth] directory changes when I run jboss-cli with LDAP in place and get the username/password prompt, so it appears that the client is putting a token in there to try to use local authentication. The server just never picks it up.
> The documentation specifically mentions that <local/> should work along with <ldap/> here:
> https://docs.jboss.org/author/display/WFLY8/Security+Realms
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 8 months
[JBoss JIRA] (WFLY-3212) Access Base URI without CDI
by Caleb Cushing (JIRA)
Caleb Cushing created WFLY-3212:
-----------------------------------
Summary: Access Base URI without CDI
Key: WFLY-3212
URL: https://issues.jboss.org/browse/WFLY-3212
Project: WildFly
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Reporter: Caleb Cushing
Priority: Minor
I need to get at the baseUri, I'm familliar with this
@Context
UriInfo uriInfo;
my problem is I need the baseUri in a piece of code I can't Inject into, (a sub object of an entity). I could pass `uriInfo` or the builder down but that doesn't seem ideal, as most of the objects have no business knowing about it. The end goal is HATEOAS URI's in my JSON responses, but I don't need it to be a JAX-RS specific solution, I figure if I can just get at the Base URI either in my jackson converters, or entities, I can create the `URIBuilder` from there. It seems to me that once the app is deployed the base uri could be a global singleton.
This is requesting a feature that allows me to access the base uri in the application or a URIBuilder similar to UriInfo.getBaseUriBuilder() except without requiring that the object be injected, this object would obviously not have request specific information
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 8 months
[JBoss JIRA] (WFLY-3048) "Local" authentication fails when LDAP is used for ManagementRealm
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-3048?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated WFLY-3048:
------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1069127
> "Local" authentication fails when LDAP is used for ManagementRealm
> ------------------------------------------------------------------
>
> Key: WFLY-3048
> URL: https://issues.jboss.org/browse/WFLY-3048
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Security
> Affects Versions: 8.0.0.Final
> Environment: Ubuntu 13.04, Xeon-based VPS
> Reporter: Matt Jensen
> Assignee: Darran Lofthouse
> Fix For: 8.0.1.Final
>
>
> When LDAP is used for authentication in ManagementRealm, "local" authentication, which is enabled in configuration for the realm, appears to stop working.
> I have configured my ManagementRealm to use LDAP for authentication of remote clients. However, I also need to allow local authentication without a username and password, for when jboss-cli is invoked from the command line on the server. This is needed in order for the wildfly-init-debian.sh script to shut down the server. I have configured the ManagementRealm as follows:
> <security-realm name="ManagementRealm">
> <authentication>
> <local default-user="$local" />
> <ldap connection="..." base-dn="ou=accounts,dc=..." recursive="false">
> ...
> </ldap>
> </authentication>
> <authorization map-groups-to-roles="false">
> <ldap connection="...">
> ...
> </ldap>
> </authorization>
> </security-realm>
> I left out most of the LDAP configuration because I don't think it is important for this issue. LDAP authentication works fine for remote clients. In fact, it works fine for local clients as well--when I invoke jboss-cli with LDAP authentication enabled, it prompts for a username and password; if I enter a valid combination from the LDAP directory, jboss-cli connects successfully and executes its command.
> The problem is that I need it to NOT prompt for a username and password when jboss-cli is invoked locally. Which, I believe, is how things are supposed to work when "local" authentication is also enabled; it just doesn't work that way when LDAP is enabled for the same realm.
> If I comment out the <ldap .../> element in <authentication> for the realm, local authentication starts working again. I can invoke jboss-cli locally and the command is carried out without a username and password prompt. Re-enable LDAP, with no other configuration changes, and again it flips back to requiring a username and password.
> I have tried replacing "$local" in the @default-user element of the <local> element with a valid name from the LDAP directory, both as a simple username and as a full DN, and jboss-cli still prompts for a username and password.
> The modification date on the [tmp/auth] directory changes when I run jboss-cli with LDAP in place and get the username/password prompt, so it appears that the client is putting a token in there to try to use local authentication. The server just never picks it up.
> The documentation specifically mentions that <local/> should work along with <ldap/> here:
> https://docs.jboss.org/author/display/WFLY8/Security+Realms
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 8 months
[JBoss JIRA] (WFLY-3048) "Local" authentication fails when LDAP is used for ManagementRealm
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-3048?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated WFLY-3048:
------------------------------------------
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1069127, https://bugzilla.redhat.com/show_bug.cgi?id=1043667 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1069127)
> "Local" authentication fails when LDAP is used for ManagementRealm
> ------------------------------------------------------------------
>
> Key: WFLY-3048
> URL: https://issues.jboss.org/browse/WFLY-3048
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Security
> Affects Versions: 8.0.0.Final
> Environment: Ubuntu 13.04, Xeon-based VPS
> Reporter: Matt Jensen
> Assignee: Darran Lofthouse
> Fix For: 8.0.1.Final
>
>
> When LDAP is used for authentication in ManagementRealm, "local" authentication, which is enabled in configuration for the realm, appears to stop working.
> I have configured my ManagementRealm to use LDAP for authentication of remote clients. However, I also need to allow local authentication without a username and password, for when jboss-cli is invoked from the command line on the server. This is needed in order for the wildfly-init-debian.sh script to shut down the server. I have configured the ManagementRealm as follows:
> <security-realm name="ManagementRealm">
> <authentication>
> <local default-user="$local" />
> <ldap connection="..." base-dn="ou=accounts,dc=..." recursive="false">
> ...
> </ldap>
> </authentication>
> <authorization map-groups-to-roles="false">
> <ldap connection="...">
> ...
> </ldap>
> </authorization>
> </security-realm>
> I left out most of the LDAP configuration because I don't think it is important for this issue. LDAP authentication works fine for remote clients. In fact, it works fine for local clients as well--when I invoke jboss-cli with LDAP authentication enabled, it prompts for a username and password; if I enter a valid combination from the LDAP directory, jboss-cli connects successfully and executes its command.
> The problem is that I need it to NOT prompt for a username and password when jboss-cli is invoked locally. Which, I believe, is how things are supposed to work when "local" authentication is also enabled; it just doesn't work that way when LDAP is enabled for the same realm.
> If I comment out the <ldap .../> element in <authentication> for the realm, local authentication starts working again. I can invoke jboss-cli locally and the command is carried out without a username and password prompt. Re-enable LDAP, with no other configuration changes, and again it flips back to requiring a username and password.
> I have tried replacing "$local" in the @default-user element of the <local> element with a valid name from the LDAP directory, both as a simple username and as a full DN, and jboss-cli still prompts for a username and password.
> The modification date on the [tmp/auth] directory changes when I run jboss-cli with LDAP in place and get the username/password prompt, so it appears that the client is putting a token in there to try to use local authentication. The server just never picks it up.
> The documentation specifically mentions that <local/> should work along with <ldap/> here:
> https://docs.jboss.org/author/display/WFLY8/Security+Realms
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 8 months
[JBoss JIRA] (WFLY-3207) ContextNotActiveException: WELD-001303: No active contexts for scope type javax.faces.flow.builder.FlowDefinition on reload
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-3207?page=com.atlassian.jira.plugin.... ]
Radoslav Husar commented on WFLY-3207:
--------------------------------------
Seems like a [lot of people ran into the issue|https://www.google.com/search?q=No+active+contexts+for+scope+type+j...] but I couldn't see any Jira report.
> ContextNotActiveException: WELD-001303: No active contexts for scope type javax.faces.flow.builder.FlowDefinition on reload
> ---------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-3207
> URL: https://issues.jboss.org/browse/WFLY-3207
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JSF
> Affects Versions: 8.0.0.Final
> Reporter: Radoslav Husar
> Assignee: Farah Juma
>
> Deploy JSF application and reload the server (:reload from CLI).
> {noformat}
> 14:07:53,201 SEVERE [javax.enterprise.resource.webcontainer.jsf.config] (MSC service thread 1-2) Critical error during deployment: : org.jboss.weld.context.ContextNotActiveException: WELD-001303: No active contexts for scope type javax.faces.flow.builder.FlowDefinition
> at org.jboss.weld.manager.BeanManagerImpl.getContext(BeanManagerImpl.java:680) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
> at org.jboss.weld.util.ForwardingBeanManager.getContext(ForwardingBeanManager.java:181) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
> at com.sun.faces.application.ApplicationAssociate$PostConstructApplicationListener.loadFlows(ApplicationAssociate.java:323) [jsf-impl-2.2.6-jbossorg-2.jar:]
> at com.sun.faces.application.ApplicationAssociate$PostConstructApplicationListener.processEvent(ApplicationAssociate.java:303) [jsf-impl-2.2.6-jbossorg-2.jar:]
> at javax.faces.event.SystemEvent.processListener(SystemEvent.java:108) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6]
> at com.sun.faces.application.ApplicationImpl.processListeners(ApplicationImpl.java:2187) [jsf-impl-2.2.6-jbossorg-2.jar:]
> at com.sun.faces.application.ApplicationImpl.invokeListenersFor(ApplicationImpl.java:2163) [jsf-impl-2.2.6-jbossorg-2.jar:]
> at com.sun.faces.application.ApplicationImpl.publishEvent(ApplicationImpl.java:296) [jsf-impl-2.2.6-jbossorg-2.jar:]
> at org.jboss.as.jsf.injection.weld.ForwardingApplication.publishEvent(ForwardingApplication.java:294) [wildfly-jsf-injection-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> at com.sun.faces.config.ConfigManager.publishPostConfigEvent(ConfigManager.java:692) [jsf-impl-2.2.6-jbossorg-2.jar:]
> at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:253) [jsf-impl-2.2.6-jbossorg-2.jar:]
> at io.undertow.servlet.core.ApplicationListeners.contextInitialized(ApplicationListeners.java:173) [undertow-servlet-1.0.3.Final.jar:1.0.3.Final]
> at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:189) [undertow-servlet-1.0.3.Final.jar:1.0.3.Final]
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:86)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.start(UndertowDeploymentService.java:71)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.8.0]
> 14:07:53,208 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.undertow.deployment.default-server.default-host./clusterbench-passivating: org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./clusterbench-passivating: Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) [jboss-msc-1.2.1.Final.jar:1.2.1.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.8.0]
> Caused by: java.lang.RuntimeException: java.lang.RuntimeException: org.jboss.weld.context.ContextNotActiveException: WELD-001303: No active contexts for scope type javax.faces.flow.builder.FlowDefinition
> at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:218)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:86)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.start(UndertowDeploymentService.java:71)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.1.Final.jar:1.2.1.Final]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.1.Final.jar:1.2.1.Final]
> ... 3 more
> Caused by: java.lang.RuntimeException: org.jboss.weld.context.ContextNotActiveException: WELD-001303: No active contexts for scope type javax.faces.flow.builder.FlowDefinition
> at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:273)
> at io.undertow.servlet.core.ApplicationListeners.contextInitialized(ApplicationListeners.java:173)
> at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:189)
> ... 7 more
> Caused by: org.jboss.weld.context.ContextNotActiveException: WELD-001303: No active contexts for scope type javax.faces.flow.builder.FlowDefinition
> at org.jboss.weld.manager.BeanManagerImpl.getContext(BeanManagerImpl.java:680)
> at org.jboss.weld.util.ForwardingBeanManager.getContext(ForwardingBeanManager.java:181)
> at com.sun.faces.application.ApplicationAssociate$PostConstructApplicationListener.loadFlows(ApplicationAssociate.java:323)
> at com.sun.faces.application.ApplicationAssociate$PostConstructApplicationListener.processEvent(ApplicationAssociate.java:303)
> at javax.faces.event.SystemEvent.processListener(SystemEvent.java:108)
> at com.sun.faces.application.ApplicationImpl.processListeners(ApplicationImpl.java:2187)
> at com.sun.faces.application.ApplicationImpl.invokeListenersFor(ApplicationImpl.java:2163)
> at com.sun.faces.application.ApplicationImpl.publishEvent(ApplicationImpl.java:296)
> at org.jboss.as.jsf.injection.weld.ForwardingApplication.publishEvent(ForwardingApplication.java:294)
> at com.sun.faces.config.ConfigManager.publishPostConfigEvent(ConfigManager.java:692)
> at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:253)
> ... 9 more
> 14:07:53,437 INFO [javax.enterprise.resource.webcontainer.jsf.config] (MSC service thread 1-1) Initializing Mojarra 2.2.6-jbossorg-2 20140318-1712 for context '/translator'
> 14:07:53,542 INFO [javax.enterprise.resource.webcontainer.jsf.config] (MSC service thread 1-6) Initializing Mojarra 2.2.6-jbossorg-2 20140318-1712 for context '/clusterbench'
> 14:07:53,704 INFO [org.wildfly.extension.undertow] (MSC service thread 1-6) JBAS017534: Registered web context: /clusterbench
> 14:07:54,448 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) JBAS017534: Registered web context: /translator
> 14:07:54,456 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "clusterbench-ee7.ear")]) - failure description: {"JBAS014671: Failed services" => {"jboss.undertow.deployment.default-server.default-host./clusterbench-passivating" => "org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./clusterbench-passivating: Failed to start service
> Caused by: java.lang.RuntimeException: java.lang.RuntimeException: org.jboss.weld.context.ContextNotActiveException: WELD-001303: No active contexts for scope type javax.faces.flow.builder.FlowDefinition
> Caused by: java.lang.RuntimeException: org.jboss.weld.context.ContextNotActiveException: WELD-001303: No active contexts for scope type javax.faces.flow.builder.FlowDefinition
> Caused by: org.jboss.weld.context.ContextNotActiveException: WELD-001303: No active contexts for scope type javax.faces.flow.builder.FlowDefinition"}}
> 14:07:54,475 INFO [org.jboss.as.server] (ServerService Thread Pool -- 31) JBAS018559: Deployed "clusterbench-ee7.ear" (runtime-name : "clusterbench-ee7.ear")
> 14:07:54,475 INFO [org.jboss.as.server] (ServerService Thread Pool -- 31) JBAS018559: Deployed "translator.war" (runtime-name : "translator.war")
> 14:07:54,477 INFO [org.jboss.as.controller] (Controller Boot Thread) JBAS014774: Service status report
> JBAS014777: Services which failed to start: service jboss.undertow.deployment.default-server.default-host./clusterbench-passivating: org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./clusterbench-passivating: Failed to start service
> 14:07:54,489 INFO [org.jboss.as] (Controller Boot Thread) JBAS015961: Http management interface listening on http://127.0.0.1:9990/management
> 14:07:54,493 INFO [org.jboss.as] (Controller Boot Thread) JBAS015951: Admin console listening on http://127.0.0.1:9990
> 14:07:54,493 ERROR [org.jboss.as] (Controller Boot Thread) JBAS015875: WildFly 8.0.1.Final-SNAPSHOT "WildFly" started (with errors) in 4618ms - Started 843 of 957 services (3 services failed or missing dependencies, 243 services are lazy, passive or on-demand)
> 14:07:54,704 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) JBAS017535: Unregistered web context: /clusterbench
> 14:07:54,704 INFO [org.wildfly.extension.undertow] (MSC service thread 1-8) JBAS017535: Unregistered web context: /clusterbench-granular
> 14:07:54,707 INFO [org.infinispan.eviction.PassivationManagerImpl] (ServerService Thread Pool -- 28) ISPN000029: Passivating all entries to disk
> 14:07:54,709 SEVERE [javax.faces] (MSC service thread 1-8) Unable to obtain InjectionProvider from init time FacesContext. Does this container implement the Mojarra Injection SPI?
> 14:07:54,707 INFO [org.infinispan.eviction.PassivationManagerImpl] (ServerService Thread Pool -- 27) ISPN000029: Passivating all entries to disk
> 14:07:54,709 SEVERE [javax.faces] (MSC service thread 1-8) Unable to call @PreDestroy annotated methods because no InjectionProvider can be found. Does this container implement the Mojarra Injection SPI?
> 14:07:54,709 INFO [org.infinispan.eviction.PassivationManagerImpl] (ServerService Thread Pool -- 27) ISPN000030: Passivated 0 entries in 1 milliseconds
> 14:07:54,709 SEVERE [javax.faces] (MSC service thread 1-8) Unable to obtain InjectionProvider from init time FacesContext. Does this container implement the Mojarra Injection SPI?
> 14:07:54,709 INFO [org.infinispan.eviction.PassivationManagerImpl] (ServerService Thread Pool -- 28) ISPN000030: Passivated 0 entries in 1 milliseconds
> 14:07:54,709 SEVERE [javax.faces] (MSC service thread 1-8) Unable to call @PreDestroy annotated methods because no InjectionProvider can be found. Does this container implement the Mojarra Injection SPI?
> 14:07:54,712 INFO [org.infinispan.eviction.PassivationManagerImpl] (ServerService Thread Pool -- 21) ISPN000029: Passivating all entries to disk
> 14:07:54,713 INFO [org.infinispan.eviction.PassivationManagerImpl] (ServerService Thread Pool -- 21) ISPN000030: Passivated 0 entries in 0 milliseconds
> 14:07:54,721 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 27) JBAS010282: Stopped clusterbench-ee7.ear/clusterbench-ee7-ejb-1.1.0-SNAPSHOT.jar cache from ejb container
> 14:07:54,722 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 28) JBAS010282: Stopped default-host/clusterbench-passivating cache from web container
> 14:07:54,724 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 21) JBAS010282: Stopped default-host/clusterbench-granular cache from web container
> 14:07:54,728 INFO [org.infinispan.eviction.PassivationManagerImpl] (ServerService Thread Pool -- 27) ISPN000029: Passivating all entries to disk
> 14:07:54,728 INFO [org.infinispan.eviction.PassivationManagerImpl] (ServerService Thread Pool -- 27) ISPN000030: Passivated 0 entries in 0 milliseconds
> 14:07:54,737 INFO [org.jboss.weld.deployer] (MSC service thread 1-4) JBAS016009: Stopping weld service for deployment clusterbench-ee7.ear
> 14:07:54,739 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 27) JBAS010282: Stopped default-host/clusterbench cache from web container
> 14:07:54,755 INFO [org.jboss.as.server.deployment] (MSC service thread 1-5) JBAS015974: Stopped subdeployment (runtime-name: clusterbench-ee7-web-1.1.0-SNAPSHOT-passivating.war) in 57ms
> 14:07:54,755 INFO [org.jboss.as.server.deployment] (MSC service thread 1-1) JBAS015974: Stopped subdeployment (runtime-name: clusterbench-ee7-ejb-1.1.0-SNAPSHOT.jar) in 57ms
> 14:07:54,755 INFO [org.jboss.as.server.deployment] (MSC service thread 1-5) JBAS015974: Stopped subdeployment (runtime-name: clusterbench-ee7-web-1.1.0-SNAPSHOT-granular.war) in 58ms
> 14:07:54,758 INFO [org.jboss.as.server.deployment] (MSC service thread 1-6) JBAS015974: Stopped subdeployment (runtime-name: clusterbench-ee7-web-1.1.0-SNAPSHOT-default.war) in 60ms
> 14:07:54,759 INFO [org.jboss.as.server.deployment] (MSC service thread 1-3) JBAS015877: Stopped deployment clusterbench-ee7.ear (runtime-name: clusterbench-ee7.ear) in 61ms
> 14:07:54,852 INFO [org.jboss.as.server] (DeploymentScanner-threads - 2) JBAS018558: Undeployed "clusterbench-ee7.ear" (runtime-name: "clusterbench-ee7.ear")
> 14:07:54,853 INFO [org.jboss.as.controller] (DeploymentScanner-threads - 2) JBAS014774: Service status report
> JBAS014775: New missing/unsatisfied dependencies:
> service jboss.deployment.subunit."clusterbench-ee7.ear"."clusterbench-ee7-ejb-1.1.0-SNAPSHOT.jar".deploymentCompleteService (missing) dependents: [service jboss.deployment.unit."clusterbench-ee7.ear".deploymentCompleteService]
> service jboss.deployment.subunit."clusterbench-ee7.ear"."clusterbench-ee7-web-1.1.0-SNAPSHOT-default.war".deploymentCompleteService (missing) dependents: [service jboss.deployment.unit."clusterbench-ee7.ear".deploymentCompleteService]
> service jboss.deployment.subunit."clusterbench-ee7.ear"."clusterbench-ee7-web-1.1.0-SNAPSHOT-granular.war".deploymentCompleteService (missing) dependents: [service jboss.deployment.unit."clusterbench-ee7.ear".deploymentCompleteService]
> service jboss.deployment.subunit."clusterbench-ee7.ear"."clusterbench-ee7-web-1.1.0-SNAPSHOT-passivating.war".component."com.sun.faces.config.ConfigureListener".START (missing) dependents: [service jboss.deployment.subunit."clusterbench-ee7.ear"."clusterbench-ee7-web-1.1.0-SNAPSHOT-passivating.war".deploymentCompleteService]
> service jboss.deployment.subunit."clusterbench-ee7.ear"."clusterbench-ee7-web-1.1.0-SNAPSHOT-passivating.war".component."javax.faces.webapp.FacesServlet".START (missing) dependents: [service jboss.deployment.subunit."clusterbench-ee7.ear"."clusterbench-ee7-web-1.1.0-SNAPSHOT-passivating.war".deploymentCompleteService]
> service jboss.deployment.subunit."clusterbench-ee7.ear"."clusterbench-ee7-web-1.1.0-SNAPSHOT-passivating.war".component."javax.faces.webapp.FacetTag".START (missing) dependents: [service jboss.deployment.subunit."clusterbench-ee7.ear"."clusterbench-ee7-web-1.1.0-SNAPSHOT-passivating.war".deploymentCompleteService]
> service jboss.deployment.subunit."clusterbench-ee7.ear"."clusterbench-ee7-web-1.1.0-SNAPSHOT-passivating.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".START (missing) dependents: [service jboss.deployment.subunit."clusterbench-ee7.ear"."clusterbench-ee7-web-1.1.0-SNAPSHOT-passivating.war".deploymentCompleteService]
> service jboss.deployment.subunit."clusterbench-ee7.ear"."clusterbench-ee7-web-1.1.0-SNAPSHOT-passivating.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".START (missing) dependents: [service jboss.deployment.subunit."clusterbench-ee7.ear"."clusterbench-ee7-web-1.1.0-SNAPSHOT-passivating.war".deploymentCompleteService]
> service jboss.deployment.subunit."clusterbench-ee7.ear"."clusterbench-ee7-web-1.1.0-SNAPSHOT-passivating.war".component."org.jboss.test.clusterbench.web.session.GranularHttpSessionServlet".START (missing) dependents: [service jboss.deployment.subunit."clusterbench-ee7.ear"."clusterbench-ee7-web-1.1.0-SNAPSHOT-passivating.war".deploymentCompleteService]
> service jboss.deployment.subunit."clusterbench-ee7.ear"."clusterbench-ee7-web-1.1.0-SNAPSHOT-passivating.war".deploymentCompleteService (missing) dependents: [service jboss.deployment.unit."clusterbench-ee7.ear".deploymentCompleteService]
> service jboss.undertow.deployment.default-server.default-host./clusterbench-passivating (missing) dependents: [service jboss.deployment.subunit."clusterbench-ee7.ear"."clusterbench-ee7-web-1.1.0-SNAPSHOT-passivating.war".deploymentCompleteService]
> JBAS014777: Services which failed to start: service jboss.undertow.deployment.default-server.default-host./clusterbench-passivating
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 8 months