> -----Original Message----- > From: Niclas Hedhman [mailto:[EMAIL PROTECTED] > Sent: Wednesday, December 31, 2003 2:39 AM > > I "wild" guess; > The (Kernel) cast would then implicitly load the merlin-api jar, which > probably then conflicts with the merlin-api being loaded by the > avalon-repository system.
Probably something along those lines. Doubt that I will ever find out. I tried to follow your advice and traced all classloading events during the testcase. To that end I wrote a custom classloader which simply spat out which class was currently being loaded and if the effective class loader was the parent classloader or this classloader. This gave me a whole lot of info, albeit nothing useful. At least not for me. My faithful classloader was tracing and tracing and then, right out of the middle of nowhere there was this good ol' LinkageError again. But then again, I had a look at the source for java.lang.ClassLoader and java.net.URLClassLoader. At least I learned a bit from this one. Cheers, Olaf > > Niclas > > On Wednesday 31 December 2003 07:46, Olaf Bergner wrote: > > OK, think I got it. My rewrite of the AbstractMerlinTestCase > eliminated the > > use of reflection. So instead of > > > > [AMTC] > > m_kernel = factory.create( criteria ); > > m_shutdown = m_kernel.getClass().getMethod( "shutdown", new Class[0] ); > > > > I simply do > > > > m_kernel = (Kernel) factory.create(criteria); > > ... > > m_kernel.shutdown(); > > > > to the same effect. I didn't see any reason why I should keep to the > > reflection way, since this works just fine. BUT, every testcase derived > > from my non-reflection testcase has to be run with some merlin > jars on the > > classpath, i.e. avalon-activation-api, avalon-composition-api, > > avalon-meta-api and merlin-api since otherwise the testcase won't load. > > > > For some reason unbeknownst to my feeble mind this causes the > LinkageError > > on each second test method. At least I was able to eliminate > the problem by > > switching to AMTC and removing the above mentioned dependencies from > > project.xml (maven). I came to this conclusion only a few > minutes ago and > > did only some preliminary testing, but I am quite confident in > this. Still, > > I would be glad if somebody out there could confirm this. > > > > Cheers, > > > > Olaf > > > > > -----Original Message----- > > > From: Stephen McConnell [mailto:[EMAIL PROTECTED] > > > Sent: Tuesday, December 30, 2003 3:06 AM > > > To: Avalon framework users > > > Subject: Re: Merlin Dynamic Block Un/Loading > > > > > > Olaf Bergner wrote: > > > >> (5) Second test method fails during setUp() > > > >> > > > >>Not in my example > > > >>Take a look at avalon-sandbox/merlin-test/hello > > > >>It has to be something else. > > > > > > > >You are right: it has to be something else. I took your template > > > > project, tweaked merlin.properties a bit and added > avalon.properties so > > > > that everything builds just fine and StandardTestCase passes. Then I > > > > added an empty test method to StandardTestCase. Works like a charm, > > > > absolutely no problems. Merlin shuts down and restarts just > fine. Now > > > > what's going on here? I don't get it. Did you notice > something special > > > > about Fernando's setup? > > > > > > Fernando's setup is a pure junit.framework.TestCase - nothing > > > special. In each test he's creating a new kernel (no difference > > > if you move this to the setUp() method). > > > > > > >Anyway, it's getting late here in Germany. > > > > > > Here in France as well! > > > > > > >I'll call it a night and put this > > > >mistery back on the shelf, right next to my monograph about unsolved > > > >problems in superstring theory. > > > > > > ROTFL - I'm thinking along the same lines as you. > > > > > > :-) > > > > > > Stephen. > > > > > > Stephen J. McConnell > > > mailto:[EMAIL PROTECTED] > > > > > > |------------------------------------------------| > > > | Magic by Merlin | > > > | Production by Avalon | > > > | > > > | http://avalon.apache.org/merlin | > > > | http://dpml.net/ | > > > |------------------------------------------------| > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
