December 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-348) review server debug-options configuration

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-348?page=com.atlassian.jira.plugin... ] Brian Stansberry moved WFLY-1229 to WFCORE-348: ----------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-348 (was: WFLY-1229) Component/s: Domain Management (was: Domain Management) > review server debug-options configuration > ----------------------------------------- > > Key: WFCORE-348 > URL: https://issues.jboss.org/browse/WFCORE-348 > Project: WildFly Core > Issue Type: Task > Components: Domain Management > Reporter: Emanuel Muckenhuber > Assignee: Emanuel Muckenhuber > > We need to review the server debug-options configuration, since it's not entirely clear what value is expected. Currently the JVM specific builder is doing additional checks, so that the value passed to the JVM startsWith -X. Which might not be true for all JVMs. > <jvm name="default" debug-enabled="true" debug-options="runjdwp:transport=dt_socket,address=8787,server=y,suspend=n" /> > https://issues.jboss.org/browse/AS7-1606 -- This message was sent by Atlassian JIRA (v6.3.8#6338)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-349) Document new system properties for the configuration history length and the number of days

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-349?page=com.atlassian.jira.plugin... ] Brian Stansberry moved WFLY-1231 to WFCORE-349: ----------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-349 (was: WFLY-1231) Component/s: Domain Management (was: Documentation) (was: Domain Management) > Document new system properties for the configuration history length and the number of days > ------------------------------------------------------------------------------------------ > > Key: WFCORE-349 > URL: https://issues.jboss.org/browse/WFCORE-349 > Project: WildFly Core > Issue Type: Task > Components: Domain Management > Reporter: Ivo Studensky > > New system properties have been introduced to AS7 which allow setting of the configuration history length and the number of days they are kept. These properties need to be documented properly. See AS7-4931. > The default value of jboss.config.current-history-length is 100 and the default value of jboss.config.history-days is 30. > Here is an example configuration: > {code:title=standalone.xml|xml} > .. > </extensions> > <system-properties> > <property name="jboss.config.current-history-length" value="50"/> > <property name="jboss.config.history-days" value="15"/> > </system-properties> > <management> > .. > {code} -- This message was sent by Atlassian JIRA (v6.3.8#6338)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-343) Trailing forgotten --> does not generate a good error message on host.xml

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-343?page=com.atlassian.jira.plugin... ] Brian Stansberry moved WFLY-1047 to WFCORE-343: ----------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-343 (was: WFLY-1047) Component/s: Domain Management (was: Domain Management) > Trailing forgotten --> does not generate a good error message on host.xml > ------------------------------------------------------------------------- > > Key: WFCORE-343 > URL: https://issues.jboss.org/browse/WFCORE-343 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Jim Tyrrell > Labels: eap6-ux > > This snippet from the host.xml file, note the --> that was forgotten to be removed in the remote line... > <domain-controller> >  >  > </domain-controller> > Generates this error message: > [Host Controller] 21:24:51,341 ERROR [org.jboss.as.controller] (Controller Boot Thread) JBAS014601: Error booting the container: java.lang.RuntimeException: org.jboss.as.controller.persistence.ConfigurationPersistenceException: JBAS014676: Failed to parse configuration > Several lines further down...you get this message... > [Host Controller] Caused by: com.ctc.wstx.exc.WstxParsingException: Received non-all-whitespace CHARACTERS or CDATA event in nextTag(). > [Host Controller] at [row,col {unknown-source}]: [44,4] > It would be nice if the first error message in an XML parsing error would just show me the place it failed, along with maybe the prior line. > Less nice would be the 44,4 to be in the first message and break it down as line 44, character 4. More verbosity would be nice. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-344) Create operations to view the host and process controller log files

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-344?page=com.atlassian.jira.plugin... ] Brian Stansberry moved WFLY-2825 to WFCORE-344: ----------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-344 (was: WFLY-2825) Component/s: Domain Management (was: Domain Management) > Create operations to view the host and process controller log files > ------------------------------------------------------------------- > > Key: WFCORE-344 > URL: https://issues.jboss.org/browse/WFCORE-344 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: James Perkins > Assignee: James Perkins > > Operations need to exist somewhere so the {{host-controller.log}} and {{process-controller.log}} files can be read with a management operation. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

10 years, 1 month

1
0
0 / 0

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

10 years, 1 month

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)

10 years, 1 month

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)

10 years, 1 month

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)

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

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

10 years, 1 month

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira December 2014