It's definitely due to improper/non-existent teardowns and the ContextClassloader. I'll have a patch ready shortly.
For everyones information, do NOT ever do: Setup: Thread.currentThread().setContextClassLoader(getClass().getClassLoader()); Teardown: Thread.currentThread().setContextClassLoader(null); That is wrong. The original classloader may not be null. Thus, after the teardown, the VM is not back to it's original state. You need to do something like: Setup: origLoader = Thread.currentThread().getContextClassLoader(); Thread.currentThread().setContextClassLoader(getClass().getClassLoader()); Teardown: Thread.currentThread().setContextClassLoader(origLoader); Enjoy! Dan On Thursday 23 March 2006 09:46, Daniel Kulp wrote: > Ick... OK. Another set of tests that only fail on my machine. > (like the rhino ones) > > I just did a fresh checkout into a completely new directory, deleted my > ~/.m2/repository dir, and rebuilt and I'm still seeing the failures. > Probably some more teardown methods that need to be implemented to > reset things back to pre-test state. I'll investigate more. > > Thanks for confirming. I really wonder what it is with my machine > that is exposing these problem. Is anyone else using JDK 1.5.0_06 on > Linux? I'm using ext3 filesystem which I expect everyone else is using > as well. > > Dan > > On Thursday 23 March 2006 09:04, ant elder wrote: > > svn st and svn up say I'm current and mvn clean, mvn for > > container.java are successful for me. > > > > ...ant > > > > On 3/23/06, Frank Budinsky <[EMAIL PROTECTED]> wrote: > > > Hi Dan, > > > > > > Are the container.java tests run as part of "mvn" from the root? I > > > can run "mvn clean" and then "mvn" from the tuscany/java directory > > > and everything works fine for me. > > > > > > Could somebody else please confirm that they are also having > > > problems like Dan? > > > > > > Thanks, > > > Frank. > > > > > > > > > > > > > > > Daniel Kulp <[EMAIL PROTECTED]> > > > 03/22/2006 10:57 PM > > > Please respond to > > > tuscany-dev > > > > > > > > > To > > > [email protected] > > > cc > > > Frank Budinsky/Toronto/[EMAIL PROTECTED] > > > Subject > > > Re: new XSD to SDO mapping > > > > > > > > > > > > > > > > > > > > > > > > Frank, > > > > > > This commit seams to have REALLY broken the sca builds. The > > > container.java tests are failing pretty badly. Are you (or > > > someone else) working on fixing them? > > > > > > For now, I'm going to revert my SDO dir to -r 387955. > > > > > > Thanks! > > > Dan > > > > > > On Wednesday 22 March 2006 17:55, Frank Budinsky wrote: > > > > I just committed a change to the SDO XSDHelper.define() method > > > > which changes the behavior significantly. It used to mangle names > > > > (using EMF's mangling algorithm) and it didn't map simple types > > > > (like xsd:int) to the proper SDO Types as specified in the SDO 2 > > > > spec. > > > > > > > > With this change, many of the sca schemas no longer generated > > > > valid Java classes. For example things like <element > > > > name="binding.java" ...> now produces a get method named > > > > getBinding.java(), which doesn't compile because of the "." > > > > character. Don't blame me, that's what the SDO spec says it > > > > should do :-) > > > > > > > > The solution is to add sdo annotations (e.g., > > > > sdo:name="bindingJava") in the schema with the bad names. I fixed > > > > all of the existing places with this problem ... seemed like > > > > hundreds of them :-) ... so everything is still working. Please > > > > beware of this issue, though, when adding new schemas. > > > > > > > > Longer term, we might want to think about adding some mangling to > > > > the Tuscany SDO generator as an option (value-add feature). > > > > > > > > Frank. > > > > > > -- > > > J. Daniel Kulp > > > Principal Engineer > > > IONA > > > P: 781-902-8727 C: 508-380-7194 > > > [EMAIL PROTECTED] -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727 C: 508-380-7194 [EMAIL PROTECTED]
