MP definition of CDI

[Ken Finnigan]

All,

On several different threads there have been discussions around various parts of CDI that may, or may not, be applicable to MicroProfile.

To date, we've somewhat ignored those issues but I think we need to explicitly define what we mean when we say "CDI" in relation to MicroProfile.

Currently, CDI has a couple of variations (CDI SE, CDI EE), neither of which may accurately reflect what MicroProfile wants from CDI.

In this thread I'd like everyone to propose what pieces of CDI they definitely think should be necessary for MicroProfile, and which parts MicroProfile definitely shouldn't use.

From this list we can then decide the best approach to defining it in the short and longer terms.

Thanks

Ken

[Ken Finnigan]

I want to clarify what I meant by saying "MicroProfile definitely shouldn't use".

It's about defining the parts of CDI that are not applicable to the goal of MicroProfile, and thus make those parts optional for an implementation to include. I'm not proposing that pieces we might consider not applicable to MicroProfile should be excluded from an implementation.

[Emily Jiang]

Ken,

There are two usages in CDI.

1. CDI foundation in MicroProfile

2. CDI dependencies by other MicroProfile.

For 1) I would like MicroProfile consume the full CDI or CDI lite when it exists so that end users who use Jakarta EE CDI can still have their microservices working with MicroProfile implementations.

For 2) I think it depends on the subsequent MicroProfile specifications. At the moment, I don't see any requirements to limit MP specs to depend on a partial CDI because of point 1.

As for the exclusion of EL, I think it is not a good strategy of directly disabling the el integration. If EL exposes volunerability, we should fix it in CDI instead of tearing it apart by MP.

In summary, I would like MP to follow Jakarta EE CDI either full or lite not partial.

As for what lite means, I think the AOT portion should be factored in and it is better discussed on CDI mailinglist or the issue I raised.

Thanks

Emily

[Ken Finnigan]

I never viewed the Architectural removal of EL from CDI as being specifically to specifications only, and not applicable for the platform.

We need to have a common definition of "CDI", irrespective of whether it applies to the foundation of the platform, or as dependencies used within specifications. Having different definitions just muddies the waters about what's going on.

MicroProfile needs to define what it wants from CDI. When that is done, we can then participate in the Jakarta EE community for CDI to achieve that objective. I saw you'd raised an issue in the CDI community, which is great, but we need to go to that community with a full list of what we think does and does not fit for MicroProfile. Without that list, all the CDI community can do is guess as to what MicroProfile might want. Yes, there are several members of the MicroProfile and CDI communities that overlap, but there are also a lot of the MicroProfile community that are not involved in CDI and this is an opportunity for everyone to comment here.

I have several parts of CDI EE that I feel aren't applicable to MicroProfile goals, but I'd like others from the community to make their views known.

It's important to emphasize that MicroProfile saying it doesn't want something from CDI, such as EL, does not prevent implementations from including it. The goal here is to have a minimal set of requirements for MP implementations that suits the goals of MicroProfile. If the goals of MicroProfile don't align with a full spec from Jakarta EE, then we shouldn't require it's usage.

Ken

--
You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/cad6a501-e285-4430-a138-15c087b99b02%40googlegroups.com.

[Laird Nelson]

On Tuesday, February 18, 2020 at 11:17:06 AM UTC-8, Ken Finnigan wrote:

I never viewed the Architectural removal of EL from CDI as being specifically to specifications only, and not applicable for the platform.

I know this is an old issue with lots of history and I don't want to open a rathole here.  That said: could you point me at discussions or documentation on how EL is currently removed from MicroProfile's usage of CDI, given that there is an API dependency upon it (https://jakarta.ee/specifications/cdi/2.0/apidocs/javax/enterprise/inject/spi/BeanManager.html#wrapExpressionFactory-javax.el.ExpressionFactory-)?  I'd like to better understand any "prior art" in how certain subsets of foundational APIs are deemed optional (or not) in MicroProfile's usage of them to date.

Best,

Laird

[Ken Finnigan]

https://wiki.eclipse.org/MicroProfile/ArchGuidelines outlines the agreements on MP Architectural guidelines. In there it defines EL is excluded from CDI base spec dependency.

All specifications have a dependency exclusion such as MP Health: https://github.com/eclipse/microprofile-health/blob/master/pom.xml#L125

https://docs.google.com/document/d/1uAKRymdAL5Wj1KADzrYKZzSnAFsq74lBfj8lxKQnI6I/edit?usp=sharing contains some notes from architecture meetings related to EL (search for "EL API"), but there's more discussion on the issue that lead to EL being excluded.

--

You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/251a5457-816b-4de8-87d9-034c9f43849f%40googlegroups.com.

[Ondro Mihályi]

Here's the original issue about removing EL: https://github.com/eclipse/microprofile/issues/56

It documents all steps and reasons for the decision. The last comment states that EL is removed from the platform but, unfortunately, the platform spec wasn't updated to specify this, only individual specs were updated to remove EL.

Ondro

[Emily Jiang]

Instead of removing EL from MP, I think it is better to discuss the root cause for this issue in CDI spec and have it discussed there (maybe making el-api dependency as optional in CDI spec if we cannot address the security vulnerability.). As a consequence, I have raised this issue to have it fixed instead of pulling CDI apart.

Thanks,

Emily

[Ken Finnigan]

Irrespective of what happens around EL and CDI, personally it’s more than the security risk, the MP community needs to define what it considers is appropriate for CDI and MP, and what bits of CDI we don’t think are appropriate for MP.

I definitely see a case where what MP needs isn’t the same as what Jakarta needs. Hopefully that can be achieved in a layered fashion as CDI SE and EE are today.

But, MP community needs to define what that means before we start numerous discussions directly on the CDI spec

Ken

Sent from my iPhone

On Feb 24, 2020, at 14:39, 'Emily Jiang' via Eclipse MicroProfile <microp...@googlegroups.com> wrote:



--

You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/b7e9b3b4-69c9-420f-aa15-9f0f478b5f1d%40googlegroups.com.

[Emily Jiang]

Below are the funcationalities I think MP should have from CDI

Here is the list of functionalities I think CDI core should provide:

• Relationships to other specifications:
  

• Relationship to Dependency Injection for Java
• Relationship to Java Interceptors

• Concepts

• Dependent, ApplicationScoped, RequestScoped
• Support Alternatives, Stereotypes, Interceptors, Decorators

• Programming model

• Producer methods, Producer fields, Disposer methods
• Injection support: bean constructor, injected fields, Initializer methods

• Events
• Portable extensions

Thanks

Emily

To unsubscribe from this group and stop receiving emails from it, send an email to microp...@googlegroups.com.

[Ken Finnigan]

Thanks Emily

Do you see a lot of need for Decorators and Alternatives in MP?

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/b84f44da-2dea-4bad-af45-d5484712b0e6%40googlegroups.com.

[Emily Jiang]

I think end users do use Decorators and Alternatives, directly judging from support.

Thanks

Emily

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/b84f44da-2dea-4bad-af45-d5484712b0e6%40googlegroups.com.

[Reza Rahman]

For me it is far easier to specify functionality I would not expect in the typical microservices application that I have seen in the past few years:

* EJB - we really need a replacement to EJB in Jakarta EE as soon as possible. The EJB brand has been a serious adoption damper since at least Java EE 7.

* JSF/EL - the pendulum for the next few years will continue to favor JavaScript frameworks.

* @Model, @SessionScoped, @ConversationScoped - same rationale as above.

I went through the specification a couple of times and I am unable to convince myself removing anything else outside of these and related features won't result in frustrated developers. I don't think Jakarta EE or MicroProfile can afford to have very many of those.

Reza Rahman
Jakarta EE Ambassador, Author, Speaker, Blogger

Please note views expressed here are my own as an individual community member and do not reflect the views of my employer.

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/b84f44da-2dea-4bad-af45-d5484712b0e6%40googlegroups.com.

[Venkata Rahul Satuluri]

Well laid out.

Apologies for intervening in the exchange of ideas (if that is a bad surprise).

Early 2016, I was looking at developing something like Microprofile, so I tried to loosely tie together Eclipse Jetty, EclipeLink, JAX-RS and for DI I was using Google Guice.

When I found Microprofile recently, I tried to look for how the CDI w.r.t. the usage in MP is different from that in Guice and whether I can continue to use Guice (due to Syntactial familiarity). I was looking for exactly the information in @Emily Jiang's note.

I'd also like to see how Microprofile handles large scale configuration necessities (intrinsically involving dependency injection), but that will be for another post, at least because I started going thu MP only two days ago and I am yet to glean through a lot of documentation and code

Regards

Rahul

[John Hogan]

Hello Reza.  I may be in the minority but still make frequent use of ejb (lite only).  I believe Jakarta EE will be hard pressed to come up with a lighter weight, easier to use and more feature rich API than ejb.  What are some of the issues causing it to be an adoption damper?  Is it mostly old prejudices, do people want to see it in CDI ...?  Thank you.

John H

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/b84f44da-2dea-4bad-af45-d5484712b0e6%40googlegroups.com.

[m.reza.rahman]

John,

We should briefly discuss these issues here and probably move EJB specific deeper discussions to the Jakarta EJB development alias for now.

Firstly, you are hardly alone in EJB usage. What you said essentially holds true of everyone that uses Java EE today.

The problem with EJB is twofold.

The larger problem is the brand. EJB 2 got things so wrong on so many levels that it was a bad idea to continue with the EJB brand in EJB 3/Java EE 5. For most people with limited time to learn anything new, the moment they hear the EJB acronym, they do not want to hear anything else despite what the technical merits may or may not be. Fighting this uphill branding battle is just not a worthy use of effort and probably not even wise or necessary.

The second issue is technical. From a programming model perspective, EJB and CDI are highly redundant. The same held true of the JSF managed bean model that is now deprecated in favor of CDI. Not considering the programming/state management/life-cycle model, the rest of what is in EJB can be delivered through CDI in a much more lightweight, modern and flexible fashion though the right technology set such as EE Concurrency, JMS/JCA. In addition, sensible features can be grouped together much more effectively though CDI stereotypes. This in the end is actually exactly what Spring does and very clearly it is compelling for the majority of developers. Here again, we have been fighting a needless uphill battle for a long while now and I do not think it has helped.

Hope this makes sense. Let me know if we need to discuss it further and I will help us move the discussion to the correct discussion groups properly.

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.

Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/aa9f7f3e-042f-4af5-884c-bc36713d4205%40googlegroups.com.

[John Clingan]

IMHO, nailed it and nailed it. Hey, I think we've had this discussion before :-)

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile+unsubscribe@googlegroups.com.

[John Clingan]

Venkata, feel free to start a new thread on this or open up a github issue. You could also bring it up at the weekly config hangout, although I think first priming the discussion with the afore-mentioned approaches would really help.

[John Clingan]

I've always been a fan of EJB (3+) functionality. However, when I taught Java EE courses, it was painful to cover JavaBeans, JSF Managed Beans, EJBs, and then CDI. Java EE really needs a unified model. With JSF managed beans gone, whatever consensus of EJB functionality is decided on should be built/aligned with CDI. This will make Jakarta EE much more approachable for new developers.

[Emily Jiang]

See this issue I raised a while to make CDI supercede EJB fully.

John H, feel free to add any other useful features in EJB but missing in CDI there. We only want one central injection framework not two. Fading away EJB will make Jakarta EE lightweight and modernised.

Emily

[John Hogan]

John and Reza.

Thank you your inciteful thoughts.

I love cdi too, but feel having the option to use either or both as a situation dictates is a strength.  I do understand the need to eliminate overlapping functionality, and the desire to make the platform more approachable for easier adoption.  I guess I'll trust to the community that when ejb is gone, we'll have some sort of enterprise cdi beans to fill the void.  Thanks again.

John H

You received this message because you are subscribed to a topic in the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/microprofile/Rg4MPG4E6J4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to microprofile...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/5e98c22a.1c69fb81.eaa5e.c047%40mx.google.com.

[Amit Mendapara]

Hi all,

We have recently migrated a big project from Guice to CDI. The project is a kind of micro framework using Tomcat, JPA, JAX-RS and Guice, and now CDI. 

We are still not targeting microprofile but our ultimate goal is to make full transition to microprofile as some stage.

During this migration, we have tried many alternatives but it was only with Helidon CDI extensions, we were able to solve many of the use cases. So IMO, CDI extensions is very important feature microprofile should support else it will be very difficult for old projects if they ever want to migrate to microprofile.

Regards

--

Amit 

[m.reza.rahman]

I would say you should stay tuned after Jakarta EE 9 is done to make sure we indeed do the right thing especially for existing EJB users.

I just want to say as someone that has written a book on EJB 3+ that I did not arrive at my current position frivolously. I have studied the issue as objectively as I can more than once over the years and it seems like the community has in fact been ready to move on from EJB for some time. Here is the most recent decent analysis on the issue as a worthwhile reference: https://developers.redhat.com/blog/2019/10/22/jakarta-ee-whats-in-store-for-enterprise-javabeans/.

Anyway, I appreciate your chiming in and my ask would be to stay engaged when we do try to spin up this discussion again - probably starting in the EJB development alias some time after summer. I think for now it is a fairly safe assumption for any new profile for CDI to exclude EJB instead of removing it later.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/CAMgrf35oBnNuS3jM4ZxA5mTp97tWCtQ064SnfzOcLbMm8xUz-w%40mail.gmail.com.

[John Hogan]

Thank you Emily.  I'll go through the discussion and add to if I notice anything I feel is important being omitted.

You received this message because you are subscribed to a topic in the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/microprofile/Rg4MPG4E6J4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to microprofile...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/523db308-7ced-4bde-bad2-07173f419949%40googlegroups.com.

[Emily Jiang]

Thank you Amit for your feedback!

CDI portable extension is on my proposed list (https://github.com/eclipse-ee4j/cdi/issues/425#issuecomment-595779932). Please add your feedback there as well.

Thanks

Emily

[Emily Jiang]

Thank you John!

Emily

To unsubscribe from this group and all its topics, send an email to microp...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/523db308-7ced-4bde-bad2-07173f419949%40googlegroups.com.

[Ebuzer Taha Kanat]

I think CDI should be fully covered by MicroProfile since it is major glue that holds whole EE ecosystem together. But main problem from MicroProfile stand point some implementations do have some problems satisfying that because CDI uses reflection heavily and GraalVM which those implementations uses as base for their technology doesn't have complete tool to cover reflection fully. https://github.com/oracle/graal/blob/master/substratevm/REFLECTION.md

If those tools can be increased to fully cover without a manual intervention that will be the dream scenario. Yes that will require close world assumption at the build stage but i think anyone who uses those tools would be okay with it. Since they already choose static approach to gain some memory efficiency by choosing those technologies to create native image with Graal . 

Otherwise ecosystem going to be fractured as static and dynamic. Which means there is going to be two version of everything which means lots of unnecessary cost. Which means repeating ourselves instead of going forward.

All those efforts going to be spend creating static version of  everything that exists  imho should be spend to improve Graals reflection coverage. That way we won't disintegrate our ecosystem to death. 

18 Şubat 2020 Salı 18:04:21 UTC+3 tarihinde Ken Finnigan yazdı:

[Erik Mattheis]

Let’s be careful about pigeonholing this to GraalVM. Reflection has a real cost in the traditional JVM as well. Even without making the leap to generating native binaries, there is a trend towards AOT processing to remove the need for reflective access at runtime.

-- 

Erik

--
You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/8af1e9ae-3cb0-4187-939c-909ae28414af%40googlegroups.com.

[Jason Greene]

Indeed. It's also worth noting that Amit's use-case mentions Guice/Dagger, which is also a build-time solution, and would have similar problems with portable extensions as currently defined, since they allow a framework to make unlimited changes at any point in time of lifecycle. They offer a very different extensibility SPI.

It might be worth checking out Antoine's blog on ideas towards a CDI-Lite, which touches on benefits outside of better native compilation:

http://www.cdi-spec.org/news/2020/03/09/CDI_for_the_future/

To unsubscribe from this group and stop receiving emails from it, send an email to microp...@googlegroups.com.

[m.reza.rahman]

Thanks Jason for sharing that blog post. For others that have not seen it before, I think the additional context will help.

Having read it a few times now, there is one aspect that still remains unclear. Is the desire to exclude portable extensions primarily driven by a current technical limitation of Graal or is it a longer term design tradeoff in favor of performance over an expanded feature set for CDI extensions writers? Could you kindly help provide a clear and definitive answer to that?

I do have another related and perhaps even more important question. The Micronaut folks recently expressed an interest in adopting Jakarta EE APIs. I imagine this likely includes things like CDI, JAX-RS, JPA, Bean Validation and Servlet. Has anyone reached out to those folks to see what their options on some of these things are? Wouldn't it be helpful if those folks also validated some of the design decisions in Quarkus with regards to CDI Lite? To me, the prospect of broadening the reach of the Jakarta EE ecosystem would be a pretty compelling value proposition for CDI Lite?

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.

Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone

-------- Original message --------

From: Jason Greene <jason....@redhat.com>

Date: 4/17/20 4:45 PM (GMT-05:00)

To: Eclipse MicroProfile <microp...@googlegroups.com>

Subject: Re: [microprofile] Re: MP definition of CDI

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/46d0f36f-132c-4433-8ea1-5ac4a9082809%40googlegroups.com.

[Amit Mendapara]

Hi Jason,

Though I have migrated a big project, I still consider myself new to CDI and don't have much understanding of it's internal working. So you may be right about extensions, however when migrating complex projects like ours, we face many case which are difficult to resolve without some kind of extensibility.

I saw that quarkus support Hibernate natively which has really good extension SPI and we can do many things with it (and we did). So I don't understand why hibernate SPI is not a problem and CDI extensions are. It will be really helpful if someone from quarkus team can provide more details on why cdi extensions are problematic and not hibernate SPI.

[Guillermo González de Agüero]

Hi Reza,

On Sat, Apr 18, 2020 at 1:16 PM m.reza.rahman <m.reza...@gmail.com> wrote:

Thanks Jason for sharing that blog post. For others that have not seen it before, I think the additional context will help.

Having read it a few times now, there is one aspect that still remains unclear. Is the desire to exclude portable extensions primarily driven by a current technical limitation of Graal or is it a longer term design tradeoff in favor of performance over an expanded feature set for CDI extensions writers? Could you kindly help provide a clear and definitive answer to that?

I'm also curious and a bit worried about that. Interestingly, Helidon also uses Weld as its CDI implementation and already provides native support for MicroProfile. Maybe some Oracle folks can shed some light here?

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/5e9ae1a4.1c69fb81.84168.66cc%40mx.google.com.

[Ebuzer Taha Kanat]

I'm all for modularization of anything CDI case is not different It is all good on Antoine's post except that if we assume that MicroProfile going to be CDI-Lite only compatible then Portable extensions going to be left out in MicroProfile. Which will be sad thing to see when you consider it is a beautiful achievement that makes possible clean, concise, powerful and low coupling integrations which are in scope of MicroProfile like this https://www.baeldung.com/cdi-portable-extension .

Portable extensions creates a way for any service provider to reach out their hands to CDI world and any curious person from there to grab it with out hassle. Which makes experimenting and innovation frictionless for consumer, Also it is inviting to world outside CDI to join us. As much as creating a portable extension little painful, being on the consumer side of it is pretty good feeling.  We can live without it but does that kind of life worth living?

17 Nisan 2020 Cuma 23:45:02 UTC+3 tarihinde Jason Greene yazdı:

[m.reza.rahman]

I just want to understand - how essential is it to also provide input via the GitHub issue? What is actually the canonical decision making mechanism?

I am asking this as it is already difficult for busy professionals to make time to provide input. I think we should seek to minimize the effort required to do so. For me personally these forums and email are the best one place to centralize input and decision making. GitHub should remain auxiliary and mainly the domain for acting on decisions by contributors, committers and vendors rather than end users with busy lives and day jobs. This was certainly the operating model in the more well functioning JCP projects and I do have to say I believe in general it worked well especially for end user engagement.

Could someone kindly provide some guidance on some of this? What are the Eclipse Foundation best practices, for example?

Reza Rahman

Jakarta EE Ambassadors, 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.

Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone

-------- Original message --------

From: 'Emily Jiang' via Eclipse MicroProfile <microp...@googlegroups.com>

Date: 4/17/20 12:07 PM (GMT-05:00)

To: Eclipse MicroProfile <microp...@googlegroups.com>

--

You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/29a9489d-c6dd-4849-a89b-cdd8c8e96983%40googlegroups.com.

[Marc Magon]

No this is incorrect and not researched - Guice has no problems with builder native libraries from JDK 11 to JDK 14 as demonstrated here www.guicedee.com

This is because it is dynamically compiled modules in a modular environment, it moved cleanly into the native distribution space.

As I have said before,I do stronly believe you should use DI the base injection library, and not CDI to define your injections so that other projects can also use MicroProfile.

Again - this is a massive miss, and in my opinion and enormous mistake for the selection of library.

[Marc Magon]

Hi Amit,

Have you looked at GuicedEE for building native JAXRS and MicroServices in JDK native distributions - www.guicedee.com

You should only use one dependency provider, so either Guice DI or CDI/Weld

My personal opinion is you should have stuck with Guice. it is going to be many a year before jakarta becomes modular and capable for native distributions.

[Werner Keil]

Hi,

Several Jakarta EE specs are already modular, others may take a while, but at least by Jakarta EE 10 I expect that to be done across most of them.

First time I heard abut GuicedEE, seems another "kid on the block" beside so many others like Dropwizard, Micronaut or MP.

What was the reason for that version 62 btw, it completely messes up the latest release in Sonatype, or was that intentional for some reason?

Werner

[Emily Jiang]

Hi Marc,

Injection alone is very limited. CDI has many awesome features such as Bean Definining annotations, interceptors, decorators, extension, etc over and above injection. Hence, CDI has gained a lot of population and is the center piece of Jakarta EE and essential base in MicroProfile.

>>My personal opinion is you should have stuck with Guice. it is going to be many a year before jakarta becomes modular and capable for native distributions.

I disagree with the above comment. Not sure why CDI has to do with Jakarta modularity.

Emily

[Reza Rahman]

I was involved in AtInject back in the day and sadly it really does bring out some very unpleasant memories. It was a pretty bleak moment for enterprise Java that could have been so much more (sigh). I entirely understand why MicroProfile or Jakarta EE technologies really can't do much in practical terms with AtInject. It is just far too under-specified and the ship has really sailed on doing very much of anything with it other than serving as some kind of very minimal compatibility layer between CDI, Spring, Guice, etc.

Reza Rahman
Jakarta EE Ambassador, Author, Speaker, Blogger

Please note views expressed here are my own as an individual community member and do not reflect the views of my employer.

--

You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/5e8f3cc8-af67-449a-a510-66733dcd4978%40googlegroups.com.

[Amit Mendapara]

Thank Marc for mentioning GuicedEE, I came across it accidentally but haven't checked in deep. Native distribution is not our immediate goal and yes with the migration we will only use CDI not Guice.

[Amit Mendapara]

I agree with Emily, injection alone is not enough, we need lots of boilerplate code to integrate other services/frameworks. Also, while migrating to CDI we realized what we missed. Marc, we don't need full JakartaEE to use CDI. Thanks to CDI extensions and Helidon providing some nice CDI extensions, it was much easier to migrate than we expected.

[Jason Greene]

On Apr 18, 2020, at 6:16 AM, m.reza.rahman <m.reza...@gmail.com> wrote:

Thanks Jason for sharing that blog post. For others that have not seen it before, I think the additional context will help.

Sure. I’m glad it was helpful.  One quick point I want to bring up before answering these questions, just in case it wasn’t picked up by others is that no one is saying portable extensions should be removed or put into prune status or anything like that. What has been suggested is that they should be optional to MicroProfile, much like other features and even entire frameworks are today.  Developers would always have the ability to pick a platform that offers CDI Full if they wanted.

Ideally MicroProfile continues to offer a wide degree of flexibility, and focuses more on adding value than unnecessary restrictions that are at best ineffective and at worst limit adoption and participation. So IMO base platform requirements should be only what is truly necessary to support the MP specs. You can certainly implement all of them without portable extensions, and even in environments that have CDI portable extensions, only a subset of those users make use of them.  

Having read it a few times now, there is one aspect that still remains unclear. Is the desire to exclude portable extensions primarily driven by a current technical limitation of Graal or is it a longer term design tradeoff in favor of performance over an expanded feature set for CDI extensions writers? Could you kindly help provide a clear and definitive answer to that?

It’s not quite either of these things. The desire to allow extensibility is a reasonable one, it's the mechanism by which that is accomplished that is the issue.  The problem is basically an impedance mismatch. The portable extension SPI is a very loose, weakly encapsulated SPI that is open-ended, and very much built around the assumption that injection happens at runtime as part of a traditional application deployment/initialization phase. The side effect of that it’s approach is inherently incompatible with any build-time injection approach (Guice/Dagger, Micronaut, Quarkus etc).

Further, since a CDI Portable Extension is expected to be executed at runtime, and with a lifecycle that is commingled with the application and framework  runtime, extensions end up being strongly coupled to application elements. Live objects can and often are, directly passed between the layers. This can’t work in a build-time model because injection decisions and application start are executed at completely different points in time and in completely different VMs.

Build-time injection is very important to native compilation, since otherwise you negate optimizations the compilation process would otherwise bring.  However, it also benefits JVM execution as well, since discovery,  wiring, and code generation is all precomputed, and you avoid a significant number of reflection call sites, as well as massive amount of metadata and large lookup tables to support it all. 

To use an example of this on the native side, AOT native compilers like GraalVM, can do closed-world optimizations such as dead code elimination, however, if you tried to handle this with traditional runtime injection like in Weld, you would have to force the compiler to include everything (all classes, all methods all fields, etc) because until injection is resolved it’s not known what’s used and what’s not used.  So if there was 100 classes, but only one of them was actually wired (alternatives etc), you include the 99 and all the dependencies they bring anyway. This is especially the case when portable extensions are involved, since they can transform anything into a bean, arbitrarily rewrite metadata, generate proxies, and/or new bytecode/classes. The latter will not work at all since the application is already compiled, and there is no JVM to recompile it.

The problems portable extensions are intended to solve can be addressed with purpose-built SPIs that are more encapsulated and thus better suited to tolerate implementation variance (and likely simpler to use). Think of it as USB/bluetooth vs the soldering iron + screwdriver we have in the spec today. This would all be complementary, and not in competition. Antoine mentioned in the referenced blog how something similar was already partly done in SE.

Once we have a CDI-Lite that addresses these points it can make a much cleaner dependency for MP, although it might be worth considering defining the dependency on JSR-330/Atinject since that offers even greater flexibility to implementations and solves the problem today. 

I do have another related and perhaps even more important question. The Micronaut folks recently expressed an interest in adopting Jakarta EE APIs. I imagine this likely includes things like CDI, JAX-RS, JPA, Bean Validation and Servlet. Has anyone reached out to those folks to see what their options on some of these things are? Wouldn't it be helpful if those folks also validated some of the design decisions in Quarkus with regards to CDI Lite? To me, the prospect of broadening the reach of the Jakarta EE ecosystem would be a pretty compelling value proposition for CDI Lite?

I can’t speak for them, but I think it’s very unlikely they would ever consider implementing CDI Full since like Quarkus their DI architecture is build-time oriented

They did express interest in CDI-Lite (I would welcome their participation!), but note the explicit reference to overreach (i.e. lack of flexibility): 

https://twitter.com/micronautfw/status/1237715200637374465

I agree the goal should be to broaden the ecosystem, and the best way to achieve that is through being flexible, so that we can support a diverse set of implementations. 

One way to achieve that is through either requiring 330/Atinject (almost everyone implements 330),  CDI-Lite (once it’s defined) and a similar CDI subset in the meantime, or of course we could just leave it indefinitely undefined as is the case today.

-Jason

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/5e9ae1a4.1c69fb81.84168.66cc%40mx.google.com.

[Reza Rahman]

Jason,

Thanks for taking the time to write this. I have to say I am more convinced now of removing portable extensions from CDI Lite than I had been. In the least I can now provide customers/end users a cogent answer. I do hope that this is sorted out so compatibility in MicroProfile is a little more unambiguous.

I would encourage outreach to the Micronaut folks. I think the right people to do that would be more on the Jakarta EE/MicroProfile vendor side than the community side.

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/A1E90974-E881-4B75-9044-D7ED2DE9EDD6%40redhat.com.

[Amit Mendapara]

Thanks Jason, it was quite helpful. As I am new to CDI, I didn't know much about it but makes sense now. Looking forward for CDI Lite efforts. 

Regards

--

Amit

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/A1E90974-E881-4B75-9044-D7ED2DE9EDD6%40redhat.com.

[Emily Jiang]

It’s not quite either of these things. The desire to allow extensibility is a reasonable one, it's the mechanism by which that is accomplished that is the issue.  The problem is basically an impedance mismatch. The portable extension SPI is a very loose, weakly encapsulated SPI that is open-ended, and very much built around the assumption that injection happens at runtime as part of a traditional application deployment/initialization phase. The side effect of that it’s approach is inherently incompatible with any build-time injection approach (Guice/Dagger, Micronaut, Quarkus etc).

Further, since a CDI Portable Extension is expected to be executed at runtime, and with a lifecycle that is commingled with the application and framework  runtime, extensions end up being strongly coupled to application elements. Live objects can and often are, directly passed between the layers. This can’t work in a build-time model because injection decisions and application start are executed at completely different points in time and in completely different VMs.

Build-time injection is very important to native compilation, since otherwise you negate optimizations the compilation process would otherwise bring.  However, it also benefits JVM execution as well, since discovery,  wiring, and code generation is all precomputed, and you avoid a significant number of reflection call sites, as well as massive amount of metadata and large lookup tables to support it all. 

To use an example of this on the native side, AOT native compilers like GraalVM, can do closed-world optimizations such as dead code elimination, however, if you tried to handle this with traditional runtime injection like in Weld, you would have to force the compiler to include everything (all classes, all methods all fields, etc) because until injection is resolved it’s not known what’s used and what’s not used.  So if there was 100 classes, but only one of them was actually wired (alternatives etc), you include the 99 and all the dependencies they bring anyway. This is especially the case when portable extensions are involved, since they can transform anything into a bean, arbitrarily rewrite metadata, generate proxies, and/or new bytecode/classes. The latter will not work at all since the application is already compiled, and there is no JVM to recompile it.

The problems portable extensions are intended to solve can be addressed with purpose-built SPIs that are more encapsulated and thus better suited to tolerate implementation variance (and likely simpler to use). Think of it as USB/bluetooth vs the soldering iron + screwdriver we have in the spec today. This would all be complementary, and not in competition. Antoine mentioned in the referenced blog how something similar was already partly done in SE.

Once we have a CDI-Lite that addresses these points it can make a much cleaner dependency for MP, although it might be worth considering defining the dependency on JSR-330/Atinject since that offers even greater flexibility to implementations and solves the problem today.

I understand it is difficult for AOT to work with the current portable extensions. I think the requirement on Portable Extensions is still valid and on demand. I see the way forward is to rework the current portable extension from runtime to buildtime such as a new spi Antoine mentioned in his blog. We should not just exclude them just because AOT cannot cope with them. I have raised an issue to track this.

Thanks

Emily

You received this message because you are subscribed to a topic in the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/microprofile/Rg4MPG4E6J4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to microprofile...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/A1E90974-E881-4B75-9044-D7ED2DE9EDD6%40redhat.com.

--

Thanks
Emily

[Guillermo González de Agüero]

Hi Jason,

If current extension mechanism is not suited for build time, then we should aim for an alternative mechanism before making the current one optional. Most CDI integrations are done via extensions today, mainly because they are the only mechanism we have. Most of those extensions could be migrated to a different SPI that can be processed at build time, but making the only available mechanism optional now just means they won't work.

With all EE specs leaning to CDI, having Extensions support on MP means I can basically plug those new specs, on any runtime. I can add Soteria dependency and get EE Security API on my MP implementation (provided that it has Servlet and JASPIC, but that's another story). Making them optional breaks this assumption by making the main integration mechanism vendor specific.

Yes, current extensions SPI misses a lot of build time optimization opportunities, but as you say, that doesn't mean they don't work. Helidon has full native CDI support, using JBoss Weld. You can warn users about the trade-offs of using Extensions, encourage not to use them and provide vendor specific alternatives. But I don't think it's fair to make it optional for MP until there's an *official* alternative, as Emily proposed.

Regards,

Guillermo González de Agüero

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/A1E90974-E881-4B75-9044-D7ED2DE9EDD6%40redhat.com.

[m.reza.rahman]

Interesting point indeed. What is the practical assessment of when it will be possible to create an AOT friendly equivalent of portable extensions? Is it truly that far afield? If it isn't, why not wait a bit to define CDI Lite properly?

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/CAG1ZpUZfP6WEOESfjEdmYA7r%2B1zXMgQaMuYuF41qMyMsDhVhdg%40mail.gmail.com.

[Jason Greene]

> On Apr 21, 2020, at 8:43 AM, Guillermo González de Agüero <z06.gu...@gmail.com> wrote:
>
> Hi Jason,
>
> If current extension mechanism is not suited for build time, then we should aim for an alternative mechanism before making the current one optional.

Hello Guillermo,

The problem is that while we could declare this as a new requirement (the status quo is undefined, so its effectively already optiional), it would be at best ineffective or at worst hurt participation. You ultimately can’t force working implementations that can implement all of the MP specs from implementing something that they can’t do, that is incompatible with their architecture ( can’t squeeze blood from a stone!) There isn’t much teeth with an open spec/standard anyway, since everyone is free to implement the APIs and report that truth . What you can do though is make them feel unwelcome, to discourage future implementations from joining, and discourage existing participants from contributing improvements and innovations that benefit everyone back. We need more carrot and less stick. More value and less you can’t dos

At the end of the day the same number of platforms that support portable extensions will remain, regardless of any decision made here, since those that can support full CDI will and already do. So there is no harm on that side of the equation, only the potential for more on the other frameworks.

-Jason

[Guillermo González de Agüero]

Hi Jason,

Thanks for replying!

On Tue, Apr 21, 2020 at 4:59 PM Jason Greene <jason....@redhat.com> wrote:

> On Apr 21, 2020, at 8:43 AM, Guillermo González de Agüero <z06.gu...@gmail.com> wrote:
>
> Hi Jason,
>
> If current extension mechanism is not suited for build time, then we should aim for an alternative mechanism before making the current one optional.

Hello Guillermo,

The problem is that while we could declare this as a new requirement (the status quo is undefined, so its effectively already optiional), it would be at best ineffective or at worst hurt participation.

There are multiple interpretations of what exactly it means (hence this thread), but I don't think that means exactly that some arbitrary feature (extensions in this case) is optional.

 

You ultimately can’t force working implementations that can implement all of the MP specs from implementing something that they can’t do, that is incompatible with their architecture ( can’t squeeze blood from a stone!) There isn’t much teeth with an open spec/standard anyway, since everyone is free to implement the APIs and report that truth .  What you can do though  is make them feel unwelcome, to discourage future implementations from joining, and discourage existing participants from contributing improvements and innovations that benefit everyone back. We need more carrot and less stick. More value and less you can’t dos

The current situation is that extensions are not AOT friendly, but Helidon using Weld with AOT demonstrates that it's actually possible. Quarkus decided to create a CDI implementation optimized for native compilation, but to my knowledge, the reason it doesn't support Extensions is because they can't be optimized, but because they *can't* be done.

Making this support optional for everyone, without providing an alternative, just because it's not suitable for some particular approach, is not fair IMO. I don't know if there are other reasons why people think Extensions shouldn't be required.

 

At the end of the day the same number of platforms that support portable extensions will remain,  regardless of any decision made here, since those that can support full CDI will and already do.  So there is no harm on that side of the equation, only the potential for more on the other frameworks.

I agree with this, but I see it orthogonal to the MP definition of CDI. A new CDI Lite is needed to increase its adoption. It can be seen as an enhanced Atinject spec, that people can use to create DI frameworks upon. But CDI ecosystem as we know it is built on top of extensions, and supporting them is beneficial to both MP and Jakarta.

Given that the MP process allows for breaking backward compatibility, we can now agree on requiring Extension support and make it optional once there's an AOT friendly or lighterweight alternative.

 

-Jason

--
You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/EDFA9144-CFFB-4FDE-A115-8938BB831626%40redhat.com.

[Ebuzer Taha Kanat]

21 Nisan 2020 Salı 17:59:34 UTC+3 tarihinde Jason Greene yazdı:

  
The problem is that while we could declare this as a new requirement (the status quo is undefined, so its effectively already optiional)

I don't get this status quo undefined part as you can see here https://projects.eclipse.org/proposals/eclipse-microprofile "The first MicroProfile release was based on three existing Java EE technologies -- JAX-RS 2.0, CDI 1.2, and JSON-P 1.0." 

https://github.com/microprofile/microprofile/blob/master/spec/src/main/asciidoc/required-apis.asciidoc

"MicroProfile applications that make use of APIs or versions not mentioned below are not considered portable."

Am i missing something because as of now it looks like portable implementations should cover CDI 2.0 which requires portable extensions and much more. Nothing undefined in here.

[Jason Greene]

On Apr 21, 2020, at 11:05 AM, Guillermo González de Agüero <z06.gu...@gmail.com> wrote:

Hi Jason,

Thanks for replying!

Hi Gullermo, your very welcome. My reply is inline.

On Tue, Apr 21, 2020 at 4:59 PM Jason Greene <jason....@redhat.com> wrote:

> On Apr 21, 2020, at 8:43 AM, Guillermo González de Agüero <z06.gu...@gmail.com> wrote:
>
> Hi Jason,
>
> If current extension mechanism is not suited for build time, then we should aim for an alternative mechanism before making the current one optional.

Hello Guillermo,

The problem is that while we could declare this as a new requirement (the status quo is undefined, so its effectively already optiional), it would be at best ineffective or at worst hurt participation.

There are multiple interpretations of what exactly it means (hence this thread), but I don't think that means exactly that some arbitrary feature (extensions in this case) is optional.

Right, its the varying interpretations that make it all optiona.. Some think its required some think it’s not and here we are, To be required we need very clear unambiguous next and consensus around it. 

 

You ultimately can’t force working implementations that can implement all of the MP specs from implementing something that they can’t do, that is incompatible with their architecture ( can’t squeeze blood from a stone!) There isn’t much teeth with an open spec/standard anyway, since everyone is free to implement the APIs and report that truth .  What you can do though  is make them feel unwelcome, to discourage future implementations from joining, and discourage existing participants from contributing improvements and innovations that benefit everyone back. We need more carrot and less stick. More value and less you can’t dos

The current situation is that extensions are not AOT friendly, but Helidon using Weld with AOT demonstrates that it's actually possible. Quarkus decided to create a CDI implementation optimized for native compilation, but to my knowledge, the reason it doesn't support Extensions is because they can't be optimized, but because they *can't* be done.

This is not correct. I addressed this in my overly long email (sorry!) but what I explained was that a build-time architecture is fundamentally incompatible with portable extensions. Dagger/Guice. Quarkus, Micronaut, etc are all build-time implementations. The reason to want a build-time architecture is among other things the ability to optimize,  but its not something you can change without abandoning the entire architecture of the project and going in a totally different direction.  That’s a bridge too far.

-Jason

[Werner Keil]

Mark/all,

In fact with CDI you put your finger into one of the worst wounds of Jakarta EE at least when it comes to modularity ;-/

I mentioned it in the platform call yesterday and everyone agrees as discussed in a prior call, that Jakarta EE 9 would not mandate use of Jigsaw yet, which may (and IMO should) come with Jakarta EE 10 if possible.

CDI declares not one, but two main packages https://github.com/eclipse-ee4j/cdi/tree/master/api/src/main/java/jakarta

- decorator 

- enterprise

The Decorator annotation is based on jakarta.enterprise.inject.Stereotype, so it has a dependency on the "enterprise" package. I hope there's no circular dependency where elements under "enterprise" then use "decorator" but this makes it clear, even if a "jakarta.cdi" module definition was possible and desired, cutting it down into smaller modules is not so easy. 

The "se" subpackage with two elements that could be seen as a rudimentary "CDI Light" intended for Java SE have a deep and disturbing interconnection with the SPI package so defining a module like "se" won't work without using all of the SPI elements in the "spi" package, because unless the SPI was cut differently you can't share the package across different modules in the Java Module system.

So I don't think a CDI Light is likely before Jakarta EE 10 and if it was to define proper Jigsaw modules it may even require some incompatible refactoring to accomplish that.

Werner

On Tuesday, April 21, 2020 at 4:03:42 PM UTC+2, Reza Rahman wrote:

Interesting point indeed. What is the practical assessment of when it will be possible to create an AOT friendly equivalent of portable extensions? Is it truly that far afield? If it isn't, why not wait a bit to define CDI Lite properly?

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.

Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone

-------- Original message --------

From: Guillermo González de Agüero <z06.gu...@gmail.com>

Date: 4/21/20 9:43 AM (GMT-05:00)

To: Eclipse MicroProfile <microp...@googlegroups.com>

Subject: Re: [microprofile] MP definition of CDI

Hi Jason,

If current extension mechanism is not suited for build time, then we should aim for an alternative mechanism before making the current one optional. Most CDI integrations are done via extensions today, mainly because they are the only mechanism we have. Most of those extensions could be migrated to a different SPI that can be processed at build time, but making the only available mechanism optional now just means they won't work.

With all EE specs leaning to CDI, having Extensions support on MP means I can basically plug those new specs, on any runtime. I can add Soteria dependency and get EE Security API on my MP implementation (provided that it has Servlet and JASPIC, but that's another story). Making them optional breaks this assumption by making the main integration mechanism vendor specific.

Yes, current extensions SPI misses a lot of build time optimization opportunities, but as you say, that doesn't mean they don't work. Helidon has full native CDI support, using JBoss Weld. You can warn users about the trade-offs of using Extensions, encourage not to use them and provide vendor specific alternatives. But I don't think it's fair to make it optional for MP until there's an *official* alternative, as Emily proposed.

Regards,

Guillermo González de Agüero

On Tue, Apr 21, 2020 at 1:41 AM Jason Greene <jason...@redhat.com> wrote:

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/46d0f36f-132c-4433-8ea1-5ac4a9082809%40googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.

To unsubscribe from this group and stop receiving emails from it, send an email to microp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/5e9ae1a4.1c69fb81.84168.66cc%40mx.google.com.

--
You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.

To unsubscribe from this group and stop receiving emails from it, send an email to microp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/A1E90974-E881-4B75-9044-D7ED2DE9EDD6%40redhat.com.

--
You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.

To unsubscribe from this group and stop receiving emails from it, send an email to microp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/CAG1ZpUZfP6WEOESfjEdmYA7r%2B1zXMgQaMuYuF41qMyMsDhVhdg%40mail.gmail.com.

[Ivar Grimstad]

Hi,

I have started a thread on this topic over at the CDI Development mailing list, https://www.eclipse.org/lists/cdi-dev/msg00029.html. 

Feel free to chime in on that thread. 

Join the list here: https://accounts.eclipse.org/mailing-list/cdi-dev

Ivar

[Werner Keil]

Will do, but how does this list relate to the one on JBoss.org?

I saw because I had subscribed to that a long time ago, that some news about committer votes also got mentioned there.

Are they both active or mirror each other?

Werner