December 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-407) JBAS018040: Failed to start context

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-407?page=com.atlassian.jira.plugin... ] Brian Stansberry commented on WFCORE-407: ----------------------------------------- The 'enabled' attribute means the admin wants the server to attempt to install this deployment into the runtime. It doesn't indicate success or failure. A separate attribute would be needed to track the running state of the deployment. > JBAS018040: Failed to start context > ----------------------------------- > > Key: WFCORE-407 > URL: https://issues.jboss.org/browse/WFCORE-407 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Environment: Redhat Linux 4 (??). Kernel version is: 2.6.18-194.26.1.el5 > Reporter: B K > Assignee: Heiko Braun > Labels: jboss > > The error found in the server log files was: > 13:58:40,009 INFO [org.jboss.as.controller] (Controller Boot Thread) JBAS014774: Service status report > JBAS014777: Services which failed to start: service jboss.web.deployment.default-host./apex: org.jboss.msc.service.StartException in service jboss.web.deployment.default-host./apex: JBAS018040: Failed to start context > Occurence details: > 1. The issue occured following a restart of the application server > Analysis details: > 1. From the perspective of the JBOSS 7 admin console ... the admin console shows that the "apex.war" application is deployed and "enabled". I believe it should not display "enabled" as the context has failed to start and it is NOT capable of servicing requests. > Details to reproduce: > 1. Download Oracle Apex Listener 1.1.4 from: > http://www.oracle.com/technetwork/developer-tools/apex-listener/downloads... > 2. Unzip the war file e.g jar xvf apex.war > 3. Modify the web.xml by adding: > <context-param> > <param-name>config.dir</param-name> > <param-value>/opt/jboss/apex_config_dir</param-value> > </context-param> > 4. Create the path "/opt/jboss/apex_config_dir". > 5. Zip the war file. > cd locationContaining the Web-INF directory > jar cvf apex.war * > 6. Deploy war file and enable via admin console. Stop Server. Start server. > 7. Exception occurs. > NOTE: there could be an additional step to reproduce. Will detail if above does not work. > NOTE2: I can redeploy the above application and get it working again by removing some files that are auto generated by apex.war (so a partial bit of this issue is probably application related). -- This message was sent by Atlassian JIRA (v6.3.8#6338)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-407) JBAS018040: Failed to start context

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-407?page=com.atlassian.jira.plugin... ] Brian Stansberry moved WFLY-780 to WFCORE-407: ---------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-407 (was: WFLY-780) Issue Type: Enhancement (was: Bug) Component/s: Domain Management (was: Domain Management) Steps to Reproduce: (was: See description) > JBAS018040: Failed to start context > ----------------------------------- > > Key: WFCORE-407 > URL: https://issues.jboss.org/browse/WFCORE-407 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Environment: Redhat Linux 4 (??). Kernel version is: 2.6.18-194.26.1.el5 > Reporter: B K > Assignee: Heiko Braun > Labels: jboss > > The error found in the server log files was: > 13:58:40,009 INFO [org.jboss.as.controller] (Controller Boot Thread) JBAS014774: Service status report > JBAS014777: Services which failed to start: service jboss.web.deployment.default-host./apex: org.jboss.msc.service.StartException in service jboss.web.deployment.default-host./apex: JBAS018040: Failed to start context > Occurence details: > 1. The issue occured following a restart of the application server > Analysis details: > 1. From the perspective of the JBOSS 7 admin console ... the admin console shows that the "apex.war" application is deployed and "enabled". I believe it should not display "enabled" as the context has failed to start and it is NOT capable of servicing requests. > Details to reproduce: > 1. Download Oracle Apex Listener 1.1.4 from: > http://www.oracle.com/technetwork/developer-tools/apex-listener/downloads... > 2. Unzip the war file e.g jar xvf apex.war > 3. Modify the web.xml by adding: > <context-param> > <param-name>config.dir</param-name> > <param-value>/opt/jboss/apex_config_dir</param-value> > </context-param> > 4. Create the path "/opt/jboss/apex_config_dir". > 5. Zip the war file. > cd locationContaining the Web-INF directory > jar cvf apex.war * > 6. Deploy war file and enable via admin console. Stop Server. Start server. > 7. Exception occurs. > NOTE: there could be an additional step to reproduce. Will detail if above does not work. > NOTE2: I can redeploy the above application and get it working again by removing some files that are auto generated by apex.war (so a partial bit of this issue is probably application related). -- This message was sent by Atlassian JIRA (v6.3.8#6338)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-553) Allow for alternative access control providers to be plugged into management.

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-553?page=com.atlassian.jira.plugin.s... ] Brian Stansberry commented on WFLY-553: --------------------------------------- I believe this is a duplicate of WFCORE-386. If so, please resolve. If not, please move to WFCORE. Thanks. > Allow for alternative access control providers to be plugged into management. > ----------------------------------------------------------------------------- > > Key: WFLY-553 > URL: https://issues.jboss.org/browse/WFLY-553 > Project: WildFly > Issue Type: Feature Request > Components: Domain Management, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Labels: Authorization, Realm_Management > Fix For: 9.0.0.Beta1 > > -- This message was sent by Atlassian JIRA (v6.3.8#6338)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-406) Resource description for platform mbean properties that throw UnsupportedOperationException should say nillable="true"

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-406?page=com.atlassian.jira.plugin... ] Brian Stansberry moved WFLY-53 to WFCORE-406: --------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-406 (was: WFLY-53) Component/s: Domain Management (was: Domain Management) Fix Version/s: 1.0.0.CR1 (was: 9.0.0.Beta1) > Resource description for platform mbean properties that throw UnsupportedOperationException should say nillable="true" > ---------------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-406 > URL: https://issues.jboss.org/browse/WFCORE-406 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Environment: FreeBSD, OpenJDK 1.6 > Reporter: Brian Stansberry > Priority: Minor > Fix For: 1.0.0.CR1 > > > Some platform mbean getters are documented to throw a UOE on some VMs. The read-resource handler will catch the UOE and leave the attribute undefined, but the description says it's not nillable. > Specifically, PlatformMBeanDescriptions.getThreadingResource()'s THREAD_CPU_TIME_ENABLED attribute, although there may well be others. > This leads to this unit test failure on jvms where the UOE is thrown: > failure message="thread-cpu-time-enabled is undefined" > type="junit.framework.AssertionFailedError">junit.fra mework.AssertionFailedError: thread-cpu-time-enabled is undefined > at junit.framework.Assert.fail(Assert.java:50) > at junit.framework.Assert.assertTrue(Assert.java:20) > at > org.jboss.as.platform.mbean.PlatformMBeanResourceUnitTestCase.validateResource(PlatformMBeanResourceUn > itTestCase.java:595) > at org.jboss.as.platform.mbean.PlatformMBeanResourceUnitTestCase.basicResourceTest(PlatformMBeanResourceUnitTestCase.java:563) > at > org.jboss.as.platform.mbean.PlatformMBeanResourceUnitTestCase.testThreadingMXBean(PlatformMBeanResourceUnitTestCase.java:340) -- This message was sent by Atlassian JIRA (v6.3.8#6338)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-405) Filesystem deployment scanner for a managed domain

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-405?page=com.atlassian.jira.plugin... ] Brian Stansberry moved WFLY-1017 to WFCORE-405: ----------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-405 (was: WFLY-1017) Component/s: Domain Management (was: Domain Management) > Filesystem deployment scanner for a managed domain > -------------------------------------------------- > > Key: WFCORE-405 > URL: https://issues.jboss.org/browse/WFCORE-405 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Environment: Ubuntu 12.04 Os , JBOSS As 7.1.0 final > Reporter: hitesh yadav > Original Estimate: 1 day, 4 hours > Remaining Estimate: 1 day, 4 hours > > Is there any folder or path at which if any .war is put, in such a way that when JBOSS AS 7.1.0 start in domain mode the .war file deploy in Master node and it's related slave Node. > For Example......... In standalone mode if we put .war file in /jboss-as-7.1.0.Final/standalone/deployments/ folder and start the JBOSS AS 7.1.0 in standalone mode ,the .war deploy properly.......i want same thing domain mode, in other-server-group ..... > Means the requirement is that the .war file should put in one folder and when JBOSS AS 7.1.0 start in domain mode the .war file should deploy in other-server-group ............. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-403) Evaluate making operation "composite" EntryType.PUBLIC

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-403?page=com.atlassian.jira.plugin... ] Brian Stansberry moved WFLY-1315 to WFCORE-403: ----------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-403 (was: WFLY-1315) Component/s: Domain Management (was: Domain Management) Fix Version/s: 1.0.0.Beta1 (was: 9.0.0.Beta1) > Evaluate making operation "composite" EntryType.PUBLIC > ------------------------------------------------------ > > Key: WFCORE-403 > URL: https://issues.jboss.org/browse/WFCORE-403 > Project: WildFly Core > Issue Type: Task > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Fix For: 1.0.0.Beta1 > > > When the composite operation handler is registered, it's marked as EntryType.PRIVATE. This operation really isn't private; any reasonable management client will need to invoke it. > Changing it may have some implications though; we need to evaluate those. The biggest is the operation metadata cannot be complete, because the step parameter elements cannot be fully described. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-398) Avoid running out of threads when connecting to the DC from a slave to pull down missing data

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-398?page=com.atlassian.jira.plugin... ] Brian Stansberry moved WFLY-315 to WFCORE-398: ---------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-398 (was: WFLY-315) Component/s: Domain Management (was: Domain Management) Fix Version/s: 1.0.0.Beta1 (was: 9.0.0.Beta1) > Avoid running out of threads when connecting to the DC from a slave to pull down missing data > --------------------------------------------------------------------------------------------- > > Key: WFCORE-398 > URL: https://issues.jboss.org/browse/WFCORE-398 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Kabir Khan > Assignee: Emanuel Muckenhuber > Priority: Blocker > Fix For: 1.0.0.Beta1 > > > For WFLY-259 when a slave connects to the DC to pull down missing data, it does this by either getting a lock for the DC, or by joining the permit of the existing DC lock if the request to update a slave's server-config was executed as part of a composite obtaining a lock on the DC. > The way it works at present there is a thread per slave which is blocked until the transaction completes. The DC threads are a finite resource, so a large number of slaves trying to pull down dats will cause deadlock -- This message was sent by Atlassian JIRA (v6.3.8#6338)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-399) Domain Management - Support for database connection pool in non AS process.

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-399?page=com.atlassian.jira.plugin... ] Brian Stansberry moved WFLY-434 to WFCORE-399: ---------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-399 (was: WFLY-434) Component/s: Domain Management (was: Domain Management) Fix Version/s: 1.0.0.Beta1 (was: 9.0.0.Beta1) > Domain Management - Support for database connection pool in non AS process. > --------------------------------------------------------------------------- > > Key: WFCORE-399 > URL: https://issues.jboss.org/browse/WFCORE-399 > Project: WildFly Core > Issue Type: Task > Components: Domain Management > Reporter: Darran Lofthouse > Assignee: Brian Stansberry > Fix For: 1.0.0.Beta1 > > > We need to support authentication for users stored in database, the domain management is in a non-AS process so we also need a pool of database connections. > These connections will be used to read only from the database, other than the isolation offered by the driver we should not require any advanced transaction support. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-400) Remove <any-ipv4-address/> and <any-ipv6-address>

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-400?page=com.atlassian.jira.plugin... ] Brian Stansberry moved WFLY-571 to WFCORE-400: ---------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-400 (was: WFLY-571) Component/s: Domain Management (was: Domain Management) Fix Version/s: 1.0.0.Beta1 (was: 9.0.0.Beta1) > Remove <any-ipv4-address/> and <any-ipv6-address> > ------------------------------------------------- > > Key: WFCORE-400 > URL: https://issues.jboss.org/browse/WFCORE-400 > Project: WildFly Core > Issue Type: Task > Components: Domain Management > Reporter: Brian Stansberry > Fix For: 1.0.0.Beta1 > > > These options have no reliable semantic (see, for example, WFLY-533) and should be removed. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-401) Consider using a "describe" notion for providing the model to slaves on registration

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-401?page=com.atlassian.jira.plugin... ] Brian Stansberry moved WFLY-568 to WFCORE-401: ---------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-401 (was: WFLY-568) Component/s: Domain Management (was: Domain Management) Fix Version/s: 1.0.0.Beta1 (was: 9.0.0.Beta1) > Consider using a "describe" notion for providing the model to slaves on registration > ------------------------------------------------------------------------------------ > > Key: WFCORE-401 > URL: https://issues.jboss.org/browse/WFCORE-401 > Project: WildFly Core > Issue Type: Task > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Emanuel Muckenhuber > Fix For: 1.0.0.Beta1 > > > When a slave HC registers, the master provides it a copy of the domain-wide model as a DMR tree. This has a weakness in that the Resource impl types that comprise that tree on the master side are not transmitted. If custom Resource impls are used, they may not be recreated on the slave. > Consider instead sending a list of mgmt ops, a la what we do with servers when starting from an HC. > This could potentially be limited to subsystems, with the core model sent as it is now. The core model is handled by core-AS code on the slave side, so we can reasonably ensure that code always uses the correct Resource type. There are places where we already do that. The bigger problem is subsystems. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

10 years, 1 month

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira December 2014