thanks. will check out 4.2.2 :)
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4100452#4100452
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4100452
___
jboss-user mailing list
This behavior has changed with the implementation of a new ThreadlocalPool. Now
the pool completely cleans up at undeploy and calls @PreDestroy on all session
bean instances.
See http://jira.jboss.com/jira/browse/EJBTHREE-1031
View the original post :
http://www.jboss.com/index.html?module=bb&
+1 to change this (if possible without turning the everything upside down).
And I don't say that because I think Bill did a bad job with his
implementation. I am sure that from that point of view it is a very nice
solution.
But my point of view is just the one of an AS user and not of an AS imple
+1 to fix this anomaly. Can't believe someone who preaches standards says "its
my implementation".
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4100045#4100045
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4100045
___
"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 undeploy
you cannot extract all instances stored in a ThreadLocal. Write another pool
if you do not like this behavior.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3963322#3963322
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&
@PreDestroy works per instance (EJB3 4.5.1 last paragraph)
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3963498#3963498
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3963498
"[EMAIL PROTECTED]" 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
"[EMAIL PROTECTED]" 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, weirdI mean PREDESTROY, sorry! :D Just frustrated
with this behavior
it is our implementation not the spec.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3963323#3963323
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3963323
___
jboss-user maili
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 :)
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3963312#3963312
Reply to the post :
ht
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
@PreDestoryI'm not sure what the spec group was thinking here with respe
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
I can probably work around it too but I just want to understand the @Predestroy
lifecycle callback a little bit better!
Thanks!
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3962487#3962487
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=po
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
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.
View the original post :
http://www.jboss.com/index.html?mod
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.)
View the original post :
Uggh, shall I file a JIRA incident on this?
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3962355#3962355
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3962355
___
jboss-user
18 matches
Mail list logo
