Thank you !! :) read on :) On Mon, 29 Dec 2003, Stephen McConnell wrote:
> 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. Yes. I'm still new to maven/merlin so I'm not sure what to do about it. Something weird I noticed, is that I tried to import AbstractBlock, and add a maven dependency to merlin-impl or avalon-??-impl to get access to the class.. it would compile, but failed the run badly. So a classloader issue is probably correct.. :( > 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. The model.addModel and block.addModel was another issue that I forgot to bring up :) thank you for reminding me :) I was wondering why there are two addModels as well. One in block and one in model; especially since I had to use block.addModel to properly add Hello ( it didn't work if I added it directly to the block.containmentModel ). I like your proposal of making the MerlinRuntime be event driven off of the AvalonModel. Could this be used to add/remove blocks from a running kernel? ( so I don't have to shutdown/startup? ) :) I had another idea as well. Since technically we can only ( or should only ) change the model while the kernel is shutdown ( for now ), could we have a flag, and have modification methods throw an exception or something, if the kernel it not in a modifiable state?? So people don't put it in an inconsistent state, that we can't back out from. So you got the removeModel working on my code. Is there anything that I have to change on my code ( like use the block.removeAppliance instead of the model.removeModel )? or simply cvs up the latest avalon/merlin? > I'm going to post a followup note on this subject to [EMAIL PROTECTED] > > Cheers, Steve. Thank you!! :) Fernando --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
