On Thu, May 28, 2009 at 5:54 PM, Luciano Resende <[email protected]> wrote: > 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. >
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
