[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jakartaee-platform-dev] [External] : Additional profiles
|
I think most of the microservices require DB access and JPA should be included.
Hopefully you did not mean xml out of date when labeling as a last-century technology. XML vs. YAML is still under debate. XML is widely used and powerful. There are a lot of YAML haters! Don't have a problem with supporting json or yaml though but we need to keep xml. I agree with Steve and Alasdair on the deployment story. Keep the option open.
For configuration, I think Jakarta EE and MicroProfile should settle under CN4J. I am not in favour of forking, which creates a competing message (something not advocated by CN4J).
Back to the spec list on the core profile: Thanks for educating me on the significance of JSON-P!
JAX-RS
JSON-B
JSON-P
Annotation
Bean Validation
CDI Lite
Config *
Security
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?
Thanks
Emily
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/. 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 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.
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
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
Hi,
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
--
_______________________________________________
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!LIry2y8KlDpW6rUynIJ5upLsWt56u_tWjo98jJytP27iquVQ6IgodpQzS5BqAwl9f3M2$
_______________________________________________
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!OEWfJIqfOCJX65wS261z3w1esVzuyIkrtAgVpUgW2Y6u6amQ8rEU--bUHhzViu-AaWHM$
_______________________________________________jakartaee-platform-dev mailing listjakartaee-platform-dev@xxxxxxxxxxxTo 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
