April 2015 - jboss-jira - Jboss List Archives

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

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-399?page=com.atlassian.jira.plugin... ] Darran Lofthouse edited comment on WFCORE-399 at 4/7/15 11:11 AM: ------------------------------------------------------------------ I would suggest closing either as deferred or out of date - I think really Kabir's subsystems in the HC work makes this obsolete. If we still have an issue then that is potentially a new issue anyway as this issue was raised on the basis there are absolutely no subsystems in the HC. was (Author: dlofthouse): I would suggest closing either as differed or out of date - I think really Kabir's subsystems in the HC work makes this obsolete. If we still have an issue then that is potentially a new issue anyway as this issue was raised on the basis there are absolutely no subsystems in the HC. > 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: 2.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.11#6341)

11 years, 3 months

1
0
0 / 0

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

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFCORE-429?page=com.atlassian.jira.plugin... ] Jason Greene commented on WFCORE-429: ------------------------------------- We should definitely sort out the requirements. We have 3 types of deployments: 1) Exploded - picked up by the file scanner (which hot redeploys), development only, and standalone mode only 2) Managed - deployed to standalone and domain mode, and stored in the content repository, indexed by the SHA of the deployment content 3) External - A reference in the configuration to an external file system location. This doesn't use the scanner, and it doesn't involve the content repository. It's usable in standalone and domain mode, and in both cases its the user's responsibility to copy the files over to all of the servers that reference it from the configuration. One key requirement in EAP7-204, is that changes *must* survive a restart. > 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 > > (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)

11 years, 3 months

1
0
0 / 0

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

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-399?page=com.atlassian.jira.plugin... ] Darran Lofthouse commented on WFCORE-399: ----------------------------------------- I would suggest closing either as differed or out of date - I think really Kabir's subsystems in the HC work makes this obsolete. If we still have an issue then that is potentially a new issue anyway as this issue was raised on the basis there are absolutely no subsystems in the HC. > 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: 2.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.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-365) inconsistent usage of min/max-occurs in model description

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-365?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFCORE-365: ------------------------------------ Fix Version/s: 2.0.0.Beta1 (was: 1.0.0.CR1) > inconsistent usage of min/max-occurs in model description > --------------------------------------------------------- > > Key: WFCORE-365 > URL: https://issues.jboss.org/browse/WFCORE-365 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Emanuel Muckenhuber > Assignee: Enrique González Martínez > Fix For: 2.0.0.Beta1 > > Attachments: patch.txt > > > The usages of min/max-occurs in the model description are not consistent - e.g. missing in ResourceDescription, mostly wrong when used in the descriptionProvider or outdated examples in the documentation. > I'll attach a simple patch which should actually fix that issue in line with the documentation [1] (incl. recursive usage) and the usage of the CLI (ls -l). However there might be more to it. > [1] https://docs.jboss.org/author/display/AS71/Description+of+the+Management+... -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-377) The management API should provide a command to restart only all servers that are in state 'reload-required'

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-377?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFCORE-377: ------------------------------------ Fix Version/s: 2.0.0.Beta1 (was: 1.0.0.CR1) > The management API should provide a command to restart only all servers that are in state 'reload-required' > ----------------------------------------------------------------------------------------------------------- > > Key: WFCORE-377 > URL: https://issues.jboss.org/browse/WFCORE-377 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Wolf-Dieter Fink > Labels: cli, domain, management > Fix For: 2.0.0.Beta1 > > > After configuration changes via CLI batch it might be that different processes needs to be restarted. > It is possible to iterate over all servers and check it. > But I think it would be easier to have a command that restart all controllers and servers conditional to the 'relod required' state > - at domain level > - at host level > - at server level > command example : > :restart(ifRequired=true) > :reload(ifRequired=true) -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-389) Alllow non persistent configuration(runtime) changes for server groups and domain using CLI

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-389?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFCORE-389: ------------------------------------ Fix Version/s: 2.0.0.Beta1 (was: 1.0.0.CR1) > Alllow non persistent configuration(runtime) changes for server groups and domain using CLI > ------------------------------------------------------------------------------------------- > > Key: WFCORE-389 > URL: https://issues.jboss.org/browse/WFCORE-389 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Shay Matasaro > Assignee: Brian Stansberry > Labels: EAP > Fix For: 2.0.0.Beta1 > > > Using the CLI , It is currently not possible to make runtime config changes to multiple servers , unless you are using a roll-out plan > One example is the ability to disable a mod-cluster context on multiple servers at once. > Since this operation does not affect the persistent server config it is currently not supported. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-388) Overall 'server-state' flag on the Host Controller

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-388?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFCORE-388: ------------------------------------ Fix Version/s: 2.0.0.Beta1 (was: 1.0.0.CR1) > Overall 'server-state' flag on the Host Controller > -------------------------------------------------- > > Key: WFCORE-388 > URL: https://issues.jboss.org/browse/WFCORE-388 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Brian Stansberry > Fix For: 2.0.0.Beta1 > > > This is for consideration; we need to see if it makes sense. > Request is for an attribute on the HC that indicates aggregate 'server-state'. The desire is to know when all servers are available, and thus it is safe to invoke management ops knowing all servers will receive them. > The only reason a server wouldn't receive an op is if it is started in a non-blocking mode, so the server gets its config but then hasn't connected with the HC and therefore won't get update operations. Starting the server in blocking mode will avoid this situation (as could changes to how we start servers, to make it more like how a slave HC registers with the master HC). So, before doing this let's first look at how to reduce/eliminate the use case for it. > Also to consider when looking at this is how to represent servers in things like "restart-required" state in this overall aggregate 'server-state'. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

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 updated WFCORE-399: ------------------------------------ Fix Version/s: 2.0.0.Beta1 (was: 1.0.0.CR1) [~dlofthouse] How does this relate to the Elytron work? I'm scheduling it out of WFCORE 1.0 because it won't happen, but I don't want to leave it in 2.0 either unless it's clearly required for the Elytron work. > 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: 2.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.11#6341)

11 years, 3 months

1
0
0 / 0

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

by Max Rydahl Andersen (JIRA)

[ https://issues.jboss.org/browse/WFCORE-429?page=com.atlassian.jira.plugin... ] Max Rydahl Andersen commented on WFCORE-429: -------------------------------------------- if it does not work for non-exploded deployments then it wont be usable in context of deploying to a dockerized or cloud running EAP with no SSH/SCP access. > 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 > > (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)

11 years, 3 months

1
0
0 / 0

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

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-429?page=com.atlassian.jira.plugin... ] Brian Stansberry commented on WFCORE-429: ----------------------------------------- [~luck3y] FYI. This relates to the managed exploded deployment EAP7-204 JIRA, although reading this it implies it may work for non-exploded deployments too, which I don't think we should support, except via the deployment-overlay feature. At this point this JIRA should be regarded as informational, an input to the requirements gathering around EAP7-204. Perhaps it becomes the upstream JIRA for EAP7-204, perhaps it becomes extra stuff to do later, perhaps it gets closed and other JIRAs get opened. > 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 > > (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)

11 years, 3 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