In a container being developed now based on Avalon 4 we decided to have an internal microkernel service called Importer. Each component is running in its own sandbox restricting access to the services declared in deployment descriptor. If the component needs to add a dependance it may ask Importer service to "import" a service and bind it to a String name (ROLE). Importer can throw a checked exception if it is not possible.
This approach is utilized by the components performing role of component "factories" similar to EJB Home objects. This component may use an internal container service called Installer to "install" a new component and then get access to it calling Importer service. Terminus (http://cheblogs.com/roller/page/terminus) --- Stephen McConnell <[EMAIL PROTECTED]> wrote: > > > Farr, Aaron wrote: > > >Hello. > > > >This was discussed before, but I don't think there > was any resolution. Out > >current service dependency contracts look something > like this: > > > > /** > > * @avalon.dependency type="org.proj.MyService" > key="myService " > > */ > > public void service(ServiceManager > serviceManager) throws ServiceException > > { > > MyService srv = (MyService) > serviceManager.lookup("myService"); > > getLogger().info("Hello! we got this service = > "+srv.ROLE); > > } > > > > I figure I'm probably the only person here who > thinks this - I just > don't get the value of <class>.ROLE. In fact I think > its a bad > practice. The role of a service is something > understandable relative to > the consumer - not the provider. > > Anyway, moving on. > > >which is all well and good -- _IF_ you know what > services you need to lookup > >at build and deployment time. > > > >If you have a component which looks up arbitrary > services which are perhaps > >given in the configuration (like the Codehaus Ivory > project) then you're > >going to have issues if you MUST declare service > dependencies, which is the > >case for Merlin. > > > > This is the issue I raised before. There is a > semantic difference > between resolving a dependency and service > discovery. A dependency is > something structurally bound to the component type. > A component that > requires a service discovery service should be > declaring this as a > dependency (in an ideal world). Unfortuately we are > dealing with a > historical context in which the semantics of type > based dependencies and > service discovery have been implied on a single > interface (ServiceManager). > > This conflict raises an important issue. If a > component requests > something that is not a dependency, does this action > represent an error > or does the action represent a ligitimate service > discovery request? > > >In Merlin if you build the above code, and leave > out the @avalon.dependency > >tag, then deployment fails. > > > > Correct. Deployment fails because the component is > requesting something > that it did not declare as a structural dependency. > > > Even leaving out the 'key' attribute will cause > >this to fail. > > > > Leaving out the key is fine. > > This just means that your using the type as the key. > I have just added > an example of key-less dependency resolution to the > merlin/merlin-platform/tutorials package under > ./dependencies/auto. > > >While I understand dependency resolution is > important, we need to have a way to support runtime > dependencies. > > > > Just so that we are on the same page - I'm > interpriting what your saying > as "we need to have a mechanism through which a > component can declare to > a container that it has a dependency on a service > discovery service" and > by implication, (a) the container should be > providing this service > independently of the containment context, and (b) > for compatibility > reasons, the functionality of a such a service > should be exposed using > the service manager lookup operation. > > > > >Even something like a wildcard would be nice: > > > >@avalon.dependency type="org.proj.MyService" > key="*" > > > > What is the problem with: > > @avalon.dependency type="org.proj.MyService" > > > > > > >This bring me back to an older discussion [1] about > lookup methods. At the > >time Berin put together the following: > > > >Lookup Method | ECM | > Fortress | Merlin | Phoenix > >--------------------------------------+-----+----------+--------+-------- > >Object <- lookup("alias") | | > | X | X > >Object <- lookup(ROLE) | X | X > | X | X > >Object <- lookup(ROLE+"/alias") | | X > | | X > >List <- lookup(ROLE+"[]") | | > | | X > >Map <- lookup(ROLE+"{}") | | > | | X > >Selector <- lookup(ROLE+"Selector") | X | X > | | > > > >(edited to provide accurate Merlin status) > > > >Since Merlin is aiming at being _the_ container, > what lookup methods will it > >support? > > > > I would like to take the approach of looking at this > subject from a A5 > perspective and from that, look at how to provide > consistent A4 > support. The reason I'm suggesting that is that I > really think that the > mixed semantics approach is a broken solution and > that we should > approach this problem with the objective of defining > something clean and > from that - addressing A4 compatibility. > > Cheers, Steve. > > > >Thanks! > > > >J. Aaron Farr > > SONY ELECTRONICS > > DDP-CIM > > (724) 696-7653 > > > >[1] > http://www.mail-archive.com/[EMAIL PROTECTED]/msg06296.html > > > >--------------------------------------------------------------------- > >To unsubscribe, e-mail: > [EMAIL PROTECTED] > >For additional commands, e-mail: > [EMAIL PROTECTED] > > > > > > > > > > -- > > Stephen J. McConnell > mailto:[EMAIL PROTECTED] > http://www.osm.net > > Sent via James running under Merlin as an NT > service. > http://avalon.apache.org/sandbox/merlin > > > -- > > Stephen J. McConnell > mailto:[EMAIL PROTECTED] > > === message truncated === __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
