March 2013 - jboss-jira - Jboss List Archives

[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

13 years, 4 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

13 years, 4 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

13 years, 4 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

13 years, 4 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

13 years, 4 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

13 years, 4 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 commented on AS7-6121: ---------------------------------- 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

13 years, 4 months

1
0
0 / 0

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

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/AS7-6121?page=com.atlassian.jira.plugin.s... ] Brian Stansberry commented on AS7-6121: --------------------------------------- David, that's from the naming subsystem config. > 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

13 years, 4 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 commented on AS7-6121: ---------------------------------- [~jameslivingston] - what XML are you quoting in the description? Is that from some deployment descriptor? > 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

13 years, 4 months

1
0
0 / 0

[JBoss JIRA] (AS7-6306) Validate composite operation steps just before executing them

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/AS7-6306?page=com.atlassian.jira.plugin.s... ] Brian Stansberry commented on AS7-6306: --------------------------------------- Yes, we roll back. I wasn't clear in the description. In all cases, the various steps are all steps within the same overall operation execution. So failure of any step triggers rollback. > Validate composite operation steps just before executing them > ------------------------------------------------------------- > > Key: AS7-6306 > URL: https://issues.jboss.org/browse/AS7-6306 > Project: Application Server 7 > Issue Type: Enhancement > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Brian Stansberry > > Say we have a composite operation with 2 steps: > 1) /extension=org.jboss.as.messaging:add > 2) /subsystem=messaging:add > This will fail: > Failed to execute batch: JBAS014739: No handler for add at address > [("subsystem" => "messaging")] > This fails because at the time of validation the /subsystem=messaging:add is not valid. > To illustrate, the execution order is > Validate 1-2 > 1 > 2 > A possible solution is to convert this to the following: > V1 > 1 > V2 (works now because 1 has registered the subsystem API) > 2 > I think that should work but it's a very complex area, particularly in a managed domain, so it's not at all certain this would prove feasible. -- 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

13 years, 4 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 March 2013