Pablo Lalloni wrote:
This proposal sounds ok to me, but if I understand your problem correctly, it could be easily implemented with the current implementation, just using symbols.
Example follows...
<service-point id="ServiceDependingOnAnotherServiceThatChangesDependingOnTier" interface="...">
<invoke-factory>
<set-service property="..." service-id="${service.implementation}"/>
</invoke-factory>
</service-point>
<contribution configuration-id="hivemind.FactoryDefaults">
<default symbol="service.implementation" value="TheDefaultServiceImplementationServicePoint"/>
</contribution>
Then, in client side you could make another contribution setting the default for that symbol pointing to client side implementation, like...
<contribution configuration-id="hivemind.ApplicationDefaults">
<default symbol="service.implementation" value="TheClientSideServiceImplementationServicePoint"/>
</contribution>
Also, you could implement your own "TierAwareSymbolSource" that based on a configured current-tier and some contributed mappings [symbol, tier, value], can resolve appropriately the service-id (or anything) for a given symbol.
But maybe there are some other facets of your particular case that I didn't understand correctly.
Also, this doesn't mean I don't support your proposal, I think that it could be a nicer way of doing this. B)
I hope this can be useful.
El Jue 21 Abr 2005 08:35, Liebig, Stefan escribi�:
I would like to discuss the current overriding solution for services (again). I think that it is not sufficent, at least not for the use case that we have.
A few time ago I posted an alternative approach for this problem, but the response was very weak, except one consent. What I have missed to explain was the motivation for the proposal. So here it is.
Our use case is the following: We are building a framework using HiveMind, the framework is used on both client and server side and this framework is used by our customers. Our client is a Java client that communicates via web services with the server. There are client/server parts which are common and parts which are different. However, we have services which are declared (not yet implemented) in the common part and different implementations based on client/server side. So far this works quite well. But know we have the requirement that our customers would like to override our �default� implementations. The current implementation of overidable services prevents that, because our server/client implementation is already the �override�. But it should be the default.
The approach I posted a few weeks ago could solve this and by choosing the appropriate default values for the new attributes, this proposal would be compatible to hivemind 1.0. The current solution is not compatible to 1.0
I simply attach here my first posting/proposal:
Could we not add two attributes to the existing service point/implementation elements to support this? Such as:
<service-point id=".." .. overridable="true"/> <implementation service-id=".." type="default"/> <implementation service-id=".." type="override"/>
With: [EMAIL PROTECTED]: not requiered, ( true | false ), default value = false [EMAIL PROTECTED]: not requiered, ( default | override ), default value = default
[EMAIL PROTECTED] defines whether a service is overridable or not. Default behaviour is like it is today, which is not overridable. [EMAIL PROTECTED] defines whether the implementation is a default implementation or the overriden implementation. Default is �default�, so that the behaviour is as today.
An �inlined� implementation is a final (not overridable) implementation if [EMAIL PROTECTED] is false. If [EMAIL PROTECTED] is true than the �inlined� implementation is a default (overridable) implementation.
Conflicts (HiveMind error): [EMAIL PROTECTED] == false && [EMAIL PROTECTED] == override are there any other possible conflicts?
Stefan
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
