I know it was possible to make it happening with a naked tomcat as well, not sure they fixed it or not but just reading your description it is not shocking
Romain Manni-Bucau @rmannibucau http://www.tomitribe.com http://rmannibucau.wordpress.com https://github.com/rmannibucau 2015-02-03 13:00 GMT+01:00 Alexander Wagner <[email protected]>: > Hm we didn't see this behaviour on any other system before. But sounds to me > that you do not see here a correlation. > > Am 03.02.2015 um 12:55 schrieb Romain Manni-Bucau: > >> Hi >> >> about 3 it is due to the backgroundProcess() of tomcat which regularly >> checks what it has to do, not sure there is a real protection against >> it without changing the process (autoDeploy=false for instance) or >> uploading elsewhere >> >> >> Romain Manni-Bucau >> @rmannibucau >> http://www.tomitribe.com >> http://rmannibucau.wordpress.com >> https://github.com/rmannibucau >> >> >> 2015-02-03 12:49 GMT+01:00 Alexander Wagner >> <[email protected]>: >>> >>> Hello TomEE-Community, >>> >>> we have three curios observation with TomEE 1.7.1 running under Debian >>> (Debian 3.2.57-3+deb7u1 x86_64 GNU/Linux). All the problem only occur on >>> that debian server. Two of the problems are already solved in the >>> 1.7.2-SNAP. Maybe the third one belongs somehow to same failure...: >>> >>> 1. This failure was already described here, that in some cases the name >>> of >>> the tomee directory or a symbolic link prevents the servlet annotations >>> to >>> work correctly. This failure does not occur in 1.7.2-SNAP any more. >>> >>> 2. The second one we observed, which is also already solved in >>> 1.7.2-SNAPSHOT is that we had a problem when we injected a jms topic in a >>> managed bean (ejb, cdi doesn’t matter) and tried to use this topic to >>> send a >>> message. Ok here comes the bad part, we used this managed bean from a >>> thread >>> which listen on socket connections. Locally we do not had any problems at >>> all on this part. But when we tried to send a message with that injected >>> topic on the debian system we got a: >>> >>> java.lang.UnsupportedOperationException: A destination must be specified. >>> at >>> >>> org.apache.activemq.ActiveMQMessageProducer.send(ActiveMQMessageProducer.java:257) >>> ~[activemq-client-5.10.0.jar:5.10.0] >>> >>> After some debugging etc. we decided to get the Topic from jndi directly: >>> Topic lookup = (Topic) new >>> InitialContext().lookup("java:comp/env/MyTopic"); >>> >>> And than we got a ClassCastException: >>> java.lang.ClassCastException: org.apache.activemq.command.ActiveMQQueue >>> cannot be cast to javax.jms.Topic >>> >>> After that we decided to give the 1.7.2-SNAPSHOT a chance and wow we do >>> not >>> have that problem anymore. :-) >>> >>> 3. We deploy our webapps over the tomcat manger with the tomcat7 maven >>> plugin. The tomcat manager copies the temp war file to the webapps folder >>> during upload. We are not sure if this the default behaviour and the >>> manager >>> normally starts deploying only .war files. But for some reasons the >>> manager >>> try immediately to deploy the tmp war file, which ist not fully uploaded. >>> This failure do we get also with the 1.7.2-SNAPSHOT on this debian >>> machine. >>> >>> >>> Best Regards >>> Alexander Wagner >>> > >
