Marcus Crafter wrote: > > Hi All, > > Hope all is well. > > In our project I recently delved into the world of creating custom > markers specific for our particular application domain. I'd > thought that IoC/SoC was an excellent programming paradigm, > and could > be applied to our application in a greater context, not just within > the standard avalon interfaces. > > It turned out to be easy to begin with but difficult to finish, and > there seem to be lots of issues, at least to me :) > > What I wanted to do was define a custom marker interface > that would be > checked for each time a component was accessed (ie. during > lookup()), > and have a method defined in that particular interface called each > time, appropriately. > +10, this is really a very usefull feature!
> The solution was to extend ECM's lookup() method in a subclass, > however the first problem I found was that most application code > specifies 'new ExcaliburComponentManager()' directly and needs to be > changed to use a derived class or made configurable to accept an > arbitrary component manager class, sometimes in several places > (eg. Cocoon, with my patch #8614 in bugzilla). > Yes, subclassing the ECM has another drawback if you have a CM hierarchy (as Cocoon has :( ): if you simply override lookup() in your own CM you delegate the lookup to the real CM which is either the parent class or a parent CM in the hierarchy. But when you do a simple super.lookup() you don't know who created the component. If it is a parent CM, this component is completly initialized, if it was the parent class, then we can apply our own marker interfaces. This took me some time to get it working... > The other issue I realized later is ECS, select() also needs to be > extended, however this class incurs the same problem as ECM but more > often as selectors are specified in roles files and java code. It's > also more of an issue if a custom selector has already been written > (eg. Cocoon, with it's ExtendedComponentSelector). > > So, subclassing doesn't seem to be the solution. > Yupp. > Another issue is that it seems to be quite difficult to insert a > custom marker mid-way into a component's startup/destruction phase. > I know this one won't come up as often as the others above, > but as an > example Lief had this problem supporting the Instrumentable > marker interface. > > I think we still need a way to ensure the defined order of the > standard avalon startup/destruction interfaces, but it could be > useful to include the ability to insert custom ones during > component startup (or should we consider the startup/destruction > process to be immutable ?). > > I've taken a look at both the ECM/ECS and Fortress code, but both > don't seem to cover this space just yet (?). I'm looking for ideas > about how to add such functionality to our existing classes that > doesn't require excessive subclassing of handlers or component > managers. > +5 Carsten > Any ideas ? thoughts ? > > I'm currently mulling over the thought of a potential solution that > involves modifying component handler/factories so that they > can accept > a configurable startup/destruction sequence, but since I'm still an > avalon novice it would be great to hear comments/thoughts ? :) > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
