January 2013 - jboss-jira - Jboss List Archives

[JBoss JIRA] (AS7-6411) Cygwin, add-user.sh and error "JBAS015232: Aucune java.io.Console disponible pour interagir avec l'utilisateur."

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/AS7-6411?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse updated AS7-6411: ---------------------------------- Fix Version/s: 7.3.0.Alpha1 > Cygwin, add-user.sh and error "JBAS015232: Aucune java.io.Console disponible pour interagir avec l'utilisateur." > ---------------------------------------------------------------------------------------------------------------- > > Key: AS7-6411 > URL: https://issues.jboss.org/browse/AS7-6411 > Project: Application Server 7 > Issue Type: Bug > Components: Domain Management, Security > Affects Versions: 7.1.3.Final (EAP) > Environment: Windows XP with CYGWIN_NT-5.1 ... 1.7.17 (0.262/5/3) 2012-10-19 i686 > Java HotSpot 1.7.0_11, RE build 1.7.0_11-b21, Client VM build 23.6-b04, mixed mode > JBoss AS 7.1.3.Final > Reporter: Bernard Giroud > Assignee: Darran Lofthouse > Labels: as7, management > Fix For: 7.3.0.Alpha1 > > > First of all, the add-user.sh script has an invalid syntax on line 14 which reads: > {code} > cygwin = true; > {code} > It should read: > {code} > cygwin=true; > {code} > without spaces around the equal sign, Otherwise the truth value is not set, and the conversion back to Windows pathes is not done. > Furthermore, the back-conversions should be conditioned to avoid a "cygpath: can't convert empty path" in lines 56-60, especially with JAVA_HOME. > Finally, issuance of the following command : bin/add-user.sh u p > Gives: > {noformat} > cygpath: can't convert empty path > Exception in thread "main" java.lang.IllegalStateException: JBAS015232: Aucune java.io.Console disponible pour interagir avec l'utilisateur. > at org.jboss.as.domain.management.security.AddPropertiesUser.<init>(AddPropertiesUser.java:107) > at org.jboss.as.domain.management.security.AddPropertiesUser.<init>(AddPropertiesUser.java:118) > at org.jboss.as.domain.management.security.AddPropertiesUser.main(AddPropertiesUser.java:166) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) > at java.lang.reflect.Method.invoke(Unknown Source) > at org.jboss.modules.Module.run(Module.java:270) > at org.jboss.modules.Main.main(Main.java:294) > {noformat} > Issuance of the following command : bin/add-user.sh > Gives: > {noformat} > cygpath: can't convert empty path > Exception in thread "main" java.lang.IllegalStateException: JBAS015232: Aucune java.io.Console disponible pour interagir avec l'utilisateur. > at org.jboss.as.domain.management.security.AddPropertiesUser.<init>(AddPropertiesUser.java:78) > at org.jboss.as.domain.management.security.AddPropertiesUser.main(AddPropertiesUser.java:168) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) > at java.lang.reflect.Method.invoke(Unknown Source) > at org.jboss.modules.Module.run(Module.java:270) > at org.jboss.modules.Main.main(Main.java:294) > {noformat} > Option --silent doesn't make a difference. > An obvious workaround exists though: use with a CMD windows > {noformat} > bin\add-user.bat u p > {noformat} -- 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, 5 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1572) TP.sendToAllPhysicalAddresses does not handle singleton TP

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JGRP-1572?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated JGRP-1572: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=905387 > TP.sendToAllPhysicalAddresses does not handle singleton TP > ---------------------------------------------------------- > > Key: JGRP-1572 > URL: https://issues.jboss.org/browse/JGRP-1572 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.2.6 > Reporter: Radim Vansa > Assignee: Bela Ban > > Method {{TP.sendToAllPhysicalAddresses}} does not handle correctly TP being singleton, on line 1419 it calls directly up_prot.up(...) instead of up(...) which can handle multiple stacks based on this TP. > Result is NPE. -- 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, 5 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1572) TP.sendToAllPhysicalAddresses does not handle singleton TP

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JGRP-1572?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on JGRP-1572: ----------------------------------------------- Radim Vansa <rvansa(a)redhat.com> made a comment on [bug 905387|https://bugzilla.redhat.com/show_bug.cgi?id=905387] Method TP.sendToAllPhysicalAddresses does not handle correctly TP being singleton, on line 1419 it calls directly up_prot.up(...) instead of up(...) which can handle multiple stacks based on this TP. Result is NPE. Due to this error inserting record into __hotrodTopologyCache occasionally fails. > TP.sendToAllPhysicalAddresses does not handle singleton TP > ---------------------------------------------------------- > > Key: JGRP-1572 > URL: https://issues.jboss.org/browse/JGRP-1572 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.2.6 > Reporter: Radim Vansa > Assignee: Bela Ban > > Method {{TP.sendToAllPhysicalAddresses}} does not handle correctly TP being singleton, on line 1419 it calls directly up_prot.up(...) instead of up(...) which can handle multiple stacks based on this TP. > Result is NPE. -- 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, 5 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1572) TP.sendToAllPhysicalAddresses does not handle singleton TP

by Radim Vansa (JIRA)

Radim Vansa created JGRP-1572: --------------------------------- Summary: TP.sendToAllPhysicalAddresses does not handle singleton TP Key: JGRP-1572 URL: https://issues.jboss.org/browse/JGRP-1572 Project: JGroups Issue Type: Bug Affects Versions: 3.2.6 Reporter: Radim Vansa Assignee: Bela Ban Method {{TP.sendToAllPhysicalAddresses}} does not handle correctly TP being singleton, on line 1419 it calls directly up_prot.up(...) instead of up(...) which can handle multiple stacks based on this TP. Result is NPE. -- 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, 5 months

1
0
0 / 0

[JBoss JIRA] (AS7-6365) Hibernate/Infinispan 2nd Level Caches set to transaction-mode=NONE stop functioning after an explicit eviction

by Fredrik Lagerblad (JIRA)

[ https://issues.jboss.org/browse/AS7-6365?page=com.atlassian.jira.plugin.s... ] Fredrik Lagerblad updated AS7-6365: ----------------------------------- Issue Type: Bug (was: Feature Request) > Hibernate/Infinispan 2nd Level Caches set to transaction-mode=NONE stop functioning after an explicit eviction > -------------------------------------------------------------------------------------------------------------- > > Key: AS7-6365 > URL: https://issues.jboss.org/browse/AS7-6365 > Project: Application Server 7 > Issue Type: Bug > Components: JPA / Hibernate > Affects Versions: 7.1.3.Final (EAP) > Reporter: Fredrik Lagerblad > Assignee: Scott Marlow > > The caches in the 'infinispan' subsystem configured with <transaction mode="NONE"/> get stuck in state= CLEARING when you perform a programmatic evict() on them to clear the caches. (Using e.g. em.getEntityManagerFactory().getCache().evictAll() ) > > The problem seem to lie within the class 'org.hibernate.cache.infinispan.impl.BaseRegion, where the 'checkValid' method fails to clear the cache (and set back the state to VALID). The reason it fails is due to that it calls: cacheAdapter.withinTx() , which in turn tries to get the TransactionManager from the cache (which seems to be null for these non-transactional caches), and then NPEs on the tm.begin(); The NPE is caught and logs out "Could not invalidate region: null", and never set the state in VALID. So from thereon the caches are in an Invalid state and is not used anymore by Infinispan, thus leading to much performance. -- 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, 5 months

1
0
0 / 0

[JBoss JIRA] (AS7-6414) Management Console - LDAP authentication fails

by narayana b (JIRA)

narayana b created AS7-6414: ------------------------------- Summary: Management Console - LDAP authentication fails Key: AS7-6414 URL: https://issues.jboss.org/browse/AS7-6414 Project: Application Server 7 Issue Type: Bug Environment: JBoss 7.1.1 on windows xp 32 / jboss 7.1.2 on cent os 6.3, x86_64, standalone.xml Reporter: narayana b 1) security realms  <security-realm name="my_Ldap_Realm"> <authentication> <ldap connection="my_Ldap_Connection" base-dn="dc=example,dc=com"> <username-filter attribute="sAMAccountName"/>  </ldap> </authentication> </security-realm>  2) outbound connections  <outbound-connections> <ldap name="my_Ldap_Connection" url="ldap://localhost:10389/" search-dn="cn=jboss,ou=People,dc=example,dc=com" search-credential="admin123" /> </outbound-connections>  3) Management console info config  <native-interface security-realm="my_Ldap_Realm"> <socket-binding native="management-native"/> </native-interface> <http-interface security-realm="my_Ldap_Realm"> <socket-binding http="management-http"/>  </http-interface>  -- 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, 5 months

1
0
0 / 0

[JBoss JIRA] (JBWEB-261) All http threads spin indefinetly consuming ~100% CPU

by sivaraman saminathan (JIRA)

[ https://issues.jboss.org/browse/JBWEB-261?page=com.atlassian.jira.plugin.... ] sivaraman saminathan updated JBWEB-261: --------------------------------------- Summary: All http threads spin indefinetly consuming ~100% CPU (was: All http threads spin indefinetely consuming ~100% CPU) > All http threads spin indefinetly consuming ~100% CPU > ----------------------------------------------------- > > Key: JBWEB-261 > URL: https://issues.jboss.org/browse/JBWEB-261 > Project: JBoss Web > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Tomcat > Affects Versions: JBossWeb-2.1.3.GA > Environment: My issue happened on Solaris 10, JRE 1.6_26 & Jboss 5.1 > Reporter: sivaraman saminathan > Assignee: Remy Maucherat > Priority: Critical > > All http threads spin madly in a java.util.HashMap.getEntry indefinitely consuming 100% CPU. This issue is already reported and fixed in tomcat. > https://issues.apache.org/bugzilla/show_bug.cgi?id=50138 > The issue has affected 2 times in our production systems and we had to restart the production systems to resolve the issue. > Please integrate this fix in Jboss web 2.1.x -- 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, 5 months

1
0
0 / 0

[JBoss JIRA] (JBWEB-261) All http threads spin indefinetely consuming ~100% CPU

by sivaraman saminathan (JIRA)

sivaraman saminathan created JBWEB-261: ------------------------------------------ Summary: All http threads spin indefinetely consuming ~100% CPU Key: JBWEB-261 URL: https://issues.jboss.org/browse/JBWEB-261 Project: JBoss Web Issue Type: Bug Security Level: Public (Everyone can see) Components: Tomcat Affects Versions: JBossWeb-2.1.3.GA Environment: My issue happened on Solaris 10, JRE 1.6_26 & Jboss 5.1 Reporter: sivaraman saminathan Assignee: Remy Maucherat Priority: Critical All http threads spin madly in a java.util.HashMap.getEntry indefinitely consuming 100% CPU. This issue is already reported and fixed in tomcat. https://issues.apache.org/bugzilla/show_bug.cgi?id=50138 The issue has affected 2 times in our production systems and we had to restart the production systems to resolve the issue. Please integrate this fix in Jboss web 2.1.x -- 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, 5 months

1
0
0 / 0

[JBoss JIRA] (AS7-6387) Improper error handling when attempting to remove a server-config with a running server

by Osamu Nagano (JIRA)

[ https://issues.jboss.org/browse/AS7-6387?page=com.atlassian.jira.plugin.s... ] Osamu Nagano commented on AS7-6387: ----------------------------------- HOW TO REPRODUCE: This is easy to reproduce using the default domain.xml/host.xml configuration of 7.1.3.Final (EAP 6.0.1). 1. Edit the host.xml so that all servers 'auto-start' to be 'false'. 2. Execute domain.sh. Only the process controller and the domain controller are started. 3. In the jboss-cli.sh, try to remove a server-config then you'll get the error. [domain@localhost:9999 /] /host=master/server-config=server-three:remove { "outcome" => "failed", "result" => { "outcome" => "failed", "failure-description" => "[core-service, path, server-config, system-property, jvm, interface]", "rolled-back" => true }, "rolled-back" => true } 4. If there are any running servers, the remove command succeeds as expected. [domain@localhost:9999 /] /host=master/server-config=server-one:start { "outcome" => "success", "result" => "STARTING" } [domain@localhost:9999 /] /host=master/server-config=server-three:remove { "outcome" => "success", "result" => {"outcome" => "success"} } > Improper error handling when attempting to remove a server-config with a running server > --------------------------------------------------------------------------------------- > > Key: AS7-6387 > URL: https://issues.jboss.org/browse/AS7-6387 > Project: Application Server 7 > Issue Type: Bug > Components: Domain Management > Affects Versions: 7.1.2.Final (EAP), 7.1.3.Final (EAP) > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Fix For: 7.2.0.Alpha1 > > > Trying to remove the config for server-one while it's still running produces an uninformative failure: > [domain@localhost:9999 /] /host=master/server-config=server-one:remove > { > "outcome" => "failed", > "result" => undefined, > "rolled-back" => true, > "server-groups" => undefined > } > An EAP 6 user reported a similar problem but with a different response: > [domain@localhost:9999 /] /host=xyz/server-config=as1:remove > { > "outcome" => "success", > "result" => { > "outcome" => "failed", > "failure-description" => "[core-service, path, server-config, system-property, jvm, interface]", > "rolled-back" => true > }, > "failure-description" => undefined > } -- 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, 5 months

1
0
0 / 0

[JBoss JIRA] (AS7-6413) Remove subsystem command in JGroups management api should remove existing stacks.

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/AS7-6413?page=com.atlassian.jira.plugin.s... ] Brian Stansberry commented on AS7-6413: --------------------------------------- It's perfectly valid to fail the remove() op in Stage.MODEL if children haven't been removed first. If cleaning up the runtime services proves troublesome to get done this week, failing the op is an option. > Remove subsystem command in JGroups management api should remove existing stacks. > --------------------------------------------------------------------------------- > > Key: AS7-6413 > URL: https://issues.jboss.org/browse/AS7-6413 > Project: Application Server 7 > Issue Type: Bug > Components: Clustering > Affects Versions: 7.2.0.Alpha1 > Reporter: Richard Achmatowicz > Assignee: Richard Achmatowicz > Fix For: 7.2.0.Alpha1 > > > The management command > {noformat} > /subsystem=jgroups:remove() > {noformat} > should check for existing stack children and remove their runtime services before removing its own runtime services. > Otherwise removing the JGroups subsystem, followed by adding it back in and creating a new stack with the same name will fail due to duplicate MSC services associated with the stack. > -- 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, 5 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 January 2013