Hi! If I have a @Priority(100) public class MyAlternative implements Foo .. and @Priority(101) public class ABetterAlternative implements Foo .. Then ABetterAlternative will finally be chosen. This ordering can be changed via AfterTypeDiscovery#getAlternatives(). But the spec only says "returns the ordered list of enabled alternatives for the application.." But it does NOT define in which sorting this list is ordered ;) In OWB we hat the 'most important' alternative come first. It seems in Weld it is the other way around.

I have no problem with changing this in OWB, but I would like to get this clarified in our JavaDocs and spec.

LieGrue, strub _______________________________________________ cdi-dev mailing list cdi-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.

hi 2014-12-22 9:23 GMT+01:00 Jozef Hartinger <jharting(a)redhat.com&gt;: > On 12/20/2014 11:26 AM, Mark Struberg wrote: >> Hi! >> >> If I have a >> >> >> @Priority(100) >> public class MyAlternative implements Foo .. >> >> and >> >> >> @Priority(101) >> public class ABetterAlternative implements Foo .. >> >> >> Then ABetterAlternative will finally be chosen. >> >> This ordering can be changed via AfterTypeDiscovery#getAlternatives(). >> >> But the spec only says "returns the ordered list of enabled alternatives for the application.." >> >> But it does NOT define in which sorting this list is ordered ;) >> >> In OWB we hat the 'most important' alternative come first. It seems in Weld it is the other way around. > What sorting do you use for interceptors and decorators? until yesterday the same as for runtime

>> I have no problem with changing this in OWB, but I would like to get this clarified in our JavaDocs and spec. > Agreed. Go ahead and file an issue. >> LieGrue, >> strub >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. > _______________________________________________ > cdi-dev mailing list > cdi-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.

Why did you change that for interceptors and decorators?

Why did you change that for interceptors and decorators?

On 12/20/2014 11:26 AM, Mark Struberg wrote: > Hi! > > If I have a > > > @Priority(100) > public class MyAlternative implements Foo .. > > and > > > @Priority(101) > public class ABetterAlternative implements Foo .. > > > Then ABetterAlternative will finally be chosen. > > This ordering can be changed via AfterTypeDiscovery#getAlternatives(). > > But the spec only says "returns the ordered list of enabled alternatives for the application.." > > But it does NOT define in which sorting this list is ordered ;) > > In OWB we hat the 'most important' alternative come first. It seems in Weld it is the other way around. What sorting do you use for interceptors and decorators? > > I have no problem with changing this in OWB, but I would like to get this clarified in our JavaDocs and spec. Agreed. Go ahead and file an issue. > > LieGrue, > strub > _______________________________________________ > cdi-dev mailing list > cdi-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. _______________________________________________ cdi-dev mailing list cdi-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.

Agree, we should think about that again for CDI-2.0. But I did not find an easy and backward compatible solution right now. Still waiting for an idea to struck me ;) LieGrue, strub > On Monday, 22 December 2014, 9:52, Martin Kouba <mkouba(a)redhat.com&gt; wrote: > >T he issue already exists for a long time ;) > > https://issues.jboss.org/browse/CDI-434?focusedCommentId=12963824&pag... > > And this is also related: https://issues.jboss.org/browse/CDI-437 > > M > > Dne 22.12.2014 v 09:23 Jozef Hartinger napsal(a): >> >> On 12/20/2014 11:26 AM, Mark Struberg wrote: >>> Hi! >>> >>> If I have a >>> >>> >>> @Priority(100) >>> public class MyAlternative implements Foo .. >>> >>> and >>> >>> >>> @Priority(101) >>> public class ABetterAlternative implements Foo .. >>> >>> >>> Then ABetterAlternative will finally be chosen. >>> >>> This ordering can be changed via AfterTypeDiscovery#getAlternatives(). >>> >>> But the spec only says "returns the ordered list of enabled > alternatives for the application.." >>> >>> But it does NOT define in which sorting this list is ordered ;) >>> >>> In OWB we hat the 'most important' alternative come first. It > seems in Weld it is the other way around. >> What sorting do you use for interceptors and decorators? >>> >>> I have no problem with changing this in OWB, but I would like to get > this clarified in our JavaDocs and spec. >> Agreed. Go ahead and file an issue. >>> >>> LieGrue, >>> strub >>> _______________________________________________ >>> cdi-dev mailing list >>> cdi-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>> >>> Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 > (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided > on this list, the provider waives all patent and other intellectual property > rights inherent in such information. > >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 > (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided > on this list, the provider waives all patent and other intellectual property > rights inherent in such information. >> > _______________________________________________ cdi-dev mailing list cdi-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.