RE: Again: Overridable services

[Liebig, Stefan]

Title: RE: Again: Overridable services

Yes, that could be done and it was already described in 1.0 as a solution. But I think that this concept is worth enough to be made explicitly, instead of using symbol replacement.



-----Original Message-----
From: Pablo Lalloni [mailto:[EMAIL PROTECTED]]
Sent: Thu 21.04.2005 16:46
To: hivemind-dev@jakarta.apache.org
Cc: Liebig, Stefan
Subject: Re: Again: Overridable services

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

--
Pablo I. Lalloni <[EMAIL PROTECTED]>
Tel�fono +54 (11) 4347-3177
Proyecto Pampa
Direcci�n Inform�tica Tributaria
AFIP

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Remember: Silly is a state of Mind, Stupid is a way of Life.
                -- Dave Butler