April 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-4297) [PATCH] fix 2 bugs in bin/standalone.sh

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-4297?page=com.atlassian.jira.plugin.... ] Brian Stansberry reassigned WFLY-4297: -------------------------------------- Assignee: Tomaz Cerar (was: Jason Greene) Component/s: Scripts Tomaz, please move to WFCORE if this is still valid, else please resolve as Out of Date. > [PATCH] fix 2 bugs in bin/standalone.sh > --------------------------------------- > > Key: WFLY-4297 > URL: https://issues.jboss.org/browse/WFLY-4297 > Project: WildFly > Issue Type: Bug > Components: Scripts > Reporter: Martin Petricek > Assignee: Tomaz Cerar > Attachments: bin-fix.patch > > > bin/standalone.sh does not use "shift" correctly when parsing commandline option, failing with "bin/standalone.sh: 34: shift: can't shift that many" if "--debug" without a parameter is used on dash (default shell in debian) > Second issue is that the script does not handle correctly situation when CDPATH environment variable is set, failing completely. > Attaching patch that fixes both these issues. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-4315) Allow Individual servers in a server group to be restarted

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-4315?page=com.atlassian.jira.plugin.... ] Brian Stansberry closed WFLY-4315. ---------------------------------- Resolution: Out of Date You can start/stop any server by accessing the /host=<hostname>/server=<servername> resource or the /host=<hostname>/server-config=<servername> resource. > Allow Individual servers in a server group to be restarted > ---------------------------------------------------------- > > Key: WFLY-4315 > URL: https://issues.jboss.org/browse/WFLY-4315 > Project: WildFly > Issue Type: Feature Request > Reporter: Carlton Zachary > Assignee: Jason Greene > > Currently, in domain mode you can only do a restart on a server group. Could the feature be added to have the option to do a restart on an individual server in the server group. Seems to only be there when a configuration change has been made and requires a restart. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-4367) jboss-cli.xml should include timeout of 30 seconds

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-4367?page=com.atlassian.jira.plugin.... ] Brian Stansberry commented on WFLY-4367: ---------------------------------------- This should be moved to WFCORE, as that is where this file is currently maintained. > jboss-cli.xml should include timeout of 30 seconds > --------------------------------------------------- > > Key: WFLY-4367 > URL: https://issues.jboss.org/browse/WFLY-4367 > Project: WildFly > Issue Type: Enhancement > Components: CLI > Affects Versions: 8.2.0.Final > Reporter: Travis Rogers > Assignee: Alexey Loubyansky > Attachments: loop-cli-cmd.sh > > > Description of problem: > CLI commands use a default timeout of 5 seconds. Testing has shown that connection timeouts will occur with a timeout value this low. Recommended value is 30 seconds. > The following default setting should be added to $JBOSS_HOME/bin/jboss-cli.xml: > <connection-timeout>30000</connection-timeout> > Version-Release number of selected component (if applicable): > How to reproduce: > Loop calling the CLI executing a command. > Example command: > jboss-cli.sh -c --command=":read-attribute(name=server-state)" > Actual results: > Connection timeout error will eventually be thrown. > Expected results: > No errors due to connection timeout. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-4373) WildFly CLI API ModelControllerClient memory leak?

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-4373?page=com.atlassian.jira.plugin.... ] Brian Stansberry commented on WFLY-4373: ---------------------------------------- Does this happen with WildFly 9.0.0.Beta2? If so, please attach a thread dump of both the client process and the server process, taken while close() is hanging. Also, why does the title refer to a memory leak? Finally, the "Environment" field references some xnio versions. Are those the standard versions in WildFly 8.2.0.Final? If not, does the problem occur when the standard versions are used? > WildFly CLI API ModelControllerClient memory leak? > -------------------------------------------------- > > Key: WFLY-4373 > URL: https://issues.jboss.org/browse/WFLY-4373 > Project: WildFly > Issue Type: Bug > Components: Domain Management, IO > Affects Versions: 8.2.0.Final > Environment: Ubuntu 14.04 LTS, Java 1.8, xnio-api and xnio-nio are 3.3.0.Final > Reporter: Georgy Go > Assignee: Tomaz Cerar > Labels: cli, dmr > > The following snippet of code to redeploy an application: > ModelControllerClient cl = ModelControllerClient.Factory.create("localhost", 9999); > ModelNode operation = new ModelNode(); > operation.get("operation").set("redeploy"); > operation.get("address").add("deployment", "server.war"); > cl.execute(operation); > cl.close(); > - works fine, but .close() freezes forever. > This issue depends to not only redeploy, but also for any other operations. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-4373) WildFly CLI API ModelControllerClient memory leak?

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-4373?page=com.atlassian.jira.plugin.... ] Brian Stansberry updated WFLY-4373: ----------------------------------- Component/s: Domain Management (was: CLI) > WildFly CLI API ModelControllerClient memory leak? > -------------------------------------------------- > > Key: WFLY-4373 > URL: https://issues.jboss.org/browse/WFLY-4373 > Project: WildFly > Issue Type: Bug > Components: Domain Management, IO > Affects Versions: 8.2.0.Final > Environment: Ubuntu 14.04 LTS, Java 1.8, xnio-api and xnio-nio are 3.3.0.Final > Reporter: Georgy Go > Assignee: Alexey Loubyansky > Labels: cli, dmr > > The following snippet of code to redeploy an application: > ModelControllerClient cl = ModelControllerClient.Factory.create("localhost", 9999); > ModelNode operation = new ModelNode(); > operation.get("operation").set("redeploy"); > operation.get("address").add("deployment", "server.war"); > cl.execute(operation); > cl.close(); > - works fine, but .close() freezes forever. > This issue depends to not only redeploy, but also for any other operations. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-4373) WildFly CLI API ModelControllerClient memory leak?

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-4373?page=com.atlassian.jira.plugin.... ] Brian Stansberry reassigned WFLY-4373: -------------------------------------- Assignee: Brian Stansberry (was: Alexey Loubyansky) > WildFly CLI API ModelControllerClient memory leak? > -------------------------------------------------- > > Key: WFLY-4373 > URL: https://issues.jboss.org/browse/WFLY-4373 > Project: WildFly > Issue Type: Bug > Components: Domain Management, IO > Affects Versions: 8.2.0.Final > Environment: Ubuntu 14.04 LTS, Java 1.8, xnio-api and xnio-nio are 3.3.0.Final > Reporter: Georgy Go > Assignee: Brian Stansberry > Labels: cli, dmr > > The following snippet of code to redeploy an application: > ModelControllerClient cl = ModelControllerClient.Factory.create("localhost", 9999); > ModelNode operation = new ModelNode(); > operation.get("operation").set("redeploy"); > operation.get("address").add("deployment", "server.war"); > cl.execute(operation); > cl.close(); > - works fine, but .close() freezes forever. > This issue depends to not only redeploy, but also for any other operations. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-4373) WildFly CLI API ModelControllerClient memory leak?

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-4373?page=com.atlassian.jira.plugin.... ] Brian Stansberry reassigned WFLY-4373: -------------------------------------- Assignee: Tomaz Cerar (was: Brian Stansberry) > WildFly CLI API ModelControllerClient memory leak? > -------------------------------------------------- > > Key: WFLY-4373 > URL: https://issues.jboss.org/browse/WFLY-4373 > Project: WildFly > Issue Type: Bug > Components: Domain Management, IO > Affects Versions: 8.2.0.Final > Environment: Ubuntu 14.04 LTS, Java 1.8, xnio-api and xnio-nio are 3.3.0.Final > Reporter: Georgy Go > Assignee: Tomaz Cerar > Labels: cli, dmr > > The following snippet of code to redeploy an application: > ModelControllerClient cl = ModelControllerClient.Factory.create("localhost", 9999); > ModelNode operation = new ModelNode(); > operation.get("operation").set("redeploy"); > operation.get("address").add("deployment", "server.war"); > cl.execute(operation); > cl.close(); > - works fine, but .close() freezes forever. > This issue depends to not only redeploy, but also for any other operations. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-4407) Upgrade wildfly-core to 1.0.0.Beta1

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-4407?page=com.atlassian.jira.plugin.... ] Brian Stansberry resolved WFLY-4407. ------------------------------------ Fix Version/s: 9.0.0.Beta1 (was: 9.0.0.CR1) Resolution: Done Please don't file these kinds of issues. Merging a PR in WildFly Core is sufficient to meet the "upstream" requirement for EAP. WildFly Core is the upstream for those portions of the EAP 6 codebase that are now maintained in WildFly Core. > Upgrade wildfly-core to 1.0.0.Beta1 > ----------------------------------- > > Key: WFLY-4407 > URL: https://issues.jboss.org/browse/WFLY-4407 > Project: WildFly > Issue Type: Component Upgrade > Affects Versions: 9.0.0.Alpha1 > Reporter: Bartosz Baranowski > Assignee: Jason Greene > Fix For: 9.0.0.Beta1 > > -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-4412) Not able to enable JMX Remote access

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-4412?page=com.atlassian.jira.plugin.... ] Brian Stansberry updated WFLY-4412: ----------------------------------- Component/s: Domain Management Logging (was: ConfigAdmin) > Not able to enable JMX Remote access > ------------------------------------ > > Key: WFLY-4412 > URL: https://issues.jboss.org/browse/WFLY-4412 > Project: WildFly > Issue Type: Bug > Components: Class Loading, Domain Management, Logging > Affects Versions: 8.2.0.Final > Environment: windows & linux > Reporter: Shark Xu > Assignee: David Lloyd > > Can not enable JMX remote access port. > Config in domain.xml: > <jvm-options> > <option value="-Dcom.sun.management.jmxremote.port=19999"/> > <option value="-Dcom.sun.management.jmxremote.authenticate=false"/> > <option value="-Dcom.sun.management.jmxremote.ssl=false"/> > </jvm-options> > java.lang.IllegalStateException raised during startup. > Logs: > [Server:server-one] Exception in thread "main" java.lang.IllegalStateException: The LogManager was not properly installed (you must set the "java.util > .logging.manager" system property to "org.jboss.logmanager.LogManager") > [Server:server-one] at org.jboss.logmanager.Logger.getLogger(Logger.java:61) > [Server:server-one] at org.jboss.as.server.DomainServerMain.main(DomainServerMain.java:86) > [Server:server-one] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > [Server:server-one] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > [Server:server-one] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > [Server:server-one] at java.lang.reflect.Method.invoke(Method.java:606) > [Server:server-one] at org.jboss.modules.Module.run(Module.java:312) > [Server:server-one] at org.jboss.modules.Main.main(Main.java:460) -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-4471) Enabled automatic encryption of passwords stored in configuration

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-4471?page=com.atlassian.jira.plugin.... ] Brian Stansberry reassigned WFLY-4471: -------------------------------------- Assignee: (was: Thomas Diesler) > Enabled automatic encryption of passwords stored in configuration > ----------------------------------------------------------------- > > Key: WFLY-4471 > URL: https://issues.jboss.org/browse/WFLY-4471 > Project: WildFly > Issue Type: Feature Request > Components: Domain Management, Security > Environment: Wildfly 9 > Reporter: Jason Shepherd > > Currently encrypting passwords such as Datasource passwords can only be done 'after the fact'. You have to create the datasource first, then retrospectively store the password in the vault and dereference it in the configuration. > It would be great if could turn on automatic storage of passwords in the vault so that when you create a Datasource password, or add a resource adapter which specifies a remote resource password, those passwords were automatically added to the vault, and deferenced in the configuration file. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

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 April 2015