Intruducing Extensions for MicroProfile

[Phillip Krüger]

Hi all

Myself and Derek Moore started a project called Extensions for MicroProfile (https://www.microprofile-ext.org/).

It's a collection of useful libraries to use with MicroProfile. So far we have:

Config Extensions:

• Config Sources
• Memory Config source
• Properties Config source
• Yaml Config source
• Json Config source
• Xml Config source
• Etcd Config source
• Config utils
• Config events
• Config source CDI Providers
• Config Converters
• List Config converter
• Json Config converter

The properties, yaml, json, xml and memory source also reload on file changes and fire CDI events for every change.

OpenApi Extensions:

• Swagger UI.

A easy way to get Swagger UI. The UI is configurable and you can 'theme' it

Health Extensions:

• System Health probe
• JVM Health probe
• Health UI

Some generic health probes and a basic UI

JAX-RS Extensions

• Configurable Exception Handler
• Bean validation Exception Handler

Some configurable Exception handlers

Rest Client Extensions

• Configurable Error Response Handler

All libraries is available in Maven central, so to use it is as simple including it your pom.xml

Please have a look and let us know what you think, also, please contribute if you have some useful extensions :)

Cheers

Phillip

[Emily Jiang]

This is awesome, Philip! Thanks for your contribution!

I think some extensions can contribute towards some future spec improvement, especially MP Health. I think what you have done for providing some essential health check payload will adds value to the spec. I would like to propose to the community to host these extensions under MicroProfile, so that it is much more visible and it can have a better influence towards the future spec contents.

We could either:

1. host the extension under microprofile-sandbox

2. Create microprofile-ext project

Thoughts?

Thanks

Emily

[Ken Finnigan]

While I agree that the work Phillip and Derek have done could lead to inclusion into future versions of some MP specifications, I don't agree that it makes sense to add them under MP project "control".

The MP Sandbox is purely for initial steps to something becoming an MP specification, but as most/all of the extensions relate to existing specifications, doing that doesn't appear to align with the purpose of Sandbox.

We could add the whole project under MP "control", but then it runs into the issue of being another project that needs maintenance, etc. It also means releasing those extensions becomes a lot harder as it needs to go through the Eclipse IP and Release processes.

Tangentially, I would say it's unrealistic for us to "control" all things MP related that are created in the community. For sure we need to work with the open source community to nurture and assist with things like this, but I would prefer to see an ecosystem grow than force everything through MP.

Ken

[Derek Moore]

Our independent "Extensions for MicroProfile" community project *does* have a license from the Eclipse Foundation legal department to use the MicroProfile trademark. So we do have some recognition as well as a commitment to continue to using the MicroProfile name "with permission."

I think there are great opportunities for this MP-Ext project, one of them being transferring technologies or capabilities back to the parent projects.

MP-Ext could be another ambassador for growth (and early experimentation) in the MP ecosystem, like Hammock also is.

MP-Ext could be a home for portable versions of the many MP-related "wheels" that people are constantly re-inventing in a less-than-reusable manner right now. E.g., SmallRye is an implementation with a ZooKeeper config source, and Playx is a Javax-&-MP-for-Play adapter with a Typesafe Config config source, etc.

I don't think Phillip or I would be opposed to MP-Ext gaining some kind of "official", "semiofficial" or "unofficial" recognition, or maybe over time it does make sense to make a collection of official and portable extensions under the Eclipse Foundation & MicroProfile umbrellas.

We don't need to rush into anything! But we do want to start several conversations right away!

For example, our Config Events system should be adopted in some manner (I don't know if ConfigJSR can consider this also):

  https://github.com/microprofile-extensions/config-ext/blob/master/config-events/README.md

This way Java applications can react to config changes without application restarts. Phillip implemented the config events system at my request (I have a rudimentary version in my as-yet-uncontributed ZooKeeper config source), and he is finding it quite useful in his own work already.

Hopefully we have a fruitful cooperation with the MicroProfile parent project and its many specifications well before anything "official" is determined about our handy collection of extensions that hope to be portable across all MP impls!

Thanks, Emily & Ken, for your enthusiastic support and your obvious desire to help lead us toward a path to success!

Derek

PS: One thing we'd like help with right away is following best practices to make sure our jars are proper OSGi bundles.

[Emily Jiang]

Thanks Derek! Maybe microprofile.io is a better place to mention mp-ext, so that developers that consider contributing extension can directly partipate in this repo instead of reinvent wheels.  By the way, I can help you with OSGi versioning and bundling etc. 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/as-2ReGQhks/unsubscribe.
To unsubscribe from this group and all its topics, send an email to microprofile...@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/9053729c-de2b-42e8-93e6-93d6e8b01c18%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[John Clingan]

First, this is freakin' awesome! Thanks Derek/Phillip for taking the initiative! This, along with SmallRye, is an example of the growing ecosystem around MicroProfile. To be a healthy ecosystem, MicroProfile needs projects like these that are not directly under the MicroProfile umbrella. My two cents.

To unsubscribe from this group and all its topics, send an email to microprofile+unsubscribe@googlegroups.com.

[Reza Rahman]

Finally catching up with my GMail inbox. Emily, I rather agree with you. It is far too early to start having extensions of MicroProfile. Having as much work as possible within MicroProfile itself is what will help core adoption at the moment (and that is the biggest challenge this project specifically and Java EE generally still has).

--
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 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/54f37b9e-36ab-4c57-bbfb-cb4fd353d729%40googlegroups.com.

[Asad Kazmi]

Hi,

This is a great idea but I have a few questions.

1- Why not contribute to the microprofile instead of creating the extensions? 

2- If it has to be extensions then this should be mentioned somewhere on the mircroprofile website. 

3- Since there is breaking change coming next release in some apis, how will this work with the extensions?

I personally like the extensions overall and some features from extension should be added to microprofile unless it is getting "big". Which features should be moved / get inspiration from, that's up to the community to decide.

BR,

Asad

On Thursday, November 15, 2018 at 5:34:20 AM UTC+1, Phillip Krüger wrote:

[Phillip Krüger]

Hi Asad.

Here my response:

1) This was discussed, and decided to keep it separate. These extensions is not really specification, but rather common libraries that can be used by most implementations.

2) Like mentioned we decided to keep this separate for now. Maybe in the future there can be a section on Microprofile.io that mention "side" projects like this.

3) We will continue to test compatibility with the latest releases, and if needed we might also have to bump to a new major version

[Werner Keil]

Hi,

MicroProfile already is a number of extensions to Java EE/Jakarta EE among other frameworks and technologies. 

Creating an "extension of the extension" sounds almost like a "complication of the complication" (Brazil: https://youtu.be/_-gJrmIL5BE) and would inevitably cause fragmentation and lack of compatibility.

Werner

[Rhuan Henrique]

Hi,

I think it is an amazing project. But I think it can be submitted to Microprofile, because the Microprofile works with concept of portable microservice, because we can use N vendors. The Microprofile extension is not a spec, then when we use the microprofile extension we can not use another vendor to promote those. 

Congrats for this project!

Rhuan Rocha

--

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 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/ed4cab39-c02f-4d19-95fb-467a8016cfaf%40googlegroups.com.

[Ondro Mihályi]

Hi,

The MicroProfile project itself is specifically about creating specifications that complement Java EE, or in other words, work well with Java EE / Jakarta EE. I wouldn't say they "extend" Java EE because they don't require all Java EE specs and they also don't force using any extensions points in Java EE in implementations.

MicroProfile-ext is a separate community project which provides real portable extensions or utilities on top MicroProfile API or integrate them with SPI. This is possible, because many MicroProfile specs provide SPI (extensions points), e.g. for providing additional portable config sources. These extensions define custom functionality which is not yet ready to be specified.

While providing extensions within the MicroProfile project itself isn't in scope right now, it can change in the future. Until then, I think it's a good idea that the MicroProfile-ext project moves to the Eclipse Foundation to improve coordination with the MicroProfile project as they would be in the same opensource foundation.

--Ondro

[John Clingan]

MicroProfile is not an extension to Java EE/Jakarta EE. MicroProfile is a standalone project that uses the base programming model provided by 4-5 JSRs. MicroProfile implementations can implement MicroProfile without implementing Jakarta EE.

--
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 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/ee7d9dd5-d110-4d9c-99ac-3e5cfe8fa697%40googlegroups.com.

[Mark Little]

+1

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/F77847D9-1B69-43B9-9CB8-19CE5FC15912%40redhat.com.

[Rhuan Henrique]

Ondro Mihályi,

I disagree that MicroProfile-ext is a separate community project which provides real portable extensions. The Microprofile-ext is a good project, but don't provides a real portable extensions, because if you use the features provided by Microprofile-ext, you cannot change the vendor that provide those solutions. I guess some features of Microprofile-ext can be submitted to Microprofile. 

Thank you!

Rhuan Rocha

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/754E0930-8687-4A32-A272-AAC62EA8C462%40gmail.com.

[Ken Finnigan]

Rhuan,

In what way is the MicroProfile-ext project not vendor neutral?

My understanding is that they are simply extensions that can be added to an application to provide additional functionality and features, irrespective of where that application is deployed.

Ken

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/CA%2BZAF_b%3DzeB%3DzWRJ2p0hu8tAA1J6C5LWcXeiP0vof94ezenpsQ%40mail.gmail.com.

[Phillip Krüger]

Hi Rhuan

Microprofile-ext is really just a library (or libraries) that you can include with you MicroProfile application. It's not tied to any MicroProfile vendor, and in most of the examples (that's included in the projects) you can run against Payara Micro, Open Liberty and Thorntail :

    mvn -Pthorntail clean install

or

    mvn -Ppayara clean install

or

    mvn -Popenliberty clean install

(example the config-ext: https://github.com/microprofile-extensions/config-ext/blob/master/config-example/README.md)

And the only reason it's these 3 is at time of writing this libraries, those 3 where MP 1.3 Compatible.

There are some libraries, specifically those that contains front-ends, like the Swagger UI library and the Health UI library, that uses webjars (https://www.webjars.org/) and webjars needs a Servlet Engine to work. (https://www.webjars.org/documentation#servlet3)

So they might not work on MicroProfile implementations that does not include Servlet. This is something we can re-think at some point, if needed.

Cheers

[John Clingan]

On Feb 21, 2019, at 9:07 AM, Ondro Mihályi <ondrej....@gmail.com> wrote:

Hi,

The MicroProfile project itself is specifically about creating specifications that complement Java EE, or in other words, work well with Java EE / Jakarta EE. I wouldn't say they "extend" Java EE because they don't require all Java EE specs and they also don't force using any extensions points in Java EE in implementations.

+1

MicroProfile-ext is a separate community project which provides real portable extensions or utilities on top MicroProfile API or integrate them with SPI. This is possible, because many MicroProfile specs provide SPI (extensions points), e.g. for providing additional portable config sources. These extensions define custom functionality which is not yet ready to be specified.

While providing extensions within the MicroProfile project itself isn't in scope right now, it can change in the future. Until then, I think it's a good idea that the MicroProfile-ext project moves to the Eclipse Foundation to improve coordination with the MicroProfile project as they would be in the same opensource foundation.

Actually, I think it is great that there is a non-affiliated project that supports MicroProfile. Remember in the early days of J2EE when there seemed to be a new web framework every day? That was an amazing ecosystem that drove J2EE (and later Java EE) forward. I see microprofile-ext in a similar manner. Relatively speaking,  MicroProfile is in its early days and I think microprofile-ext I think it shows the growing MicroProfile community.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/71db3823-5c0e-4e74-873f-151e0f0e76f6%40googlegroups.com.

[Rhuan Henrique]

Hi,

Ken Finnigan, Maybe the concept of portable microservice is different to me. What's a portable microservice? To me is a microservice that run in any vendors (thorntail, payara and other). But, is not only that, to me. To me in a portable microservice, all dependencies are provided by vendor (thorntail, payara and other). As explained by Phillip Krüger, the microprofile-ext is a library and is a dependency included on the package or inserted on the server as a module. 

Getting the Java EE as example, when we use JPA, we have N vendors implementing that (Hibernate, Eclipse Link). When we use a spec we can select the vendor to use (not only the server like Jboss, Glassfish and other). In the case of use microprofile-ext like Config-ext we cannot select the implementation, because it's a library and this dependency is not provided by server by default. 

I guess it is an amazing project, but when we use that we can impact the portability (if my concept of portability is correct), because it extend the features of Microprofile, but only microprofile-ext provide these extensions.

Rhuan Rocha

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/316E420D-A5F9-4FA3-8C63-1DBE155F88F9%40redhat.com.

[Ladislav Thon]

čt 21. 2. 2019 v 18:39 odesílatel Rhuan Henrique <rhua...@gmail.com> napsal:

What's a portable microservice? To me is a microservice that run in any vendors (thorntail, payara and other). But, is not only that, to me. To me in a portable microservice, all dependencies are provided by vendor (thorntail, payara and other). As explained by Phillip Krüger, the microprofile-ext is a library and is a dependency included on the package or inserted on the server as a module. 

Do you avoid Guava because it's not a spec and by definition is only provided by one vendor? Spring? RxJava? Log4J? I think you're stretching it a bit too far.

To me, community extensions to MicroProfile specifications are important part of the entire ecosystem, and also a proof that MP delivers what it promised.

LT

 

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/CA%2BZAF_bxuU0UqYJ-d0eJfEaztrE0iHVPmV3fxPJVuT_WvmaubQ%40mail.gmail.com.

[Rhuan Henrique]

I'm sorry, let me explain. I don't say to avoid microprofile-ext. What I want to say is to submit some solutions of microprofile-ext to turn party of a spec and turn able to other vendors implement that. I'm sorry if I expressed myself poorly. I think microprofile-ext is an amazing project and I will contribute to this project. 

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/CALbocOkbqGc2%2BEEmwM-Dqu2gkq4jwEJ0hZ2_L0YzrRLOLJWUwg%40mail.gmail.com.

[Werner Keil]

You'll find several MicroProfile modules that are also maintained by just one or two vendors, so that should not speak against Guava, but for some aspects of Guava like the Collection support you may also use Eclipse Collections if you want ;-)

Werner

[Ken Finnigan]

I tend to refer to what you describe as either "provided", "bundled", or "pre packaged" depending on the particular context.

Portability should refer to the ability for the same deployment to be run on multiple vendors without customization.

Though the two concepts are related, they could be done separately or in combination. Though it would be great for vendors to bundle these extensions, as John mentioned I would consider this to be a BYO type situation for them at present. Not everyone will want all parts of the extensions in all applications.

None of the above precludes anything from within the library being proposed as MP specs or alternations to existing specs.

However, I do see it as important that the MicroProfile community does not try to own or control everything in the ecosystem, as we want it to flourish wherever it may decide to grow.

Ken

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/CA%2BZAF_bxuU0UqYJ-d0eJfEaztrE0iHVPmV3fxPJVuT_WvmaubQ%40mail.gmail.com.

[Werner Keil]

It's an extension to a subset of Java EE that does not exist as a "profile" so far, if you use monitoring for JDBC or JAX-WS there are several other Java EE specs beside the half a dozen base dependencies.

[Emily Jiang]

The microprofile-ext project is a convenient lib built on top of MP specs. How to use it? Packaged it with your microservices. This is very similar to Apache DeltaSpike, which is a kind of CDI extension. It demonstrates some CDI usage and it directly influence CDI spec. Similarly, microprofile-ext serves the similar purpose. If some features are widely used, it can be adopted by the future releases of the corresponding specs.

I see microprofile-ext as an addendum of the spec where end users can choose to package the libs if they want to use them and still rest assured that the microservices is still portable.

HTH

Emily

[John Clingan]

JCP JSRs are composable. There are plenty of technologies that utilize JSRs without including all of Java EE. Java EE is a composition of JCP JSRs with additional rules for how to use them together.   MicroProfile is a composition of JSRs plus home-grown specifications.

Looking at MicroProfile as an extension of Java EE (or even Jakarta EE) is an incorrect framing of the problem MicroProfile is trying to solve. MicroProfile can be used both in Java EE contexts and non-Java EE contexts.