title: Can an embedded XMPP server in a Java EE container be harmful because of threads?
body: <p>I was playing a little bit with <a href="https://mina.apache.org/vysper-project/embed.html" rel="nofollow noreferrer">Vysper</a>, embedding it into a Java EE web application in <a href="http://tomee.apache.org/apache-tomee.html" rel="nofollow noreferrer">TomEE</a>. Vysper is an alpha/beta version of a XMPP server based on Apache Mina that can be easily embedded into java applications. I could sucessfully instantiate a Vysper instance into a @Startup / @Singleton scoped bean. So far so good. It seems to work ok when I run it in a vanilla TomEE instance from inside eclipse.</p>
  
  <p>But then I've remembered that Java EE applications should not use threads (see this answer at stack overflow - <a href="https://stackoverflow.com/questions/533783/why-spawning-threads-in-java-ee-container-is-discouraged">Why is spawning threads in Java EE container discouraged?</a>). If I remember well, there are even wrappers for threads when someone need to run such a thing from inside a Java EE app.</p>
  
  <p>I know that TomEE+ uses Quartz and ActiveMQ as backend to implement several Java EE services, but they're part of the container, not part of the web application. </p>
  
  <p>I bet Mina and Vysper use threads internally, so I wonder it's not a good idea to embed Vysper directly into a Java EE web application in this context. Of course, I could just run the XMPP server as another component of the system, outside the container, which would also make more sense in a clustered deployment.</p>
  
  <p>But supposing I am running in a standalone deployment (single TomEE), running an embedded Vysper into a Java EE web application could be harmful because it relies internally on threads? If it's not, why?</p>