+1 on 1).
+1 on 2). If all the system services are declarative, then "lookup" should
be fine without any ordering. I understand we have some extension points or
extensions are added programmatically by the module activators. A good
example is that all the module activators should be started by the ranking
and stopped by the reverse order.
+1 on 4). Removing "duplicate" modules is not always intuitive if a user
download an all-in-one distribution. It would be nice if they can co-exist
and Tuscany runtime will pick one by some means (such as ranking or some
kind of filter)
5): OSGi has the "filter" concept when a service is looked up from the
registry. By default it selects the one with highest ranking. Do you have a
good use case how Tuscany would require that?
Thanks,
Raymond
--------------------------------------------------
From: "ant elder" <[email protected]>
Sent: Thursday, May 21, 2009 12:14 AM
To: <[email protected]>
Subject: Re: Supporting an optional ranking attribute for system services
On Thu, May 21, 2009 at 8:01 AM, Simon Laws <[email protected]>
wrote:
On Thu, May 21, 2009 at 6:04 AM, ant elder <[email protected]> wrote:
Having a way to define "default" impls and have those easily overriden
would be really useful. We've often needed to be able to do that and
have clunky work arounds at various places to deal with not having any
defaulting mechanism. But there are several other problems with the
current discovery mechanism which it would be good to fix, some of
them have already been mentioned in this thread, here's the list i can
think of:
1) unable to define default impls and have an easy way to override the
default
2) random startup order so intermittent fails when a service looks up
another service during startup
4) how to choose when there are multiple impls
5) choose impls programaticaly at runtime so impls can enable/disable
themselves based on the environment
Before suggesting approaches on how to fix do we agree with that list
of things to fix?
...ant
I think 1 and 4 (what was 3?) are the same issue. Not sure about 5.
Sounds like a solution. I would prioritize as follows because 2 keeps
hurting us.
2) random startup order so intermittent fails when a service looks up
another service during startup
1) unable to define default impls and have an easy way to override the
default
Simon
Not sure what happened to (3) and just now I can't think what it might
have been :) I'll reply back if i think of it.
I had (1) and (4) separate because i think they're subtly different,
and I'm not totaly convinced yet that we really need much for (4) if
we have (1). For (1) a default impl would be included within the
tuscany base runtime and it should be easy for a user to add their own
jar on top of the base runtime and have the impl picked up from there
to override the default. For (4) its the user has included multiple
jars containing impls for the same system service on top of the base
runtime, thats the host-jetty/host-tomcat scenario and the simplest
fix seems to be just delete one of the jars, so if we have (1) then do
we really need to implement anything for (4).
...ant
