Andreas I agree with you. It is my fault that setting empty methods. But, I never did it for enforce any things, It was happened with my changes to remove two ‘init’ methods(Only concern was removing tow init methods ). I didn’t care it until this thread begins.
Definitely, it may require substantial changes. But, if something needs to be correct, then it should do at some point. If community like for changes, we need to do. I may not able to take responsibly at this stage as I can’t guarantee allocating time. One thing, I have to fix some jiras and statistic collection functionally. Other thing, I am always busy during these days due to education related things. It is great if you can do this (if you have time and community too like these changes) Thanks Indika On Tue, Mar 17, 2009 at 4:13 AM, Andreas Veithen <[email protected]> wrote: > Indika, > > I still fail to see how the fact that AbstractMediator implements > ManagedLifecycle (with empty default implementations for init and > destroy) is enforcing anything. What is the improvement compared with > the situation before? > > On the other hand, I agree with you that the issues related to > mediator lifecycle management that we have seen in the past are (or at > least could be seen as) an indication of a flaw in the design. Indeed, > one attribute of a good design or architecture is that it enforces > things and prevents people from implementing things in the wrong way. > > From the issues we have seen in the past, I would identify two > problems with the current lifecycle management: > > 1. We rely on the fact that mediators having child sequences (list > mediators, switch-case, etc.) are able to correctly manage the > lifecycle of their child mediators. We have seen examples in the past > where this wasn't the case. > > 2. We will sooner or later run into problems where during > initialization, one managed object tries to interact with another > managed object that has not yet been initialized. (This is the typical > problem that arises with managed objects) > > If we want to avoid these issues, then we should use (or should have > used) another pattern: Register all managed objects in a central place > as soon as they are created. Note that in case of mediators, this > would require some sort of configuration context to be passed around > to MediatorFactory implementations and to MediatorFactoryFinder > (getMediator in particular). Instead of initializing the managed > objects recursively as described above, one would then simply > initialize all the registered objects sequentially. This solves issue > 1 and enforces lifecycle management because the only place where a > mediator can be created is MediatorFactoryFinder#getMediator and that > method would require the configuration context. The pattern could also > be used to solve issue 2 because one could postpone the initialization > of a managed object if it fails due to some uninitialized dependency. > > The problem with all this is that it would require some substantial > changes that will break existing code... > > Regards, > > Andreas > > On Mon, Mar 16, 2009 at 17:53, indika kumara <[email protected]> wrote: >> Hi All >> >> Just now had a time to look at this. >> >> Actually what I did from commit say by my commit log ‘remove >> ManagedLifecycle from mediators that extends AbstractMediator as >> AbstractMediator already implements ManagedLifecycle’. Actually, I >> just replied to the thread as I have to replay as this related with >> me. I just want to get rid if this thread as I had many works to do >> and I really don’t care other things, when I have important things to >> do. >> >> I am trying to take design decision on this and I expect to get answer >> for these. >> >> 1) Is ‘ManagedLifecycle’ is a trick to allow mediators and others to >> do require work related with initialization and destroy. Currently, I >> can see only this as a trick. Trick is still worked. >> 2) Otherwise…. Synapse initiators came up with great set of >> abstractions such as mediators, endpoints, tasks, registry, etc to >> build an ESB using these abstractions. Then, they have thought that >> these abstractions should be properly managed. Therefore, came up with >> a new abstraction “Lifecycle Management” to enforce that. If it is >> the case, ‘implementers’ of this abstraction really misused concept of >> design. >> One: >> There is no semantic validation. The “Lifecycle Management” >> abstraction has great semantic and just naming ‘init’, ‘destroy’ >> cannot get this as it is just syntax. Abstractions are the ever greats >> things that builds the any system. Currently, there is no >> differentiating on calling a method based on ‘init’ or ‘destroy’ has >> been already called or not on that. Definitely, it can get exceptions >> like ‘NPE’ if ‘init’ had not been called. This is not semantic >> validation but failure due to avoiding it. I can remind some >> situations … As I remind some user has reported errors that have been >> happened due to fact Mediators inside switch case, has not been >> initiated. Another situation was occurred when using an indirect >> endpoint (only for indirect endpoint) within in send mediator. Send >> mediator’s init method did not get called and as a reason indirect >> endpoint has been not initialized. Still, this kind of things possible >> as any user can create custom mediators and there is no semantic >> validation on “Lifecycle Management”. Actually, these are transient >> failures - until get executed a particular code fragment failures are >> hidden. There are the ever bad failures. All these are happened due to >> fact there is no semantic validation on. There cannot be an >> abstraction without semantic. Without semantic validation, it is just >> a class for use to implements some trick. >> >> Two: >> There are no semantic enforcements. All initialized and not >> initialized objects can be used together. >> >> For the case two, I can only do refractor. >> >> I just want to say the way I think about these and never want to prove >> concerns of others are bad or good. >> >> I may have said one to one. If it was happened it is completely due I >> wanted get grid of this thread as I had many works to do. >> >> Thanks >> Indika >> >> --------------------------------------------------------------------- >> 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]
