Skip to content
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.

Sign up for GitHub

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-468 Split Spec doc to introduce CDI Lite #470

Merged
merged 11 commits into from
May 20, 2021
Merged

cdi-468 Split Spec doc to introduce CDI Lite #470

Show file tree
Hide file tree
Changes from 1 commit
Commits
Show all changes
11 commits
Select commit Hold shift + click to select a range
58177d9
cdi-468 Split Spec doc to introduce CDI Lite
antoinesd Mar 18, 2021
0aec646
cdi-468 Split Spec doc to introduce CDI Lite
antoinesd Apr 26, 2021
893141b
Contributing suggested changes.
manovotn Apr 27, 2021
a45fbe3
Incorporate additional changes - move specialization to Full; change …
manovotn Apr 29, 2021
af8fc82
Attempt to make the Full part more readable - merge decorator limitat…
manovotn Apr 29, 2021
2717c29
Split interceptors chapter into Lite and Full, state that Lite only s…
manovotn May 3, 2021
ac06dcd
comprehensive review and various Lite/Full split changes
Ladicek May 4, 2021
e29216e
remove duplicate interceptors_full inclusion
Ladicek May 4, 2021
b1638a2
actually include the beanmanager_lite.asciidoc file
Ladicek May 4, 2021
d8d2885
Rename occurrences of BeanManagerLite to BeanContainer.
manovotn May 5, 2021
864e1b4
fix some typos and clumsy wording
Ladicek May 5, 2021
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
16 changes: 8 additions & 8 deletions spec/src/main/asciidoc/core/beanmanager_lite.asciidoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2,18 +2,17 @@

== Programmatic access to container

CDI 3.0 used to provide a single `BeanManager` object, which allows access to many useful operations.
In CDI 4.0, this is split into `BeanContainer` and `BeanManager`.
The `BeanContainer` and `BeanManager` interfaces allow programmatic access to the CDI container.

`BeanContainer` provides access to a subset of `BeanManager` features which can be implemented in more restricted environments;
It is available in {cdi_lite} environments.
`BeanContainer` provides features that can be implemented in more restricted environments.
It is available in {cdi_lite} environment, and therefore also in {cdi_full} environment.

`BeanManager` extends `BeanContainer` and provides the remaining features.
It is available in {cdi_full} environments.
`BeanManager` extends `BeanContainer` and provides additional features.
It is only available in {cdi_full} environment.

In {cdi_lite} environment, attempting to obtain a `BeanManager` or invoking methods on it results in non-portable behavior.

[[beanmanager]]
[[beancontainer]]

=== The `BeanContainer` object

Expand All @@ -24,10 +23,11 @@ Thus, any bean may obtain an instance of `BeanContainer` by injecting it:

[source, java]
----
@Inject BeanContainer manager;
@Inject BeanContainer container;
----

The operations of `BeanContainer` may be called at any time during the execution of the application.
// TODO Full has restrictions on when BeanManager methods can be called, do we want to reflect them here in some way?
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How about we instead change the The BeanManager object and mention that those rules apply to both, BM and BeanContainer?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That should be implied by

In {cdi_full} environment, BeanContainer is subject to the same rules as BeanManager.

What I'm more thinking about here is: if we're saying that in Lite, BeanContainer can be invoked at any time, that's a superset of what's allowed in Full. Which might be problematic at least from the "Lite is a strict subset of Full" perspective.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Or at least, it might look like a superset. That will depend on how we define the container lifecycle in Lite, which isn't there yet. (In Full, it's defined in the SPI section.)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

BeanContainer can be invoked at any time

That's not what you wrote there though. You stated ... at any time during the execution of the application which means after the CDI container is bootstrapped, doesn't it? In other words, in Lite you cannot even try to use BeanContainer earlier.
And so long as you cannot use BeanContainer where you couldn't use BM (from within extensions), you should be good.

Or am I missing something?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Again, "at any time during the execution of the application" depends on how we define lifecycle, which we didn't do yet. If we define it in a way that all initialization phases are considered before application execution, then sure.

I added the TODO here mainly as a reminder, to revisit this section after we define lifecycle. I could have worded it more explicitly, for sure -- sorry about that.


[[provider]]

Expand Down
2 changes: 1 addition & 1 deletion spec/src/main/asciidoc/core/injectionandresolution_full.asciidoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -15,7 +15,7 @@ An alternative is not available for injection, lookup or name resolution to clas

==== Declaring selected alternatives in {cdi_full}

{cdi_full} provides an additional way to select alternatives to the one defined in <<declaring_selected_alternatives_application>>:
{cdi_full} provides an additional way to select alternatives to the one defined in <<declaring_selected_alternatives_application>>.

[[declaring_selected_alternatives_bean_archive]]

Expand Down
2 changes: 1 addition & 1 deletion spec/src/main/asciidoc/core/interceptors_full.asciidoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -16,7 +16,7 @@ Interceptor bindings may be used to associate interceptors with any managed bean

It is possible to apply interceptors programmatically to the return value of a producer method, with the `InterceptionFactory` interface as defined in <<interception_factory>>.

[[enabled_interceptors_full]]
[[enabled_interceptors]]

=== Interceptor enablement and ordering in {cdi_full}

Expand Down
4 changes: 2 additions & 2 deletions spec/src/main/asciidoc/core/spi.asciidoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -202,11 +202,11 @@ The container sets the value of all injected fields, and calls all initializer m

Implementations of `Producer` and `InjectionTarget` must ensure that the set of injection points returned by `getInjectionPoints()` are injected by `produce()` or `inject()`.

[[beanmanager_full]]
[[beanmanager]]

=== The `BeanManager` object

In addition to rules defined in <<beanmanager>>, the following rules apply.
In addition to rules defined in <<beancontainer>>, the following rules apply.

The interface `jakarta.enterprise.inject.spi.BeanManager` provides operations for obtaining contextual references for beans, along with many other operations of use to applications and portable extensions.

Expand Down