April 2015 - jboss-jira - Jboss List Archives

[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)

9 years, 3 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)

9 years, 3 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)

9 years, 3 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)

9 years, 3 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)

9 years, 3 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)

9 years, 3 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)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-471) pre/post cli-scripts for AS patching feature

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFCORE-471?page=com.atlassian.jira.plugin... ] Stuart Douglas updated WFCORE-471: ---------------------------------- Fix Version/s: 1.0.0.CR1 (was: 1.0.0.Beta1) > pre/post cli-scripts for AS patching feature > -------------------------------------------- > > Key: WFCORE-471 > URL: https://issues.jboss.org/browse/WFCORE-471 > Project: WildFly Core > Issue Type: Feature Request > Components: Patching , Scripts > Reporter: Nicklas Karlsson > Assignee: Alexey Loubyansky > Fix For: 1.0.0.CR1 > > > It would be handy to be able to attach pre/post CLI scripts to be applied for an AS patch. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-470) support patching through the http mgmt API

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFCORE-470?page=com.atlassian.jira.plugin... ] Stuart Douglas updated WFCORE-470: ---------------------------------- Fix Version/s: 1.0.0.CR1 (was: 1.0.0.Beta1) > support patching through the http mgmt API > ------------------------------------------ > > Key: WFCORE-470 > URL: https://issues.jboss.org/browse/WFCORE-470 > Project: WildFly Core > Issue Type: Feature Request > Components: Patching > Affects Versions: 1.0.0.Alpha1 > Reporter: Emanuel Muckenhuber > Fix For: 1.0.0.CR1 > > > The patch operation requires an input stream attachment of the patch content, which is not generally supported for all operations of the http API. We probably need to do something similar to the deployment add-content handler. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-459) Account for attribute groups in CLI behavior

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFCORE-459?page=com.atlassian.jira.plugin... ] Stuart Douglas updated WFCORE-459: ---------------------------------- Fix Version/s: 1.0.0.CR1 (was: 1.0.0.Beta1) > Account for attribute groups in CLI behavior > -------------------------------------------- > > Key: WFCORE-459 > URL: https://issues.jboss.org/browse/WFCORE-459 > Project: WildFly Core > Issue Type: Feature Request > Components: CLI > Reporter: Brian Stansberry > Assignee: Alexey Loubyansky > Fix For: 1.0.0.CR1 > > > See http://lists.jboss.org/pipermail/wildfly-dev/2014-December/003414.html > This JIRA is for reflecting the attribute group notion in CLI behavior. > I think this is just reflecting it in the output of the "ls -l" command, although there may be other places I'm not thinking of. For "ls -l" simplest is just to add a GROUP column to the right, and then sort the attributes by group and then by name, but perhaps something else is better. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 3 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira April 2015