[JBoss JIRA] (WFCORE-392) Stack trace improvements, summarize the things that broke to make them not so intimidating
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFCORE-392?page=com.atlassian.jira.plugin... ]
Kabir Khan updated WFCORE-392:
------------------------------
Fix Version/s: 1.0.0.CR1
(was: 1.0.0.Beta6)
> Stack trace improvements, summarize the things that broke to make them not so intimidating
> ------------------------------------------------------------------------------------------
>
> Key: WFCORE-392
> URL: https://issues.jboss.org/browse/WFCORE-392
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Jim Tyrrell
> Assignee: Brian Stansberry
> Priority: Critical
> Labels: eap6-ux
> Fix For: 1.0.0.CR1
>
> Attachments: log.txt
>
>
> See the typical attached stack dump:
> It would be nice if the stack dump could include all of the information above as a summary as shown below, basically just the first lines of the errors w/o the whole stack dump:
> 11:51:45,391 INFO [org.jboss.as.server.controller] (HttpManagementService-threads - 5) Deployment of "SpringWAR.war" was rolled back with failure message {"Failed services" => {"jboss.web.deployment.default-host./SpringWAR" => "org.jboss.msc.service.StartException in service jboss.web.deployment.default-host./SpringWAR: failed to start context"}}
> 11:51:45,392 INFO [org.jboss.as.controller] (HttpManagementService-threads - 5) Service status report
> Services which failed to start:
> service jboss.web.deployment.default-host./SpringWAR: org.jboss.msc.service.StartException in service jboss.web.deployment.default-host./SpringWAR: failed to start context
> 11:51:45,417 INFO [org.jboss.as.server.deployment] (MSC service thread 1-2) Stopped deployment SpringWAR.war in 26ms
> 11:51:45,417 Error Summary of Exceptions in deployment:
> - [org.springframework.web.context.ContextLoader] (MSC service thread 1-5) Context initialization failed: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'jbossQueue' defined in class path resource [applicationContextServices.xml]: Invocation of init method failed; nested exception is javax.naming.NameNotFoundException: queue/B -- service jboss.naming.context.java.queue.B
> - [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/SpringWAR]] (MSC service thread 1-5) Exception sending context initialized event to listener instance of class org.springframework.web.context.ContextLoaderListener: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'jbossQueue' defined in class path resource [applicationContextServices.xml]: Invocation of init method failed; nested exception is javax.naming.NameNotFoundException: queue/B -- service jboss.naming.context.java.queue.B
> - [org.apache.catalina.core.StandardContext] (MSC service thread 1-5) Error listenerStart
> - ERROR [org.apache.catalina.core.StandardContext] (MSC service thread 1-5) Context [/SpringWAR] startup failed due to previous errors
> - [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/SpringWAR]] (MSC service thread 1-5) Closing Spring root WebApplicationContext
> - [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC00001: Failed to start service jboss.web.deployment.default-host./SpringWAR:
> ERROR Scroll up to see more info...
> Or
> 11:51:45,417 Error Summary of Exceptions in deployment:
> [1] [org.springframework.web.context.ContextLoader] (MSC service thread 1-5) Context initialization failed: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'jbossQueue' defined in class path resource [applicationContextServices.xml]: Invocation of init method failed; nested exception is javax.naming.NameNotFoundException: queue/B -- service jboss.naming.context.java.queue.B
> [2] [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/SpringWAR]] (MSC service thread 1-5) Exception sending context initialized event to listener instance of class org.springframework.web.context.ContextLoaderListener: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'jbossQueue' defined in class path resource [applicationContextServices.xml]: Invocation of init method failed; nested exception is javax.naming.NameNotFoundException: queue/B -- service jboss.naming.context.java.queue.B
> [3] [org.apache.catalina.core.StandardContext] (MSC service thread 1-5) Error listenerStart
> [4] ERROR [org.apache.catalina.core.StandardContext] (MSC service thread 1-5) Context [/SpringWAR] startup failed due to previous errors
> [5] [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/SpringWAR]] (MSC service thread 1-5) Closing Spring root WebApplicationContext
> [6] [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC00001: Failed to start service jboss.web.deployment.default-host./SpringWAR:
> ERROR Scroll up to see more info...
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
11 years, 2 months
[JBoss JIRA] (WFCORE-390) Add reference description information to resource metadata
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFCORE-390?page=com.atlassian.jira.plugin... ]
Kabir Khan updated WFCORE-390:
------------------------------
Fix Version/s: 1.0.0.CR1
(was: 1.0.0.Beta6)
> Add reference description information to resource metadata
> ----------------------------------------------------------
>
> Key: WFCORE-390
> URL: https://issues.jboss.org/browse/WFCORE-390
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Brian Stansberry
> Fix For: 1.0.0.CR1
>
>
> The AS's configuration model frequently includes attributes that are references to the name of some other resource in the model. The metadata describing such attributes must include information to help users and tooling to understand that reference.
> A simple approach would be to include a metadata attribute whose value is an absolute or relative path to the target resource.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
11 years, 2 months
[JBoss JIRA] (WFCORE-393) Clone a profile
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFCORE-393?page=com.atlassian.jira.plugin... ]
Kabir Khan updated WFCORE-393:
------------------------------
Fix Version/s: 1.0.0.CR1
(was: 1.0.0.Beta6)
> Clone a profile
> ---------------
>
> Key: WFCORE-393
> URL: https://issues.jboss.org/browse/WFCORE-393
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Kabir Khan
> Fix For: 1.0.0.CR1
>
>
> Add the ability to clone a profile.
> This could be a new "clone" operation on the existing profile resource, or perhaps a "clone-from" parameter on the existing "add" operation. Probably the former, as that will be more transformation-friendly.
> Implementation will likely involve using the "describe" operation used for configuring managed domain servers and adding steps from the describe results directly on the HC instead of passing them to a server.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
11 years, 2 months
[JBoss JIRA] (WFCORE-401) Consider using a "describe" notion for providing the model to slaves on registration
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFCORE-401?page=com.atlassian.jira.plugin... ]
Kabir Khan updated WFCORE-401:
------------------------------
Fix Version/s: 1.0.0.CR1
(was: 1.0.0.Beta6)
> 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: Kabir Khan
> Fix For: 1.0.0.CR1
>
>
> 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.15#6346)
11 years, 2 months
[JBoss JIRA] (WFCORE-396) Look into whether READ_ONLY but not RUNTIME_ONLY domain server ops should be visible to users
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFCORE-396?page=com.atlassian.jira.plugin... ]
Kabir Khan updated WFCORE-396:
------------------------------
Fix Version/s: 1.0.0.CR1
(was: 1.0.0.Beta6)
> Look into whether READ_ONLY but not RUNTIME_ONLY domain server ops should be visible to users
> ---------------------------------------------------------------------------------------------
>
> Key: WFCORE-396
> URL: https://issues.jboss.org/browse/WFCORE-396
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: luck3y
> Fix For: 1.0.0.CR1
>
>
> Ops registered on a domain server without the RUNTIME_ONLY flag are hidden from users (e.g. in read-operation-names results etc) in order to not delude users into thinking they can do something like :write-attribute directly on a server (instead of modifying host or domain config elements.)
> But shouldn't a READ_ONLY flag be sufficient as well? An op that only reads config should be valid.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
11 years, 2 months
[JBoss JIRA] (WFCORE-424) .jar's on "current runtime classpath"
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFCORE-424?page=com.atlassian.jira.plugin... ]
Kabir Khan updated WFCORE-424:
------------------------------
Fix Version/s: 1.0.0.CR1
(was: 1.0.0.Beta6)
> .jar's on "current runtime classpath"
> -------------------------------------
>
> Key: WFCORE-424
> URL: https://issues.jboss.org/browse/WFCORE-424
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Modules
> Reporter: Ondrej Zizka
> Assignee: David Lloyd
> Fix For: 1.0.0.CR1
>
>
> (Based on JBDS use case - see EAP6-1)
> In certain scenarios, JBDS needs to know the classpath. (Compilation of non-maven project, against a remote server, ...(?) )
> The classpath would be:
> * for the deployment after deployed
> * for a generic deployment if it was deployed right now - what would WildFly use?
> * for the deployment before deployed - sounds a bit advanced but technically possible
> We (David, Stuart, Jason, Max, Ondra) have discussed this on EAP F2F 2014.
> The output was that we don't need exact classpath / list of jars which would probably end up being almost all modules; rather we need the direct deps. As someone said - "just to get rid of the red lines in the IDE".
> The non-maven compilation use case is that the user has a server in a directory, and the jars to build against should all be in there. So the IDE should be able to ask WildFly for a list of .jar's to build the application against, and just use that instead of forcing the user to gather them manually.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
11 years, 2 months
[JBoss JIRA] (WFCORE-431) CLI should WARN about usage deprecated api
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFCORE-431?page=com.atlassian.jira.plugin... ]
Kabir Khan updated WFCORE-431:
------------------------------
Fix Version/s: 1.0.0.CR1
(was: 1.0.0.Beta6)
> CLI should WARN about usage deprecated api
> ------------------------------------------
>
> Key: WFCORE-431
> URL: https://issues.jboss.org/browse/WFCORE-431
> Project: WildFly Core
> Issue Type: Feature Request
> Components: CLI
> Reporter: Tomaz Cerar
> Assignee: Alexey Loubyansky
> Fix For: 1.0.0.CR1
>
>
> We added support for deprecating resources/attributes/operations/parameters some time ago.
> I would be a good thing that we would warn users if they are using deprecated API.
> Every resource/attribute/operation/param that is deprecated has extra element "deprecated" in metadata
> With sub elements
> - "since", which tells in what version it was deprecated
> - "reason", text description why it is deprecated.
> Reason in most cases also tells what is new replacement.
> This should be only displayed in case of interactive shell usage.
> Unless there is also some special CLI log file, it could be part of that even for non-interactive usage
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
11 years, 2 months
[JBoss JIRA] (WFCORE-442) AbstractMultiTargetHandler-based handlers do not propagate failures to the top level failure-description
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFCORE-442?page=com.atlassian.jira.plugin... ]
Kabir Khan updated WFCORE-442:
------------------------------
Fix Version/s: 1.0.0.CR1
(was: 1.0.0.Beta6)
> AbstractMultiTargetHandler-based handlers do not propagate failures to the top level failure-description
> --------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-442
> URL: https://issues.jboss.org/browse/WFCORE-442
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 1.0.0.Alpha13
> Reporter: Brian Stansberry
> Assignee: Heiko Braun
> Fix For: 1.0.0.CR1
>
>
> An example is worth a thousand words:
> {code}
> [standalone@localhost:9990 /] /path=*:query(where={read-only=1})
> {
> "outcome" => "failed",
> "result" => [
> {
> "address" => [("path" => "jboss.server.temp.dir")],
> "outcome" => "failed",
> "result" => {
> "name" => "jboss.server.temp.dir",
> "path" => "/Users/hbraun/dev/prj/wildfly-core/core-build/target/wildfly-core-1.0.0.Alpha14-SNAPSHOT/standalone/tmp",
> "read-only" => true,
> "relative-to" => undefined
> },
> "rolled-back" => true
> },
> {
> "address" => [("path" => "user.home")],
> "outcome" => "failed",
> "result" => {
> "name" => "user.home",
> "path" => "/Users/hbraun",
> "read-only" => true,
> "relative-to" => undefined
> },
> "rolled-back" => true
> },
> {
> "address" => [("path" => "jboss.server.base.dir")],
> "outcome" => "failed",
> "result" => {
> "name" => "jboss.server.base.dir",
> "path" => "/Users/hbraun/dev/prj/wildfly-core/core-build/target/wildfly-core-1.0.0.Alpha14-SNAPSHOT/standalone",
> "read-only" => true,
> "relative-to" => undefined
> },
> "rolled-back" => true
> },
> {
> "address" => [("path" => "java.home")],
> "outcome" => "failed",
> "result" => {
> "name" => "java.home",
> "path" => "/Library/Java/JavaVirtualMachines/jdk1.7.0_67.jdk/Contents/Home/jre",
> "read-only" => true,
> "relative-to" => undefined
> },
> "rolled-back" => true
> },
> {
> "address" => [("path" => "user.dir")],
> "outcome" => "failed",
> "result" => {
> "name" => "user.dir",
> "path" => "/Users/hbraun/dev/prj/wildfly-core/core-build/target/wildfly-core-1.0.0.Alpha14-SNAPSHOT",
> "read-only" => true,
> "relative-to" => undefined
> },
> "rolled-back" => true
> },
> {
> "address" => [("path" => "jboss.server.data.dir")],
> "outcome" => "failed",
> "result" => {
> "name" => "jboss.server.data.dir",
> "path" => "/Users/hbraun/dev/prj/wildfly-core/core-build/target/wildfly-core-1.0.0.Alpha14-SNAPSHOT/standalone/data",
> "read-only" => true,
> "relative-to" => undefined
> },
> "rolled-back" => true
> },
> {
> "address" => [("path" => "jboss.home.dir")],
> "outcome" => "failed",
> "result" => {
> "name" => "jboss.home.dir",
> "path" => "/Users/hbraun/dev/prj/wildfly-core/core-build/target/wildfly-core-1.0.0.Alpha14-SNAPSHOT",
> "read-only" => true,
> "relative-to" => undefined
> },
> "rolled-back" => true
> },
> {
> "address" => [("path" => "jboss.server.log.dir")],
> "outcome" => "failed",
> "result" => {
> "name" => "jboss.server.log.dir",
> "path" => "/Users/hbraun/dev/prj/wildfly-core/core-build/target/wildfly-core-1.0.0.Alpha14-SNAPSHOT/standalone/log",
> "read-only" => true,
> "relative-to" => undefined
> },
> "rolled-back" => true
> },
> {
> "address" => [("path" => "jboss.server.config.dir")],
> "outcome" => "failed",
> "result" => {
> "name" => "jboss.server.config.dir",
> "path" => "/Users/hbraun/dev/prj/wildfly-core/core-build/target/wildfly-core-1.0.0.Alpha14-SNAPSHOT/standalone/configuration",
> "read-only" => true,
> "relative-to" => undefined
> },
> "rolled-back" => true
> },
> {
> "address" => [("path" => "jboss.controller.temp.dir")],
> "outcome" => "failed",
> "result" => {
> "name" => "jboss.controller.temp.dir",
> "path" => "/Users/hbraun/dev/prj/wildfly-core/core-build/target/wildfly-core-1.0.0.Alpha14-SNAPSHOT/standalone/tmp",
> "read-only" => true,
> "relative-to" => undefined
> },
> "failure-description" => "Illegal argument for attribute 'read-only'. Expected type BOOLEAN",
> "rolled-back" => true
> }
> ],
> "rolled-back" => true
> }
> {code}
> One item in the set has a failure description but the overall response does not.
> ReadResourceDescriptionHandler handles similar things but has logic for creating an overall failure-description.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
11 years, 2 months