Von: Knut Wannheden [mailto:[EMAIL PROTECTED]
Gesendet: Mo 25.04.2005 10:12
An: [email protected]
Betreff: Re: Again: Overridable services
Stefan,
Yes, please open an enhancement request in
JIRA.
IMO the 'overridable' attribute on <service-point> doesn't
feel quite
right. I think it is odd to declare a service point as overridable
in
one module while the default implementation is possibly declared
in
another module. Isn't this overridability really just a property of
the
implementation?
So a different solution would be to move the
'overrideable' attribute
to the implementation. In fact that does not quite
work when the
implementation is "inlined" into the <service-point>
declaration. It
would thus need to be declared for both
<create-instance> and
<invoke-factory>. Then the question arises
if the 'type' attribute is
still required? Also is 'final' maybe a better
name for the attribute?
--knut
On 4/25/05, Liebig, Stefan
<[EMAIL PROTECTED]> wrote:
> How to proceed?
> Shall
I make a �feature� request for this in JIRA?
>
>
________________________________
>
> Von: James Carman [mailto:[EMAIL PROTECTED]]
>
Gesendet: Do 21.04.2005 20:51
> An:
[email protected]
> Betreff: RE: Again: Overridable
services
>
>
> Yeah, that sounds about right. I guess it
would be better to allow there to be "default" implementations defined outside
the scope of the declaring module for the service
point.
>
>
-----Original
Message-----
> From:
Liebig, Stefan [mailto:[EMAIL PROTECTED]]
>
Sent: Thursday, April 21, 2005 2:49
PM
> To:
[email protected]
>
Subject: FW: Again: Overridable
services
>
> An
error?!
>
>
-----Original
Message-----
> From: James
Carman [mailto:[EMAIL PROTECTED]]
>
Sent: Thu 21.04.2005
20:01
> To:
[email protected]
>
Subject: RE: Again: Overridable
services
>
> There
are other possible conflicts. What if two implementations claim to
be
> the "default"
implementation?
>
>
-----Original
Message-----
> From:
Liebig, Stefan [mailto:[EMAIL PROTECTED]]
>
Sent: Thursday, April 21, 2005 7:35
AM
> To:
[email protected]
>
Subject: Again: Overridable
services
>
> 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]
>
>
---------------------------------------------------------------------
To
unsubscribe, e-mail: [EMAIL PROTECTED]
For
additional commands, e-mail:
[EMAIL PROTECTED]
