I don't see this behavior occurring in 3.2 so let's start with what branch and/or version you are talking about, and describe the redeployment process.
I looked at a standalone ejb-jar and and ear/ejb-jar and both clean up the ejb correctly. Redeployment causes a SubDeployer.DESTROY_NOTIFICATION which is where the EJB mbeans are torn down. The stats are not themselves mbean so they would never be registered. Stats are attributes of the ejb mbeans. xxxxxxxxxxxxxxxxxxxxxxxx Scott Stark Chief Technology Officer JBoss Group, LLC xxxxxxxxxxxxxxxxxxxxxxxx ----- Original Message ----- From: "Rod Burgett" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, May 30, 2003 10:20 AM Subject: [JBoss-dev] jsr-77 and undeploying ejbs > There's a bug in here somewhere, but I'm not sure exactly where because I'm > not sure exactly about the intent. Here's the process, as I read it: > > - when an ejb is deployed, the LocalJBossServerDomain is notified and a > statistics mbean is registered for the ejb > - this is handled by EJBModuleFactory.createEJB() and EJB.create() > - if the ejb is undeployed, any notification is ignored by > LocalJBossServerDomain, and the stats mbean remains registered > - if the ejb is redeployed, EJBModuleFactory.createEJB() and EJB.create() > again create and attempt to register a stats mbean > - registration fails because the object is still in use by the original > stats mbean > - EJB.create() returns null > - EJBModuleFactory.createEJB() puts this null value into it's > containerToModuleNameMap > - the factory here loses it's reference to the original stats mbean > - stats mbean unregistration is attempted upon notification of ejb service > destroy > - but it doesn't happen because of the null value previously put into > containerToModuleNameMap > > Any stats mbean method invocation that goes through the mbean server will > operate on the original stats mbean, accumulating stats across deployments. > This stats mbean won't be unregistered when the actual ejb is destroyed. > > If ejb stats are supposed to accumulate over multiple deployments (as they > now are), then handling of the 'mbean already registered' situation should > be changed. Maybe EJB.create() should return the existing object name, or > maybe EJBModuleFactory.createEJB() should check for create() returning a > null reference, or maybe there's another alternative. > > If ejb stats are NOT supposed to accumulate, but to cover only a single > deployment, then the server domain should pay attention to the notification. > > It looks to me like there are three options: > a) there's a bug associated with creation of the stats ejb mbean > b) there's a bug associated with destruction of the stats ejb mbean > c) I'm misreading something > > Which is it? a?, b?, c?, a and c?, b and c? > > > Rod Burgett > Senior Software Engineer > > webMethods, Inc. > 3930 Pender Drive > Fairfax, VA 22030 USA > Ph: 703.460.5819 (tty only) > > "It's all just 0s & 1s - > the trick is getting them lined up in the proper order" ------------------------------------------------------- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
