Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cn4j-alliance] Thoughts on the CN4J purpose

To be honest, there are many things I like and dislike about Spring, it's ecosystem and it's stakeholders. One must observe that while components to build a Spring application do come from different sources, the Spring team works hard to build a sense of cohesion by providing a uniform programming model, idiomatic abstractions, tools and runtimes. This is why the Spring brand is so strong, has managed to evolve without fragmentation and the developer experience overall feels simple. I am afraid the same cannot truly be said of the status quo of Jakarta EE/MicroProfile where even closely related bits of high level functionality like Jakarta REST and MicroProfile REST Client currently feel at least somewhat less than cohesive. The more we go down this path the worse this feel will get. That's what is ultimately worth avoiding I believe and I cannot really say I don't understand why a good number of people consistently think status quo is untenable and more convergence is needed.

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: arjan tijms <arjan.tijms@xxxxxxxxx>
Date: 1/12/21 9:16 AM (GMT-05:00)
To: Discussions on formation of a CN4J Alliance with the MicroProfile Working Group <cn4j-alliance@xxxxxxxxxxx>
Subject: Re: [cn4j-alliance] Thoughts on the CN4J purpose

Hi,

On Tue, Jan 12, 2021 at 2:02 PM Edwin Derks <ederks85@xxxxxxxxx> wrote:
This is a very good example of where it doesn't really matter from which platform the defined specification is maintained because a developer chooses a mix of ingredients for his app that happen to come from platform one, or platform two.

Correct, up till so far the APIs from both platform one and two agree to totally support each other. Meaning that e.g. Config is usable for all specs, and, say, the "Security Backbone" is used throughout all security specs. If I pic JWT as my authentication mechanism, and if I then define an additional identity store, it should be used. It should also be clear that if an app happens to define an authentication mechanism in web.xml and define JWT as the authentication mechanism what happens.

Kind regards,
Arjan Tijms


 

Back to the top