On Tuesday 23 December 2003 05:09, Marco Tedone wrote: > Niclas Hedman wrote: > > remove the ability for components to "go out and find" on their own. > > However, no container prevent stuff like this from happening (yet), but I > > doubt you will see something that generic. > > I see. But this way don't you force all components to know about each > other? Suppose you're running 5000 services, and that tomorrow you write a > service that is useful for all of them. Probably there is another way, but > with what you're saying, should all the 5000 services add the new entry to > their declarative execution environment? This is one of the issues that > Naming Services want to address and one of the reason why they are so > popular.
The components don't know about each other. The container knows about the components. I also don't think that you will have 5000 components in a "flat structure", but in component hierarchies, composing of larger and larger sub-systems. In Merlin, that means that all components can not lookup all other components, but only what is within its own containment structure (I don't know the correct terminology, but think you get the idea). > I've tried both but I obtain the following: > > D:\Projects\myMerlin>merlinx -execute target\merlinj-1.0.jar > How could I solve? What JAR file is that? And what is the content of /BLOCK-INF/block.xml file inside? <snip about="Jini" /> > This sounds good, but isn't that against the Inversion of Control pattern? No, not necessarily. Let's say that component A needs a Service A, so in its code it does the same thing as always, look it up via the ServiceManager. But behind the scenes, the container, Merlini(tm), can satisfy that request by providing a remote service instead of a local one. So from the components point of view, we should actually be able to implement this transparently. BUT, an "availability" contract is required, since we must also handle that the service is no longer available (for whatever reason, network problems, reloading of classes...) It is an exciting path we can take for Merlin. Cheers Niclas --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
