-
1. Re: Extensions and conflicts in producer methods
agori Dec 29, 2009 9:22 AM (in response to agori)FacesContext injection is only an utility (the injection is not supposed to be used outside the extension, I mean developers shouldn't use it).
I need something to say that this producer is valid only inside this package or jar. -
2. Re: Extensions and conflicts in producer methods
meetoblivion Dec 29, 2009 4:26 PM (in response to agori)Limiting injection to a particular module is not supported, as far as I am aware. However, you could qualify it a bit further (since unqualified injection seems like a really bad idea).
@Produces @RequestScoped @AlbertoFaces FacesContext getFacesContext() { return FacesContext.getCurrentInstance(); }
-
3. Re: Extensions and conflicts in producer methods
gavin.king Dec 29, 2009 5:59 PM (in response to agori)If you annotate your producer method @Alternative, it will be used only by modules which explicitly enable that alternative. And it would be used in preference to any other non-alternative bean. Read spec sections 5.1-5.2.1.
-
4. Re: Extensions and conflicts in producer methods
gavin.king Dec 29, 2009 6:00 PM (in response to agori)
John Ament wrote on Dec 29, 2009 16:26:
Limiting injection to a particular module is not supported, as far as I am aware.That's not right. Please read spec section 5.1, titled
Modularity
. -
5. Re: Extensions and conflicts in producer methods
meetoblivion Dec 29, 2009 6:06 PM (in response to agori)
Gavin King wrote on Dec 29, 2009 18:00:
That's not right. Please read spec section 5.1, titledModularity
.Hmm maybe it's just a different interpretation, but my understanding of 5.1 is that a bean archive may provide an alternative that only impacts that bean module, but does that necessarily stop another module from using the same alternative?
-
6. Re: Extensions and conflicts in producer methods
gavin.king Dec 29, 2009 6:11 PM (in response to agori)
John Ament wrote on Dec 29, 2009 18:06:
Gavin King wrote on Dec 29, 2009 18:00:
That's not right. Please read spec section 5.1, titledModularity
.
Hmm maybe it's just a different interpretation, but my understanding of 5.1 is that a bean archive may provide an alternative that only impacts that bean module, but does that necessarily stop another module from using the same alternative?An alternative defined in one module X may be used by any other module that has X in its classpath.
-
7. Re: Extensions and conflicts in producer methods
gavin.king Dec 29, 2009 6:12 PM (in response to agori)
Gavin King wrote on Dec 29, 2009 18:11:
John Ament wrote on Dec 29, 2009 18:06:
Gavin King wrote on Dec 29, 2009 18:00:
That's not right. Please read spec section 5.1, titledModularity
.
Hmm maybe it's just a different interpretation, but my understanding of 5.1 is that a bean archive may provide an alternative that only impacts that bean module, but does that necessarily stop another module from using the same alternative?
An alternative defined in one module X may be used by any other module that has X in its classpath.But every module that uses X must explicitly declare it in beans.xml, or course.
-
8. Re: Extensions and conflicts in producer methods
agori Dec 29, 2009 6:17 PM (in response to agori)
Gavin King wrote on Dec 29, 2009 17:59:
If you annotate your producer method @Alternative, it will be used only by modules which explicitly enable that alternative. And it would be used in preference to any other non-alternative bean. Read spec sections 5.1-5.2.1.Ok thanks. CDI is amazing!
-
9. Re: Extensions and conflicts in producer methods
meetoblivion Dec 29, 2009 6:43 PM (in response to agori)
Gavin King wrote on Dec 29, 2009 18:12:
Gavin King wrote on Dec 29, 2009 18:11:
John Ament wrote on Dec 29, 2009 18:06:
Gavin King wrote on Dec 29, 2009 18:00:
That's not right. Please read spec section 5.1, titledModularity
.
Hmm maybe it's just a different interpretation, but my understanding of 5.1 is that a bean archive may provide an alternative that only impacts that bean module, but does that necessarily stop another module from using the same alternative?
An alternative defined in one module X may be used by any other module that has X in its classpath.
But every module that uses X must explicitly declare it in beans.xml, or course.Right, this is sort of what I was alluding to. As a result, even if your bean archive used an alternative, there's nothing stopping my bean archive from using it (I just need to configure it appropriately).