[JBoss JIRA] (CDI-539) Support for 'profile' in CDI
by Mark Struberg (JIRA)
[ https://issues.jboss.org/browse/CDI-539?page=com.atlassian.jira.plugin.sy... ]
Mark Struberg commented on CDI-539:
-----------------------------------
> global activation of @Alternative @Stereotypes with @Priority or using an extension.
In OpenWebBeans they are globally enabled per ee module by default, even without @Priority.
I think the question was more about WHEN to activate those Alternatives and @Specializes. We did discuss the ProjectStage in the past and the conclusio was that this is nothing which CDI should define but it's an EE umbrella wide topic.
> Support for 'profile' in CDI
> ----------------------------
>
> Key: CDI-539
> URL: https://issues.jboss.org/browse/CDI-539
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Contexts
> Reporter: Dhiraj Dwarapudi
>
> I would like to activate a set of beans at application start-time. Currently I can use Programmatic lookup in CDI for dynamically injecting the beans. But I believe it'll be easier with better support for this.
> Spring has a nice support for this with the concept of a 'Profile':
> https://spring.io/blog/2011/02/14/spring-3-1-m1-introducing-profile/
> Would be really helpful if CDI has support for this.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 5 months
[JBoss JIRA] (CDI-539) Support for 'profile' in CDI
by George Gastaldi (JIRA)
[ https://issues.jboss.org/browse/CDI-539?page=com.atlassian.jira.plugin.sy... ]
George Gastaldi commented on CDI-539:
-------------------------------------
I agree that @Alternatives and @Stereotypes can solve the problem, but I guess the idea here is to activate them using a system property or something like it. Activating alternatives in beans.xml would require changes to the XML, and I suppose that's what this issue is about, or maybe Dhiraj can elaborate a bit more?
> Support for 'profile' in CDI
> ----------------------------
>
> Key: CDI-539
> URL: https://issues.jboss.org/browse/CDI-539
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Contexts
> Reporter: Dhiraj Dwarapudi
>
> I would like to activate a set of beans at application start-time. Currently I can use Programmatic lookup in CDI for dynamically injecting the beans. But I believe it'll be easier with better support for this.
> Spring has a nice support for this with the concept of a 'Profile':
> https://spring.io/blog/2011/02/14/spring-3-1-m1-introducing-profile/
> Would be really helpful if CDI has support for this.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 5 months
[JBoss JIRA] (CDI-539) Support for 'profile' in CDI
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-539?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand commented on CDI-539:
------------------------------------------
Agree with Jozef but I may have missed something. [~gastaldi]: What is missing in your opinion in @Alternatives activated via @Stereotypes to provide this feature? [~jharting] what do you suggest to improve this in CDI 2.0?
> Support for 'profile' in CDI
> ----------------------------
>
> Key: CDI-539
> URL: https://issues.jboss.org/browse/CDI-539
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Contexts
> Reporter: Dhiraj Dwarapudi
>
> I would like to activate a set of beans at application start-time. Currently I can use Programmatic lookup in CDI for dynamically injecting the beans. But I believe it'll be easier with better support for this.
> Spring has a nice support for this with the concept of a 'Profile':
> https://spring.io/blog/2011/02/14/spring-3-1-m1-introducing-profile/
> Would be really helpful if CDI has support for this.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 5 months
[JBoss JIRA] (CDI-539) Support for 'profile' in CDI
by Jozef Hartinger (JIRA)
[ https://issues.jboss.org/browse/CDI-539?page=com.atlassian.jira.plugin.sy... ]
Jozef Hartinger commented on CDI-539:
-------------------------------------
This is exactly what @Alternative @Stereotypes are for in CDI. You can create your own "profiles" by introducing a stereotype annotated with @Alternative, e.g. @Mock, @Production etc. You can then activate the stereotypes you want active in beans.xml. This concept should be extended in CDI 2.0 to work with @Priority and CDI extensions.
> Support for 'profile' in CDI
> ----------------------------
>
> Key: CDI-539
> URL: https://issues.jboss.org/browse/CDI-539
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Contexts
> Reporter: Dhiraj Dwarapudi
>
> I would like to activate a set of beans at application start-time. Currently I can use Programmatic lookup in CDI for dynamically injecting the beans. But I believe it'll be easier with better support for this.
> Spring has a nice support for this with the concept of a 'Profile':
> https://spring.io/blog/2011/02/14/spring-3-1-m1-introducing-profile/
> Would be really helpful if CDI has support for this.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 5 months
[JBoss JIRA] (CDI-540) Clarify CDIProvider.isInitialized() javadoc
by Martin Kouba (JIRA)
Martin Kouba created CDI-540:
--------------------------------
Summary: Clarify CDIProvider.isInitialized() javadoc
Key: CDI-540
URL: https://issues.jboss.org/browse/CDI-540
Project: CDI Specification Issues
Issue Type: Clarification
Affects Versions: 2.0-EDR1
Reporter: Martin Kouba
I believe the spec should be more specific and define what it means for a CDIProvider to be initialized. E.g. _"a {{CDIProvider}} is initialized if at least one CDI container was started and is still running"_.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 5 months
[JBoss JIRA] (CDI-539) Support for 'profile' in CDI
by Dhiraj Dwarapudi (JIRA)
[ https://issues.jboss.org/browse/CDI-539?page=com.atlassian.jira.plugin.sy... ]
Dhiraj Dwarapudi commented on CDI-539:
--------------------------------------
[~tzwoenn]
Yeah, something similar to ProjectStage.
But 'profile' is more usable and covers larger use cases.
* I can have mutliple profiles active at the same time
* I would like to boootstrap my application at start-time with different profiles. ProjectStage can be used to accomplish this, but the intent of ProjectStage (as the name suggests) seem to be more for different stages of application development
* The way 'profile's are implemented in Spring, a custom profile is just another string. So you don't need to write any code to support custom 'profile'. For that matter there are not built-in profiles. They are user-defined.
> Support for 'profile' in CDI
> ----------------------------
>
> Key: CDI-539
> URL: https://issues.jboss.org/browse/CDI-539
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Contexts
> Reporter: Dhiraj Dwarapudi
>
> I would like to activate a set of beans at application start-time. Currently I can use Programmatic lookup in CDI for dynamically injecting the beans. But I believe it'll be easier with better support for this.
> Spring has a nice support for this with the concept of a 'Profile':
> https://spring.io/blog/2011/02/14/spring-3-1-m1-introducing-profile/
> Would be really helpful if CDI has support for this.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 5 months
Constructor dependency
by Sebastian Łaskawiec
Hey!
I've seen CDI 2.0 Early Draft - congratulations! Looks very promising!
I would like to ask about something slightly different than CDI 2.0 -
constructor injection. I'm a big fan of using it because I can easily
inject mocks into tested objects. This way I can limit the number of
Arquillian tests and speed up testing phase in my project.
However the drawback is that need 2 constructors in my beans:
@ApplicationScoped
public class MyBean {
public MyBean() {
}
@Inject
public MyBean(OtherBean bean) {
}
}
Is it possible to get rid of the zero-parameter constructor? I can
imagine that it may be required by dependency resolution mechanism (for
example instantiating beans with cyclic dependencies A -> B -> C -> A),
but on the other hand we actually can create an instance without calling
a constructor - using Unsafe (but using Unsafe is always questionable).
Could you please tell me if there are any plans around this topic?
Thanks
Sebastian
9 years, 5 months
[JBoss JIRA] (CDI-438) Fix type parameters ordering in ProcessProducerMethod and ProcessProducerField events
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-438?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba commented on CDI-438:
----------------------------------
{quote}
With this change done, is there still any reason to prevent delivering of ProcessProducerMethod<Foo,Producer> to observer of ProcessBean<Foo>? I think it could make sense in certain use cases...
{quote}
Yes, I think so. For a producer method like this:
{code}
class Producer {
Foo produce() {
return new Foo();
}
}
{code}
The event types include {{ProcessProducerMethod<Foo,Producer>}}, {{ProcessBean<Producer>}} and {{Object}}. And none of these types is assignable to {{ProcessBean<Foo>}}.
To be honest I'm not quite sure whether it would be better to observe the return type or the bean class (current wording) for producer methods/fields. But if I understand your previous comment correctly we can't fix this anyway...
We should also fix the {{javax.enterprise.inject.spi.ProcessBean}} javadoc:
{quote}
...
For a producer method with method return type X of a bean with bean class T, the container must raise an event of type javax.enterprise.inject.spi.ProcessProducerMethod<T, X>.
...
{quote}
> Fix type parameters ordering in ProcessProducerMethod and ProcessProducerField events
> -------------------------------------------------------------------------------------
>
> Key: CDI-438
> URL: https://issues.jboss.org/browse/CDI-438
> Project: CDI Specification Issues
> Issue Type: Bug
> Affects Versions: 1.2.Final
> Reporter: Martin Kouba
> Assignee: Antoine Sabot-Durand
> Fix For: 2.0-EDR1
>
>
> Since CDI 1.0 there is an inconsistency in the description of {{ProcessProducerMethod}} event...
> The text:
> {quote}
> For a producer method with method *return type X* of a bean with *bean class T*, the container must raise an event of type ProcessProducerMethod<T, X>.
> {quote}
> API:
> {code:java}
> /**
> * @param <T> The return type of the producer method
> * @param <X> The class of the bean declaring the producer method
> */
> public interface ProcessProducerMethod<T, X> extends ProcessBean<X> {
> }
> {code}
> The same applies to {{ProcessProducerField}}.
> TCK and RI (Weld) follow the API. As one of the consequences an {{ProcessProducerMethod<Foo,Producer>}} event is not delivered to an observer with the event parameter {{ProcessBean<Foo>}} - which is required by the spec but does not make sense at the same time.
> It's obvious that JCP compatibility rules required to keep the wrong ordering for CDI 1.x (see also the comments in {{javax.enterprise.inject.spi.ProcessProducerMethod}}). I believe this should be fixed in CDI 2.0.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 5 months
