On Wed, 30 Oct 2002 00:23, Bulbuk Ole wrote: > 1. ServiceManager.lookup() seems to deliver a proxy instead of the > requested component.
yep. > The problem is that the component implements > an interface (Executable) that the proxy doesn't implement. > So we don't get to know that we should call the execute method > anymore and the component doesn't do its work anymore. > I suppose that the proxy could be executed (with proxy.execute()) > and would then call component.execute(). But how do I know??? One way to fix this is to make the Executable interface part of the components "service" interface. This means adding a line such as <service name="org.apache.avalon.framework.activity.Executable"/> into the <services/> element in your BlockInfo for this object. If you are using QDox to generate the BlockInfo then you need to add a line such as * @phoenix:service name="org.apache.avalon.framework.activity.Executable" to your class javadoc. > 2. All components are instantiated and even started before lookup. > This seems to block everything else because the start (or execute) > methods of my components usually do a lot of work and are sometimes > supposed to be started in an own thread (which would exist when > lookup is done). Correct. If Component A depends on Component B then B needs to be started before A can get a reference to B. If we did not do this it would be possible for Component A to make a call against Component B before it was fully initialized (and prepared to accept method calls). If B needs to do a lot of work on startup but that does not effect it's ability to handle method calls then you should kick off a new thread for Bs costly startup work. If however the work should complete before A can call any methods on B then I think you are stuck with this behaviour :) Alternatively you could handle concurrency inside the actuall methods and kickstart the heavy processing in another thread. The methods would block untill all the processing is done. > 3. How am I able to get more than one instance of the same component > with the same role? Just specify the lookup name in the dependency declatation in the BlockInfo. It defaults to the name of the class but you can specify any arbitary string. For example if we were to have two instances of the service - one looked up using string "role1" and one looked up using string "role2" the following would appear in the BlockInfo file. <dependencies> <dependency> <role>role1</role> <service name="o.a.MyService"/> </dependency> <dependency> <role>role2</role> <service name="o.a.MyService"/> </dependency> </dependencies> > I need this to run the same component in > multiple threads. Only the implementation of the component could > decide that the component is threadsafe (but usually it is NOT). > So how can I get multiple instances of a (non) threadsafe > component? Phoenix has no notion of thread safe or not threadsafe. It just maps allows users to map components into dependencies of other components. It is up to the developer to decide which components get mapped where. What I would suggest is that you create a CompilerManager component that manages several different Compiler components. It will allow users of CompilerManager to aquire a Compiler that is determined by runtime data. If you still want to have some Compiler components managed by Phoenix (rather than by the CompilerManager) and you are using the latest CVS version of Phoenix (rather than last release) then you can declare dependencies on arrays of services by appending "[]" to the service type. ie <dependencies> <dependency> <service name="o.a.MyService[]"/> </dependency> </dependencies> Will allow an array of MyService objects to be mapped in as a dependency. You then just provide multiple <provide/> elements for the service in the assembly.xml file. Does this make sense? > I hope somebody can help me with this. Hopefully that helps. If not then feel free to ask for more information. -- Cheers, Peter Donald -------------------------------------------------- The fact that nobody understands you doesn't mean you're an artist. -------------------------------------------------- -- To unsubscribe, e-mail: <mailto:avalon-users-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:avalon-users-help@;jakarta.apache.org>
