Scott,
I get that, I'm more arguing about where the work should happen. Shouldn’t it be the job of an independent MicroProfile WG when creating the MicroProfile Platform CTS rather than a Jakarta responsibility?
I wouldn’t want to delay a Jakarta EE 10 release because we are preparing a profile for MicroProfile.
Steve
From: jakartaee-platform-dev <jakartaee-platform-dev-bounces@xxxxxxxxxxx>
On Behalf Of Scott Stark
Sent: 25 March 2021 20:57
To: jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Subject: Re: [jakartaee-platform-dev] [External] : Re: : Additional profiles
Currently the TCKs involved in even this minimal profile have assumptions that preclude a clean definition of an MP CTS due to the fact that the minimal platform target is the web profile. Adding a headless profile
as the core does not go far enough to eliminate unwanted dependencies because RPC is back in vogue with gRPC and serverless that have no need of a servlet container. Assumption of a deployment vehicle is another problem with expanding the use of the 'core'
specification outside runtimes that are smaller than the current web profile.
Interesting picture.
Personally I don’t see why Jakarta needs a profile that just includes ONLY MP required dependencies. The MPWG by definition has this as a profile and in the future could utilise the TCKs for these Jakarta apis and create their own Platform CTS without there
needing to be a Jakarta corresponding profile.
I am more aligned with David’s headless profile proposition as the core. I’d also like to get Concurrency into a core profile so other common required capabilities e.g. @Asynchronous could develop in a core profile.
Steve
Hi,
I did a small writeup regarding some of the ideas related to a core or super profile for EE and MP.
That is a very good additional point, that it’s worth looking at 2 or 3 Jakarta specs that already define annotations already like
·
Jakarta Annotations
·
Jakarta Inject
·
CDI
·
EJB
Spring doesn’t have some blown up „Spring Config“ module anywhere either, it is a very small number of annotations most of them existed much sooner than Spring Boot or even Spring Roo in the core framework.
Werner
The problem I see with config (and why I think it should be a Jakarta EE spec) is that it is a core specification that all other specs should use.
MP Config currently has several features that are not mature and as such is not suitable for being a base for other specs:
- the @ConfigProperties that is not well aligned with CDI (as it allows injection of classes, not just interfaces, bringing in another component that instantiates classes in a custom way)
- unclear behaviour related to caching/mutablity/consistence (such as mutability is kind of expected, yet there is no possibility to react on change; caching is not allowed on config level, yet it is somehow maybe allowed on config source level)
- I think the @ConfigProperty is too verbose… Other frameworks can live with @Value, also why does it not use `value` property? You need to use `@ConfigProperty(name=“my.property”)`, instead of `@Value(“my.property”)` - I think this is significant
MP tends to do breaking changes quite often and backward compatibility does not have high priority (e.g. even when something could have been done in a backward compatible way with proper deprecation, it is done in a breaking way - such as changes
in Config 2.0). This is not suitable for Jakarta EE (actually I think this is not suitable for any specification, but that is a different topic).
I think the Jakarta Config should be much smaller - single annotation and a very straight-forward programmatic API to start with.
Please do not use MP Config as a config spec for Jakarta EE!
While the idea of vendor-neutrality was good as a contrast to e.g. Spring not every MP API and feature has enough momentum or maturity to stand up to that cause, and some ene up with just one, at most two implementations all the supporting containers
then use.
Some like Metrics, Failsafe or to a large extent JWT were highly biased and shaped by just one JVM based solution, ignoring all the others and effectively incompatible with them which is not the aim of a broader specification like Jakarta EE.
I was not advocating declining. I was saying that it’s a bad practice to adopt other WG APIs. We are talking about about different use cases. I’ll try to explain.
You listed non-Java specifications. In Jakarta EE we have corresponding specifications with Java APIs. In case of underlying spec changes we adopt (or not adopt) our APIs. We have control over it.
The situation with MP Config is different. We are talking about taking it from MP WG as it is, declare that it’s a part of Jakarta EE Core profile and potentially make some Jakarta specs depend on it. Jakarta EE WG doesn’t have a control over
it. Some unwanted changes there may screw up all the whole Jakarta EE Platform.
Um, Jakarta EE relies on 3rd party specs all the time. JSON, XML, HTTP, SQL, REST, LDAP, SOAP, Java SE Platform, ... Declining to rely on a 3rd party spec just because it comes from another
Eclipse Working Group seems quite wrong and is not a valid reason.
Points about the stability of the 3rd party spec are valid. This can of course be negotiated with the spec author.
--
BJ Hargrave
Senior Technical Staff Member, IBM // office: +1 386 848 1781
OSGi Fellow and OSGi Specification Project lead // mobile: +1 386 848 3788
hargrave@xxxxxxxxxx
It was never a good practice to rely on a spec created by another working group. It’s out of control. It can be evolved a not desired way or abandoned. Look what’s happened with MP Tracing
when OpenTracing turned into OpenTelemetry.
Moving MP Config to Jakarta is definitely one of the options. It has its own pros and cons. As it was created by another WG, moving will require some approval process. I cannot guarantee
that it will be accepted as it is without modifications. Or maybe it can be accepted assuming that it will be modified in next releases. If we agree that this option is a way to go, it’s definitely a CN4J responsibility to define how to do it. It will require
some time, significant time, considering the fact of how it goes now. The solution with simplified Jakarta Config spec looks easier to me.
I think that Core profile must have Config. Even more, I think that other specs in Core must use it.
Well, my suggestion is to move MP Config to Jakarta and put it under core profile and then MP can directly get it back. I am also fine not to put config in the core but not having two configs.
Anyway, I think this discussion needs to happen under CN4J.
What is your idea? How shall we deal with Config in Jakarta EE?
I disagree with creating a Jakarta Config, which creates a competing message with MicroProfile Config. When MP consumes this core profile, it will have two configs to deal with.
MP Config is not huge and I don't see the value to further split it.
I agree that Config must be in Core profile, but I disagree that it should be MP Config. IMO, it must be Jakarta EE spec. Depending on a spec from another project brings many disadvantages
and Jakarta is all about stability and backwards compatibility.
I think it should be a new spec which MP Config should possibly extend. It can be very minimalistic like one @ConfigValue annotation. So, there is a similar relationship as between @Inject
spec and CDI. Or it can contain the most stable features of MP Config.
MP Config of course only given a sufficient stable and guaranteed release plan for Jakarta.
I'd almost say this Core profile should be governed by its own working group, who take into account the interests of both EE and MP, being a core profile for them both.
Now I know we can't have yet another actual working group, but such Core profile (should it come to fruition in this form) probably benefits from such shared interest governance.
Unless the MP Folks can commit on „mature Features“ (a bi like the maturity Level of CNCF) that won’t suddenly receive breaking changes and they also guarantee to provide a Jakarta
first Roadmap where e.g. MP Config is migrated to the „jakarta“ Namespace and newest Jakarta release ASAP before any other MP specs it is not ready to be included in any Jakarta EE profile I’m afraid.
Implementations may use it at their own risk but we already see how badly that affects and slows down Jakarta NoSQL and its implementations.
Gesendet von Mail für
Windows 10
Just thinking about Core from another perspective, is having it contain exactly what EE and MP have in common.
So that could be, for now:
Following this Core profile, both the rest of EE and the rest of MP could depend on it.
I agree persistence is too much for Core. While the issue is that most microservices do persist data, the sources are often varied including simply messaging and some microservices
merely perform orchestration of one kind or the other.
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.
> On Mar 23, 2021, at 7:27 AM, Lukas Jungmann <lukas.jungmann@xxxxxxxxxx> wrote:
>
> On 3/18/21, 6:07 PM, "jakartaee-platform-dev
on behalf of Emily Jiang via jakartaee-platform-dev" <jakartaee-platform-dev-bounces@xxxxxxxxxxx on behalf of jakartaee-platform-dev@xxxxxxxxxxx>
wrote:
>
> Do we need to put Data Access on the list? Microservices normally need to access a database. Do we want to add JPA or JNoSQL or something else?
>
> This is good question. Both might be too big for the "core". OTOH, when I look the JNoSQL stuff and compare that with current Persistence, I think, it would probably make sense to define sth like "persistence-core" containing annotations common to both of
them + some lightweight EntityManager/EntityManagerFactory like interface(s) offering just basic CRUD operations with some unwrap method eventually and nothing more. A Map.Entry or an item in the List could then be seen as trivial implementation of the "Entity"
from the "persistence-core". It could be even part of existing common-annotations API. Seeing jakarta.persistence.Entity and jakarta.nosql.mapping.Entity together reminded me times figuring out what type of Node is the code I have to work with using - is it
org.w3c.dom.Node or javax/jakarta.xml.soap.Node? - and that can be confusing for users in some cases in the future.
>
> thanks,
> --lukas
>
>
> Thanks
> Emily
>
>
>
> On Thu, Mar 18, 2021 at 2:59 PM Reza Rahman <reza_rahman@xxxxxxxxx> wrote:
>
>
> With regards to deployment models, I think it is best to leave it completely open. The problem is that the dust hasn’t quite settled yet and there are several options that make sense to one extent or the other: thin wars, fat/uber jars and hollow jars.
I bet it would be hard to get complete consensus on which deployment models should be required.
> With regards to Configuration, one can live with XML but it is far from ideal. I think it is best to aim for property files via a Configuration specification. In addition, a fully Java/annotation way of configuration could also be explored but I think
it is a lower priority. If you look at Spring Boot specifically, the properties based configuration mechanism seems to have won out for the most part. In order to get the Core Profile out in time for Quarkus perhaps it is best to leave configuration unspecified
at least initially.
>
> Most folks here are probably aware of this analysis of the various ways of bringing Configuration into Jakarta EE: https://reza-rahman.me/2021/02/09/your-input-needed-to-determine-path-for-jakarta-ee-microprofile-alignment/ <https://reza-rahman.me/2021/02/09/your-input-needed-to-determine-path-for-jakarta-ee-microprofile-alignment/>.
I think it should help make the discussion a bit easier. All options are workable, but this would be the order for me: A2, A1, B, C. B I think carries too many unnecessary risks and complexities. C I think really sends a poor message to the community as to
the relationship between Jakarta EE and MicroProfile. I think effectively what you are proposing is C.
>
> Reza RahmanJakarta 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.
>
>
>
> On Mar 18, 2021, at 6:41 AM, Dmitry Kornilov <dmitry.kornilov@xxxxxxxxxx> wrote:
>
>
>
>
> We talked a lot about which specs should or should not be included in the core profile. I would like to go a little beyond this topic and talk about two things which are not clear to me. The first is what kind of deployment model should we use?
>
> Logically it should support the standard Jakarta EE deployment model assuming using war/ear archives and supporting multiple deployments. It will provide maximum portability between Jakarta profiles. On the other hand it’s an overhead for the smallest
profile. In the most cases microservice is one application, so multiple applications support maybe not needed. XML-based deployment descriptors are something from the last century. We actually don’t want to include any XML processing specs to the core profile
and even made them optional in the main Jakarta profile. I am trying to say that maybe deployment specification needs a rework to support more modern approach like yaml or json files or even be based on configuration spec. It’s one of the options. Another
option would be using executable jar files the same way as in Spring Boot, Helidon, Quarkus, etc. This approach has many advantages such as unnecessary class loading madness, potential GraalVM native-image support, etc.
>
> Another topic is configuration. There is no doubt that configuration specification is needed in Jakarta. Potentially we can use MicroProfile Config, but we immediately have namespace problems. IMO, Jakarta profile must use/depend on Jakarta specifications
only. Recently I talked with Tomas Langer (Helidon architect) and he had an idea of creating a minimalistic config specification in Jakarta which contains one annotation - @ConfigValue. More functionality can be added later. MicroProfile Config can depend
on Jakarta Config. It will make possible using MP Config implementations in Core Profile implementations. It makes sense to me.
>
> I would like to hear your opinions.
>
> -- Dmitry
>
>
> On 18. 3. 2021, at 10:51, Dmitry Kornilov <dmitry.kornilov@xxxxxxxxxx> wrote:
>
>
>
>
> On 17. 3. 2021, at 23:44, Emily Jiang via jakartaee-platform-dev <jakartaee-platform-dev@xxxxxxxxxxx> wrote:
>
> I think the Cloud Profile from Ivar's doc https://docs.google.com/presentation/d/1THhvjZazSFpDE95rqtcdQXgBQxa-B3aMFksq8xKJo08/edit#slide=id.g786c259e4b_0_101 <https://docs.google.com/presentation/d/1THhvjZazSFpDE95rqtcdQXgBQxa-B3aMFksq8xKJo08/edit#slide=id.g786c259e4b_0_101>should
be renamed to the core profile and the list is a good start. By the way, I don't want to see EJB on the Core profile list. CDI is the replacement for EJB.
>
>
> I think this list can be further shortened to:
>
> JAX-RS
> JSON-B
> Annotation
> Bean Validation
> CDI
> Config
> Security
>
> CDI contains Injection, no need to mention Injection I think.
>
> Since we have JSON-B, do we still need JSON-P?
>
>
>
>
>
> We need both JSONP and JSONB.
>
>
> -- Dmitry
>
>
>
>
> Thanks
> Emily
>
>
>
> On Wed, Mar 17, 2021 at 3:14 PM arjan tijms <arjan.tijms@xxxxxxxxx> wrote:
>
>
> Hi,
>
>
> On Wed, Mar 17, 2021 at 3:33 PM Reza Rahman <reza_rahman@xxxxxxxxx> wrote:
>
>
> I think either it is best to leave Web Profile mostly alone (and maybe prune it) or use it as a more effective replacement to Full Profile (and basically treat the Full Profile as mostly legacy).
>
>
> I would like to see the latter option. Speaking with my Piranha Cloud hat on; we're not looking forward to implementing things like the Application Client Container, EAR support, and some of the more obscure aspects of Corba and EJB2 and whatever else
still lingers in EJB-full.
>
> Moving at least Concurrency and Authorization to Web Profile (for Authorization, perhaps for simplicity make it a sub-spec of Security), and perhaps a Messaging lite (Messaging with only the newer, simplified API) and Mail, would make the Web Profile essentially
the Legacy Free Profile that has been talked about before.
>
> When Concurrency absorbs most of the still useful EJB-based services in an CDI version, EJB-lite can be safely pruned from the Web Profile, IMHO.
>
> Kind regards,
> Arjan
>
>
>
> _______________________________________________
> jakartaee-platform-dev mailing list
> jakartaee-platform-dev@xxxxxxxxxxx
> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev<https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev>
>
>
>
>
>
> --
> Thanks
> Emily
>
>
>
>
> _______________________________________________
> jakartaee-platform-dev mailing list
> jakartaee-platform-dev@xxxxxxxxxxx
> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
>
>
>
>
> _______________________________________________
> jakartaee-platform-dev mailing list
> jakartaee-platform-dev@xxxxxxxxxxx
> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
>
>
>
>
>
>
> _______________________________________________
> jakartaee-platform-dev mailing list
> jakartaee-platform-dev@xxxxxxxxxxx
> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev<https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev>
>
>
>
>
>
> _______________________________________________
> jakartaee-platform-dev mailing list
> jakartaee-platform-dev@xxxxxxxxxxx
> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev<https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev>
>
>
>
>
>
> --
> Thanks
> Emily
>
>
>
> _______________________________________________
> jakartaee-platform-dev mailing list
> jakartaee-platform-dev@xxxxxxxxxxx
> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev__;!!GqivPVa7Brio!KxVLs81rWG5eLJIR8uSN8yyIF3uSLQ5wuvd7u4_MqwQHcFaMqFO5HXUQmY6dc7Q-DQ$
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
|
