Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdi-dev] CDI profiles (was RE: About parsing beans.xml files in Lite)
On 26. 01. 21 23:13, Emily Jiang wrote:
By the way, I am not a big fan of profiles. Profile is an overloaded world already. Jakarta EE itself has the concept of Web Profile, Full Profile, etc. Now, in CDI, we are trying to define many profiles. This would cause a lot of confusion.

I don't think it's a new thing. CDI already has SE and EE "modes" or "profiles".

I am with Mark on the points of - CDI Lite needs to be the subset of CDI if we call it CDI Lite; We should not change the defined behaviour (I am against the idea of ignoring the content of beans.xml and scan jars regardless of the bean-discovery-mode setting).

I guess we could just ignore beans.xml completely and mandate CDI implementations to provide (in their native way) some means of configuring which artifacts should be scanned.

LT


Thanks
Emily

On Tue, Jan 26, 2021 at 4:18 PM Ladislav Thon <lthon@xxxxxxxxxx> wrote:

Hi,

I think that's very nice, and quite close to what we've just discussed on the call. (Meeting minutes coming :-) )

I'd like to get back to the "defining feature", if I may. I have probably misunderstood you completely. At this point, there's no new _feature_ proposed, no new API, no new configuration, etc. (except the new extension API, which is just inevitable fact of life and I guess we would all be happier if we didn't have to do them :-) ). It's mostly about restructuring or redefining of what's already there, in a way that doesn't break existing CDI users yet allows CDI to be used in more environments (notably, in an environment that "pre-wires" beans during application build).

Hope that I said it better than the last time.

LT

On 26. 01. 21 16:22, Manfred Riem wrote:

Hi,

 

As it is clear that we are NOT gravitating towards a solution here I would like to pivot and propose an alternative that could be hopefully acceptable to all parties involved.

 

  1. Drop the notion of CDI Lite
  2. Introduce the notion of CDI profiles
  3. Define 3 profiles for the CDI specification
    1. CDI
    2. CDI – CP (Core Profile)
    3. CDI – BTF (Build Time Profile)
  4. Make 3c an optional profile as far as the specification is concerned (EE runtimes should not have to be required to support 3c)

 

Where 3b is a proper subset of 3a and 3c is a subgroup of 3b (or in other words 3c uses 3b and it is allowed to add its own incompatible  “sugar”).

 

Thoughts?

 

Thanks!


Kind regards,

Manfred Riem

 

From: cdi-dev <cdi-dev-bounces@xxxxxxxxxxx> On Behalf Of Ladislav Thon
Sent: Tuesday, January 26, 2021 7:59 AM
To: cdi-dev@xxxxxxxxxxx
Subject: Re: [cdi-dev] About parsing beans.xml files in Lite

 

Hi,

On 26. 01. 21 15:27, Manfred Riem wrote:

 I am sorry you think me asking for the one defining feature is inconvenient and make you feel like going around and around, but from my perspective it is a very important question to answer.

no, that's not inconvenient, I understand the desire to have a "defining feature" -- I'm just pointing out that we already went through a very similar discussion (here on this mailing list).

What is the one defining feature for CDI itself? I would argue when most folks think about CDI they think Dependency Injection.

 

So my question stands! What would most folks think this to be named variant would stand for?

 

Everything I have heard so far does not tell me that as I have only heard implementation concerns.

I don't think it's an implementation concern. If the specification can't be implemented under certain constraints, then either such implementation doesn't make any sense, or the specification needs to change. I personally believe it's the latter.

LT

 

Thanks!

 

Kind regards,

Manfred Riem


_______________________________________________
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


--
Thanks
Emily


_______________________________________________
cdi-dev mailing list
cdi-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdi-dev

Back to the top