Well, other containers also regularly blurp up with ClassCastException, ClassNotFoundException, NoClassDefFoundException exactly because of that :) There are tons of errors reported for those situations in other containers as well.
So you are right: TomEE is not worse than the others - but we could do much better :) LieGrue, strub ----- Original Message ----- > From: David Blevins <[email protected]> > To: [email protected]; Mark Struberg <[email protected]> > Cc: > Sent: Saturday, April 21, 2012 5:05 PM > Subject: Re: generated beans.xml content in tomee? > > > On Apr 21, 2012, at 6:54 AM, Mark Struberg wrote: > >> Hi! >> >> In my EAR projects with tons of jars I have a <interceptors> and > <alternatives> section in ONE of my jars. >> >> But it seems that >> >> >> $> ./bin/tomee.sh deploy my_app.ear >> >> propagates this info to other jars ending up in ./apps/myapp/lib/*.jar ? ^^ >> >> a.) how is the rule which determines to which jars it gets propagated? >> b.) why so? Guess it has to do with the BDA crazyness? > > Right, it's the "one BeanManager per EAR, shared by all apps" > strangeness that you've been trying to get clarified at the spec level. > > Here's the test that has so far made everyone do it the global way: > > > org.jboss.jsr299.tck.tests.deployment.packaging.bundledLibrary.LibraryInEarTest > > We could easily support other modes as long as the default mode is compliant. > > > -David >
