CDI extensions for MicroProfile

[Ondrej Mihályi]

Hi all,

I think that it is important to support the fact that MicroProfile has a great potential and could be already evaluated for production applications. 

In my experience, people are now confused about MicroProfile, asking what they can do with just 3 sets of API. The current answer is that they can bundle any library with their application to extend the functionality, but that leaves the pain of integration onto the users.

Since CDI is already in MicroProfile, I suggest to create a platform to support/promote development and publishing CDI extensions for various technologies and usecases. Currently, there is only a single well-known repository for CDI extensions - DeltaSpike - and it's a project on its own, not promoting third-party CDI extensions. I imagine that MicroProfile could be a place to promote useful CDI extensions, including Deltapike, and provide a catalog to search for and get started with the extensions easily. If all the current and future MicroProfile proposals RIs are also bundled as CDI extensions, they could be published into such catalog and used with any MicroProfile runtime even before officially accepted into the core API.

I'm willlig to put an effort to this and work on the MicroProfile site to add a page for such extensions catalog.

But it is also necessary to have many relevant extensions, and also test them with MicroProfile implementations. We could start with the set of relevant DeltaSpike extensions. But I suggest that all vendors and the community invest some time to building CDI wrappers around popular libraries so that they may be easily integrated into any MicroProfile app or runtime.

What do you think? Is anybody willing to put effort into this with me?

--Ondrej

[Gordon Hutchison]

Hi Ondrej,

I think that is a very interesting idea.

In a microservices context I had wondered about creating a CDI equivalent of a JAX-WS dynamic proxy.

So this could mean a @Produces that constructs a dynamic proxy to microservices found in a service registry.
This would allow a programming model of plain-old-java-objects locally but also give somewhere to
hook in value added services/contexts.

I was going to write an example list of these services here (logging context, TLS etc.... )
but I am not sure what would belong in it (versus being better off in the application or in
a sidecar/fabric of something like Amalgam8/Istio/Envoy).

Some of the reasons why local/remote transparency were considered an anti-pattern by some people
( http://www.rgoarchitects.com/Files/fallacies.pdf etc. ) might be weaker than the first time around perhaps.

CDI has fantastic potential to enable all sorts of good stuff (Hammock, https://vimeo.com/181814358 etc. )  so I think your idea has
great timing and microprofile seems like a good place to me to kick these ideas around.

Gordon Hutchison
(My own opinions, not speaking on behalf of my employer :-) )

[Werner Keil]

Actually subject to more than one thread, but since this one talks about CDI extensions, a "Red Hatter" also created one for Dropwizard Metrics: https://github.com/astefanutti/metrics-cdi

Werner

[Ken Finnigan]

Ondrej,

It sounds like you're discussing two separate concerns: existing CDI extensions (DeltaSpike) and existing third party libraries where a CDI extension would need to be implemented that wraps it.

I would expect that in most cases the former should be possible without any integration required, and if there is integration needed I believe it should require agreement with the MicroProfile community as to how that integration is defined. If it requires agreement within the community, then it makes sense for it to be part of the normal proposal process.

With respect to third party libraries that aren't CDI aware, that's a tricky one. There are so many libraries out there and not every vendor would agree as to which libraries are adding value and should be wrapped with CDI. That then leads to the issue of, potentially, some vendor implementations not supporting each of them the same way, or at all.

I can agree that v1 of MicroProfile is very light, but that was the point to get it in motion. My concern with doing something like this is it appears to be offering a "back door" of sorts into MicroProfile inclusion. If something's worthy of inclusion in MicroProfile it needs to go through the usual process, otherwise we will easily see MicroProfile becoming the kitchen sink of Java EE libraries.

I'd rather ramp up, fine tune, improve, or whatever, the process by which we decide/develop things to be part of MicroProfile so that the community can see progress and growth for specific things that will be of benefit when developing microservices. This should improve with the new year and once the actual move to Eclipse Foundation has occurred.

What's included in MicroProfile as time goes on will not please everyone, and I fear having some kind of "extensions" registry will make it even more confusing and displeasing.

Just my 2c

Ken

--
You received this message because you are subscribed to the Google Groups "MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile+unsubscribe@googlegroups.com.
To post to this group, send email to microp...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/3266e822-1186-4879-8325-61309035808b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[John D. Ament]

Ondrej,

What you're describing here actually aligns to some conversations Antoine (S-D) and I have had about the CDI ecosystem.  When looking at what has happened, there's two patterns that have come out:

- Projects adopting CDI into their own suite of integrations

- Developers (projects?) building CDI + some other component together.

There's been some successes on the first part - Spring Data CDI, Camel CDI.  All three JAX-RS impls have CDI modules.  There have also been projects that have been approached and said "yes, that makes sense" and have been able to bring up two so far - Apache ActiveMQ Artemis CDI & Feign CDI.  There's a short list of projects that may make sense to reach out and see if they're interested in building out the integration into their platform.  JTA is a big one, only Narayana supports CDI natively, so it may make sense to contact other projects to gauge interest.

As far as developers go, I would have to say that Antonin Stefanutti has been a big influence in this area, having laid the original ground work for Camel CDI and Metrics CDI.  A lot of this is what drove the original Seam3 project forward, before it merged with CODI to create DeltaSpike.  DeltaSpike's focus has been on Java EE integration, so it leaves the playground wide open to allow others to build extensions targeted to non-EE use cases.  One of my goals with Hammock in 2017 and its move to the ASF is to continue to build this playground of extensions that are meant to be one off - they serve a single purpose, do that one purpose really well.  You'll see the beginnings of this - there's RabbitMQ integration, and starting to gear up on integrating the netflix stack.  All of this done with the intention of being plain CDI extensions.  So far their only reliance is from configuration provided by DeltaSpike.

John

[Reza Rahman]

Integrating CDI with just about any technology X out there has interested me for a long time. If there is something I can do to help, do let me know. It can be something as mundane as writing documentation or blogging.

--

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

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/ef225a63-3b74-425a-a8f1-7deca5f59ad0%40googlegroups.com.

[Steve Millidge]

CDI extensions around popular frameworks is a very interesting area. IMHO a lot of the popularity of Spring is exactly that. Spring wrappers around existing frameworks so they can be used easily in a Spring aware application.

Whether this is a microprofile project is another discussion.

So +1 from me even if not via Microprofile.

On Monday, 26 December 2016 04:11:14 UTC, Reza Rahman wrote:

Integrating CDI with just about any technology X out there has interested me for a long time. If there is something I can do to help, do let me know. It can be something as mundane as writing documentation or blogging.

[Reza Rahman]

It does not particularly matter to me where it is hosted. Is this sort of thing part of the DeltaSpike charter? If not, perhaps it should be? I think as long as it is CDI, it should be almost trivially pluggable into any CDI capable environment, MicroProfile or not.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/bc62d736-d76f-4ef2-8e2b-62f3e16601b7%40googlegroups.com.

[Werner Keil]

Ken,

On Thursday, December 22, 2016 at 2:48:32 PM UTC+1, Ken Finnigan wrote:

Ondrej,

It sounds like you're discussing two separate concerns: existing CDI extensions (DeltaSpike) and existing third party libraries where a CDI extension would need to be implemented that wraps it.

I would expect that in most cases the former should be possible without any integration required, and if there is integration needed I believe it should require agreement with the MicroProfile community as to how that integration is defined. If it requires agreement within the community, then it makes sense for it to be part of the normal proposal process.

With respect to third party libraries that aren't CDI aware, that's a tricky one. There are so many libraries out there and not every vendor would agree as to which libraries are adding value and should be wrapped with CDI. That then leads to the issue of, potentially, some vendor implementations not supporting each of them the same way, or at all.

I can agree that v1 of MicroProfile is very light, but that was the point to get it in motion. My concern with doing something like this is it appears to be offering a "back door" of sorts into MicroProfile inclusion. If something's worthy of inclusion in MicroProfile it needs to go through the usual process, otherwise we will easily see MicroProfile becoming the kitchen sink of Java EE libraries.

I'd rather ramp up, fine tune, improve, or whatever, the process by which we decide/develop things to be part of MicroProfile so that the community can see progress and growth for specific things that will be of benefit when developing microservices. This should improve with the new year and once the actual move to Eclipse Foundation has occurred.

What's included in MicroProfile as time goes on will not please everyone, and I fear having some kind of "extensions" registry will make it even more confusing and displeasing.

While .NET and earlier VB or Delphi had very active market places for components and extensions, Java never really saw a similar market succeed. In the late 90s some of the markets for extensions, plugins or widgets offered JavaBeans, I also did sell some components there at the time. One of those FlashLine.com ended up with BEA and hoped to sell Enterprise JavaBeans (EJBs) then in a similar way. It never got off the ground and Oracle also never created a successful "Component Registry" or market place similar to say those by Apple or Google for all sorts of apps.

It is focussed on plugins and drag-and-drop installation into the IDE, but maybe even on the server side Eclipse MarketPlace could be leveraged somehow for certain extensions, now that Microprofile is an Eclipse Project.
https://marketplace.eclipse.org/ has over 23 Million "solutions" to install. Many are open source, but you also find commercial products and extensions to pay for similar to Google Play or Apple Market place.

Werner

 

Just my 2c

Ken

On Thu, Dec 22, 2016 at 3:31 AM, Ondrej Mihályi <ondrej....@gmail.com> wrote:

Hi all,

I think that it is important to support the fact that MicroProfile has a great potential and could be already evaluated for production applications. 

In my experience, people are now confused about MicroProfile, asking what they can do with just 3 sets of API. The current answer is that they can bundle any library with their application to extend the functionality, but that leaves the pain of integration onto the users.

Since CDI is already in MicroProfile, I suggest to create a platform to support/promote development and publishing CDI extensions for various technologies and usecases. Currently, there is only a single well-known repository for CDI extensions - DeltaSpike - and it's a project on its own, not promoting third-party CDI extensions. I imagine that MicroProfile could be a place to promote useful CDI extensions, including Deltapike, and provide a catalog to search for and get started with the extensions easily. If all the current and future MicroProfile proposals RIs are also bundled as CDI extensions, they could be published into such catalog and used with any MicroProfile runtime even before officially accepted into the core API.

I'm willlig to put an effort to this and work on the MicroProfile site to add a page for such extensions catalog.

But it is also necessary to have many relevant extensions, and also test them with MicroProfile implementations. We could start with the set of relevant DeltaSpike extensions. But I suggest that all vendors and the community invest some time to building CDI wrappers around popular libraries so that they may be easily integrated into any MicroProfile app or runtime.

What do you think? Is anybody willing to put effort into this with me?

--Ondrej

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

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

[Ken Finnigan]

Werner,

Not sure whether there was meant to be a question in there or not?

Anyway, I don't dispute that a "marketplace" for CDI extensions, or more general Java EE things, would not be beneficial to the Java EE community as a whole.

What I'm saying is that such a thing is not a small amount of work/maintenance to achieve, and MicroProfile has more important things to be solving right now.

Ken

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

To post to this group, send email to microp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/e7570b81-f365-45d9-9f1c-f8136b751d7e%40googlegroups.com.

[Werner Keil]

Ken,

That's exactly why Microprofile entered the Eclipse Foundation as a project. It has established infrastructure for many of that including a Marketplace.
Whether it is already used on the server side for updates of containers, let's leave that to others for answering. At least the solutions with OSGi support based on Karaf, Equinox, etc. should have no problem to use the same mechanisms you see inside the IDE. Virgo (by Pivotal and SAP) or Gemini https://eclipse.org/gemini/ hoped to archive that also for Enterprise "containers" (including Spring Boot) before.

Both don't seem too active, but while I don't know if they use Market Place or not, the way they intended handle modules and extensions on the Server Side this would work the same with CDI / JSR 330.

Werner

[Antoine Sabot-Durand]

Having a place to list all CDI initiatives could benefit Microprofile and Java EE. I started this work on CDI site month ago, but it's still very  modest, but it's a start. Building a CDI ecosystem is a huge work that nobody want to do right now but pointing to existing initiative is a reachable target IMO.

Antoine

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/89bb34b4-67a0-4010-800a-82638e49aaf3%40googlegroups.com.

[Werner Keil]

I can't say if e.g. Eclipse Marketplace could be expanded that way so app servers and compatible runtimes may directly consume it (like you see on the IDE side) but it's worth talking about it.

Guess we can also do that next week in London.

Werner

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

[Ondrej Mihályi]

I wonder if the Eclipse marketplace can also provide extensions developed outside Eclipse fnd (like Apache DeltaSpike), but it would be interesting to have a common place for all CDi extensions, and possibility to filter those that are applicable to MicroProfile.

However, what I was seeking in this thread was a catalog for extensions to MicroProfile (not necessarily CDI-based), which can be easily bundled into any application as a maven dependency and just work when the app is running on a MicroProfile impl. Unfortunately, most of DeltaSpike CDI extensions require Java EE APIs, which are not (yet) in MicroProfile (JPA, JSF, etc.) The point is to select only those extensions that can work with MicroProfile to get developers find and start using them easily.

I don't think that in the beginning that would require a lot of effort. Only include a searchable catalog (like the Grails one) into the microprofile.io site and let people contribute the data into the catalog via pull requests.

We can encourage the community to develop new MicroProfile-specific extensions, but we don't have to invest time into that. However, for some popular libraries, it wouldn't require a lot of effort to create a simple CDI wrapper. But very often, such wrappers already exist on the internet, but are not easy to find.

--Ondrej

Dňa piatok, 6. januára 2017 15:27:25 UTC+1 Werner Keil napísal(-a):

[Werner Keil]

I briefly asked Mike Milinkovich (I think it was in the Q&A for a Microprofile presentation by IBM, see https://jcp.org/aboutJava/communityprocess/ec-public/materials/2017-01-1011/January-2017-Public-Minutes.html) when I dialed into the London EC Meeting, if Eclipse marketplace was able to serve other components than "Plugins" or OSGi bundles and he said it could.
Unfortunately my question wasn't recorded there in the minutes, but I'm sure, Mike or Wayne can tell us more about this option here.

Werner

[Werner Keil]

Actually if you look at E4 https://wiki.eclipse.org/Eclipse4/RCP/Dependency_Injection

It's based on the handful of standard annotations like @Inject from JSR 330, so components and extensions to E4 that are properly written (e.g. no hard-wired dependencies to a UI framework neither SWT/RCP nor server side like JSF or MVC) should work inside any runtime or container. Whether it's Eclipse RCP/IDE, Equinox (not restricted to rich GUI apps) or other OSGi containers like Felix, Karaf,... As well as Dagger, Guice or CDI.

With CDI 2 aiming for Java SE support, that should make desktop/server compatibility even easier to accomplish.

Werner