New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CDI-160 : Introducing SE and EE part #241

Closed
wants to merge 22 commits into
base: master
from

Conversation

Projects
None yet
5 participants
@antoinesd
Member

antoinesd commented Apr 14, 2015

This is the fist step of spliting the spec between Core and Java EE in CDI spec.
New parts have been created. All EJB content has bee removed from Core part to go to Java EE.

There're are still ref to Java EE in part regarding EL, Servlet/JSP and JSF.

Show outdated Hide outdated spec/src/main/doc/spi.asciidoc Outdated
However, if the application directly instantiates a bean class, instead of letting the container perform instantiation, the resulting instance is not managed by the container and is not a contextual instance as defined by <<contextual_instance>>. Furthermore, the capabilities listed in <<capabilities>> will not be available to that particular instance. In a deployed application, it is the container that is responsible for instantiating beans and initializing their dependencies.
If the application requires more control over instantiation of a contextual instance, a producer method or field may be used. Any Java object may be returned by a producer method or field. It is not required that the returned object be a contextual reference for a bean. However, if the object is not a contextual reference for another bean, the object will be contextual instance of the producer method bean, and therefore available for injection into other objects and use in EL expressions, but the other capabilities listed in <<capabilities>> will not be available to the object.
If the application requires more control over instantiation of a contextual instance, a producer method or field may be used. Any Java object may be returned by a producer method or field. It is not required that the returned object be a contextual reference for a bean. However, if the object is not a contextual reference for another bean, the object will be contextual instance of the producer method bean, and therefore available for injection into other objects and use in name resolution, but the other capabilities listed in <<capabilities>> will not be available to the object.

This comment has been minimized.

@tremes

tremes May 15, 2015

Contributor

Missing "will" in: "It is not required that the returned object be a contextual reference for a bean."

@tremes

tremes May 15, 2015

Contributor

Missing "will" in: "It is not required that the returned object be a contextual reference for a bean."

This comment has been minimized.

@antoinesd

antoinesd May 15, 2015

Member

This "mistake" is in the original text (so it's out of scope of this split) and I'm not sure it's an error. We should check with a native english speaker.

@antoinesd

antoinesd May 15, 2015

Member

This "mistake" is in the original text (so it's out of scope of this split) and I'm not sure it's an error. We should check with a native english speaker.

Show outdated Hide outdated spec/src/main/doc/core/spi.asciidoc Outdated
* during the +service()+ method of any servlet in the web application, during the +doFilter()+ method of any servlet filter and when the container calls any +ServletRequestListener+ or +AsyncListener+,
* during any Java EE web service invocation,
* during any remote method invocation of any EJB, during any asynchronous method invocation of any EJB, during any call to an EJB timeout method and during message delivery to any EJB message-driven bean, and
* during +@PostConstruct+ callback of any bean.

This comment has been minimized.

@jharting

jharting May 26, 2015

Contributor

Is the "request scope available during @PostConstruct" feature intentionally restricted to Java EE only or is this an oversight?

@jharting

jharting May 26, 2015

Contributor

Is the "request scope available during @PostConstruct" feature intentionally restricted to Java EE only or is this an oversight?

This comment has been minimized.

@antoinesd

antoinesd Jun 1, 2015

Member

It is intentional. In core, all normal scope are only said to be required and must be defined depending of the platform. Thus we can define how these scope are implemented in EE and how they be implemented in SE.

@antoinesd

antoinesd Jun 1, 2015

Member

It is intentional. In core, all normal scope are only said to be required and must be defined depending of the platform. Thus we can define how these scope are implemented in EE and how they be implemented in SE.

This comment has been minimized.

@jharting

jharting Jun 2, 2015

Contributor

I see

@jharting

jharting Jun 2, 2015

Contributor

I see

Show outdated Hide outdated spec/src/main/doc/preface.asciidoc Outdated
Show outdated Hide outdated spec/src/main/doc/preface.asciidoc Outdated
* non-contextual instances of session beans (for example, session beans obtained by the application from JNDI or injected using +@EJB+),
* non-contextual instances of managed beans, and
* instances of any other Java EE component class supporting injection.

This comment has been minimized.

@jharting

jharting Jun 2, 2015

Contributor

"other classes supporting injection" should be preserved here

@jharting

jharting Jun 2, 2015

Contributor

"other classes supporting injection" should be preserved here

This comment has been minimized.

@antoinesd

antoinesd Jun 2, 2015

Member

From what I understand If you request such an instance from the container from an InjectionTarget or Unmanaged object, dependency injection is not performed by the container at instantiation but when you request it with the inject() method. So it shouldn't be there IMO.

@antoinesd

antoinesd Jun 2, 2015

Member

From what I understand If you request such an instance from the container from an InjectionTarget or Unmanaged object, dependency injection is not performed by the container at instantiation but when you request it with the inject() method. So it shouldn't be there IMO.

This comment has been minimized.

@jharting

jharting Jun 2, 2015

Contributor

ok

@jharting

jharting Jun 2, 2015

Contributor

ok

[[fields_initializer_methods]]
==== Injection of fields and initializer methods
When the container creates a new instance of a managed bean, session bean, or of any other Java EE component class supporting injection the container must:

This comment has been minimized.

@jharting

jharting Jun 2, 2015

Contributor

"other classes supporting injection" should be preserved here

@jharting

jharting Jun 2, 2015

Contributor

"other classes supporting injection" should be preserved here

This comment has been minimized.

@antoinesd

antoinesd Jun 2, 2015

Member

Same as above. This is not done at instantiation but when inject() is called.

@antoinesd

antoinesd Jun 2, 2015

Member

Same as above. This is not done at instantiation but when inject() is called.

@antoinesd

This comment has been minimized.

Show comment
Hide comment
@antoinesd

antoinesd Jun 11, 2015

Member

Close in favor of #251 targeted to the right branch

Member

antoinesd commented Jun 11, 2015

Close in favor of #251 targeted to the right branch

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment