August 2006 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JGRP-283) VERIFY_SUSPECT: don't suspect yourself, send back a I_AM_ALIVE message and discard SUSPECT(self)

by Bela Ban (JIRA)

VERIFY_SUSPECT: don't suspect yourself, send back a I_AM_ALIVE message and discard SUSPECT(self) ------------------------------------------------------------------------------------------------ Key: JGRP-283 URL: http://jira.jboss.com/jira/browse/JGRP-283 Project: JGroups Issue Type: Bug Affects Versions: 2.3 SP1, 2.3, 2.2.9 SP3 (2.2.9.3), 2.2.9.2, 2.2.9.1, 2.2.9, 2.2.8 Reporter: Bela Ban Assigned To: Bela Ban Fix For: 2.4 VERIFY_SUSPECT should handle the case where it *itself* is suspected ! Solution: simply don't pass up the SUSPECT and send an I_AM_ALIVE message back to the sender -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 11 months

1
1
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-532) jboss-messaging.jar inappropriately packs service deployment descriptors

by Ovidiu Feodorov (JIRA)

jboss-messaging.jar inappropriately packs service deployment descriptors ------------------------------------------------------------------------ Key: JBMESSAGING-532 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-532 Project: JBoss Messaging Issue Type: Bug Affects Versions: 1.0.1.CR4 Reporter: Ovidiu Feodorov Assigned To: Ovidiu Feodorov Fix For: 1.0.1.CR5 jboss-messaging.jar contains various service deployment descriptors in root, and this breaks TCK. The jar must only contains classes and AOP descriptors. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 11 months

1
2
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-534) Create a new "messaging" subdirectory in repository.jboss.com and start uploading messaging artifacts there

by Ovidiu Feodorov (JIRA)

Create a new "messaging" subdirectory in repository.jboss.com and start uploading messaging artifacts there ----------------------------------------------------------------------------------------------------------- Key: JBMESSAGING-534 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-534 Project: JBoss Messaging Issue Type: Task Components: Build System Reporter: Ovidiu Feodorov Assigned To: Ovidiu Feodorov Fix For: 1.0.1.CR5 "messaging" is consistent with the naming convention used by all others JBoss sub-projects (microcontainer, remoting, etc) "jboss-messaging" it is a wrong name and the corresponding directory should go from repository. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 11 months

1
1
0 / 0

[JBoss JIRA] Closed: (JBCACHE-651) Node should not implement Externalizable

by Manik Surtani (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-651?page=all ] Manik Surtani closed JBCACHE-651. --------------------------------- Resolution: Done > Node should not implement Externalizable > ---------------------------------------- > > Key: JBCACHE-651 > URL: http://jira.jboss.com/jira/browse/JBCACHE-651 > Project: JBoss Cache > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Replication > Reporter: Brian Stansberry > Assigned To: Brian Stansberry > Priority: Minor > Fix For: 2.0.0 > > Original Estimate: 30 minutes > Remaining Estimate: 30 minutes > > Node (or whatever class replaces it in 2.0) does not need to implement Externalizable. The only reason it does now is to interoperate with 1.2.3 caches. That will not be possible in 2.0, so we should remove the Externalizable implementation. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 11 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBCACHE-318) CacheLoader persistent item should have an age limit

by Manik Surtani (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-318?page=all ] Manik Surtani updated JBCACHE-318: ---------------------------------- Fix Version/s: 2.1.0 (was: 2.0.0) > CacheLoader persistent item should have an age limit > ---------------------------------------------------- > > Key: JBCACHE-318 > URL: http://jira.jboss.com/jira/browse/JBCACHE-318 > Project: JBoss Cache > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Ben Wang > Assigned To: Ben Wang > Fix For: 2.1.0 > > Original Estimate: 2 weeks > Remaining Estimate: 2 weeks > > Currently items that are persisted has no notion of age out. So let's say it is fairly common in SFSB to have the state not live more than 2 weeks in the store, for example. The other usage is when the cache crashed and the persistent store won't get cleaned up even when the items are orphaned. > Bela refused to put this functionality in the cache loader layer. So Manik's idea is to wrap around the object in the CacheStoreInterceptor with an additional timestamp. This way an offline thread can come in and clean them. > We can also check how does the current SFSB does this? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 11 months

1
0
0 / 0

[JBoss JIRA] Commented: (JBSEAM-95) Have Seam handle "concurrent access to stateful bean" exceptions elegantly.

by Raja (JIRA)

[ http://jira.jboss.com/jira/browse/JBSEAM-95?page=comments#action_12341884 ] Raja commented on JBSEAM-95: ---------------------------- This also happened in a Stateful Bean where the producer and consumer of an event are in the same stateful bean. Once the event got fired, the Container started another thread for the consumer of the bean leading to the "concurrent access to stateful bean" > Have Seam handle "concurrent access to stateful bean" exceptions elegantly. > --------------------------------------------------------------------------- > > Key: JBSEAM-95 > URL: http://jira.jboss.com/jira/browse/JBSEAM-95 > Project: JBoss Seam > Issue Type: Feature Request > Components: JSF > Affects Versions: 1.0 beta 1 > Reporter: ryan dewell > > See the rejected issue: EJBTHREE-313 > This can be duplicated in the demo app (or any other app), by simply double clicking a commandLink/commandButton. If Seam could detect the double postback, and just ignore one of them, that would be ideal. Perhaps JSF 1.2 provides better postback detection handling? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 11 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBCACHE-254) Provide an efficient way to relocate a child Node

by Manik Surtani (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-254?page=all ] Manik Surtani updated JBCACHE-254: ---------------------------------- Fix Version/s: 2.1.0 (was: 2.0.0) Affects Version/s: 2.0.0 For 2.0.0, this is implemented internally as calls to TreeCache.remove(Fqn) and TreeCache.put(Fqn). For 2.1.0, this will be revisited to provide a more efficient internal relocating mechanism. > Provide an efficient way to relocate a child Node > ------------------------------------------------- > > Key: JBCACHE-254 > URL: http://jira.jboss.com/jira/browse/JBCACHE-254 > Project: JBoss Cache > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Affects Versions: 2.0.0 > Reporter: Ben Wang > Assigned To: Manik Surtani > Fix For: 2.1.0 > > > Can TreeCache provide an efficient to re-locate a child Node say from parent A to parent B? The only problem I see is the associated fqn name. I may need this feature in TreeCacheAop. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 11 months

1
0
0 / 0

[JBoss JIRA] Created: (JBCACHE-734) Update Interceptor.invoke() signature to use JBCMethodCall rather than JGroups MethodCall

by Manik Surtani (JIRA)

Update Interceptor.invoke() signature to use JBCMethodCall rather than JGroups MethodCall ----------------------------------------------------------------------------------------- Key: JBCACHE-734 URL: http://jira.jboss.com/jira/browse/JBCACHE-734 Project: JBoss Cache Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: 1.4.0 Reporter: Manik Surtani Assigned To: Manik Surtani Fix For: 2.0.0 Saves on unnecessary casts in invoke() implementations. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 11 months

1
1
0 / 0

[JBoss JIRA] Created: (JBAS-3566) Invalid mbean code reference in mssql-jdbc2-service.xml

by Luc Texier (JIRA)

Invalid mbean code reference in mssql-jdbc2-service.xml ------------------------------------------------------- Key: JBAS-3566 URL: http://jira.jboss.com/jira/browse/JBAS-3566 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: JMS service Affects Versions: JBossAS-4.0.4RC1 Reporter: Luc Texier Assigned To: Luc Texier Fix For: JBossAS-4.0.4.CR2 in the d -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 11 months

1
3
0 / 0

[JBoss JIRA] Resolved: (JBAS-3233) Web services debug logging is causing the classloader to be switched

by Darran Lofthouse (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-3233?page=all ] Darran Lofthouse resolved JBAS-3233. ------------------------------------ Fix Version/s: (was: JBossAS-4.0.5.GA) Resolution: Rejected I have tracked down the cause of this problem, the class org.jboss.ws.soap.SOAPContentElement caches the XML after it has been generated. If the debug logging is enabled the first time SOAPContentElement is called to generate the XML is when the classloader of the EJB is the current classloader, this means it has not problems generating the XML. When the response is generated SOAPContentElement is asked a second time for the XML, as it has already been generated once the cached value is returned. When the debug logging is switched off SOAPContentElement is not called so the XML is not cached, then it is called to generate the response this is using the classloader of the web application and as there is no cached value it has to be generated. The web application classloader does not have visibility of the classloader used for the EJB which is why it can not load the class. JBWS-941 Resolved this issue and the web application now makes use of the scoped classloader of the ear so if the XML is first requested in the web application or in the debug code the correct classloader will be used to load the classes. > Web services debug logging is causing the classloader to be switched > -------------------------------------------------------------------- > > Key: JBAS-3233 > URL: http://jira.jboss.com/jira/browse/JBAS-3233 > Project: JBoss Application Server > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: ClassLoading > Affects Versions: JBossAS-4.0.4.GA > Reporter: Darran Lofthouse > Assigned To: Darran Lofthouse > Attachments: ComplexReturnEJB_DocLit.ear > > > Web services debug logging is causing the classloader to be switched. > Currently the web services stack does not correctly set the classloader for web services deployments when deployed as part of an ear with an issolated classloader (see JBWS-941). However debug logging in the web services code is incorectly causing the deployment to work! > In the class 'org.jboss.ws.server.ServiceEndpoint' there is a method called 'postProcessResponse', this method contains some logging wrapped with a 'log.isDebugEnabled': - > // debug the outgoing message > if(log.isDebugEnabled()) > { > resMessage.saveChanges(); > SOAPEnvelope soapEnv = resMessage.getSOAPPart().getEnvelope(); > String envStr = DOMWriter.printNode(soapEnv, true); > log.debug("Outgoing SOAPMessage\n" + envStr); > } > If this logging is remove the ClassNotFoundException is thrown regardless of the log4j configuration. > The ClassNotFoundException is good and shows that the classloader has not been switched. > I will attach a deployment that can be used to reproduce this. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 11 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 August 2006