Expected value of getType() for the injection point of an Instance object
by John Ament
Hi,
I found a small issue within OWB. The closest found TCK test (found by Romain) is https://github.com/cdi-spec/cdi-tck/blob/master/impl/src/main/java/org/jb... which tests the Instance type, but not the value of InjectionPoint.getType(). What should be the return value of getType() here?
John
________________________________
NOTICE: This e-mail message and any attachments may contain confidential, proprietary, and/or privileged information which should be treated accordingly. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this message, and destroy all physical and electronic copies. Thank you.
6 years, 7 months
Multiple CDI containers per ClassLoader
by Todor Boev
Hi all,
The javax.enterprise.inject.se.SeContainerInitializer seems to allow me to
create and use simultaneously multiple CDI containers.
Furthermore I don't seem to be required to setup each one with it's own
ClassLoader.
If I create multiple containers over the same ClassLoader, what would it
mean to call javax.enterprise.inject.spi.CDI.current() in each one?
Regards,
Todor
6 years, 7 months
Re: [cdi-dev] Correct way to programatically instantiate a Bean
by Matej Novotny
Hi,
sorry for the ambiguity of the answer.
I meant contexual instance - e.g. each individual object of type T (aka your first code snippet).
BTW keep hitting "reply to all" so that we keep cdi-dev list in the loop :)
Matej
----- Original Message -----
> From: "Todor Boev" <rinsvind(a)gmail.com>
> To: "Matej Novotny" <manovotn(a)redhat.com>
> Sent: Friday, September 8, 2017 10:03:21 AM
> Subject: Re: [cdi-dev] Correct way to programatically instantiate a Bean
>
> Hi Matej,
>
> I am struggling to understand what do you mean by "bean".
> The Bean<T> object that produces objects of type T, or each individual
> object of type T?
>
> If it is the T this should be the first of my code snippets: a new
> CreationalContext for every new T.
> If it is the Bean<T> this should be the second of my code snippets: one
> CreationalContext all new T.
>
> Regards,
> Todor
>
> On Fri, Sep 8, 2017 at 8:42 AM, Matej Novotny <manovotn(a)redhat.com> wrote:
>
> > Hi Todor,
> >
> > if I am not mistaken, the CreationalContext is a way to bind
> > dependent instances to bean (and so align their lifecycles).
> >
> > Which means I'd use new CreationalContext for each bean.
> >
> > Matej
> >
> > ----- Original Message -----
> > > From: "Todor Boev" <rinsvind(a)gmail.com>
> > > To: cdi-dev(a)lists.jboss.org
> > > Sent: Thursday, September 7, 2017 5:07:35 PM
> > > Subject: [cdi-dev] Correct way to programatically instantiate a Bean
> > >
> > > Hello,
> > >
> > > I need to create beans from a portable extension.
> > > It is not clear to me if every instance of a bean must have an associated
> > > instance of CreationalContext or rather one CreationalContext must be
> > used
> > > for all instances:
> > >
> > > // Store a CreationalContext per bean instance
> > > BeanManager manager = ...
> > > Bean<T> bean = ...
> > > Context ctx = manager.getContext(bean.getScope());
> > >
> > > Map<T, CreationalContext<T>> dependents = ...
> > >
> > > public T createBean() {
> > > CreationalContext<T> cctx = manager.createCreationalContext(bean);
> > > T instance = ctx.get(bean, cctx);
> > > dependents.put(instance, cctx);
> > > return instance;
> > > }
> > >
> > > public void destroyBean(T instance) {
> > > dependents.computeIfPresent(instance, (inst, cctx) -> {
> > > bean.destroy(inst, cctx);
> > > return null;
> > > });
> > > }
> > >
> > > // CDI tracks dependents for me
> > > BeanManager manager = ...
> > > Bean<T> bean = ...
> > > Context ctx = manager.getContext(bean.getScope());
> > > CreationalContext cctx = manager.createCreationalContext(bean);
> > >
> > > public T createBean() {
> > > T instance = ctx.get(bean, cctx);
> > > return instance;
> > > }
> > >
> > > public void destroyBean(T instance) {
> > > bean.destroy(instance, cctx);
> > > }
> > >
> > > Best Regards,
> > > Todor
> > >
> > > _______________________________________________
> > > 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.
> >
>
6 years, 7 months
Fwd: Correct way to programatically instantiate a Bean
by Todor Boev
Including CDI-DEV
---------- Forwarded message ----------
From: Todor Boev <rinsvind(a)gmail.com>
Date: Fri, Sep 8, 2017 at 11:03 AM
Subject: Re: [cdi-dev] Correct way to programatically instantiate a Bean
To: Matej Novotny <manovotn(a)redhat.com>
Hi Matej,
I am struggling to understand what do you mean by "bean".
The Bean<T> object that produces objects of type T, or each individual
object of type T?
If it is the T this should be the first of my code snippets: a new
CreationalContext for every new T.
If it is the Bean<T> this should be the second of my code snippets: one
CreationalContext all new T.
Regards,
Todor
On Fri, Sep 8, 2017 at 8:42 AM, Matej Novotny <manovotn(a)redhat.com> wrote:
> Hi Todor,
>
> if I am not mistaken, the CreationalContext is a way to bind
> dependent instances to bean (and so align their lifecycles).
>
> Which means I'd use new CreationalContext for each bean.
>
> Matej
>
> ----- Original Message -----
> > From: "Todor Boev" <rinsvind(a)gmail.com>
> > To: cdi-dev(a)lists.jboss.org
> > Sent: Thursday, September 7, 2017 5:07:35 PM
> > Subject: [cdi-dev] Correct way to programatically instantiate a Bean
> >
> > Hello,
> >
> > I need to create beans from a portable extension.
> > It is not clear to me if every instance of a bean must have an associated
> > instance of CreationalContext or rather one CreationalContext must be
> used
> > for all instances:
> >
> > // Store a CreationalContext per bean instance
> > BeanManager manager = ...
> > Bean<T> bean = ...
> > Context ctx = manager.getContext(bean.getScope());
> >
> > Map<T, CreationalContext<T>> dependents = ...
> >
> > public T createBean() {
> > CreationalContext<T> cctx = manager.createCreationalContext(bean);
> > T instance = ctx.get(bean, cctx);
> > dependents.put(instance, cctx);
> > return instance;
> > }
> >
> > public void destroyBean(T instance) {
> > dependents.computeIfPresent(instance, (inst, cctx) -> {
> > bean.destroy(inst, cctx);
> > return null;
> > });
> > }
> >
> > // CDI tracks dependents for me
> > BeanManager manager = ...
> > Bean<T> bean = ...
> > Context ctx = manager.getContext(bean.getScope());
> > CreationalContext cctx = manager.createCreationalContext(bean);
> >
> > public T createBean() {
> > T instance = ctx.get(bean, cctx);
> > return instance;
> > }
> >
> > public void destroyBean(T instance) {
> > bean.destroy(instance, cctx);
> > }
> >
> > Best Regards,
> > Todor
> >
> > _______________________________________________
> > 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.
>
6 years, 7 months
Correct way to programatically instantiate a Bean
by Todor Boev
Hello,
I need to create beans from a portable extension.
It is not clear to me if every instance of a bean must have an associated
instance of CreationalContext or rather one CreationalContext must be used
for all instances:
// Store a CreationalContext per bean instance
BeanManager manager = ...
Bean<T> bean = ...
Context ctx = manager.getContext(bean.getScope());
Map<T, CreationalContext<T>> dependents = ...
public T createBean() {
CreationalContext<T> cctx = manager.createCreationalContext(bean);
T instance = ctx.get(bean, cctx);
dependents.put(instance, cctx);
return instance;
}
public void destroyBean(T instance) {
dependents.computeIfPresent(instance, (inst, cctx) -> {
bean.destroy(inst, cctx);
return null;
});
}
// CDI tracks dependents for me
BeanManager manager = ...
Bean<T> bean = ...
Context ctx = manager.getContext(bean.getScope());
CreationalContext cctx = manager.createCreationalContext(bean);
public T createBean() {
T instance = ctx.get(bean, cctx);
return instance;
}
public void destroyBean(T instance) {
bean.destroy(instance, cctx);
}
Best Regards,
Todor
6 years, 7 months
Re: [cdi-dev] Attributes on scope annotations
by Xavier Dury
forwarding your mail to the mailing list
From: Todor Boev <rinsvind(a)gmail.com>
Sent: Monday, September 4, 2017 11:03 AM
To: Xavier Dury
Subject: Re: [cdi-dev] Attributes on scope annotations
I did expect BeanManager.getScope() to return an annotation instance, when implementing my scope.
Similarly to JSF my use case that the type of applications I need to support do not have such a specific execution flow as to allow me to define a singleton scope. Instead the users must be able to define the scope at a particular place in the execution flow. My workaround is to require that the users create a new scope annotation for each such scope and meta-annotate it with the data consumed by my extension. Then they can use their custom annotation for their custom scoped classes. This is however inconvenient for the most common case of a single custom-scoped class.
Given however attributes on scopes are used in JSF should I open an issue for the CDI spec to support this use case?
Regards
On Sat, Sep 2, 2017 at 1:08 PM, Xavier Dury <kalgon(a)hotmail.com> wrote:
JSF [1] and Omnifaces [2] are doing it but it's against the spec.
If this was allowed, I suppose BeanManager.getContext() [3] would have taken an annotation parameter instead of an annotation type.
Xavier
----
[1] http://docs.oracle.com/javaee/7/api/javax/faces/flow/FlowScoped.html
[2] http://omnifaces.org/docs/javadoc/2.6/org/omnifaces/cdi/ViewScoped.html
[3] http://docs.oracle.com/javaee/7/api/javax/enterprise/inject/spi/BeanManag...
From: cdi-dev-bounces(a)lists.jboss.org <cdi-dev-bounces(a)lists.jboss.org> on behalf of Matej Novotny <manovotn(a)redhat.com>
Sent: Friday, September 1, 2017 1:43 PM
To: Todor Boev
Cc: cdi-dev
Subject: Re: [cdi-dev] Attributes on scope annotations
Let's keep this conversation on CDI-dev list, please (adding back to CC).
Hmm, I think it is not forbidden to add another plain java annotation.
However, having it working as scope and cdi qualifier in the same time won't work.
Matej
----- Original Message -----
> From: "Todor Boev" <rinsvind(a)gmail.com>
> To: "Matej Novotny" <manovotn(a)redhat.com>
> Sent: Friday, September 1, 2017 12:33:54 PM
> Subject: Re: [cdi-dev] Attributes on scope annotations
>
> Thank you for the timely replay,
>
> I need portable behavior, so the other option I am considering is to
> meta-annotate the scope annotation with the additional information I need.
> The issues are now: is this allowed, can in principle my custom
> meta-annotation be a qualifier. Probably a plain annotation will be
> sufficient, but I may need to have it do double-duty as a qualifier as well.
>
> Thanks in advance,
> Todor
>
> On Fri, Sep 1, 2017 at 11:49 AM, Matej Novotny <manovotn(a)redhat.com> wrote:
>
> > Hello Todor,
> >
> > From CDI specification 2.0 section 2.4.2 Defining new scopes[1]:
> >
> > "A scope type must not have any attributes. If a scope type has attributes
> > non-portable behavior results."
> >
> > Matej
> >
> > ____________________________________________________________
> > _______________-
> > [1] http://docs.jboss.org/cdi/spec/2.0/cdi-spec.html#
JSR 365: Contexts and Dependency Injection for Java 2.0
docs.jboss.org
Starting with version 2.0 CDI targets Java SE and Java EE platforms. CDI in Java SE and CDI in a Java EE container share the features defined in core CDI.
> > defining_new_scope_type
> >
> >
> >
> > ----- Original Message -----
> > > From: "Todor Boev" <rinsvind(a)gmail.com>
> > > To: cdi-dev(a)lists.jboss.org
> > > Sent: Friday, September 1, 2017 9:51:47 AM
> > > Subject: [cdi-dev] Attributes on scope annotations
> > >
> > > Hello,
> > >
> > > Is it against the CDI 2.0 specification to have attributes on a scope
> > > annotation? If not is this a corner case that may become forbidden or
> > simply
> > > not be taken into account in future versions of the specification?
> > >
> > > E.g. @ComponentScoped("my-component")
> > >
> > > With Weld 3.0.0 I was able to successfully use such annotations.
> > >
> > > Regards,
> > > Todor
> > >
> > >
> > > _______________________________________________
> > > cdi-dev mailing list
> > > cdi-dev(a)lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/cdi-dev
cdi-dev Info Page - lists.jboss.org Mailing Lists
lists.jboss.org
List to discuss the development of CDI (the specification) To see the collection of prior postings to the list, visit the cdi-dev Archives.
> > >
> > > 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
Apache License, Version 2.0
www.apache.org
Apache License Version 2.0, January 2004 http://www.apache.org/licenses/ TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION. 1. Definitions.
> > > 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
cdi-dev Info Page - lists.jboss.org Mailing Lists
lists.jboss.org
List to discuss the development of CDI (the specification) To see the collection of prior postings to the list, visit the cdi-dev Archives.
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.
6 years, 7 months
[JBoss JIRA] (CDI-10) Add ability to access a bean instance from a proxy
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-10?page=com.atlassian.jira.plugin.sys... ]
Antoine Sabot-Durand commented on CDI-10:
-----------------------------------------
Some use cases here may be solved with CDI-194: giving access to the actual Bean class (or AnnotatedType) would give access annotations on classe, fields or methods.
> Add ability to access a bean instance from a proxy
> --------------------------------------------------
>
> Key: CDI-10
> URL: https://issues.jboss.org/browse/CDI-10
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Beans
> Affects Versions: 1.0
> Reporter: Stuart Douglas
> Labels: F2F2016
> Fix For: 2.1 (Discussion)
>
>
> There are occasions when it would be useful to access a bean instance directly from a proxy. This could be achieved by making all proxies assignable to an interface (say BeanProxy) that provides a getBeanInstance() method.
> Client code that needs access to the actual instance can check if the object is assignable to the BeanProxy interface and then call getBeanInstance() to get the actual instance if required.
> This is something that is probably more useful to extension writers than the end user, but there have already been a few requests on the weld forum about this so it is probably worth considering.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 7 months
[JBoss JIRA] (CDI-716) Allow to recognize custom Bean at runtime
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-716?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand commented on CDI-716:
------------------------------------------
Agree to go that way. IMO it would be better to add {{getKind()}} and know the exact bean kind (Managed, EJB, Producer, Custom, Built-in)
> Allow to recognize custom Bean at runtime
> -----------------------------------------
>
> Key: CDI-716
> URL: https://issues.jboss.org/browse/CDI-716
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Beans
> Affects Versions: 2.0 .Final
> Reporter: Matej Novotny
>
> At the moment, they only way to tell custom bean (created via {{BeanConfigurator}} or class implementing {{javax.enterprise.inject.spi.Bean}}) from "standard" one is to have an extension and listen to {{ProcessSyntheticBean}}. This is good enough if it's sufficient to tell the difference at bootstrap time.
> However, at runtime, there is no way to do this.
> We could add a method to {{javax.enterprise.inject.spi.Bean}} which would allow to tell the difference. The name of the method could be {{isCustom()}} or {{getKind()}}.
> Generally, there should be no need to differentiate between custom/standard beans, but when digging deeper, it doesn't hurt to know. Putting this into {{Bean}} interface keeps it deep enough while still giving the information.
> One of the use cases for this would be CDI-194, which could be "nicely" implemented (avoiding {{null}} values), if there was a way to recognize custom bean.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 7 months
[JBoss JIRA] (CDI-715) Transitive stereotype declarations - clarify conflicting default scopes
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-715?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba updated CDI-715:
-----------------------------
Description:
Stereotype declarations are transitive. However, the spec is not clear what happens if a stereotype declares a default scope and also a second stereotype which also declares a default scope. Only _"If a stereotype declares more than one scope, the container automatically detects the problem and treats it as a definition error."_ is defined.
Weld currently does merge the stereotypes and throws {{DefinitionException}} if NOT all stereotypes specify the same scope _and_ the bean does NOT declare a scope (this makes sense imho).
Note that this is not a problem for {{@Named}}, {{@Alternative}} and -interceptor bindings-.
Any {{@Alternative}} makes a bean an alternative. Any {{@Named}} means the name is defaulted. -All bindings are added to the set-.
UPDATE: Interceptor bindings are probably also affected. The interceptors spec defines _"An interceptor binding declared on a method or constructor replaces an interceptor binding of the same type declared at class level or inherited from a superclass."_ (3.3 Binding an Interceptor to a Component) which implies that multiple interceptor bindings of the same type are not supported. So the spec should probably cover cases where stereotypes declare the interceptor bindings of the same type.
was:
Stereotype declarations are transitive. However, the spec is not clear what happens if a stereotype declares a default scope and also a second stereotype which also declares a default scope. Only _"If a stereotype declares more than one scope, the container automatically detects the problem and treats it as a definition error."_ is defined.
Weld currently does merge the stereotypes and throws {{DefinitionException}} if NOT all stereotypes specify the same scope _and_ the bean does NOT declare a scope (this makes sense imho).
Note that this is not a problem for {{@Named}}, {{@Alternative}} and interceptor bindings.
Any {{@Alternative}} makes a bean an alternative. Any {{@Named}} means the name is defaulted. All bindings are added to the set.
> Transitive stereotype declarations - clarify conflicting default scopes
> -----------------------------------------------------------------------
>
> Key: CDI-715
> URL: https://issues.jboss.org/browse/CDI-715
> Project: CDI Specification Issues
> Issue Type: Clarification
> Reporter: Martin Kouba
> Priority: Minor
>
> Stereotype declarations are transitive. However, the spec is not clear what happens if a stereotype declares a default scope and also a second stereotype which also declares a default scope. Only _"If a stereotype declares more than one scope, the container automatically detects the problem and treats it as a definition error."_ is defined.
>
> Weld currently does merge the stereotypes and throws {{DefinitionException}} if NOT all stereotypes specify the same scope _and_ the bean does NOT declare a scope (this makes sense imho).
> Note that this is not a problem for {{@Named}}, {{@Alternative}} and -interceptor bindings-.
> Any {{@Alternative}} makes a bean an alternative. Any {{@Named}} means the name is defaulted. -All bindings are added to the set-.
> UPDATE: Interceptor bindings are probably also affected. The interceptors spec defines _"An interceptor binding declared on a method or constructor replaces an interceptor binding of the same type declared at class level or inherited from a superclass."_ (3.3 Binding an Interceptor to a Component) which implies that multiple interceptor bindings of the same type are not supported. So the spec should probably cover cases where stereotypes declare the interceptor bindings of the same type.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 7 months
