September 2009 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBID-191) Release JBoss Identity Federation 1.0.0.beta2

by Anil Saldhana (JIRA)

Release JBoss Identity Federation 1.0.0.beta2 --------------------------------------------- Key: JBID-191 URL: https://jira.jboss.org/jira/browse/JBID-191 Project: JBoss Identity Issue Type: Release Components: Identity-Federation Reporter: Anil Saldhana Assignee: Anil Saldhana Fix For: IDFED-1.0.0.beta2 -- 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

16 years, 10 months

1
1
0 / 0

[JBoss JIRA] Created: (EJBTHREE-1918) CLONE -NPE on client invoking remote SFSB method during shutdown

by Radoslav Husar (JIRA)

CLONE -NPE on client invoking remote SFSB method during shutdown ---------------------------------------------------------------- Key: EJBTHREE-1918 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1918 Project: EJB 3.0 Issue Type: Bug Components: Clustering, core Affects Versions: 1.1.13 Reporter: Radoslav Husar Assignee: Carlo de Wolf Priority: Critical Scenario encountered during clustered REPL_ASYNC sfsb clean failover testing: Exception occurs just after shutdown is initiated on target node. java.lang.NullPointerException at org.jboss.cache.Fqn.<init>(Fqn.java:218) at org.jboss.cache.Fqn.<init>(Fqn.java:184) at org.jboss.ejb3.cache.tree.StatefulTreeCache.getFqn(StatefulTreeCache.java:579) at org.jboss.ejb3.cache.tree.StatefulTreeCache.get(StatefulTreeCache.java:154) at org.jboss.ejb3.cache.tree.StatefulTreeCache.get(StatefulTreeCache.java:148) at org.jboss.ejb3.stateful.StatefulContainer.dynamicInvoke(StatefulContainer.java:556) at org.jboss.ejb3.session.InvokableContextClassProxyHack._dynamicInvoke(InvokableContextClassProxyHack.java:53) at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:91) at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82) at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891) at org.jboss.remoting.transport.socket.ServerThread.completeInvocation(ServerThread.java:744) at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:697) at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:551) at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:232) at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:211) at org.jboss.remoting.Client.invoke(Client.java:1724) at org.jboss.remoting.Client.invoke(Client.java:629) at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) at org.jboss.aspects.remoting.ClusterChooserInterceptor.invoke(ClusterChooserInterceptor.java:84) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) at org.jboss.aspects.tx.ClientTxPropagationInterceptor.invoke(ClientTxPropagationInterceptor.java:61) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) at org.jboss.ejb3.security.client.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) at org.jboss.ejb3.remoting.ClusteredIsLocalInterceptor.invoke(ClusteredIsLocalInterceptor.java:54) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) at org.jboss.aspects.remoting.PojiProxy.invoke(PojiProxy.java:62) at $Proxy4.invoke(Unknown Source) at org.jboss.ejb3.proxy.impl.handler.session.SessionProxyInvocationHandlerBase.invoke(SessionProxyInvocationHandlerBase.java:207) at org.jboss.ejb3.proxy.impl.handler.session.SessionProxyInvocationHandlerBase.invoke(SessionProxyInvocationHandlerBase.java:164) at $Proxy3.getSerial(Unknown Source) at org.jboss.smartfrog.ejb3.as5.SFSBProcessorFactoryImpl$EJB3RequestProcessor.processRequest(SFSBProcessorFactoryImpl.java:72) at org.jboss.smartfrog.loaddriver.CompoundRequestProcessorFactoryImpl$CompoundRequestProcessor.processRequest(CompoundRequestProcessorFactoryImpl.java:33) at org.jboss.smartfrog.loaddriver.Runner.run(Runner.java:89) at java.lang.Thread.run(Thread.java:619) at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) at org.jboss.aspects.remoting.ClusterChooserInterceptor.invoke(ClusterChooserInterceptor.java:84) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) at org.jboss.aspects.tx.ClientTxPropagationInterceptor.invoke(ClientTxPropagationInterceptor.java:61) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) at org.jboss.ejb3.security.client.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) at org.jboss.ejb3.remoting.ClusteredIsLocalInterceptor.invoke(ClusteredIsLocalInterceptor.java:54) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) at org.jboss.aspects.remoting.PojiProxy.invoke(PojiProxy.java:62) at $Proxy4.invoke(Unknown Source) at org.jboss.ejb3.proxy.impl.handler.session.SessionProxyInvocationHandlerBase.invoke(SessionProxyInvocationHandlerBase.java:207) at org.jboss.ejb3.proxy.impl.handler.session.SessionProxyInvocationHandlerBase.invoke(SessionProxyInvocationHandlerBase.java:164) at $Proxy3.getSerial(Unknown Source) at org.jboss.smartfrog.ejb3.as5.SFSBProcessorFactoryImpl$EJB3RequestProcessor.processRequest(SFSBProcessorFactoryImpl.java:72) at org.jboss.smartfrog.loaddriver.CompoundRequestProcessorFactoryImpl$CompoundRequestProcessor.processRequest(CompoundRequestProcessorFactoryImpl.java:33) at org.jboss.smartfrog.loaddriver.Runner.run(Runner.java:89) at java.lang.Thread.run(Thread.java:619) The NPE occurs when the Fqn created in StatefulTreeCache.getFqn(...) tries to create an Fqn with a null cacheNode. The reference to cacheNode is created in StatefulTreeCache.start(), and is not dereferenced anywhere, so the NPE indicates that the Cache instance used in dynamicInvoke(...) was never started. Interestingly the Cache instances used in dynamicInvoke(...) are always obtained via StatefulContainer.getCache(), which lazily creates and starts the container's cache if it either does not yet exist or is not started. At first glance, it would appear that the cache returned by getCache() should always be started. The problem, I think, is a concurrency issue with getCache() that occurs when multiple remote requests on the container reach dynamicInvoke(...) when a shutdown is in progress. So how can StatefulContainer.getCache() return a cache that was never started? Here's a possible scenario: * Container shutdown initiated, cache is stopped. * Asynchronous replication from a previous invocation kicks in calling StatefulContainer.getCache(). Due to lazy loading in getCache(), this causes a new cache to be created and started (BAD) * A second remote invocation reaches StatefulContainer.dynamicInvoke(Invocation) and simultaneously calls StatefulContainer.getCache(). * Either thread may end up returning a new instance of a cache that has not yet started, since the cache validated as started by StatefulContainer.createAndStartCache() may not necessarily be the same instance that is returned by the getCache() 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

16 years, 10 months

1
1
0 / 0

[JBoss JIRA] Created: (JBID-152) IDP should return attributes of caller such as email address

by Anil Saldhana (JIRA)

IDP should return attributes of caller such as email address ------------------------------------------------------------ Key: JBID-152 URL: https://jira.jboss.org/jira/browse/JBID-152 Project: JBoss Identity Issue Type: Feature Request Components: Identity-Federation Reporter: Anil Saldhana Assignee: Anil Saldhana Fix For: IDFED-1.0.0.beta1 The IDP should be configurable to return attributes of the subject such as email address etc that can be read from DB, LDAP etc. This feature will require attribute providers to be plugged in. -- 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

16 years, 10 months

1
2
0 / 0

[JBoss JIRA] Created: (JBAS-7252) Upgrade JBoss LogManager to 1.1.0.GA

by David Lloyd (JIRA)

Upgrade JBoss LogManager to 1.1.0.GA ------------------------------------ Key: JBAS-7252 URL: https://jira.jboss.org/jira/browse/JBAS-7252 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: David Lloyd -- 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

16 years, 10 months

1
2
0 / 0

[JBoss JIRA] Created: (JBJCA-168) Papaki 1.0.0.Beta1

by Jesper Pedersen (JIRA)

Papaki 1.0.0.Beta1 ------------------ Key: JBJCA-168 URL: https://jira.jboss.org/jira/browse/JBJCA-168 Project: JBoss JCA Issue Type: Component Upgrade Components: Build Reporter: Jesper Pedersen Assignee: Jesper Pedersen Fix For: 1.0.0.Alpha4 -- 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

16 years, 10 months

1
1
0 / 0

[JBoss JIRA] Created: (JBANN-37) Papaki 1.0.0.Beta2

by Jesper Pedersen (JIRA)

Papaki 1.0.0.Beta2 ------------------ Key: JBANN-37 URL: https://jira.jboss.org/jira/browse/JBANN-37 Project: Papaki Issue Type: Release Components: Build Reporter: Jesper Pedersen Assignee: Jesper Pedersen Fix For: 1.0.0.Beta2 -- 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

16 years, 10 months

1
2
0 / 0

[JBoss JIRA] Created: (JBANN-36) Support scanning directories

by Jesper Pedersen (JIRA)

Support scanning directories ---------------------------- Key: JBANN-36 URL: https://jira.jboss.org/jira/browse/JBANN-36 Project: Papaki Issue Type: Task Components: Core Reporter: Jesper Pedersen Assignee: Jesper Pedersen Fix For: 1.0.0.Beta2 Support scanning directories for .class files -- 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

16 years, 10 months

1
1
0 / 0

[JBoss JIRA] Created: (JBAS-7240) DataVersioningException when using EJB3 entities with OPTIMISTIC caching

by Dennis Reed (JIRA)

DataVersioningException when using EJB3 entities with OPTIMISTIC caching ------------------------------------------------------------------------ Key: JBAS-7240 URL: https://jira.jboss.org/jira/browse/JBAS-7240 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: EJB3 Affects Versions: JBossAS-4.2.3.GA Reporter: Dennis Reed Assignee: Dennis Reed Fix For: JBossAS-Branch_4_2 org.jboss.ejb3.entity.OptimisticJBCCache.DataVersionAdapter.newerThan incorrectly returns true for A.newerThan ( A ). This causes JBoss Cache to throw a DataVersioningException when trying to remove the entry from the cache. -- 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

16 years, 10 months

1
1
0 / 0

[JBoss JIRA] Created: (JBREM-1154) Client.connect() should throw an exception when Lease creation fails

by Ron Sigal (JIRA)

Client.connect() should throw an exception when Lease creation fails -------------------------------------------------------------------- Key: JBREM-1154 URL: https://jira.jboss.org/jira/browse/JBREM-1154 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.2.3, 2.5.1 (Flounder) Reporter: Ron Sigal Assignee: Ron Sigal Fix For: 2.5.2 (Flounder), 2.2.3.SP1 When any of the versions of org.jboss.remoting.Client.connect() is called, it will try, if leasing is enabled, to register the Client with an org.jboss.remoting.Lease on the server side. Client.connect() calls org.jboss.remoting.MicroRemoteClientInvoker.establishLease(), which calls org.jboss.remoting.LeasePinger.addClient(), which calls LeasePinger.sendClientPing(), which sends to the server the Clients it represents. If LeasePinger.sendClientPing() fails, it just logs a message and swallows the exception. That behavior is appropriate when sendClientPing() is just sending an ordinary PING, but if the attempt to register a new Client fails, the call to Client.connect() should fail. -- 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

16 years, 10 months

1
3
0 / 0

[JBoss JIRA] Deleted: (JGRP-1048) FC: change semantics of min_threshold

by Bela Ban (JIRA)

[ https://jira.jboss.org/jira/browse/JGRP-1048?page=com.atlassian.jira.plug... ] Bela Ban deleted JGRP-1048: --------------------------- > FC: change semantics of min_threshold > ------------------------------------- > > Key: JGRP-1048 > URL: https://jira.jboss.org/jira/browse/JGRP-1048 > Project: JGroups > Issue Type: Task > Reporter: Bela Ban > Assignee: Bela Ban > > FC.max_credits=1000000,min_threshold=0.2: > This means that when a receiver's credits for a sender drop below 800'000 bytes, the receiver will send 200'000 bytes to the sender. This can be misleading because one might think min_threshold means the number of bytes *remaining* after which to send new credits. > We need to either change the semantics of min_threshold, or introduce a new property. -- 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

16 years, 10 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 September 2009