March 2013 - jboss-jira - Jboss List Archives

[JBoss JIRA] (AS7-6664) Unable to turn on/off logging handlers using enable()/disable() in CLI

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/AS7-6664?page=com.atlassian.jira.plugin.s... ] RH Bugzilla Integration updated AS7-6664: ----------------------------------------- Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=915317 > Unable to turn on/off logging handlers using enable()/disable() in CLI > ---------------------------------------------------------------------- > > Key: AS7-6664 > URL: https://issues.jboss.org/browse/AS7-6664 > Project: Application Server 7 > Issue Type: Bug > Components: Domain Management, Logging > Affects Versions: 7.2.0.Alpha1 > Reporter: Brian Stansberry > Assignee: James Perkins > Fix For: 8.0.0.Alpha1 > > > Peter Kremens reports: > I am unable to use enable/disable operation in logging handlers. > > {code} > [standalone@localhost:9999 /] /subsystem=logging/console-handler=CONSOLE:read-resource > { > "outcome" => "success", > "result" => { > "autoflush" => true, > "enabled" => true, > ... > } > } > {code} > Calling disable() won't affect enabled attribute > {code} > [standalone@localhost:9999 /] /subsystem=logging/console-handler=CONSOLE:disable() > {"outcome" => "success"} > [standalone@localhost:9999 /] /subsystem=logging/console-handler=CONSOLE:read-resource > { > "outcome" => "success", > "result" => { > "autoflush" => true, > "enabled" => true, > ... > } > } > {code} > Must use write-attribute instead > {code} > [standalone@localhost:9999 /] /subsystem=logging/console-handler=CONSOLE/:write-attribute(name=enabled, value=false) > {"outcome" => "success"} > [standalone@localhost:9999 /] /subsystem=logging/console-handler=CONSOLE:read-resource > { > "outcome" => "success", > "result" => { > "autoflush" => true, > "enabled" => false, > ... > } > } > {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (AS7-6664) Unable to turn on/off logging handlers using enable()/disable() in CLI

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/AS7-6664?page=com.atlassian.jira.plugin.s... ] RH Bugzilla Integration commented on AS7-6664: ---------------------------------------------- Brian Stansberry <brian.stansberry(a)redhat.com> made a comment on [bug 915317|https://bugzilla.redhat.com/show_bug.cgi?id=915317] James, please assign bz 915317 to yourself. Thanks. > Unable to turn on/off logging handlers using enable()/disable() in CLI > ---------------------------------------------------------------------- > > Key: AS7-6664 > URL: https://issues.jboss.org/browse/AS7-6664 > Project: Application Server 7 > Issue Type: Bug > Components: Domain Management, Logging > Affects Versions: 7.2.0.Alpha1 > Reporter: Brian Stansberry > Assignee: James Perkins > Fix For: 8.0.0.Alpha1 > > > Peter Kremens reports: > I am unable to use enable/disable operation in logging handlers. > > {code} > [standalone@localhost:9999 /] /subsystem=logging/console-handler=CONSOLE:read-resource > { > "outcome" => "success", > "result" => { > "autoflush" => true, > "enabled" => true, > ... > } > } > {code} > Calling disable() won't affect enabled attribute > {code} > [standalone@localhost:9999 /] /subsystem=logging/console-handler=CONSOLE:disable() > {"outcome" => "success"} > [standalone@localhost:9999 /] /subsystem=logging/console-handler=CONSOLE:read-resource > { > "outcome" => "success", > "result" => { > "autoflush" => true, > "enabled" => true, > ... > } > } > {code} > Must use write-attribute instead > {code} > [standalone@localhost:9999 /] /subsystem=logging/console-handler=CONSOLE/:write-attribute(name=enabled, value=false) > {"outcome" => "success"} > [standalone@localhost:9999 /] /subsystem=logging/console-handler=CONSOLE:read-resource > { > "outcome" => "success", > "result" => { > "autoflush" => true, > "enabled" => false, > ... > } > } > {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (AS7-6664) Unable to turn on/off logging handlers using enable()/disable() in CLI

by Brian Stansberry (JIRA)

Brian Stansberry created AS7-6664: ------------------------------------- Summary: Unable to turn on/off logging handlers using enable()/disable() in CLI Key: AS7-6664 URL: https://issues.jboss.org/browse/AS7-6664 Project: Application Server 7 Issue Type: Bug Components: Domain Management, Logging Affects Versions: 7.2.0.Alpha1 Reporter: Brian Stansberry Assignee: James Perkins Fix For: 8.0.0.Alpha1 Peter Kremens reports: I am unable to use enable/disable operation in logging handlers. {code} [standalone@localhost:9999 /] /subsystem=logging/console-handler=CONSOLE:read-resource { "outcome" => "success", "result" => { "autoflush" => true, "enabled" => true, ... } } {code} Calling disable() won't affect enabled attribute {code} [standalone@localhost:9999 /] /subsystem=logging/console-handler=CONSOLE:disable() {"outcome" => "success"} [standalone@localhost:9999 /] /subsystem=logging/console-handler=CONSOLE:read-resource { "outcome" => "success", "result" => { "autoflush" => true, "enabled" => true, ... } } {code} Must use write-attribute instead {code} [standalone@localhost:9999 /] /subsystem=logging/console-handler=CONSOLE/:write-attribute(name=enabled, value=false) {"outcome" => "success"} [standalone@localhost:9999 /] /subsystem=logging/console-handler=CONSOLE:read-resource { "outcome" => "success", "result" => { "autoflush" => true, "enabled" => false, ... } } {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (AS7-6663) Usability issue: 'Reload' operation in CLI returns information that another reload is required

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/AS7-6663?page=com.atlassian.jira.plugin.s... ] RH Bugzilla Integration updated AS7-6663: ----------------------------------------- Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=900210 > Usability issue: 'Reload' operation in CLI returns information that another reload is required > ---------------------------------------------------------------------------------------------- > > Key: AS7-6663 > URL: https://issues.jboss.org/browse/AS7-6663 > Project: Application Server 7 > Issue Type: Bug > Components: Domain Management > Affects Versions: 7.1.2.Final (EAP), 7.1.3.Final (EAP), 7.2.0.Alpha1 > Reporter: Brian Stansberry > Priority: Minor > > Jan Martiska reported: > Assume a server reload is required.. then you do this: > {code} > [standalone@localhost:9999 /] :reload > { > "outcome" => "success", > "response-headers" => {"process-state" => "reload-required"} > } > {code} > I think it is quite confusing that "reload-required" is returned from 'reload' operation. (if you do more operations, it will not appear again, only once). Is it possible to fix it? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (AS7-6663) Usability issue: 'Reload' operation in CLI returns information that another reload is required

by Brian Stansberry (JIRA)

Brian Stansberry created AS7-6663: ------------------------------------- Summary: Usability issue: 'Reload' operation in CLI returns information that another reload is required Key: AS7-6663 URL: https://issues.jboss.org/browse/AS7-6663 Project: Application Server 7 Issue Type: Bug Components: Domain Management Affects Versions: 7.1.3.Final (EAP), 7.1.2.Final (EAP), 7.2.0.Alpha1 Reporter: Brian Stansberry Priority: Minor Jan Martiska reported: Assume a server reload is required.. then you do this: {code} [standalone@localhost:9999 /] :reload { "outcome" => "success", "response-headers" => {"process-state" => "reload-required"} } {code} I think it is quite confusing that "reload-required" is returned from 'reload' operation. (if you do more operations, it will not appear again, only once). Is it possible to fix it? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (AS7-6662) Batch scripts should show some error message when we set JAVA_HOME to nonexisting folder.

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/AS7-6662?page=com.atlassian.jira.plugin.s... ] RH Bugzilla Integration commented on AS7-6662: ---------------------------------------------- Brian Stansberry <brian.stansberry(a)redhat.com> made a comment on [bug 901242|https://bugzilla.redhat.com/show_bug.cgi?id=901242] Dev can devote some time to fixing this in 6.1 if it's important to PM. > Batch scripts should show some error message when we set JAVA_HOME to nonexisting folder. > ----------------------------------------------------------------------------------------- > > Key: AS7-6662 > URL: https://issues.jboss.org/browse/AS7-6662 > Project: Application Server 7 > Issue Type: Enhancement > Components: Scripts > Affects Versions: 7.1.2.Final (EAP), 7.1.3.Final (EAP), 7.2.0.Alpha1 > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Priority: Minor > Fix For: 8.0.0.Alpha1 > > > steps to reproduce: > ... > {code}jboss-eap-6.0\bin>set JAVA_HOME=c:\dummy > jboss-eap-6.0\bin>standalone.bat > Calling "W:\tmp\pk\jboss-eap-6.0\bin\standalone.conf.bat" > jboss-eap-6.0\bin>{code} > ... > batch script will end on this line (standalone.bat) > l:73 "%JAVA%" -client -version 2>&1 | findstr /I /C:"Client VM" > nul > On linux we get at least error message: > ./standalone.sh: line 178: /home/dummy/bin/java: No such file or directory -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (AS7-6662) Batch scripts should show some error message when we set JAVA_HOME to nonexisting folder.

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/AS7-6662?page=com.atlassian.jira.plugin.s... ] RH Bugzilla Integration updated AS7-6662: ----------------------------------------- Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=901242 > Batch scripts should show some error message when we set JAVA_HOME to nonexisting folder. > ----------------------------------------------------------------------------------------- > > Key: AS7-6662 > URL: https://issues.jboss.org/browse/AS7-6662 > Project: Application Server 7 > Issue Type: Enhancement > Components: Scripts > Affects Versions: 7.1.2.Final (EAP), 7.1.3.Final (EAP), 7.2.0.Alpha1 > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Priority: Minor > Fix For: 8.0.0.Alpha1 > > > steps to reproduce: > ... > {code}jboss-eap-6.0\bin>set JAVA_HOME=c:\dummy > jboss-eap-6.0\bin>standalone.bat > Calling "W:\tmp\pk\jboss-eap-6.0\bin\standalone.conf.bat" > jboss-eap-6.0\bin>{code} > ... > batch script will end on this line (standalone.bat) > l:73 "%JAVA%" -client -version 2>&1 | findstr /I /C:"Client VM" > nul > On linux we get at least error message: > ./standalone.sh: line 178: /home/dummy/bin/java: No such file or directory -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (AS7-6662) Batch scripts should show some error message when we set JAVA_HOME to nonexisting folder.

by Brian Stansberry (JIRA)

Brian Stansberry created AS7-6662: ------------------------------------- Summary: Batch scripts should show some error message when we set JAVA_HOME to nonexisting folder. Key: AS7-6662 URL: https://issues.jboss.org/browse/AS7-6662 Project: Application Server 7 Issue Type: Enhancement Components: Scripts Affects Versions: 7.1.3.Final (EAP), 7.1.2.Final (EAP), 7.2.0.Alpha1 Reporter: Brian Stansberry Assignee: Brian Stansberry Priority: Minor Fix For: 8.0.0.Alpha1 steps to reproduce: ... {code}jboss-eap-6.0\bin>set JAVA_HOME=c:\dummy jboss-eap-6.0\bin>standalone.bat Calling "W:\tmp\pk\jboss-eap-6.0\bin\standalone.conf.bat" jboss-eap-6.0\bin>{code} ... batch script will end on this line (standalone.bat) l:73 "%JAVA%" -client -version 2>&1 | findstr /I /C:"Client VM" > nul On linux we get at least error message: ./standalone.sh: line 178: /home/dummy/bin/java: No such file or directory -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-62) improve handling of subclasses of Spring transaction manager in SingleSessionCommandService.initTransactionManager(..)

by kgeis (JIRA)

kgeis created DROOLS-62: --------------------------- Summary: improve handling of subclasses of Spring transaction manager in SingleSessionCommandService.initTransactionManager(..) Key: DROOLS-62 URL: https://issues.jboss.org/browse/DROOLS-62 Project: Drools Issue Type: Enhancement Security Level: Public (Everyone can see) Affects Versions: 5.5 Reporter: kgeis Assignee: Mark Proctor SingleSessionCommandService.initTransactionManager(..) checks the transaction manager that is passed in to see if it is from the Spring Framework: {code} if ( tm != null && tm.getClass().getName().startsWith( "org.springframework" ) ) { {code} By checking the class by name, it misses the case of a subclass of a Spring transaction manager (e.g. org.codehaus.groovy.grails.orm.hibernate.GrailsHibernateTransactionManager which extends org.springframework.orm.hibernate3.HibernateTransactionManager.) It would have saved me some headache and it will save me a few lines of code if this code checks superclasses as well. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (AS7-6121) Naming subsystem <lookup> could use LinkRef/Reference

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/AS7-6121?page=com.atlassian.jira.plugin.s... ] David Lloyd edited comment on AS7-6121 at 3/1/13 5:07 PM: ---------------------------------------------------------- Aha OK. So I was discussing this with [~emmartins] and I think the best path would be to add a "<link>" tag to the subsystem config. It is my opinion that "<lookup>" should behave equivalently to <env-entry> with <lookup>, which is how this appears to behave today. was (Author: dmlloyd): Aha OK. So I was discussing this with [~emmartins] and I think the best path would be to add a "<link>" tag to the subsystem config. It is my opinion that "<lookup>" should behave equivalently to <env-entry>-with-<lookup>, which is how this appears to behave today. > Naming subsystem <lookup> could use LinkRef/Reference > ----------------------------------------------------- > > Key: AS7-6121 > URL: https://issues.jboss.org/browse/AS7-6121 > Project: Application Server 7 > Issue Type: Feature Request > Components: Naming > Affects Versions: 7.1.3.Final (EAP) > Reporter: James Livingston > Assignee: Eduardo Martins > Fix For: 7.2.0.Alpha1 > > > NameBindingAdd.installLookup() sets up the machinery so that when Context.lookup() is done it looks up the redirected name and returns it. > It should be possible to do that by binding a LinkRef, Reference or similar object into JNDI instead. > Where this could make a difference is when Context.lookupLink() is called instead. > Currently if you have > <simple name="java:/v" value="hello"/> > <lookup name="java:/a" lookup="java:/b"/> > lookupLink("java:/a") will return "hello" rather a LinkRef/Reference/whatever pointing to java:/b. > We need to decide whether a <lookup> should be considered a "link" for the purposes of lookup() or not. If it should be considered one, then we should change NameBindingAdd.installLookup() to make lookupLink() return the other value. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 2 months

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 March 2013