avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcus Crafter <craft...@fztig938.bank.dresdner.net>
Subject Re: Implementing custom marker interfaces
Date Tue, 04 Jun 2002 12:59:09 GMT
On Tue, Jun 04, 2002 at 01:44:40PM +0200, Ole Bulbuk wrote:
> So a component manager would have a list of callbacks for lookup and one for
> release. These callbacks would get the component as a parameter.
> This would even give nice ways to do very flexible things (e.g. via
> anonymous classes as callbacks :-).
> The cm would need methods to
> - register a callback for lookup,
> - deregister a callback for lookup,
> - register a callback for release and
> - deregister a callback for release.

	There are 2 others types of accesses too, when the component is
	first instantiated, and when it is decommissioned.

> The methods lookup and release would simply iterate over their list and
> execute all the callbacks. For easier management the callbacks should have a
> method that returns their name. So everybody could ask for a list of the
> names of the callbacks. And a new callback could be inserted at the right
> position in the list.

	Yes, this is similar to what I'm thinking at the moment, although
	I've its partly object oriented using virtual functions rather
	than explicit callbacks.
	So far I've been playing with the following code to see what will

	-------------------- <Random Thought Mode/> ---------------------
      	I've defined an interface like:
public interface ComponentMarker
	void create(Component component, Context context);
	void destroy(Component component, Context context);
	void access(Component component, Context context);
	void release(Component component, Context context);

	which defines 4 types of methods that can be called by the
	ComponentHandler/Factories at appropriate stages of a components 
	An example is:
public class LogEnabledMarkerImpl extends AbstractMarker
	public void create(Component component, Context context)
		final Configuration config =
			(Configuration) context.get(CONFIGURATION);
		final String logger = config.getAttribute("logger", null);
		final LoggerManager logManager =
			(LoggerManager) context.get(LOGGER_MANAGER);
		final LogEnabled logEnabled = (LogEnabled) component;
		if (null == logger)

	(I've created an Abstract class which provides empty
	implementations of all methods, so concrete marker subclasses only
	have to implement what's necessary).
	I'm hoping this fits in well with Fortress which uses the Context
	object to provide just about everything.
	This concept would allow us to configure the
	ComponentHandlers/Factories with a Configuration object containing
	something like:

		<marker	interface="o.a.a.f.l.LogEnabled"
		<marker	interface="o.a.a.f.l.Contextualizable"


	As you've described, each each stage, the handler/factory would
	iterate over the configured markers, testing and calling
	the appropriate methods.

	Adding custom markers would be a matter of implementing an
	appropriate Marker class, filling the Context with any required values,
	and adding the marker to the above configuration (and/or perhaps
	via some dynamic registration method too).
	Food for thought. What it doesn't do so far is validate that the
	standard avalon interfaces are in correct order, I'm still
	thinking about that one.
	I'm still in RT mode :) so perhaps there's some limitations I haven't
	come across yet ? Feel free to add any comments/thoughts.
     ,,$$$$$$$$$,      Marcus Crafter
    ;$'      '$$$$:    Computer Systems Engineer
    $:         $$$$:   ManageSoft GmbH
     $       o_)$$$:   82-84 Mainzer Landstrasse
     ;$,    _/\ &&:'   60327 Frankfurt Germany
       '     /( &&&

To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>

View raw message