Another way is to create an own ServiceImplementationFactory that chooses
the "correct" implementation from a list of contributed implementations.
A usage ´code´ snippet looks like this:
<!-- The ´naked´ service point, all overridable services would use the same
OverridableServiceBuilder. -->
<service-point id="Base"
interface="de.compeople.spirit.core.base.microkernel.servicebuilder.IBase">
<invoke-factory
service-id="spirit.core.base.servicebuilder.OverridableServiceBuilder"/>
</service-point>
<!-- Default implementation: this contribution tells the
OverridableServiceBuilder that
the ´default´ implementation for the service with id ´Base´ is an instance
of class ´...Default´ -->
<contribution
configuration-id="spirit.core.base.servicebuilder.OverridableServices">
<implementation service-id="Base" type="default"
implementation="instance:de.compeople.spirit.core.base.microkernel.servicebuilder.Default"/>
</contribution>
<!-- Override implementation this contribution tells the
OverridableServiceBuilder that
the ´override´ implementation for the service with id ´Base´ is an
instance of class ´...Override´ -->
<contribution
configuration-id="spirit.core.base.servicebuilder.OverridableServices">
<implementation service-id="Base" type="override"
implementation="instance:de.compeople.spirit.core.base.microkernel.servicebuilder.Override"/>
</contribution>The ´OverridableServiceBuilder´ checks for any conflicts such as doubled ´overrides´ and returns the desired implementation. Of course, the ´implementations´ specified in the contributions must implement the interface of the service point. However, there are no restrictions on the interface as you would have when using the ChainFactory. This ´pattern´ could be easily extended to perform other strategies for selecting the desired implementation, e.g. the ´OverridableServiceBuilder´ could have parameters specifying a selection critiria. I think there is more than one way to get what you need. Just choose the one that fits your needs best. For me it was important to declare (mark) a service as being overridable and having explicit ´default´ and/or ´override´ implementations. Stefan ________________________________ Von: Hensley, Richard [mailto:[EMAIL PROTECTED] Gesendet: Do 16.06.2005 02:14 An: [email protected]; Glen Stampoultzis Betreff: RE: Overriding services There are a couple of ways to do this. The hivemind website documents using properties, the list has some other methods. My personal favorite it use a service with multiple contributed implementations. In this case you have a service that implements the interface and is constructed with a configuration-point. The configuration-point is contributions of implementation of the same interface that are ordered. The service then chooses from the contributions the SPI it wants. Your default out of the box jar provides a default implementation, your customer provides a custom implementation and contributes it to your configuration, your core service chooses the customers implementation over your standard implementation. I actually use a hivemind provided version of this called the ChainFactory. The first method in the chain that returns something resembling true stops the chain. In your case, you could document to your customers to return true if they handle the search, or false if they want the default to handle the search. <service-point id="TextMiner" interface="TextExtractor"> <invoke-factory service-id="hivemind.lib.ChainFactory"> <construct configuration-id="TextExtractor" /> </invoke-factory> </service-point> <configuration-point id="TextExtractor" schema-id="hivemind.lib.ChainContribution" /> <contribution configuration-id="TextExtractor"> <command id="Html" object="instance:HtmlTextExtractor,pattern=(?i).*\.(htm|html)$" /> <command id="Pdf" object="instance:PdfTextExtractor,pattern=(?i).*\.(pdf)$" /> </contribution> Releavent documentation http://jakarta.apache.org/hivemind/hivemind-lib/ChainFactory.html Richard -----Original Message----- From: Glen Stampoultzis [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 15, 2005 4:53 PM To: [email protected] Subject: Overriding services I was wondering whether it was possible to override service implementations? For instance, say I have a Lucene indexer as a default implementation for a search service and I would like to let my customer add a jar in that would override this by copying in a hivemind-aware jar file containing an alternative search implementation. Would this be possible easily? Regards, Glen Stampoultzis --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
<<winmail.dat>>
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
