daemon threads in an app container

I read in a post to the Smack forum recently that

Starting daemon threads in a Java EE server is a big no no

Basically Smack's XMPPConnection starts one daemon thread to monitor incoming data & another to send outgoing data from/to the jabber server respectively. Is it reasonable to use daemon threads to listen for write/reads in this scenario ?

From stackoverflow

• I have used Smack API for client connections only which are stand alone programs. First you should revisit the choice (or purpose) of Smack API inside a J2EE container.

  Jacques René Mesrine : I'm actually charged with maintaining an existing codebase which already uses Smack inside Tomcat. What are the reasons against using Smack in Tomcat (or a j2ee container) ?

• Yes, XMPPConnection creates two threads--one for listening/reading and one for writing. But these only live as long as the XMPPConnection instance, which I assume is not forever.

  "Starting daemon threads in a Java EE server is a big no no"

  Are you writing spec compliant EJB? If so, then this applies. The spec says don't do it. EJB 2.1 specification:

  "The enterprise bean must not attempt to manage threads. The enterprise bean must not attempt to start, stop, suspend, or resume a thread, or to change a thread’s priority or name. The enterprise bean must not attempt to manage thread groups."

  Or is it just a webapp that happens to be running in Tomcat? If this is the case, then I do not see any fundamental problem. Without the threads, your Smack client would be unable to communicate with the server.

  Jacques René Mesrine : It is the latter (webapp on Tomcat). Thank you for your comments.