April 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-391) Add management API descriptions for alias resources and attributes

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFCORE-391?page=com.atlassian.jira.plugin... ] Stuart Douglas updated WFCORE-391: ---------------------------------- Fix Version/s: 1.0.0.CR1 (was: 1.0.0.Beta1) > Add management API descriptions for alias resources and attributes > ------------------------------------------------------------------ > > Key: WFCORE-391 > URL: https://issues.jboss.org/browse/WFCORE-391 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Brian Stansberry > Fix For: 1.0.0.CR1 > > > When a resource or an attribute is an alias for a different resource or attribute, the management API description data should include information describing that relationship. > For an attribute, an alias relationship is different from an 'alternatives' relationship, as the latter is a mutually exclusive arrangement (one alternative must be undefined if the other isn't) while with an alias, both attributes will exist but will always have the same value, and attempting to set them to different values (e.g. using both as params with different values in an 'add' op) is invalid. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-393) Clone a profile

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFCORE-393?page=com.atlassian.jira.plugin... ] Stuart Douglas updated WFCORE-393: ---------------------------------- Fix Version/s: 1.0.0.CR1 (was: 1.0.0.Beta1) > 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 > 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.11#6341)

10 years, 9 months

1
0
0 / 0

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

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFCORE-401?page=com.atlassian.jira.plugin... ] Stuart Douglas updated WFCORE-401: ---------------------------------- Fix Version/s: 1.0.0.CR1 (was: 1.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: 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.11#6341)

10 years, 9 months

1
0
0 / 0

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

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFCORE-399?page=com.atlassian.jira.plugin... ] Stuart Douglas updated WFCORE-399: ---------------------------------- Fix Version/s: 1.0.0.CR1 (was: 1.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.CR1 > > > 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.11#6341)

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-396) Look into whether READ_ONLY but not RUNTIME_ONLY domain server ops should be visible to users

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFCORE-396?page=com.atlassian.jira.plugin... ] Stuart Douglas updated WFCORE-396: ---------------------------------- Fix Version/s: 1.0.0.CR1 (was: 1.0.0.Beta1) > 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 > 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.11#6341)

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-395) Improve reporting during deployment hang

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFCORE-395?page=com.atlassian.jira.plugin... ] Stuart Douglas updated WFCORE-395: ---------------------------------- Fix Version/s: 1.0.0.CR1 (was: 1.0.0.Beta1) > Improve reporting during deployment hang > ---------------------------------------- > > Key: WFCORE-395 > URL: https://issues.jboss.org/browse/WFCORE-395 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Environment: http://java.net/jira/browse/EJB_SPEC-60 > java version "1.7.0_09" > OpenJDK Runtime Environment (IcedTea7 2.3.3) (7u9-2.3.3-0ubuntu1~12.10.1) > OpenJDK 64-Bit Server VM (build 23.2-b09, mixed mode) > Ubuntu 12.10 > Reporter: Carlo de Wolf > Assignee: Brian Stansberry > Fix For: 1.0.0.CR1 > > Attachments: deployment-hang-20130205.txt, server.log > > > Management Thread waits indefinitely for, what seems to be, a finished operation. > {noformat} > "management-handler-thread - 2" prio=10 tid=0x00007fa1380d0000 nid=0x7683 in Object.wait() [0x00007fa136deb000] > java.lang.Thread.State: WAITING (on object monitor) > at java.lang.Object.wait(Native Method) > - waiting on <0x00000000e04ae778> (a org.jboss.as.controller.ContainerStateMonitor) > at java.lang.Object.wait(Object.java:503) > at org.jboss.as.controller.ContainerStateMonitor.awaitContainerStateChangeReport(ContainerStateMonitor.java:158) > - locked <0x00000000e04ae778> (a org.jboss.as.controller.ContainerStateMonitor) > at org.jboss.as.controller.ModelControllerImpl.awaitContainerStateChangeReport(ModelControllerImpl.java:464) > at org.jboss.as.controller.OperationContextImpl.awaitModelControllerContainerMonitor(OperationContextImpl.java:148) > at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:299) > at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:229) > at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:224) > at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:142) > at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:112) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:139) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:108) > at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:296) > at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:518) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) > at java.lang.Thread.run(Thread.java:722) > at org.jboss.threads.JBossThread.run(JBossThread.java:122) > {noformat} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-431) CLI should WARN about usage deprecated api

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFCORE-431?page=com.atlassian.jira.plugin... ] Stuart Douglas updated WFCORE-431: ---------------------------------- Fix Version/s: 1.0.0.CR1 (was: 1.0.0.Beta1) > 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.11#6341)

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-429) Incremental redeployment (single file update) over management API

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFCORE-429?page=com.atlassian.jira.plugin... ] Stuart Douglas updated WFCORE-429: ---------------------------------- Fix Version/s: 1.0.0.CR1 (was: 1.0.0.Beta1) > Incremental redeployment (single file update) over management API > ----------------------------------------------------------------- > > Key: WFCORE-429 > URL: https://issues.jboss.org/browse/WFCORE-429 > Project: WildFly Core > Issue Type: Feature Request > Components: CLI, Domain Management > Reporter: Ondrej Zizka > Labels: deploy, deployment, incremental, redeployment > Fix For: 1.0.0.CR1 > > > (Based on JBDS use case - see EAP6-1) > See also https://mojo.redhat.com/docs/DOC-934058 for notes > By incremental redeployment, we mean the situation when something is deployed, and after changes (in IDE e.g.), only that single file (.jsp, .xml, .class) would be re-deployed to the server, *over management API* - which is, you'd give it a stream and a path where it belongs in the deployment, and the operation would accept that file and put it to the right place in VFS, clear caches etc. > Use cases: > Big .war's, mainly on remote > Cloud deployments > Also, you loose sessions etc. > "JSP recompile on file update" - mgmt API operation - added in WildFly 8? > Not expected to work in domain mode. > Stuart said that session persistence is implemented in WFly 8, but not the incremental redeployment. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-424) .jar's on "current runtime classpath"

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFCORE-424?page=com.atlassian.jira.plugin... ] Stuart Douglas updated WFCORE-424: ---------------------------------- Fix Version/s: 1.0.0.CR1 (was: 1.0.0.Beta1) > .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: CLI, 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.11#6341)

10 years, 9 months

1
0
0 / 0

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

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFCORE-403?page=com.atlassian.jira.plugin... ] Stuart Douglas updated WFCORE-403: ---------------------------------- Fix Version/s: 1.0.0.CR1 (was: 1.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.CR1 > > > 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.11#6341)

10 years, 9 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira April 2015