December 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-345) Provide way to display deployed application metadata

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-345?page=com.atlassian.jira.plugin... ] Brian Stansberry moved WFLY-1084 to WFCORE-345: ----------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-345 (was: WFLY-1084) Affects Version/s: (was: 8.0.0.Alpha1) Component/s: Domain Management (was: Domain Management) > Provide way to display deployed application metadata > ---------------------------------------------------- > > Key: WFCORE-345 > URL: https://issues.jboss.org/browse/WFCORE-345 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Nicklas Karlsson > Assignee: Tomaz Cerar > > It would be handy to have the deployment process print out the complete DeploymentInfo for an application so one could view the final order of filters and request listeners etc. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-339) Provide a way to add a description for a deployment

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-339?page=com.atlassian.jira.plugin... ] Brian Stansberry moved WFLY-1164 to WFCORE-339: ----------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-339 (was: WFLY-1164) Component/s: Domain Management (was: Domain Management) > Provide a way to add a description for a deployment > --------------------------------------------------- > > Key: WFCORE-339 > URL: https://issues.jboss.org/browse/WFCORE-339 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Sven Plath > Priority: Minor > > h2.Summary > It would be nice to have a feature that allows to add an *optional description* to a deployment when using the console or the web interface to deploy it. > h2.Current Situation > Currently, it is possible to deploy applications using: > {code} > deploy C:\path\to\application.jar --name=... --runtime-name=... > {code} > The _runtime-name_ is used for dependency resolution. When for example we have an application *app_A-1.0.0.jar* and deploy it using the following command_ > {code} > deploy C:\path\to\application.jar --name=app_A.jar --runtime-name=app_A-1.jar > {code} > we loose the version information of that application. > * We could write the version into the _name_ argument, however it could lead to multiple deployments of the same application when the old one is not removed before updating. > * We could add the version information into the _runtime-name_ argument, but that would be problematic when updating applications to a newer version. We would have to change the deployment-descriptor. > h2.Request > When deploying applications, we could provide an additional argument, called *description*. It would allow us to do the following: > {code} > deploy C:\path\to\application-1.0.0.jar --name=application-1.jar --description="Application v1.0.0" > {code} > When doing _/deployment=application-1.jar:read-resource_, it would result in the following output: > {code} > { > "outcome" => "success", > "result" => { > "content" => [{"hash" => bytes { > 0x10, 0xd6, 0x20, 0x46, 0x74, 0xcc, 0xe5, 0x39, > 0x7d, 0xef, 0x2e, 0xe3, 0x26, 0x45, 0x28, 0xad, > 0xa5, 0xde, 0xdd, 0x80 > }}], > "enabled" => true, > "name" => "application-1.jar", > "persistent" => true, > "runtime-name" => "application-1.jar", > "description" => "Application v1.0.0", > "subdeployment" => undefined, > "subsystem" => undefined > } > } > {code} > This description information should be kept when replacing that particular deployment, so when doing: > {code} > deploy C:\path\to\application-1.0.0.jar --name=application-1.jar --force > {code} > it should replace the existing application, but without deleting the description information. That should be removed when doing: > {code} > /deployment=application-1.jar:remove > {code} > When explicitly adding the _description_ argument to the _deploy_ command, the description has to be replaced by the new one. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-340) A write-config operation

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-340?page=com.atlassian.jira.plugin... ] Brian Stansberry moved WFLY-1122 to WFCORE-340: ----------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-340 (was: WFLY-1122) Component/s: Domain Management (was: Domain Management) > A write-config operation > ------------------------ > > Key: WFCORE-340 > URL: https://issues.jboss.org/browse/WFCORE-340 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Brian Stansberry > > Operation to force the server to write its config file, without making any actual config change. > One use case mentioned was to get the config file updated to the latest xml namespaces following an upgrade. > This should be trivial to implement with an operation step handler that simply does > context.readResourceForUpdate(PathAddress.EMPT_ADDRESS); > context.stepCompleted(); > That handler would be registered on: > 1) The root resource for a non-managed-domain server (for standalone.xml). > 2) The host=* resource on any HostController (for host.xml). > 3) The root resource on a HostController that is the master (for domain.xml). -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 7 months

1
0
0 / 0

[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, 7 months

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, 7 months

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, 7 months

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, 7 months

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, 7 months

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, 7 months

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