You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Raymond Feng <en...@gmail.com> on 2009/05/19 01:59:29 UTC
Supporting an optional ranking attribute for system services
Hi,
In Tuscany, we can declare service implementations using the META-INF/services/<SPI name> pattern. One of the use cases is to allow some of the implementations to be replaced to fit the hosting environment. If there are more than one services with the same name are available, we randomly pick the "first" one. This makes the "replacement" not straightforward.
To fix this problem, I added the support for the "ranking" attribute (FYI, OSGi has the idea for services). The discovered system services will be sorted based on the ranking (if not present, default to 0). For example, we can use it to control which embedded HTTP server (Tomcat or Jetty) is used. The attribute can be potentially used to define the ordering of multiple extensions for the same extension point.
Thanks,
Raymond
Re: Supporting an optional ranking attribute for system services
Posted by Luciano Resende <lu...@gmail.com>.
On Tue, May 19, 2009 at 9:13 AM, ant elder <an...@apache.org> wrote:
> On Tue, May 19, 2009 at 4:54 PM, Raymond Feng <en...@gmail.com> wrote:
>> It's easy. The user can just add a "fragment" module that only contains the
>> META-INF/services declarations. For example, if the default ranking for
>> Jetty is 1 and Tomcat is 2 and the user wants to use Jetty instead of
>> Tomcat, he/she can just add a new declaration for Jetty using ranking 3.
>>
>> Thanks,
>> Raymond
>>
>
> Wouldn't it be (a lot) easier for the user to just remove the tomcat module?
>
> I think we need to step back a bit and all understand the use cases.
> We've currently got tuscany as lots of little modules so you can
> configure a system by choosing the modules you want to include, and
> working that way i'm not sure i see why we need a ranking mechanism.
> If we want to just include all the tuscany modules and then configure
> a runtime then explicitly configuring which modules to activate and
> the order they start may be easier and more flexible than a ranking
> system. And an explicit config file would also do what you need in the
> use case you're describing wouldn't it?
>
> ...ant
>
I think we are getting confused because we are discussing two issues
on the same thread, let's concentrate on the "ranking attribute"
discussion here, and leave the Tomcat/Jetty for a different thread.
Let me give a concrete use case :
I have a module activator in "tuscany-web-javascript-dojo" that
register Dojo uri to servletHosts. In this case, I need to make sure
that some servletHost have been started before I can use it. Luckly,
99% of the time, the servletHosts extension is starting first and
things are working ok, but once in a while, there are issues and we
get NPE because the servletHosts is not available as described in
TUSCANY-2984.
[1] https://issues.apache.org/jira/browse/TUSCANY-2984
--
Luciano Resende
Apache Tuscany, Apache PhotArk
http://people.apache.org/~lresende
http://lresende.blogspot.com/
Re: Supporting an optional ranking attribute for system services
Posted by ant elder <an...@apache.org>.
On Thu, May 28, 2009 at 5:54 PM, Luciano Resende <lu...@gmail.com> wrote:
> On Thu, May 28, 2009 at 12:08 AM, ant elder <an...@apache.org> wrote:
>> On Wed, May 27, 2009 at 6:14 PM, Luciano Resende <lu...@gmail.com> wrote:
>>> On Wed, May 27, 2009 at 12:40 AM, ant elder <an...@apache.org> wrote:
>>>> What would be nice if this "just worked" for users who add their own
>>>> extension impls without the user needing to do anything special.
>>>>
>>>> As an example, we've the host-jms-asf module that users need to
>>>> include a dependency on if they want to use tuscany JMS services, or
>>>> if they want to have their own jms host they need to exclude
>>>> host-jms-asf and add their own new module. It would be much nicer if
>>>> Tuscany just used host-jms-asf by default if nothing else was
>>>> provided, but if there was another jms host available then the other
>>>> one would be used over the default host-jms-asf one.
>>>>
>>>
>>> This would probably work in the case where we are providing only one
>>> extension for a given thing, in the case of web 2.0, we have two
>>> versions of the same extension (JavaScript generation for
>>> Implementation Widget).... or the case where we have two embedded http
>>> stack supported (tomcat and jetty)
>>>
>>>> One way that could work is if a system service impl class name starts
>>>> with "Default" then its always replaced if there's another class
>>>> registered, and that seems quite simple and easy to understand.
>>>>
>>>
>>> On the example above, let's say we make Tomcat default, and add tomcat
>>> and jetty to our distribution.... Following what you described, Tomca
>>> is default, but there is another impl (jetty) which will always be
>>> used... how users will be able to select Tomcat ?
>>>
>>>> A problem with the ranking approach is that it doesn't seem obvious
>>>> what a ranking means without knowing all the other rankings - eg, if
>>>> my new host-jms-foo module uses a ranking of 423 will it be used?
>>>>
>>>> Same issue with the start sequence, it would be simple and obvious if
>>>> there as some file that explicitly listed the services that must be
>>>> started before others, but that start sequence is hard to see just by
>>>> looking at individual ranking values.
>>>>
>>>
>>> I was wondering if we could try to use policy here
>>>
>>> <binding.http requires="tomcat / jetty" />
>>>
>>> But I need to think more about the scenarios, and I don' t think this
>>> would work in all scenarios...
>>> We might need couple different solutions to address all scenarios
>>>
>>>
>>> --
>>> Luciano Resende
>>> Apache Tuscany, Apache PhotArk
>>> http://people.apache.org/~lresende
>>> http://lresende.blogspot.com/
>>>
>>
>> I still don't think we need to make it so complicated. We have things
>> like host-tomcat and host-jetty in separate jars so its already easy
>> to control which gets used by just using only that one jar. Even
>> relative Java newbies will understand that so do we really need
>> anything more?
>>
>
> This does not work all the time, an example is the store sample, where
> it has explicitly chosen a specific host, but when you run most of the
> times you will get the other one probably because some other module
> declare a dependency or test dependency on the other host. Anyway, I
> believe that most of the suggestions here would not affect the user
> ability to play with the classpath.
>
Well that surely is just a bug in the store sample we should fix
instead of implementing all this!
I can see people are getting wedded to ranking so how about we try
both approaches for now? We could revisit closer to 2.0 final and for
now support both the simple approach as well as the approach of adding
a new "fragment" module that only contains the META-INF/services
declarations using some random ranking number and packaging that up in
a jar and adding it to the classpath. I wonder how long it will be
before someone ends up with multiple ranking fragment jars and wants a
ranking for the rankings ;)
...ant
Re: Supporting an optional ranking attribute for system services
Posted by Luciano Resende <lu...@gmail.com>.
On Thu, May 28, 2009 at 12:08 AM, ant elder <an...@apache.org> wrote:
> On Wed, May 27, 2009 at 6:14 PM, Luciano Resende <lu...@gmail.com> wrote:
>> On Wed, May 27, 2009 at 12:40 AM, ant elder <an...@apache.org> wrote:
>>> What would be nice if this "just worked" for users who add their own
>>> extension impls without the user needing to do anything special.
>>>
>>> As an example, we've the host-jms-asf module that users need to
>>> include a dependency on if they want to use tuscany JMS services, or
>>> if they want to have their own jms host they need to exclude
>>> host-jms-asf and add their own new module. It would be much nicer if
>>> Tuscany just used host-jms-asf by default if nothing else was
>>> provided, but if there was another jms host available then the other
>>> one would be used over the default host-jms-asf one.
>>>
>>
>> This would probably work in the case where we are providing only one
>> extension for a given thing, in the case of web 2.0, we have two
>> versions of the same extension (JavaScript generation for
>> Implementation Widget).... or the case where we have two embedded http
>> stack supported (tomcat and jetty)
>>
>>> One way that could work is if a system service impl class name starts
>>> with "Default" then its always replaced if there's another class
>>> registered, and that seems quite simple and easy to understand.
>>>
>>
>> On the example above, let's say we make Tomcat default, and add tomcat
>> and jetty to our distribution.... Following what you described, Tomca
>> is default, but there is another impl (jetty) which will always be
>> used... how users will be able to select Tomcat ?
>>
>>> A problem with the ranking approach is that it doesn't seem obvious
>>> what a ranking means without knowing all the other rankings - eg, if
>>> my new host-jms-foo module uses a ranking of 423 will it be used?
>>>
>>> Same issue with the start sequence, it would be simple and obvious if
>>> there as some file that explicitly listed the services that must be
>>> started before others, but that start sequence is hard to see just by
>>> looking at individual ranking values.
>>>
>>
>> I was wondering if we could try to use policy here
>>
>> <binding.http requires="tomcat / jetty" />
>>
>> But I need to think more about the scenarios, and I don' t think this
>> would work in all scenarios...
>> We might need couple different solutions to address all scenarios
>>
>>
>> --
>> Luciano Resende
>> Apache Tuscany, Apache PhotArk
>> http://people.apache.org/~lresende
>> http://lresende.blogspot.com/
>>
>
> I still don't think we need to make it so complicated. We have things
> like host-tomcat and host-jetty in separate jars so its already easy
> to control which gets used by just using only that one jar. Even
> relative Java newbies will understand that so do we really need
> anything more?
>
This does not work all the time, an example is the store sample, where
it has explicitly chosen a specific host, but when you run most of the
times you will get the other one probably because some other module
declare a dependency or test dependency on the other host. Anyway, I
believe that most of the suggestions here would not affect the user
ability to play with the classpath.
--
Luciano Resende
Apache Tuscany, Apache PhotArk
http://people.apache.org/~lresende
http://lresende.blogspot.com/
Re: Supporting an optional ranking attribute for system services
Posted by ant elder <an...@apache.org>.
On Wed, May 27, 2009 at 6:14 PM, Luciano Resende <lu...@gmail.com> wrote:
> On Wed, May 27, 2009 at 12:40 AM, ant elder <an...@apache.org> wrote:
>> What would be nice if this "just worked" for users who add their own
>> extension impls without the user needing to do anything special.
>>
>> As an example, we've the host-jms-asf module that users need to
>> include a dependency on if they want to use tuscany JMS services, or
>> if they want to have their own jms host they need to exclude
>> host-jms-asf and add their own new module. It would be much nicer if
>> Tuscany just used host-jms-asf by default if nothing else was
>> provided, but if there was another jms host available then the other
>> one would be used over the default host-jms-asf one.
>>
>
> This would probably work in the case where we are providing only one
> extension for a given thing, in the case of web 2.0, we have two
> versions of the same extension (JavaScript generation for
> Implementation Widget).... or the case where we have two embedded http
> stack supported (tomcat and jetty)
>
>> One way that could work is if a system service impl class name starts
>> with "Default" then its always replaced if there's another class
>> registered, and that seems quite simple and easy to understand.
>>
>
> On the example above, let's say we make Tomcat default, and add tomcat
> and jetty to our distribution.... Following what you described, Tomca
> is default, but there is another impl (jetty) which will always be
> used... how users will be able to select Tomcat ?
>
>> A problem with the ranking approach is that it doesn't seem obvious
>> what a ranking means without knowing all the other rankings - eg, if
>> my new host-jms-foo module uses a ranking of 423 will it be used?
>>
>> Same issue with the start sequence, it would be simple and obvious if
>> there as some file that explicitly listed the services that must be
>> started before others, but that start sequence is hard to see just by
>> looking at individual ranking values.
>>
>
> I was wondering if we could try to use policy here
>
> <binding.http requires="tomcat / jetty" />
>
> But I need to think more about the scenarios, and I don' t think this
> would work in all scenarios...
> We might need couple different solutions to address all scenarios
>
>
> --
> Luciano Resende
> Apache Tuscany, Apache PhotArk
> http://people.apache.org/~lresende
> http://lresende.blogspot.com/
>
I still don't think we need to make it so complicated. We have things
like host-tomcat and host-jetty in separate jars so its already easy
to control which gets used by just using only that one jar. Even
relative Java newbies will understand that so do we really need
anything more?
...ant
Re: Supporting an optional ranking attribute for system services
Posted by Luciano Resende <lu...@gmail.com>.
On Wed, May 27, 2009 at 12:40 AM, ant elder <an...@apache.org> wrote:
> What would be nice if this "just worked" for users who add their own
> extension impls without the user needing to do anything special.
>
> As an example, we've the host-jms-asf module that users need to
> include a dependency on if they want to use tuscany JMS services, or
> if they want to have their own jms host they need to exclude
> host-jms-asf and add their own new module. It would be much nicer if
> Tuscany just used host-jms-asf by default if nothing else was
> provided, but if there was another jms host available then the other
> one would be used over the default host-jms-asf one.
>
This would probably work in the case where we are providing only one
extension for a given thing, in the case of web 2.0, we have two
versions of the same extension (JavaScript generation for
Implementation Widget).... or the case where we have two embedded http
stack supported (tomcat and jetty)
> One way that could work is if a system service impl class name starts
> with "Default" then its always replaced if there's another class
> registered, and that seems quite simple and easy to understand.
>
On the example above, let's say we make Tomcat default, and add tomcat
and jetty to our distribution.... Following what you described, Tomca
is default, but there is another impl (jetty) which will always be
used... how users will be able to select Tomcat ?
> A problem with the ranking approach is that it doesn't seem obvious
> what a ranking means without knowing all the other rankings - eg, if
> my new host-jms-foo module uses a ranking of 423 will it be used?
>
> Same issue with the start sequence, it would be simple and obvious if
> there as some file that explicitly listed the services that must be
> started before others, but that start sequence is hard to see just by
> looking at individual ranking values.
>
I was wondering if we could try to use policy here
<binding.http requires="tomcat / jetty" />
But I need to think more about the scenarios, and I don' t think this
would work in all scenarios...
We might need couple different solutions to address all scenarios
--
Luciano Resende
Apache Tuscany, Apache PhotArk
http://people.apache.org/~lresende
http://lresende.blogspot.com/
Re: Supporting an optional ranking attribute for system services
Posted by ant elder <an...@apache.org>.
What would be nice if this "just worked" for users who add their own
extension impls without the user needing to do anything special.
As an example, we've the host-jms-asf module that users need to
include a dependency on if they want to use tuscany JMS services, or
if they want to have their own jms host they need to exclude
host-jms-asf and add their own new module. It would be much nicer if
Tuscany just used host-jms-asf by default if nothing else was
provided, but if there was another jms host available then the other
one would be used over the default host-jms-asf one.
One way that could work is if a system service impl class name starts
with "Default" then its always replaced if there's another class
registered, and that seems quite simple and easy to understand.
A problem with the ranking approach is that it doesn't seem obvious
what a ranking means without knowing all the other rankings - eg, if
my new host-jms-foo module uses a ranking of 423 will it be used?
Same issue with the start sequence, it would be simple and obvious if
there as some file that explicitly listed the services that must be
started before others, but that start sequence is hard to see just by
looking at individual ranking values.
...ant
On Thu, May 21, 2009 at 4:45 PM, Raymond Feng <en...@gmail.com> wrote:
> +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" <an...@apache.org>
> Sent: Thursday, May 21, 2009 12:14 AM
> To: <de...@tuscany.apache.org>
> Subject: Re: Supporting an optional ranking attribute for system services
>
>> On Thu, May 21, 2009 at 8:01 AM, Simon Laws <si...@googlemail.com>
>> wrote:
>>>
>>> On Thu, May 21, 2009 at 6:04 AM, ant elder <an...@apache.org> 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
>
>
Re: Supporting an optional ranking attribute for system services
Posted by Raymond Feng <en...@gmail.com>.
+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" <an...@apache.org>
Sent: Thursday, May 21, 2009 12:14 AM
To: <de...@tuscany.apache.org>
Subject: Re: Supporting an optional ranking attribute for system services
> On Thu, May 21, 2009 at 8:01 AM, Simon Laws <si...@googlemail.com>
> wrote:
>> On Thu, May 21, 2009 at 6:04 AM, ant elder <an...@apache.org> 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
Re: Supporting an optional ranking attribute for system services
Posted by ant elder <an...@apache.org>.
On Thu, May 21, 2009 at 8:01 AM, Simon Laws <si...@googlemail.com> wrote:
> On Thu, May 21, 2009 at 6:04 AM, ant elder <an...@apache.org> 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
Re: Supporting an optional ranking attribute for system services
Posted by Simon Laws <si...@googlemail.com>.
On Thu, May 21, 2009 at 6:04 AM, ant elder <an...@apache.org> 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
Re: Supporting an optional ranking attribute for system services
Posted by ant elder <an...@apache.org>.
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
On Tue, May 19, 2009 at 7:38 PM, Raymond Feng <en...@gmail.com> wrote:
> We have a lot of default implementations for the system services (for
> example, all the model factories, processors and system utilities) and the
> declarations of such services are not in a separate module which can be
> removed.
>
> Thanks,
> Raymond
> --------------------------------------------------
> From: "ant elder" <an...@apache.org>
> Sent: Tuesday, May 19, 2009 10:26 AM
> To: <de...@tuscany.apache.org>
> Subject: Re: Supporting an optional ranking attribute for system services
>
>> I still think we need to understand a more complete picture.
>>
>> If its just to enable using different ContributionClassLoaderProvider
>> impls then maybe ContributionClassLoaderProvider should just be in a
>> separate module so it can be removed if someone wants to use their
>> own. Would that solve this particular problem without needing the
>> complications of a new ranking system?
>>
>> ...ant
>>
>> On Tue, May 19, 2009 at 5:58 PM, Raymond Feng <en...@gmail.com> wrote:
>>>
>>> Hi,
>>>
>>> My original proposal is not only just for pluggable extensions which can
>>> be
>>> easily removed. The primary use case is for vendors to embed Tuscany and
>>> replace some of the system functions. For example, we have the
>>> ContributionClassLoaderProvider and Tuscany provides a default
>>> implementation. If the vendor decides to override that, a new module will
>>> be
>>> added but the default one from Tuscany is still there. Now the one from
>>> the
>>> vendor has higher ranking and it will be the effective one.
>>> We can potentially leverage the idea to control the ordering of the
>>> module
>>> activators and other extensions for a given extension point.
>>>
>>> The selection of a set of modules to form a Tuscany runtime is a
>>> different
>>> topic. We now have the feature/profile idea to group them.
>>>
>>> Thanks,
>>> Raymond
>>>
>>> --------------------------------------------------
>>> From: "ant elder" <an...@apache.org>
>>> Sent: Tuesday, May 19, 2009 9:13 AM
>>> To: <de...@tuscany.apache.org>
>>> Subject: Re: Supporting an optional ranking attribute for system services
>>>
>>>> On Tue, May 19, 2009 at 4:54 PM, Raymond Feng <en...@gmail.com>
>>>> wrote:
>>>>>
>>>>> It's easy. The user can just add a "fragment" module that only contains
>>>>> the
>>>>> META-INF/services declarations. For example, if the default ranking for
>>>>> Jetty is 1 and Tomcat is 2 and the user wants to use Jetty instead of
>>>>> Tomcat, he/she can just add a new declaration for Jetty using ranking
>>>>> 3.
>>>>>
>>>>> Thanks,
>>>>> Raymond
>>>>>
>>>>
>>>> Wouldn't it be (a lot) easier for the user to just remove the tomcat
>>>> module?
>>>>
>>>> I think we need to step back a bit and all understand the use cases.
>>>> We've currently got tuscany as lots of little modules so you can
>>>> configure a system by choosing the modules you want to include, and
>>>> working that way i'm not sure i see why we need a ranking mechanism.
>>>> If we want to just include all the tuscany modules and then configure
>>>> a runtime then explicitly configuring which modules to activate and
>>>> the order they start may be easier and more flexible than a ranking
>>>> system. And an explicit config file would also do what you need in the
>>>> use case you're describing wouldn't it?
>>>>
>>>> ...ant
>>>
>>>
>
Re: Supporting an optional ranking attribute for system services
Posted by Raymond Feng <en...@gmail.com>.
We have a lot of default implementations for the system services (for
example, all the model factories, processors and system utilities) and the
declarations of such services are not in a separate module which can be
removed.
Thanks,
Raymond
--------------------------------------------------
From: "ant elder" <an...@apache.org>
Sent: Tuesday, May 19, 2009 10:26 AM
To: <de...@tuscany.apache.org>
Subject: Re: Supporting an optional ranking attribute for system services
> I still think we need to understand a more complete picture.
>
> If its just to enable using different ContributionClassLoaderProvider
> impls then maybe ContributionClassLoaderProvider should just be in a
> separate module so it can be removed if someone wants to use their
> own. Would that solve this particular problem without needing the
> complications of a new ranking system?
>
> ...ant
>
> On Tue, May 19, 2009 at 5:58 PM, Raymond Feng <en...@gmail.com> wrote:
>> Hi,
>>
>> My original proposal is not only just for pluggable extensions which can
>> be
>> easily removed. The primary use case is for vendors to embed Tuscany and
>> replace some of the system functions. For example, we have the
>> ContributionClassLoaderProvider and Tuscany provides a default
>> implementation. If the vendor decides to override that, a new module will
>> be
>> added but the default one from Tuscany is still there. Now the one from
>> the
>> vendor has higher ranking and it will be the effective one.
>> We can potentially leverage the idea to control the ordering of the
>> module
>> activators and other extensions for a given extension point.
>>
>> The selection of a set of modules to form a Tuscany runtime is a
>> different
>> topic. We now have the feature/profile idea to group them.
>>
>> Thanks,
>> Raymond
>>
>> --------------------------------------------------
>> From: "ant elder" <an...@apache.org>
>> Sent: Tuesday, May 19, 2009 9:13 AM
>> To: <de...@tuscany.apache.org>
>> Subject: Re: Supporting an optional ranking attribute for system services
>>
>>> On Tue, May 19, 2009 at 4:54 PM, Raymond Feng <en...@gmail.com>
>>> wrote:
>>>>
>>>> It's easy. The user can just add a "fragment" module that only contains
>>>> the
>>>> META-INF/services declarations. For example, if the default ranking for
>>>> Jetty is 1 and Tomcat is 2 and the user wants to use Jetty instead of
>>>> Tomcat, he/she can just add a new declaration for Jetty using ranking
>>>> 3.
>>>>
>>>> Thanks,
>>>> Raymond
>>>>
>>>
>>> Wouldn't it be (a lot) easier for the user to just remove the tomcat
>>> module?
>>>
>>> I think we need to step back a bit and all understand the use cases.
>>> We've currently got tuscany as lots of little modules so you can
>>> configure a system by choosing the modules you want to include, and
>>> working that way i'm not sure i see why we need a ranking mechanism.
>>> If we want to just include all the tuscany modules and then configure
>>> a runtime then explicitly configuring which modules to activate and
>>> the order they start may be easier and more flexible than a ranking
>>> system. And an explicit config file would also do what you need in the
>>> use case you're describing wouldn't it?
>>>
>>> ...ant
>>
>>
Re: Supporting an optional ranking attribute for system services
Posted by ant elder <an...@apache.org>.
I still think we need to understand a more complete picture.
If its just to enable using different ContributionClassLoaderProvider
impls then maybe ContributionClassLoaderProvider should just be in a
separate module so it can be removed if someone wants to use their
own. Would that solve this particular problem without needing the
complications of a new ranking system?
...ant
On Tue, May 19, 2009 at 5:58 PM, Raymond Feng <en...@gmail.com> wrote:
> Hi,
>
> My original proposal is not only just for pluggable extensions which can be
> easily removed. The primary use case is for vendors to embed Tuscany and
> replace some of the system functions. For example, we have the
> ContributionClassLoaderProvider and Tuscany provides a default
> implementation. If the vendor decides to override that, a new module will be
> added but the default one from Tuscany is still there. Now the one from the
> vendor has higher ranking and it will be the effective one.
> We can potentially leverage the idea to control the ordering of the module
> activators and other extensions for a given extension point.
>
> The selection of a set of modules to form a Tuscany runtime is a different
> topic. We now have the feature/profile idea to group them.
>
> Thanks,
> Raymond
>
> --------------------------------------------------
> From: "ant elder" <an...@apache.org>
> Sent: Tuesday, May 19, 2009 9:13 AM
> To: <de...@tuscany.apache.org>
> Subject: Re: Supporting an optional ranking attribute for system services
>
>> On Tue, May 19, 2009 at 4:54 PM, Raymond Feng <en...@gmail.com> wrote:
>>>
>>> It's easy. The user can just add a "fragment" module that only contains
>>> the
>>> META-INF/services declarations. For example, if the default ranking for
>>> Jetty is 1 and Tomcat is 2 and the user wants to use Jetty instead of
>>> Tomcat, he/she can just add a new declaration for Jetty using ranking 3.
>>>
>>> Thanks,
>>> Raymond
>>>
>>
>> Wouldn't it be (a lot) easier for the user to just remove the tomcat
>> module?
>>
>> I think we need to step back a bit and all understand the use cases.
>> We've currently got tuscany as lots of little modules so you can
>> configure a system by choosing the modules you want to include, and
>> working that way i'm not sure i see why we need a ranking mechanism.
>> If we want to just include all the tuscany modules and then configure
>> a runtime then explicitly configuring which modules to activate and
>> the order they start may be easier and more flexible than a ranking
>> system. And an explicit config file would also do what you need in the
>> use case you're describing wouldn't it?
>>
>> ...ant
>
>
Re: Supporting an optional ranking attribute for system services
Posted by Raymond Feng <en...@gmail.com>.
Hi,
My original proposal is not only just for pluggable extensions which can be
easily removed. The primary use case is for vendors to embed Tuscany and
replace some of the system functions. For example, we have the
ContributionClassLoaderProvider and Tuscany provides a default
implementation. If the vendor decides to override that, a new module will be
added but the default one from Tuscany is still there. Now the one from the
vendor has higher ranking and it will be the effective one.
We can potentially leverage the idea to control the ordering of the module
activators and other extensions for a given extension point.
The selection of a set of modules to form a Tuscany runtime is a different
topic. We now have the feature/profile idea to group them.
Thanks,
Raymond
--------------------------------------------------
From: "ant elder" <an...@apache.org>
Sent: Tuesday, May 19, 2009 9:13 AM
To: <de...@tuscany.apache.org>
Subject: Re: Supporting an optional ranking attribute for system services
> On Tue, May 19, 2009 at 4:54 PM, Raymond Feng <en...@gmail.com> wrote:
>> It's easy. The user can just add a "fragment" module that only contains
>> the
>> META-INF/services declarations. For example, if the default ranking for
>> Jetty is 1 and Tomcat is 2 and the user wants to use Jetty instead of
>> Tomcat, he/she can just add a new declaration for Jetty using ranking 3.
>>
>> Thanks,
>> Raymond
>>
>
> Wouldn't it be (a lot) easier for the user to just remove the tomcat
> module?
>
> I think we need to step back a bit and all understand the use cases.
> We've currently got tuscany as lots of little modules so you can
> configure a system by choosing the modules you want to include, and
> working that way i'm not sure i see why we need a ranking mechanism.
> If we want to just include all the tuscany modules and then configure
> a runtime then explicitly configuring which modules to activate and
> the order they start may be easier and more flexible than a ranking
> system. And an explicit config file would also do what you need in the
> use case you're describing wouldn't it?
>
> ...ant
Re: Supporting an optional ranking attribute for system services
Posted by ant elder <an...@apache.org>.
On Tue, May 19, 2009 at 4:54 PM, Raymond Feng <en...@gmail.com> wrote:
> It's easy. The user can just add a "fragment" module that only contains the
> META-INF/services declarations. For example, if the default ranking for
> Jetty is 1 and Tomcat is 2 and the user wants to use Jetty instead of
> Tomcat, he/she can just add a new declaration for Jetty using ranking 3.
>
> Thanks,
> Raymond
>
Wouldn't it be (a lot) easier for the user to just remove the tomcat module?
I think we need to step back a bit and all understand the use cases.
We've currently got tuscany as lots of little modules so you can
configure a system by choosing the modules you want to include, and
working that way i'm not sure i see why we need a ranking mechanism.
If we want to just include all the tuscany modules and then configure
a runtime then explicitly configuring which modules to activate and
the order they start may be easier and more flexible than a ranking
system. And an explicit config file would also do what you need in the
use case you're describing wouldn't it?
...ant
Re: Supporting an optional ranking attribute for system services
Posted by Luciano Resende <lu...@gmail.com>.
On Tue, May 19, 2009 at 8:54 AM, Raymond Feng <en...@gmail.com> wrote:
> It's easy. The user can just add a "fragment" module that only contains the
> META-INF/services declarations. For example, if the default ranking for
> Jetty is 1 and Tomcat is 2 and the user wants to use Jetty instead of
> Tomcat, he/she can just add a new declaration for Jetty using ranking 3.
>
I have just downloaded Tuscany release, and I'm building an
application... and I want to define that I want to use Jetty. Where
would I do this based on this proposal ?
--
Luciano Resende
Apache Tuscany, Apache PhotArk
http://people.apache.org/~lresende
http://lresende.blogspot.com/
Re: Supporting an optional ranking attribute for system services
Posted by Raymond Feng <en...@gmail.com>.
It's easy. The user can just add a "fragment" module that only contains the
META-INF/services declarations. For example, if the default ranking for
Jetty is 1 and Tomcat is 2 and the user wants to use Jetty instead of
Tomcat, he/she can just add a new declaration for Jetty using ranking 3.
Thanks,
Raymond
--------------------------------------------------
From: "ant elder" <an...@gmail.com>
Sent: Tuesday, May 19, 2009 12:11 AM
To: <de...@tuscany.apache.org>
Subject: Re: Supporting an optional ranking attribute for system services
> On Tue, May 19, 2009 at 12:59 AM, Raymond Feng <en...@gmail.com>
> wrote:
>> Hi,
>>
>> In Tuscany, we can declare service implementations using the
>> META-INF/services/<SPI name> pattern. One of the use cases is to allow
>> some
>> of the implementations to be replaced to fit the hosting environment. If
>> there are more than one services with the same name are available, we
>> randomly pick the "first" one. This makes the "replacement" not
>> straightforward.
>>
>> To fix this problem, I added the support for the "ranking" attribute
>> (FYI,
>> OSGi has the idea for services). The discovered system services will be
>> sorted based on the ranking (if not present, default to 0). For example,
>> we
>> can use it to control which embedded HTTP server (Tomcat or Jetty) is
>> used.
>> The attribute can be potentially used to define the ordering of multiple
>> extensions for the same extension point.
>>
>> Thanks,
>> Raymond
>
> I guess it would fix the random choice but a ranking approach doesn't
> really make this any more flexible does it? The problem is that users
> can't easily change the ranking - if we set the Jetty servlet host to
> have a higher ranking than the tomcat one then how do users who want
> to use Tomcat do that?
>
> How about instead changing to use a config file where you can say
> explicitly which extensions to use? That would fix this and some other
> issues that we have with the current approach.
>
> ...ant
Re: Supporting an optional ranking attribute for system services
Posted by Luciano Resende <lu...@gmail.com>.
On Tue, May 19, 2009 at 12:11 AM, ant elder <an...@gmail.com> wrote:
> On Tue, May 19, 2009 at 12:59 AM, Raymond Feng <en...@gmail.com> wrote:
>> Hi,
>>
>> In Tuscany, we can declare service implementations using the
>> META-INF/services/<SPI name> pattern. One of the use cases is to allow some
>> of the implementations to be replaced to fit the hosting environment. If
>> there are more than one services with the same name are available, we
>> randomly pick the "first" one. This makes the "replacement" not
>> straightforward.
>>
>> To fix this problem, I added the support for the "ranking" attribute (FYI,
>> OSGi has the idea for services). The discovered system services will be
>> sorted based on the ranking (if not present, default to 0). For example, we
>> can use it to control which embedded HTTP server (Tomcat or Jetty) is used.
>> The attribute can be potentially used to define the ordering of multiple
>> extensions for the same extension point.
>>
>> Thanks,
>> Raymond
>
> I guess it would fix the random choice but a ranking approach doesn't
> really make this any more flexible does it? The problem is that users
> can't easily change the ranking - if we set the Jetty servlet host to
> have a higher ranking than the tomcat one then how do users who want
> to use Tomcat do that?
>
> How about instead changing to use a config file where you can say
> explicitly which extensions to use? That would fix this and some other
> issues that we have with the current approach.
>
> ...ant
>
I guess we need both, the ranking mechanism would allow us to start
the tomcat/jetty extension before a binding or another extension needs
the servletHost.
Now, on what ant is suggesting, I also think we ned a way to define if
we want to use tomcat/jetty, as the classpath technique does not work
perfectly all the time... but I'm not sure if I wanted to introduce
another configuration file just for this, maybe something on the
composite or definitions.xml, but I need to think a little more about
a perfect solution here.
--
Luciano Resende
Apache Tuscany, Apache PhotArk
http://people.apache.org/~lresende
http://lresende.blogspot.com/
Re: Supporting an optional ranking attribute for system services
Posted by ant elder <an...@gmail.com>.
On Tue, May 19, 2009 at 12:59 AM, Raymond Feng <en...@gmail.com> wrote:
> Hi,
>
> In Tuscany, we can declare service implementations using the
> META-INF/services/<SPI name> pattern. One of the use cases is to allow some
> of the implementations to be replaced to fit the hosting environment. If
> there are more than one services with the same name are available, we
> randomly pick the "first" one. This makes the "replacement" not
> straightforward.
>
> To fix this problem, I added the support for the "ranking" attribute (FYI,
> OSGi has the idea for services). The discovered system services will be
> sorted based on the ranking (if not present, default to 0). For example, we
> can use it to control which embedded HTTP server (Tomcat or Jetty) is used.
> The attribute can be potentially used to define the ordering of multiple
> extensions for the same extension point.
>
> Thanks,
> Raymond
I guess it would fix the random choice but a ranking approach doesn't
really make this any more flexible does it? The problem is that users
can't easily change the ranking - if we set the Jetty servlet host to
have a higher ranking than the tomcat one then how do users who want
to use Tomcat do that?
How about instead changing to use a config file where you can say
explicitly which extensions to use? That would fix this and some other
issues that we have with the current approach.
...ant