September 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-1628) alias --help print nothing on jboss-cli

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-1628?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated WFLY-1628: ------------------------------------------ Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=980099, https://bugzilla.redhat.com/show_bug.cgi?id=1139111 (was: https://bugzilla.redhat.com/show_bug.cgi?id=980099) > alias --help print nothing on jboss-cli > --------------------------------------- > > Key: WFLY-1628 > URL: https://issues.jboss.org/browse/WFLY-1628 > Project: WildFly > Issue Type: Bug > Components: CLI > Affects Versions: 8.0.0.Alpha2 > Environment: MacOS X, JDK 1.7.0_09 > Reporter: Alexis Hassler > Assignee: Alexey Loubyansky > > I have no output when I call this : > [standalone@localhost:9990 /] alias --help > [standalone@localhost:9990 /] -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-3824) CLI doesn't read alias from .jbossclirc

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3824?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated WFLY-3824: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1139111 > CLI doesn't read alias from .jbossclirc > --------------------------------------- > > Key: WFLY-3824 > URL: https://issues.jboss.org/browse/WFLY-3824 > Project: WildFly > Issue Type: Feature Request > Components: CLI > Affects Versions: 8.1.0.Final > Reporter: Osamu Nagano > Assignee: Alexey Loubyansky > > By WFLY-1063, a variable can be defined in .jbossclirc and preloaded by CLI. But aliases are not able to define with {{org.jboss.as.cli.CliInitializationException}}. > {code} > $ cat .jbossclirc > set prod_db=/subsystem=datasources/data-source=ExampleDS > alias ll=ls -l > $ $JBOSS_HOME/bin/jboss-cli.sh -c > Unexpected command 'alias ll=ls -l'. Type 'help --commands' for the list of supported commands. > org.jboss.as.cli.CliInitializationException: Failed to process /home/onagano/cases/01180422/wf810/.jbossclirc > at org.jboss.as.cli.impl.CliLauncher.runcom(CliLauncher.java:352) > at org.jboss.as.cli.impl.CommandContextImpl.<init>(CommandContextImpl.java:305) > at org.jboss.as.cli.impl.CommandContextFactoryImpl.newCommandContext(CommandContextFactoryImpl.java:76) > at org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:273) > at org.jboss.as.cli.impl.CliLauncher.main(CliLauncher.java:253) > at org.jboss.as.cli.CommandLineMain.main(CommandLineMain.java:34) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at org.jboss.modules.Module.run(Module.java:312) > at org.jboss.modules.Main.main(Main.java:460) > {code} > Enclosing by single quote or double quote won't help. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-1063) Improvement: Provide CLI preferences

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-1063?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated WFLY-1063: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1139111 > Improvement: Provide CLI preferences > ------------------------------------ > > Key: WFLY-1063 > URL: https://issues.jboss.org/browse/WFLY-1063 > Project: WildFly > Issue Type: Feature Request > Components: CLI > Reporter: Heiko Braun > Assignee: Alexey Loubyansky > Fix For: 8.0.0.Final > > > preferences on for default settings: > [4:37pm] hbraun: CLI preferences would be cool > [4:37pm] hbraun: i am tired of writing recursive=true all the time > alias for address tokens: > [4:38pm] hbraun: plus an address book: prod-db = /subsystem=jadada/database=jadada/ > [4:38pm] hbraun: so you could call prod-db:read-resource -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-3824) CLI doesn't read alias from .jbossclirc

by Osamu Nagano (JIRA)

Osamu Nagano created WFLY-3824: ---------------------------------- Summary: CLI doesn't read alias from .jbossclirc Key: WFLY-3824 URL: https://issues.jboss.org/browse/WFLY-3824 Project: WildFly Issue Type: Feature Request Components: CLI Affects Versions: 8.1.0.Final Reporter: Osamu Nagano Assignee: Alexey Loubyansky By WFLY-1063, a variable can be defined in .jbossclirc and preloaded by CLI. But aliases are not able to define with {{org.jboss.as.cli.CliInitializationException}}. {code} $ cat .jbossclirc set prod_db=/subsystem=datasources/data-source=ExampleDS alias ll=ls -l $ $JBOSS_HOME/bin/jboss-cli.sh -c Unexpected command 'alias ll=ls -l'. Type 'help --commands' for the list of supported commands. org.jboss.as.cli.CliInitializationException: Failed to process /home/onagano/cases/01180422/wf810/.jbossclirc at org.jboss.as.cli.impl.CliLauncher.runcom(CliLauncher.java:352) at org.jboss.as.cli.impl.CommandContextImpl.<init>(CommandContextImpl.java:305) at org.jboss.as.cli.impl.CommandContextFactoryImpl.newCommandContext(CommandContextFactoryImpl.java:76) at org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:273) at org.jboss.as.cli.impl.CliLauncher.main(CliLauncher.java:253) at org.jboss.as.cli.CommandLineMain.main(CommandLineMain.java:34) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.jboss.modules.Module.run(Module.java:312) at org.jboss.modules.Main.main(Main.java:460) {code} Enclosing by single quote or double quote won't help. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-122) Clean unreferenced deployments from the content repository

by Claudio Miranda (JIRA)

[ https://issues.jboss.org/browse/WFLY-122?page=com.atlassian.jira.plugin.s... ] Claudio Miranda commented on WFLY-122: -------------------------------------- What about cleaning data/content/<hash> on startup ? Check the list of deployments in domain.xml/standalone.xml and remove those unlisted. > Clean unreferenced deployments from the content repository > ---------------------------------------------------------- > > Key: WFLY-122 > URL: https://issues.jboss.org/browse/WFLY-122 > Project: WildFly > Issue Type: Bug > Components: Domain Management > Reporter: Brian Stansberry > Fix For: 9.0.0.CR1 > > > The algorithm for removing unused deployments from the content repository is based on doing this as part of undeploy operation execution. This doesn't cover cases where the content is never explicitly undeployed. For example: > 1) Scanner content that is updated when the server is offline; the old content will not have been "undeployed" during shutdown, and on startup the new content will be installed. > 2) Similar issues with deployments generated from module resources (see "A Mixed Approach on https://community.jboss.org/wiki/ExtendingAS7). When the server shuts down, there is no "subsystem remove" as part of shutdown, so the content added during start will not be removed. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JGRP-1878) Multicast discovery does not work on JDK8

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/JGRP-1878?page=com.atlassian.jira.plugin.... ] Radoslav Husar edited comment on JGRP-1878 at 9/7/14 6:46 AM: -------------------------------------------------------------- I may have tracked down the JDK8 changes that are responsible for the behavior change we are observing: JDK8 Discussion http://mail.openjdk.java.net/pipermail/net-dev/2013-May/006246.html JDK8 Issues https://bugs.openjdk.java.net/browse/JDK-8014499 http://bugs.java.com/view_bug.do?bug_id=8014499 http://bugs.java.com/view_bug.do?bug_id=8014377 JDK8 Commits http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/bf2bacf934d1 http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/cd06fc069152 What this is esentially doing, they are now setting IP_MULTICAST_ALL=0 for DatagramChannels on Linux which is supported since kernel version 2.6.31 (http://man7.org/linux/man-pages/man7/ip.7.html). With JDK8 binding to different addresses on the same machine, the processes are not going to receive each other's messages. Some further reading: https://bugzilla.redhat.com/show_bug.cgi?id=231899 http://marc.info/?l=linux-netdev&m=121579002105636&w=2 was (Author: rhusar): I may have tracked down the JDK8 changes that are responsible for the behavior change we are observing: Issues: https://bugs.openjdk.java.net/browse/JDK-8014499 http://bugs.java.com/view_bug.do?bug_id=8014499 http://bugs.java.com/view_bug.do?bug_id=8014377 Commits http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/bf2bacf934d1 http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/cd06fc069152 What this is esentially doing, they are now setting IP_MULTICAST_ALL=0 for DatagramChannels on Linux which is supported since kernel version 2.6.31 (http://man7.org/linux/man-pages/man7/ip.7.html). With JDK8 binding to different addresses on the same machine, the processes are not going to receive each other's messages. Some further reading: https://bugzilla.redhat.com/show_bug.cgi?id=231899 http://marc.info/?l=linux-netdev&m=121579002105636&w=2 > Multicast discovery does not work on JDK8 > ----------------------------------------- > > Key: JGRP-1878 > URL: https://issues.jboss.org/browse/JGRP-1878 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.2.12, 3.5 > Environment: OpenJDK8, OracleJDK8u40 > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Priority: Minor > Fix For: 3.2.14, 3.6 > > Attachments: mcast.java > > > Multicast discovery does not work on JDK8 when using different bind IP addresses. This blocks EAP certification on JDK8. > Steps to reproduce with draw, switch to JDK8: > {noformat} > export IP_ADDR=127.0.0.1 > ./draw.sh > export IP_ADDR=192.168.1.10 > ./draw.sh > {noformat} > Everything works when binding to the same IP address or using JDK 6 or 7. Possibly a JDK8 bug.. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-3779) IllegalAccessException when a built-in normal-scoped bean defines a package-private no-arg constructor

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3779?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-3779: ----------------------------------------------- Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 1138192|https://bugzilla.redhat.com/show_bug.cgi?id=1138192] from NEW to MODIFIED > IllegalAccessException when a built-in normal-scoped bean defines a package-private no-arg constructor > ------------------------------------------------------------------------------------------------------ > > Key: WFLY-3779 > URL: https://issues.jboss.org/browse/WFLY-3779 > Project: WildFly > Issue Type: Bug > Components: CDI / Weld > Reporter: Jozef Hartinger > Assignee: Jozef Hartinger > Fix For: 8.2.0.CR1, 9.0.0.Beta1 > > -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-838) Can't get implementing classname for JSR77 MBean

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-838?page=com.atlassian.jira.plugin.s... ] RH Bugzilla Integration commented on WFLY-838: ---------------------------------------------- Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 1138595|https://bugzilla.redhat.com/show_bug.cgi?id=1138595] from POST to MODIFIED > Can't get implementing classname for JSR77 MBean > ------------------------------------------------ > > Key: WFLY-838 > URL: https://issues.jboss.org/browse/WFLY-838 > Project: WildFly > Issue Type: Bug > Components: JMX > Reporter: Anders Welen > Priority: Minor > Fix For: Awaiting Volunteers > > > The following exception are thrown when asking the MBean server for the classname implementing "jboss.jsr77:j2eeType=WebModule,name=MyWar.war,J2EEServer=default". > It should be a legal call. Why are the code clearly states it's illegal? > > java.lang.IllegalStateException: JBAS019905: Should not get called > at org.jboss.as.jsr77.managedobject.J2EEDeployedObjectHandlers$J2EEModuleHandler.queryObjectNames(J2EEDeployedObjectHandlers.java:245) > at org.jboss.as.jsr77.managedobject.BaseHandler.getMBeanInfo(BaseHandler.java:64) > at org.jboss.as.jsr77.managedobject.J2EEDeployedObjectHandlers.getMBeanInfo(J2EEDeployedObjectHandlers.java:147) > at org.jboss.as.jsr77.managedobject.ManagedObjectHandlerRegistry.getMBeanInfo(ManagedObjectHandlerRegistry.java:112) > at org.jboss.as.jsr77.subsystem.JSR77ManagementMBeanServer.getMBeanInfo(JSR77ManagementMBeanServer.java:179) > at org.jboss.as.jmx.PluggableMBeanServerImpl.getMBeanInfo(PluggableMBeanServerImpl.java:212) > > The error can easily be triggered by using JConsole to browse the same MBean. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-87) Display deployment timestamp

by Claudio Miranda (JIRA)

[ https://issues.jboss.org/browse/WFCORE-87?page=com.atlassian.jira.plugin.... ] Claudio Miranda commented on WFCORE-87: --------------------------------------- PR sent see the CLI output {code} [standalone@localhost:9990 /] /deployment=jboss-helloworld.war:read-resource { "outcome" => "success", "result" => { "content" => [{"hash" => bytes { 0x20, 0x18, 0x2d, 0xaf, 0x53, 0x1c, 0x60, 0xc3, 0xcc, 0x94, 0x83, 0xec, 0xfe, 0x7a, 0x02, 0x01, 0x23, 0x58, 0x34, 0x4d }}], "disabled-time" => 1410046635766L, "disabled-timestamp" => "2014-09-06 20:37:15,766 BRT", "enabled" => false, "enabled-time" => 1410046608131L, "enabled-timestamp" => "2014-09-06 20:36:48,131 BRT", "name" => "jboss-helloworld.war", "persistent" => false, "runtime-name" => "jboss-helloworld.war", "subdeployment" => undefined, "subsystem" => undefined } } {code} read-resource-description {code} "enabled-timestamp" => { "type" => STRING, "description" => "Last timestamp the application was enabled. Format is yyyy-MM-dd HH:mm:ss,SSS zzz.", "expressions-allowed" => false, "nillable" => false, "min-length" => 1L, "max-length" => 2147483647L, "access-type" => "read-only", "storage" => "configuration" }, "disabled-timestamp" => { "type" => STRING, "description" => "Last timestamp the application was disabled. Format is yyyy-MM-dd HH:mm:ss,SSS zzz.", "expressions-allowed" => false, "nillable" => false, "min-length" => 1L, "max-length" => 2147483647L, "access-type" => "read-only", "storage" => "configuration" }, "enabled-time" => { "type" => LONG, "description" => "Last time the application was enabled", "expressions-allowed" => false, "nillable" => false, "min" => 1L, "max" => 2147483647L, "access-type" => "read-only", "storage" => "configuration" }, "disabled-time" => { "type" => LONG, "description" => "Last time the application was disabled", "expressions-allowed" => false, "nillable" => false, "min" => 1L, "max" => 2147483647L, "access-type" => "read-only", "storage" => "configuration" }, {code} > Display deployment timestamp > ---------------------------- > > Key: WFCORE-87 > URL: https://issues.jboss.org/browse/WFCORE-87 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Affects Versions: 1.0.0.Alpha5 > Reporter: Claudio Miranda > Assignee: Brian Stansberry > Priority: Minor > > Display the deployment timestamp, that is the date of last modified deployment. It is useful for users to see the date and time of deployments. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-3823) Memory leak with EJB Timer service

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-3823?page=com.atlassian.jira.plugin.... ] Stuart Douglas reassigned WFLY-3823: ------------------------------------ Assignee: Stuart Douglas (was: David Lloyd) > Memory leak with EJB Timer service > ---------------------------------- > > Key: WFLY-3823 > URL: https://issues.jboss.org/browse/WFLY-3823 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 8.1.0.Final > Environment: Windows 8.1 64bit, Java 1.7.0_40-b43 > Reporter: Matus Zamborsky > Assignee: Stuart Douglas > > There is a memory leak during undeploy (redeploy) when there is a timer used in EJB bean. > When the timer is created (using @Schedule or programmatically), it is put in queue on Timer thread. According to JDK sources (http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/7u... line 552) The queue is processed if new timer is created or the next timer task is due to be run and the reference to last timer is retained on stack (line 521). Therefore after the module undeploy there is still a reference to TimerTask from the module. > It is not a true memory leak, because the reference will be removed when the task is due, but in environment with many redeploys (development and continuous integration) will soon hit the java.lang.OutOfMemoryError: PermGen space. > One workaround is to have another Scheduler, which will schedule job for every second. This way, the timer thread will process the queue and throw away the reference to last timerTask. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 1 month

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira September 2014