Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakartaee-platform-dev] [External] : Additional profiles

I like Quarkus approach to have properties file. This would eliminate the need for xml

On Thu, Mar 18, 2021, 5:26 PM Alasdair Nottingham <alasdair.nottingham@xxxxxxxxx> wrote:
I would certainly not be in favour of ditching XML deployment descriptors in favour of json (which doesn’t allow comments) or yaml (which has poor tooling support). I don’t think this would help make a core profile appear more developer friendly. I agree with Steve that if we go this way we need to be looking at an annotation based approach.

I don’t think that a war is incompatible with a single app per server approach, but if we have no UI components then I think allowing a jar as an alternative for packaging the application is reasonable. I’m not a fan of the executable jar approach because it makes portability of the app to another runtime harder (you have to rebuild from source) and in a docker environment I think there is a lot to recommend having the application code separate from the runtime code because you can easily place these in separate layers. In general I don’t have an issue with a spec having an opinion on packaging, but I think it should say as as little as possible about deployment and mandating an executable jar is about deployment.

Alasdair

On Mar 18, 2021, at 6:53 AM, Steve Millidge (Payara) <steve.millidge@xxxxxxxxxxx> wrote:

To move away from XML deployment descriptors then we need to ensure that everything is defined in equivalent annotations. This is largely done but not completely. Also because these annotations exist in the source level with no standard way to override short of recompiling the code Config becomes an absolute necessity to enable deploy time overrides. This will require a standard mapping of deployment annotations to Config Properties as I believe overriding annotation values is currently vendor specific. 
 
A core profile could just be silent on packaging in the same way MicroProfile is. I certainly wouldn’t want to be limited to packaging as an executable fat jar.
 
From: jakartaee-platform-dev <jakartaee-platform-dev-bounces@xxxxxxxxxxx> On Behalf Of Dmitry Kornilov
Sent: 18 March 2021 10:41
To: jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Subject: Re: [jakartaee-platform-dev] [External] : Additional profiles
 
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_101should 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


-- 

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

Back to the top