December 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-331) Configurable location for deployment scanner marker files

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-331?page=com.atlassian.jira.plugin... ] Brian Stansberry moved WFLY-2503 to WFCORE-331: ----------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-331 (was: WFLY-2503) Component/s: Domain Management (was: Domain Management) > Configurable location for deployment scanner marker files > --------------------------------------------------------- > > Key: WFCORE-331 > URL: https://issues.jboss.org/browse/WFCORE-331 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Brian Stansberry > > Add marker-dir and marker-dir-relative-to attributes to the deployment scanner resource. These control where the marker files are written, with the default being the dir being scanned itself. > The idea here is to allow sharing of a deployments/ dir by letting users redirect the markers to some other location. > To store in a server-specific subdir of deployments (making the markers still fairly accessible the user): > {code} > <deployment-scanner path="deployments" relative-to="jboss.server.base.dir" scan-interval="5000" > marker-dir="deployments/${jboss.node.name}" > marker-dir-relative-to="jboss.server.base.dir" > /> > {code} > To store the markers in the data dir, out of sight, out of mind: > {code} > <deployment-scanner path="deployments" relative-to="jboss.server.base.dir" scan-interval="5000" > marker-dir="deployment-scanner-markers" > marker-dir-relative-to="jboss.server.data.dir" > /> > {code} > This all sounds simple enough, but anyone looking into it *must* assume this will be a highly complex task, as the scanner itself is very complex and assumes that the deployments and the markers are in the same dir. Extremely extensive test coverage will be required. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-332) Allow RestartParentXXXHandlers to handle resources with multiple services

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-332?page=com.atlassian.jira.plugin... ] Brian Stansberry moved WFLY-1165 to WFCORE-332: ----------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-332 (was: WFLY-1165) Component/s: Domain Management (was: Domain Management) > Allow RestartParentXXXHandlers to handle resources with multiple services > ------------------------------------------------------------------------- > > Key: WFCORE-332 > URL: https://issues.jboss.org/browse/WFCORE-332 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Richard Achmatowicz > Assignee: Jason Greene > Priority: Minor > > I'd like to use RestartParentWriteAttributeHandler to allow handling of attributes which, when updated, case a restart of only the services installed by their parent resource. These are really useful classes and solve a commonly encountered problem. > However, the resource I want to restart involves four services, and it appears that RestartParentWriteAttriubuteHandler assumes that for every parent key name, there is only a single service registered. > If we had the private methods: > ServiceName[] getParentServiceNames(PathAddress address) > boolean areParentServicesInstalled(ServiceName[] names) > void removeServices(OperationContext context, ServiceNames[] names, ModelNode parentModel) > this could be made to work for more general resources. > -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-333) Provide a management operation to list the servers in a server group (domain mode)

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-333?page=com.atlassian.jira.plugin... ] Brian Stansberry moved WFLY-1078 to WFCORE-333: ----------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-333 (was: WFLY-1078) Component/s: CLI Domain Management (was: CLI) (was: Domain Management) > Provide a management operation to list the servers in a server group (domain mode) > ---------------------------------------------------------------------------------- > > Key: WFCORE-333 > URL: https://issues.jboss.org/browse/WFCORE-333 > Project: WildFly Core > Issue Type: Feature Request > Components: CLI, Domain Management > Reporter: Richard Achmatowicz > Assignee: Alexey Loubyansky > Priority: Minor > > In domain mode, an end user might want to start one or more servers by hand in a named server group. Obtaining the list of servers in a server group is not readily available: the "group" attribute is embedded in server-config, so we have to drill down into every /host=*/server-config=* combination to find out which servers belong to a specific server group. > It would improve the user experience to have an operation which shows which servers are in a given server group. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-334) "Ignore failure" for management operations

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-334?page=com.atlassian.jira.plugin... ] Brian Stansberry moved WFLY-1395 to WFCORE-334: ----------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-334 (was: WFLY-1395) Component/s: Domain Management (was: Domain Management) > "Ignore failure" for management operations > ------------------------------------------ > > Key: WFCORE-334 > URL: https://issues.jboss.org/browse/WFCORE-334 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Ondrej Zizka > > Most operations don't follow any "overwrite" concept. > To emulate it, one needs to check for existence of a resource, conditionally delete it, and then create the new one. > This is not easily applicable in a batch. > Implementing overwrite for all actions would be tedious. > But this could help: > Another "standard" property (similar to {{address}} and {{op-name}}) "onFail=ignore" or such, which would make the operation not fail if an exception occurs. A short CLI syntax could be a '?' at the end of operation's name: > {code} > /foo=bar/boo=baz:remove?() > {code} > This would allow mgmt API users to queue a removing operation without knowing if it exists; thus, effectively, doing an overwrite. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-326) Pushing configuration artifacts to domain servers

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-326?page=com.atlassian.jira.plugin... ] Brian Stansberry moved WFLY-1179 to WFCORE-326: ----------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-326 (was: WFLY-1179) Component/s: Domain Management (was: Domain Management) > Pushing configuration artifacts to domain servers > ------------------------------------------------- > > Key: WFCORE-326 > URL: https://issues.jboss.org/browse/WFCORE-326 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Darragh Sherwin > Priority: Minor > Labels: clustering, domain > > It should be possible to push configurations artifacts like property files, keystores, etc to domain servers from a domain controller and for applications to reference these configuration artifacts in a generic manner. > Weblogic provides this functionality -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-327) Add file based auth to http management interface

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-327?page=com.atlassian.jira.plugin... ] Brian Stansberry moved WFLY-1150 to WFCORE-327: ----------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-327 (was: WFLY-1150) Component/s: Domain Management (was: Domain Management) > Add file based auth to http management interface > ------------------------------------------------ > > Key: WFCORE-327 > URL: https://issues.jboss.org/browse/WFCORE-327 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Max Rydahl Andersen > Assignee: Darran Lofthouse > > usecase: allow clients using http api to use the file based auth so they do not have to rely on the binary protocol and remoting. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-328) Provide deployment manifest information via the CLI

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-328?page=com.atlassian.jira.plugin... ] Brian Stansberry moved WFLY-1086 to WFCORE-328: ----------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-328 (was: WFLY-1086) Component/s: CLI Domain Management (was: CLI) (was: Domain Management) > Provide deployment manifest information via the CLI > --------------------------------------------------- > > Key: WFCORE-328 > URL: https://issues.jboss.org/browse/WFCORE-328 > Project: WildFly Core > Issue Type: Feature Request > Components: CLI, Domain Management > Reporter: Brian Stansberry > Priority: Critical > > We've gotten a user request for providing the contents of a deployment's MANIFEST.MF via the CLI. > The request is to include an option to get the manifest info for a single deployment, and also the info for all deployments. > This task needs to be evaluated in relationship to the larger request to provide read (and possibly in some cases write) access to all files within a deployment. The manifest is essentially just one file with a standard location. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-329) Allow duplication of configuration parts via management API

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-329?page=com.atlassian.jira.plugin... ] Brian Stansberry moved WFLY-1106 to WFCORE-329: ----------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-329 (was: WFLY-1106) Component/s: Domain Management (was: Domain Management) > Allow duplication of configuration parts via management API > ----------------------------------------------------------- > > Key: WFCORE-329 > URL: https://issues.jboss.org/browse/WFCORE-329 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Alex Ont > Assignee: Brian Stansberry > > Allow the possibility to read part of the configuration via management API, modify it and add it back under a new id, without knowing the specific details of the resource. > This would allow for example adding a new server group configured exactly as an existing, creating a new resource (datasource, etc.) based on an existing one or even creating a profile based on a given one. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-324) Resolve startup dependency between master hostController and slave hostControllers.

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-324?page=com.atlassian.jira.plugin... ] Brian Stansberry moved WFLY-1184 to WFCORE-324: ----------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-324 (was: WFLY-1184) Component/s: Domain Management (was: Domain Management) > Resolve startup dependency between master hostController and slave hostControllers. > ----------------------------------------------------------------------------------- > > Key: WFCORE-324 > URL: https://issues.jboss.org/browse/WFCORE-324 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: karin k > > *Current situation:* > * The slave hostController can be started using option --cached-dc > Result: the slave hostContoller will be started given that a local copy of the domain.xml (exact name domain.cached-remote.xml > ) is available (created by a startup using -backup and an available master hostController) > The slave hostController will never register itself towards the master domain hostController (regardless of whether the master domain controller is running during startup or will be started afterwards) > * The slave hostController can be started without any option > If the master hostController is not running during startup of the slave, the startup of the slave will fail. > * The slave hostController can be started with option -backup > If the master hostController is not running during startup of the slave, the startup of the slave will fail. > If the master hostController is running, the slave will store a copy of the domain.xml locally. > A successful startup of the whole domain is only possible when the hostControllers are started in the correct sequence (master hostController must be available when slave host Controllers are trying to register). From my point of view a successful startup means that all hostControllers can start successfully and additionally it is possible to manage the slave hostController by means of the master hostController. > *Requirement* > To let a JBoss domain act and started in the correct way (meaning central management is possible) the following should be fullfilled > * If the master hostController is not running, the slave should still be able to start and work with its local copy of the domain.xml > * If the master hostController is started after the slave hostController, the slave host controller should still be able to start successfully but should in parallel recognize when the master hostController is finally available and register itself > * There should be the possiblity to store a local copy of the domain master hostController in parallel with the approach of starting up when the master hostController is not running (in this case the master domain.xml cannot be stored locally but anyway startup is possible). > (see also https://issues.jboss.org/browse/AS7-4281) > Regards > Karin -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-325) Allow socket-binding-group-refType to override default-interface

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-325?page=com.atlassian.jira.plugin... ] Brian Stansberry moved WFLY-1148 to WFCORE-325: ----------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-325 (was: WFLY-1148) Component/s: Domain Management (was: Domain Management) > Allow socket-binding-group-refType to override default-interface > ---------------------------------------------------------------- > > Key: WFCORE-325 > URL: https://issues.jboss.org/browse/WFCORE-325 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Todd Trimmer > Priority: Optional > Labels: configuration, domain, host-controller > > I want all the host controllers in my domain to use the same socket-binding-group. However, each host controller can have multiple servers, each with its own IP, but each IP still reuses the same port number (yet still a unique IP+port combo). The problem is that the socket-binding-group-refType will not let me override the @default-interface value from the referent socket-binding-group. I am forced to create a second, equally verbose, socket-binding-group exactly like the first group in every way, except for the @default-interface. I wish to avoid this. My particular scenario cannot rely on @port-offset because my hardware load-balancer needs all nodes in the same pool to use the same ports. > Under my proposal, the host.xml could thus more easily be written like this: > ... > <interfaces> > <interface name="public"> > <inet-address value="10.10.10.1" /> > </interface> > <interface name="public-two"> > <inet-address value="10.10.10.2" /> > </interface> > </interfaces> > ... > <servers> > <server name="server-one" group="prod-server-group" auto-start="true"> > <jvm name="jvm6g" /> > </server> > <server name="server-two" group="prod-server-group" auto-start="false"> > <jvm name="jvm2g" /> > <socket-binding-group ref="standard-sockets" default-interface="public-two" /> > </server> > </servers> > ... > This alleviates the burden of having to define a second socket-binding-group in domain.xml and maintaining the same set of socket-binding definitions in two places. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 5 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 December 2014