users@glassfish.java.net

Re: _at_PreDestroy method in web service not called when web app undeployed?

From: Stephen Connolly <stephen.alan.connolly_at_gmail.com>
Date: Mon, 14 Jul 2008 16:56:07 +0100

On Mon, Jul 14, 2008 at 4:40 PM, <glassfish_at_javadesktop.org> wrote:
> OK, thanks for the explanation, that helps a lot.
>
> I understand your explanation about @PreDestroy - it's related to garbage collection - clearly not what I want.
>
> I am deploying my application in a WAR file (by either copying it to the autodeploy directory, or using the Netbeans IDS "undeploy and deploy" action) so I should be able to implement a ServletContextListener as you suggest.
>
> Regarding starting a thread in a container not being kosher, well, I've written several web apps that need some kind of background processing, so I can't see any way to avoid this. If there's a standard way that this is supposed to be done, that would be fine, but it's not so easy to figure out what that would be. I'm coming at this whole web service programming thing from the background of someone who's used to writing C code to listen on sockets and fork off handlers. The scale of all this Java EE machinery is quite intimidating for us mere mortal programmers who learned our trade back in the day when the entire app progam, operating system and all, would fit in a few Kbytes of memory.

I completely agree that 99% of people do exactly what you have
done.... but from my reading of the JavaEE5 specs... it's not
something that the specs are expecting you to be always permitted to
do...

The only part of the spec that I can see that actually lets you start
your own threads is the JCA.

I agree it's a hole in the spec... I was more pointing it out from the
"Oh! spec leads fix this" kind of way.

The other thing is as starting a thread in your ejb/servlet is not
encouraged, you hit a lot of problems... which people then invent
crazy workarounds to solve.

The basic problems are around security and all that JAAS. There are
also issues with transactions.

The JCA spec does split out some of this stuff, but it probably needs
to be made more general, and why a resource adapter is the only thing
that can get the workmanager instance is another question....

Hmmm I've just thought of something... a trivial resource adapter
could expose the work manager that it has been given as a "propriatory
api" and therefore allow ejb, etc to access the work manager and even
have it injected with the @Resource annotation! .... I smell an
uber-hack! ;-)
>
> Thanks,
>
> Duncan
> [Message sent by forum member 'duncant' (duncant)]
>
> http://forums.java.net/jive/thread.jspa?messageID=286449
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>
>