|RE: [ecf-dev] State of the 119 distribution part|
Hi Scott, > I understood that eventhook had this behavior, but it was/is unclear to > me whether it should do this (i.e. notify preexisting services). That > is, I'm not sure what requirement for startup this service registry > hook > has...i.e. is the expectation that it will be started along with the > service registry? No, as a service it's clearly tied to the live-cycle of the registering bundle. And since it does not have service tracker semantics, the user of the hook is probably responsible for dealing with existing services. The hook only guarantees the possibility to intercept future service events. I was a bit surprised that the hook does not seem to support filters. At least in the version of the RFC that I have read, but it could be that this is not the most recent any more. I will have a look. If it would, we could restrict the hook to be called for remote-enabled services rather than applying selectivity within the hook (saves cycles). > I can see how races could be a problem (as you say > above), if it tries to deal with pre-existing registrations. Well, I resorted to the practical solution: registering the hook and immediately after processing missed services. This could worst case lead to duplication, which the distribution software is likely to filter out. I think the races were more caused by the container manager sometimes becoming available later than the registry hook wants to access it. > I don't know. I need to think about this some. We could support both > container creation (given type as service property) and existing > container access (as it is now)...again with service properties. But > I'm not clear on whether we should do this. Ideally, the service should not have to bother about container creation. Any service written for 119 should just work out of the box. This would, however, requires the 119 distribution implementation to deal with the container creation. By default, it should probably create every container possible and register the service with each of them. If container instantiators appear later, it should register the service with the new container type. > This brings up a spec question for me...what is the desired/spec'd > behavior when multiple distribution systems are present (e.g. cxf, ecf, > etc)? Are all distribution providers expected to respond? Yes. I am pretty sure that this is the case. As I said before, consider the service to be written without knowing anything particular about the distribution software. That's the motivation for spec-ing something like 119 :-) Cheers, Jan.
Back to the top