-
1. Re: Why isn't @Predestory honored in @Stateless beans as wel
Uggh, shall I file a JIRA incident on this?
-
2. Re: Why isn't @Predestory honored in @Stateless beans as wel
I can't find anything in the spec about calling @PreDestroy on undeploy. Please let me know where it is stated.
Nevertheless I find the functionality very interesting, so I think you should open a JIRA issue. (Based on the specs it's either a feature request or a bug.) -
3. Re: Why isn't @Predestory honored in @Stateless beans as wel
by default, we pool in a threadlocal variable. This is to avoid synchronization in very high thread loads. It is a common pattern. This is why predestroy is never called.
All you need to do is plug in your own pool implementation. -
4. Re: Why isn't @Predestory honored in @Stateless beans as wel
Hi wolf and Bill (nice talk at JavaOne btw):
As per section 4.5.1 in the ejb-3_0-fr-spec-ejbcore entitled, "Stateless Session Bean State Diagram", see Figure 6. And I quote from the spec:
"When the container no longer needs the instance (usually when the container wants to reducethe number of instances in the method-ready pool), the container invokes the PreDestroy lifecycle callback interceptor methods for it, if any. This ends the life of the stateless session bean instance." [pg 85]
I would think undeployment would definitely fit under that statement.
Bill, with all due respect, I shouldn't have to plug anything in...that's your job! :D!
Also, why aren't naming contexts removed from JNDI space still? Is that expected behavior?
-aps -
5. Re: Why isn't @Predestory honored in @Stateless beans as wel
I can probably work around it too but I just want to understand the @Predestroy lifecycle callback a little bit better!
Thanks! -
6. Re: Why isn't @Predestory honored in @Stateless beans as wel
I still say some thought is needed.
Here I trick the thread pool into instantiating more objects (and subsequently destroying them). So even the thread pool calls pre destroy. Question remains what to do with that 1 instance that stays in the thread pool on undeploy...deploy... 12:34:16,108 INFO [StackedStatelessBean] post construct org.jboss.ejb3.test.wolfc.StackedStatelessBean@6258e1 12:34:16,109 INFO [StackedStatelessBean] 2 is invoking next one 12:34:16,112 INFO [StackedStatelessBean] post construct org.jboss.ejb3.test.wolfc.StackedStatelessBean@fadb88 12:34:16,114 INFO [StackedStatelessBean] 1 is invoking next one 12:34:16,114 INFO [StackedStatelessBean] post construct org.jboss.ejb3.test.wolfc.StackedStatelessBean@183aedf 12:34:16,114 INFO [StackedStatelessBean] I'm done 12:34:16,114 INFO [StackedStatelessBean] pre destroy org.jboss.ejb3.test.wolfc.StackedStatelessBean@fadb88 12:34:16,116 INFO [StackedStatelessBean] pre destroy org.jboss.ejb3.test.wolfc.StackedStatelessBean@6258e1 undeploy...
-
7. Re: Why isn't @Predestory honored in @Stateless beans as wel
I mean at the bare minimum, if you UNDEPLOY your stateless session bean, @PreDestory needs to be called. My question is @PreDestory meant to be a per instance of a bean or when the entire pool is destroyed you call the @PreDestory....I'm not sure what the spec group was thinking here with respect to Stateless (Statefule beans I believe the meaning is clearer).
-
8. Re: Why isn't @Predestory honored in @Stateless beans as wel
You misspelled that so often I began thinking "what the hell is this PreDestory annotation? I never heard of it, I need to look that up"... even the subject misspells it :)
-
9. Re: Why isn't @Predestory honored in @Stateless beans as wel
you cannot extract all instances stored in a ThreadLocal. Write another pool if you do not like this behavior.
-
10. Re: Why isn't @Predestory honored in @Stateless beans as wel
it is our implementation not the spec.
-
11. Re: Why isn't @Predestory honored in @Stateless beans as wel
"mazz@jboss.com" wrote:
You misspelled that so often I began thinking "what the hell is this PreDestory annotation? I never heard of it, I need to look that up"... even the subject misspells it :)
Yeah, whoops, damn, weird....I mean PREDESTROY, sorry! :D Just frustrated with this behavior... -
12. Re: Why isn't @Predestory honored in @Stateless beans as wel
"bill.burke@jboss.com" wrote:
it is our implementation not the spec.
Great...you do realize Bill that's about the worse possible position to take. Why have the spec then? I thought one of JBoss's main tenets is to be spec compliant. Its bad enough different implementations of a Java EE platform require odd packaging rules (and classloading issues).
Look I don't mean to be a royal pain, but c'mon man...I'm going to reverse the question and say why doesn't JBoss come with a pool implementation that honors this behavior in the spec instead of asking the Java EE developer to write it?
Bill, the JBoss EJB3 implementation is really great, that's why I care.
Btw, what about NamingContexts? Why the heck do they still remain after undeployment? Is this a tracked bug already or another implementation thing? :D! -
13. Re: Why isn't @Predestory honored in @Stateless beans as wel
@PreDestroy works per instance (EJB3 4.5.1 last paragraph)
-
14. Re: Why isn't @Predestory honored in @Stateless beans as wel
"wolfc" wrote:
@PreDestroy works per instance (EJB3 4.5.1 last paragraph)
Now when you undeploy an application (which in effect should tear down the various instances in the session, no?)...though with that said I do realize that after reading the above paragraph, I suppose application undeployment is a gray area and Bill has choosen a reasonable implementation design decision.
I was just stating that ARCHITECTURALLY speaking undeployment of the entire application should cause the container to still honor the lifecycle mgmt callbacks in the spec during tear down. That's all.