[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [cdi-dev] About parsing beans.xml files in Lite
|
How about calling it CDI native compilation profile or native
profile or static profile?
Reza Rahman
Jakarta EE Ambassador, Author, Blogger, Speaker
Please note views expressed here are my own as an individual
community member and do not reflect the views of my employer.
On 1/25/2021 9:31 AM, Manfred Riem
wrote:
Hi all,
I couldn’t agree more with Mark on this
one. If it is not a proper sub set but instead borrows
concepts from CDI
it really is not CDI Lite. Naming is
important as it can cause a lot of confusion if done wrong!
Thanks!
Kind regards,
Manfred Riem
Once again: if CDI-lite is not binary
and otherwise just a subset of CDI, then PLEASE find a
different name for it.
What you want is more like a JSR-330
container with some sprinkles from CDI features here and
there - but with a different API.
Yes you probably started at CDI mind
wise, but now you are somewhere completely else. Please do
not trash CDI by adding something else!
Or to say it in different words:
If you call it CDI-lite, then people
expect that they will be able to run those libs on a fully
blown CDI server as well.
It this is not the case (because the
API is different), then please don't call it CDI-lite. The
spec might still be valuable, but please go find another
name!
On 16. 01. 21 0:16, Emily Jiang
wrote:
>
As a matter of fact, we currently pour
everything into a singular bean archive (which I
have to say I came to like as it makes
understanding the meaning of bean archive much
simpler for users).
Ah that is a great point,
totally forgot about that! I think we should
do this in Lite. Multiple bean archives made
everything really confusing
for me when I started learning CDI.
This approach leads to the
complication of merging beans.xml. What if the
beans.xml has conflicts, which one takes
precedence.
The proposal is that in Lite,
we don't take beans.xml content into account. We
"only" use it as a marker file to find JARs that
should be part of the "singular" bean archive. So
that is a non-issue, and, in fact, simplification
:-)
What
about enabling interceptors via beans.xml? Would the
enablement be done via @Priority only? Your
suggestion of discarding the contents of beans.xml
is quite a big change.
>
Tomas Langer also correctly mentioned that today
you can have beans.xml with discovery mode
"none" and therefore the presence of beans.xml
can mean you don't want to process that archive.
> This is true, although I have to point out
that I haven't really seen this used much. It is
probably a remnant of CDI 1.0 where default
discovery mode was explicit (instead of
annotated) and where you needed to always have
beans.xml present.
The only reason why I think
we might want to detect beans.xml
configuring discovery mode to "none" is legacy
JARs. Not sure how big of
Open Liberty uses this for
improving performance for migrated
applications. The applications used CDI 1.0
and then migrated to CDI 1.2/2.0. Setting
bean-discovery-mode="none" will disable the
scanning, which improves the performance.
What
I'd like to understand is, how much is that
relevant when it comes to Lite? My guess would be:
not much.
My statement was about the use
case assessment.
On 16. 01. 21 0:16,
Emily Jiang wrote:
> As a
matter of fact, we currently pour
everything into a singular bean
archive (which I have to say I came to
like as it makes understanding the
meaning of bean archive much simpler
for users).
Ah that is a
great point, totally forgot about
that! I think we should
do this in Lite. Multiple bean
archives made everything really
confusing
for me when I started learning CDI.
This approach
leads to the complication of merging
beans.xml. What if the beans.xml has
conflicts, which one takes
precedence.
The
proposal is that in Lite, we don't take
beans.xml content into account. We "only"
use it as a marker file to find JARs that
should be part of the "singular" bean
archive. So that is a non-issue, and, in
fact, simplification :-)
>
Tomas Langer also correctly mentioned
that today you can have beans.xml with
discovery mode "none" and therefore
the presence of beans.xml can mean you
don't want to process that archive.
> This is true, although I have to
point out that I haven't really seen
this used much. It is probably a
remnant of CDI 1.0 where default
discovery mode was explicit (instead
of annotated) and where you needed to
always have beans.xml present.
The only reason
why I think we might want to detect
beans.xml
configuring discovery mode to "none"
is legacy JARs. Not sure how big of
Open Liberty uses
this for improving performance for
migrated applications. The
applications used CDI 1.0 and then
migrated to CDI 1.2/2.0. Setting
bean-discovery-mode="none" will
disable the scanning, which improves
the performance.
What
I'd like to understand is, how much is
that relevant when it comes to Lite? My
guess would be: not much.
LT
On 12. 01. 21
17:26, Matej Novotny wrote:
> As a matter of fact, we
currently pour everything into a
singular bean archive (which I have
to say I came to like as it makes
understanding the meaning of bean
archive much simpler for users).
Ah that is a great point, totally
forgot about that! I think we should
do this in Lite. Multiple bean
archives made everything really
confusing
for me when I started learning CDI.
> Tomas Langer also correctly
mentioned that today you can have
beans.xml with discovery mode "none"
and therefore the presence of
beans.xml can mean you don't want to
process that archive.
> This is true, although I have
to point out that I haven't really
seen this used much. It is probably
a remnant of CDI 1.0 where default
discovery mode was explicit (instead
of annotated) and where you needed
to always have beans.xml present.
The only reason why I think we might
want to detect beans.xml
configuring discovery mode to "none"
is legacy JARs. Not sure how big of
a use case that is.
LT
_______________________________________________
cdi-dev mailing list
cdi-dev@xxxxxxxxxxx
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cdi-dev
--
_______________________________________________
cdi-dev mailing list
cdi-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdi-dev
_______________________________________________
cdi-dev mailing list
cdi-dev@xxxxxxxxxxx
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cdi-dev
--
_______________________________________________
cdi-dev mailing list
cdi-dev@xxxxxxxxxxx
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cdi-dev
_______________________________________________
cdi-dev mailing list
cdi-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdi-dev