On Wednesday, Mar 17, 2004, at 02:16 US/Pacific, Niclas Hedhman wrote:
On Wednesday 17 March 2004 17:34, Corey Jewett wrote:
Is there a replacement for ServiceManager/Serviceable that would allow me to resolve a service by ServiceDescriptor? Or perhaps some other mechanism entirely?
Stephen is pointing you to an example of a hook into Merlin's guts, which
allow you to "listen in" or to modify the Model on the fly.
You don't write in detail what you are trying to achieve, but I assume that
the services are to be exposed to the external world.
The Finder strategy was close, but I would prefer to stick with release 3.2.5 as it seems to be stable? In 3.2.5 there is not a CompositionModel, not the the commission() and resolve() methods of DeploymentModel. Therefore I came to the conclusion that there is no mechanism for instantiating service instances, from the DeploymentModel, in Merlin 3.2.5.
Instead I'm investigating using a Lifecycle Extension to load service entries into a master list. All services are singletons, but I'm concerned that the instance will be lazy-loaded and thereby cause a catch-22 where the service can't be found because it wasn't instantiated. It is acceptable to me that a service must know to declare itself as publishable. This strategy actually adds the potential for better control over what is published.
If that is the case,
you create the "Publishing Facility", which will receive a reference to the
Composition Model, via a Context entry, and it will then register itself as a
CompositionListener, for 'added' and 'removed' events.
The components should not need to know anything about that this mechanism is
in place.
The Composition package is a bit intimidating, but you will primarily be
looking at ComponentModel, its superclass DeploymentModel and perhaps
ContainmentModel.
As for different versions of the same service;
I assume you mean different versions of the same component.
You would need to ensure that they are in different <containers>, so that the
Classloading works properly, but other than that, it should be Ok.
If you need different versions of the same service, then you need to bring the
classloader hierarchy yet another level, and the resulting <container> will
NOT be able to expose both services (as classes will conflict in the higher
container.)
I somewhat don't see the purpose, but maybe you can explain your usecase.
I have a number of services that provide back-end data services. They all adhere to a basic request processor interface that won't change. The parameter for this interface is a org.dom4j.Element. All of my services are actually parameterized by an xml tree. We're building the system to scale so that there can be multiple service instances in different JVMs. The reasoning for versioning services is that older versions may be kept running to support other services, while newer services may require the new service. The backing classes for each service may conflict as you mentioned so I planned on putting each service in it's own container that is a sub-container of the core blocks. The core blocks would be publishers, db-pooling, etc. ASCII art:
+---------------------+
| Core Service Blocks |
+---------------------+
|
+---------------+----------------+
| | |
+----------+ +----------+ +----------+
| svc A, 1 | | svc A, 2 | | svc A, B |
+----------+ +----------+ +----------+I have several questions that derive from this scenario.
1) Can a block (a publisher) in core access a component in one of the sub-containers.
2) Would the composition strategy still be relevant in this scenario?
3) Am I correct that core services may be used as components in each service?
Thanks for your help, Corey
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
