Thanks, man. I was starting to believe I was going nuts. Couldn't believe my eyes when I first came across this problem and decided on refraining from reporting it since it seemed to be so far out. I am using a rewrite of the AbstractMerlinTestCase with only some setters added so that it is easier to adapt to my environment. Switched to AMTC just for verification and got the exact same LinkageError.
Cheers, Olaf > -----Original Message----- > From: Stephen McConnell [mailto:[EMAIL PROTECTED] > Sent: Monday, December 29, 2003 12:45 PM > To: Avalon framework users > Subject: Re: Merlin Dynamic Block Un/Loading > > > > > Fernando Padilla wrote: > > > Thank you Stephen for your previous responces! :) But, let's > > continue. Below are more things that I would love your comments on. > > > Fernando: > > I've downloaded your kernel and can confirm your second problem with the > link error - this seems to be some sort of a classloader issue but no > immediate idea of what the problem could be. I did some additional > tests relative to the merlin unit test case and there are no problems > with multiple tests (corresponding to multiple kernel deployments in the > same run). One reason could be that in the merlin case the classloader > structure is a lot cleaner than in your case - probably an area to look > into. > > Concerning the add/remove/add - with a little bit of playing around I > have this: > > kernel established > -----addHello > -----removeHello > -----addHello > -----startup > startup > > But in doing so I've identified a problem in the current API that I > think should delay going to final (as distinct from shipping under > beta). The problem is that we have two potentially conflicting > mechansims that can be used to modify the state of execution. One > method is to modify the model and then execute from the model. The > other method, exposed by the addModel methods on Block are in my opinion > in conflict with the model-driven approach. In order to solve your > problem I had to add a removeAppliance operation on Block (in order to > retract the reference to the appliance in the dependency graph). But I > know this is the wrong approach. > > What I think we should be doing is to remove addModel and > removeAppliance from the Block interface, and instead add a model > listener inside the block implementation which in turn triggers a > private appliance addition/removal. Then we can ensure consitency > between runtime state and model state because we ensure that all actions > are model-driven. > > I'm going to post a followup note on this subject to [EMAIL PROTECTED] > > Cheers, Steve. > > -- > > 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]
