December 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-341) monolithic config file and modules make deploying to JBossAS7 nasty

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-341?page=com.atlassian.jira.plugin... ] Brian Stansberry moved WFLY-1098 to WFCORE-341: ----------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-341 (was: WFLY-1098) Component/s: Domain Management (was: Domain Management) > monolithic config file and modules make deploying to JBossAS7 nasty > ------------------------------------------------------------------- > > Key: WFCORE-341 > URL: https://issues.jboss.org/browse/WFCORE-341 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Paul Hinds > > Previous versions of JBoss could be configured by copying files to the correct place. Each server in the cluster had identical config, this made configuring JBoss just a case of running rsync with files that you had an interest in. > Consider jboss-log4j.xml which was one file you could copy to setup logging. Now to setup logging we need to hack standalone.xml with XSLT or some tool that we dont yet have in our simple deployment system. > Previously we could rsync a new file to each server in the cluster and it would apply the new logging at runtime. Now we would have to updates standalone.xml at runtime which is not something that seems safe. > Adding a DataSource used to be a case of copy driver jar to /lib, copy -ds.xml to /deploy that process is now complicated. > Port bindings ditto. > JMS ditto. > Is there any way the monolithic config could be split up? most importantly bringing back external runtime configurable log4j config. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-342) Streamline :read-resource-description

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-342?page=com.atlassian.jira.plugin... ] Brian Stansberry moved WFLY-1092 to WFCORE-342: ----------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-342 (was: WFLY-1092) Component/s: Domain Management (was: Domain Management) > Streamline :read-resource-description > ------------------------------------- > > Key: WFCORE-342 > URL: https://issues.jboss.org/browse/WFCORE-342 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Heiko Braun > > We have a need for a streamlined read-resource-description operation response. In many cases we only need the attribute descriptions and from those descriptions only a subset of the meta data available. > For instance: > {noformat} > "enable-statistics" => { > "type" => BOOLEAN, > "description" => "Whether statistics should be enabled.", > "expressions-allowed" => true, > "nillable" => true, > "default" => false, > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "all-services" > } > {noformat} > Clients that require information about the structure don't need: > - access-type > - storage > - restart-required > In many cases we don't even need > - operations > - children > Would it be possible to further parametrize the read-resource-description operation to allow these distinctions? This would help to reduce the overall payload size when clients communicate with the DC and improve thus improve the overall performance. Not to mention parsing greatly benefits from a streamlined model as well. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-335) Convert deployment's content to a child resource

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-335?page=com.atlassian.jira.plugin... ] Brian Stansberry moved WFLY-1161 to WFCORE-335: ----------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-335 (was: WFLY-1161) Component/s: Domain Management (was: Domain Management) > Convert deployment's content to a child resource > ------------------------------------------------ > > Key: WFCORE-335 > URL: https://issues.jboss.org/browse/WFCORE-335 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Kabir Khan > Assignee: Brian Stansberry > > At the moment this is a complex attribute. > Not saying this MUST happen, just opening this to see what Brian & co think. I never really understood why it is a list either. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-336) Ability for Deployment Overlays to overlay System Properties

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-336?page=com.atlassian.jira.plugin... ] Brian Stansberry moved WFLY-2720 to WFCORE-336: ----------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-336 (was: WFLY-2720) Component/s: Domain Management (was: Domain Management) > Ability for Deployment Overlays to overlay System Properties > ------------------------------------------------------------ > > Key: WFCORE-336 > URL: https://issues.jboss.org/browse/WFCORE-336 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Joshua Henn > > Currently Deployment Overlays allow only the replacing whole resource files. It would be nice to also be able to overlay System Properties that take precedent over globally defined properties. > ie. > {code:xml} > <deployment-overlays> > <deployment-overlay name="myOverlay"> > <system-properties> > <property name="datasource" value="java:jboss/datasources/controller"/> > </system-properties> > <deployment name="controller.war"/> > </deployment-overlay> > </deployment-overlays> > {code} > Usecase: > Have two deployments active of the same application, run-time configured by descriptor replacements via System Properties. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-337) Standard method of documenting whether expressions are supported in the jboss-as-config_x_x.xsd and in the subsystem xsds

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-337?page=com.atlassian.jira.plugin... ] Brian Stansberry moved WFLY-1112 to WFCORE-337: ----------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-337 (was: WFLY-1112) Component/s: Domain Management (was: Domain Management) > Standard method of documenting whether expressions are supported in the jboss-as-config_x_x.xsd and in the subsystem xsds > ------------------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-337 > URL: https://issues.jboss.org/browse/WFCORE-337 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Brian Stansberry > > Users should be able to read the xsd to tell if expressions are supported for a given attribute/element. Reading the management API metadata is too cumbersome and indirect. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-338) Auto-promotion of slave HC to master based on a shared lock

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-338?page=com.atlassian.jira.plugin... ] Brian Stansberry moved WFLY-1429 to WFCORE-338: ----------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-338 (was: WFLY-1429) Component/s: Domain Management (was: Domain Management) > Auto-promotion of slave HC to master based on a shared lock > ----------------------------------------------------------- > > Key: WFCORE-338 > URL: https://issues.jboss.org/browse/WFCORE-338 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Emanuel Muckenhuber > > Implement an option for a properly configured slave HC to promote itself to master after acquiring an exclusive lock mediated via some persistent store shared between all HCs that are possibly master. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-330) No Spaces Allowed in Host -> Name, but ' do work, odd

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-330?page=com.atlassian.jira.plugin... ] Brian Stansberry moved WFLY-1050 to WFCORE-330: ----------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-330 (was: WFLY-1050) Component/s: Domain Management (was: Domain Management) > No Spaces Allowed in Host -> Name, but ' do work, odd > ----------------------------------------------------- > > Key: WFCORE-330 > URL: https://issues.jboss.org/browse/WFCORE-330 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Jim Tyrrell > Labels: eap6-ux > > For some reason spaces do not seem to be allowed, but an Apostrophe seems to be okay. > [Host Controller] 20:56:20,250 ERROR [org.jboss.as.controller] (Controller Boot Thread) JBAS014601: Error booting the container: java.lang.IllegalArgumentException: JBAS014719: Invalid value specification Jim's Most_Excellent_Domain_Ever_so_here > Would be nice if the error message would kick out what values are acceptable? -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 1 month

1
0
0 / 0

[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, 1 month

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, 1 month

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, 1 month

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