May 2009 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBREM-1119) CLONE [JBREM-1113] - ServerInvokerCallbackHandlers leak when client doesn't shut down

by Ron Sigal (JIRA)

CLONE [JBREM-1113] - ServerInvokerCallbackHandlers leak when client doesn't shut down -------------------------------------------------------------------------------------- Key: JBREM-1119 URL: https://jira.jboss.org/jira/browse/JBREM-1119 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.5.0.SP2 (Flounder) , 2.2.2.SP11 Reporter: Ron Sigal Assignee: Ron Sigal Fix For: 2.5.1 (Flounder), 2.2.2.SP12 1. a. org.jboss.remoting.callback.ServerInvokerCallbackHandler is referenced by org.jboss.remoting.ServerInvoker and by the org.jboss.remoting.ConnectionNotifier, if any, created by ServerInvoker. b. ServerInvokerCallbackHandler is passed to org.jboss.remoting.ServerInvocationHandler.addListener(), so the application ServerInvocationHandler could also maintain a pointer to ServerInvokerCallbackHandler. If the application calls org.jboss.remoting.Client.removeListener(), then ServerInvoker will clean up its references to ServerInvokerCallbackHandler, and it will call ServerInvocationHandler.removeListener(), giving the application a chance to remove the reference it holds. However, if the connection from the client breaks, none of these things happen. 2. There needs to be a ServerInvokerCallbackHandler method that can be called by the application, by, for example, a ConnectionListener, which will cause the references to be removed by ServerInvoker and the applications ServerInvocationHandler. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 9 months

1
3
0 / 0

[JBoss JIRA] Created: (JBREM-1125) Test for IllegalStateException when calling Timer.schedule()

by Ron Sigal (JIRA)

Test for IllegalStateException when calling Timer.schedule() ------------------------------------------------------------ Key: JBREM-1125 URL: https://jira.jboss.org/jira/browse/JBREM-1125 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.5.1 (Flounder), 2.2.2.SP11 Reporter: Ron Sigal Assignee: Ron Sigal Fix For: 2.2.2.SP12, 2.5.2 (Flounder) When a java.util.Timer has not more TimerTasks in its queue, it can shut itself down, so that subsequent calls to Timer.schedule() will throw a java.lang.IllegalStateException. Therefore, all calls to Timer.schedule() should be inside a try/catch block that will catch IllegalStateExceptions and create a new Timer. Most of these calls in Remoting are already protected, but there are a couple that are not. In particuler, branch 2.2: ======== * org.jboss.remoting.detection.AbstractDetector.startHeartbeat() * org.jboss.remoting.util.TimerUtil.schedule() branch 2.x: ======== * org.jboss.remoting.detection.AbstractDetector.startHeartbeat() -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 9 months

2
3
0 / 0

[JBoss JIRA] Commented: (JBAS-2820) ClientLoginModule improperly clears SecurityAssociation stack in logout()

by William Newman (JIRA)

[ https://jira.jboss.org/jira/browse/JBAS-2820?page=com.atlassian.jira.plug... ] William Newman commented on JBAS-2820: -------------------------------------- I am seeing this problem in 4.2.2.GA. > ClientLoginModule improperly clears SecurityAssociation stack in logout() > ------------------------------------------------------------------------- > > Key: JBAS-2820 > URL: https://jira.jboss.org/jira/browse/JBAS-2820 > Project: JBoss Application Server > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Security > Affects Versions: JBossAS-4.0.4RC1 > Reporter: Luigi Putanesca > Assignee: Scott M Stark > Priority: Critical > Fix For: JBossAS-3.2.8.SP1, JBossAS-4.0.4.CR2, JBossAS-5.0.0.Beta1 > > > I found a problem with how the ClientLoginModule handles the SecurityAssociation stack. The problem appears under the following conditions: > 1. restoreloginidentity = true > 2. method calls are made through session bean interfaces. (this causes the stack to be pushed and later popped). > 3. there are multiple logins before a logout. > Summary: > Basically what happens is I login a user, call a session bean, login a second user, logout the second user, exit the session bean and expect to revert to original user. The original user should still be logged in but it isn't. The problem is this: the ClientLoginModule.logout() method always clears the SecurityAssociation stack and then restores the login identity by logging in again. This leaves stack out of sync and when the session bean call exits, the stack is popped again and the user removed when it really should still be there. > Here is a sequence of what happens with the stack during my scenario: > 1. Starting point. (Stack.size = 0) > 2. Login 1st user.User is set to SecurityAssociation and pushed to stack. (Stack.size = 1) > 3. Make call to session bean. User is pushed to stack again by AuthenticationInterceptor. (Stack.size = 2) > 4. Login 2nd user. User is set to SecurityAssociation and pushed to stack. (Stack.size = 3) > 5. Logout 2nd user. Stack is cleared. (Stack.size = 0) (THIS IS THE PROBLEM) > 6. 1st user is reset to SecurityAssociation and pushed to stack by the ClientLoginModule. (Stack.size = 1) > 7. exit call to session bean. 1st User is popped from stack by AuthenticationInterceptor. (Stack.size = 0) > 8. No user is logged in. > What should be happening is in Step 5, the stack should be popped not cleared. The end result in Step 8 should be one user in the stack. The only way I should end up with an empty stack is if I call logout again, which I didn't. > Here is the fix I put into the ClientLoginModule: > public boolean abort() throws LoginException { > /* Changed here. Only clear if not restoring identity. */ > if (restoreLoginIdentity) { > SecurityAssociation.popSubjectContext(); > } > else { > SecurityAssociation.clear(); > } > return true; > } > public boolean logout() throws LoginException { > /* Changed here. Only clear if not restoring identity. */ > if (restoreLoginIdentity) { > SecurityAssociation.popSubjectContext(); > } > else { > SecurityAssociation.clear(); > } > Set principals = subject.getPrincipals(); > principals.remove(loginPrincipal); > return true; > } -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 9 months

1
0
0 / 0

[JBoss JIRA] Created: (JBAS-6852) JBoss looses authentication information

by Brian unknown (JIRA)

JBoss looses authentication information --------------------------------------- Key: JBAS-6852 URL: https://jira.jboss.org/jira/browse/JBAS-6852 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: EJB3 Affects Versions: JBossAS-4.2.3.GA Environment: Windows xp Reporter: Brian unknown Assignee: Carlo de Wolf I created a loginContext to log in a user, which worked fine at first. It gave me a subject with principles. But after the method finished, JBoss lost the authentication info, so that next time I tried to access a secured jsp it redirected me to the log in page. I tested it with a form submitting to j_security_check, and it worked fine. It seems to only be a problem when submitting to a custom method. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 9 months

1
0
0 / 0

[JBoss JIRA] Created: (JBRULES-2010) multibyte characters in drl fails with "no viable alternative at character"

by Yusuke Yamamoto (JIRA)

multibyte characters in drl fails with "no viable alternative at character" --------------------------------------------------------------------------- Key: JBRULES-2010 URL: https://jira.jboss.org/jira/browse/JBRULES-2010 Project: JBoss Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-compiler Affects Versions: 5.0.0.M5, 5.0.0.M4, 5.0.0.M3, 5.0.0.M2, 5.0.0.M1, 4.0.7 Reporter: Yusuke Yamamoto Assignee: Mark Proctor When multi-byte characters are used for rule name, field name, or function name, compiler reports "no viable alternative at character". Additionally, multi-byte characters are normalized into "_" and compiler fails to differenciate names when their length are same. ------ org.drools.rule.InvalidRulePackage: Rule Compilation error : [Rule name=日本語ルール２, agendaGroup=MAIN, salience=0, no-loop=false] org/drools/compiler/Rule_________0.java (3:43) : The type Rule_________0 is already defined at org.drools.rule.Package.checkValidity(Package.java:424) at org.drools.common.AbstractRuleBase.addPackage(AbstractRuleBase.java:394) at org.drools.compiler.MultibyteDRLTest.executeTestFor(MultibyteDRLTest.java:90) at org.drools.compiler.MultibyteDRLTest.testmultibyteRuleName2(MultibyteDRLTest.java:78) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:40) ------- This issue is reproducible both on Drools 4.0.7 and 5.0.0. Drools Version: 5.0.0.CR1 , 4.0.7 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 9 months

2
5
0 / 0

[JBoss JIRA] Created: (JBRULES-2008) multibyte characters in dsl fails with "no viable alternative at character"

by Yusuke Yamamoto (JIRA)

multibyte characters in dsl fails with "no viable alternative at character" ---------------------------------------------------------------------------- Key: JBRULES-2008 URL: https://jira.jboss.org/jira/browse/JBRULES-2008 Project: JBoss Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-compiler Affects Versions: 5.0.0.M5, 5.0.0.M4, 5.0.0.M3, 5.0.0.M2, 5.0.0.M1 Environment: Drools 5.0.0.CR1 Reporter: Yusuke Yamamoto Assignee: Mark Proctor Drools compiler fails to compile DSLs containing multibyte characters in them, says "no viable alternative at character". ---------- line 3:6 no viable alternative at character '出' line 3:7 no viable alternative at character '力' java.lang.NullPointerException at org.drools.common.AbstractRuleBase.addPackages(AbstractRuleBase.java:451) at org.drools.reteoo.ReteooRuleBase.addPackage(ReteooRuleBase.java:481) at org.drools.compiler.MultibyteDSLTest.testMultibyteDSL(MultibyteDSLTest.java:20) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:40) ---------- http://lists.jboss.org/pipermail/rules-users/2009-March/008293.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 9 months

2
5
0 / 0

[JBoss JIRA] Created: (EJBTHREE-1817) Update endpoint-deployer to use jboss-aop-deployers

by Carlo de Wolf (JIRA)

Update endpoint-deployer to use jboss-aop-deployers --------------------------------------------------- Key: EJBTHREE-1817 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1817 Project: EJB 3.0 Issue Type: Thirdparty Change Components: endpoint-deployers Reporter: Carlo de Wolf -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 9 months

1
2
0 / 0

[JBoss JIRA] Created: (JBAS-6840) Upgrade JGroups to 2.6.10

by Brian Stansberry (JIRA)

Upgrade JGroups to 2.6.10 ------------------------- Key: JBAS-6840 URL: https://jira.jboss.org/jira/browse/JBAS-6840 Project: JBoss Application Server Issue Type: Component Upgrade Security Level: Public (Everyone can see) Components: Clustering Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: JBossAS-5.1.0.GA Should be released this evening (April 28). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 9 months

1
1
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira May 2009