On Thu, May 28, 2009 at 12:08 AM, ant elder <[email protected]> wrote: > On Wed, May 27, 2009 at 6:14 PM, Luciano Resende <[email protected]> wrote: >> On Wed, May 27, 2009 at 12:40 AM, ant elder <[email protected]> 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/
