Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakarta.ee-community] Why not dropping EARs in Jakarta EE?
Hi,

In fact I read about that legacy free profile plan on a post from you ;) [1].

The layering behavior can be easily simulated via separated Maven projects that in which the UI project depends on the business logic project but not the other way.

For more complex (or security constrained) scenarios where you really can't accept one component to see some other class, I expect JPMS to be the final solution there.

Of course there's a lot of merit in the original idea. For me it was very interesting to fully read the EJB spec and get some context on how the different roles (runtime provider, application developer, assembler, deployer, etc) were expected to work.

I'd be interesting to see how much people actually use EARs for (new or legacy) applications running on *updated* servers.

Vendor experience will be critical here to determine whether it's possible to move away from this.


[1] https://blog.payara.fish/payara-server-5-alpha-1-release-is-here

El sáb., 28 abr. 2018 17:51, arjan tijms <arjan.tijms@xxxxxxxxx> escribió:
Hi,

I can't speak for Payara directly, but I personally would indeed love to do a legacy free profile.

As per the original thread, EARs have some sort of marginal advantages still, like the layering of business logic in the EJB module and UI code in the Web module. This gives some kind of guarantee that people do not (accidentally) use UI code in the business logic, thereby making the services etc there unsuitable to be used by e.g. web services.

On the other hand, EARs as many people attest here are riddled with issues. This one for instance just covers the tip of the iceberg:


With EJB being phased out, an "EJB module" doesn't make much sense to have, and it's still a bit unclear if I'm not mistaken if EJB modules can legally and in a portable way contain only CDI beans.

It was originally perhaps a good idea and to a degree still is, but implementations always have been sub-par and too many specs just "forgot" that EARs even existed and/or hastily bolded some ill thought out behaviour for the spec in EARs on.

Just my 2 cents

Kind regards,
Arjan





On Sat, Apr 28, 2018 at 5:33 PM, Guillermo González de Agüero <z06.guillermo@xxxxxxxxx> wrote:
Hi,

I see little reasons to use EARs on new projects and some specs (CDI at least) have suffered difficulties from their class visibility particularities.

Please note the Web Profile already supports only WAR deployment and also leave behind some less frequently used technologies.

Implementors will have more elaborated oponions, but I think EARs should be deprecated (not removed) and made optional on some specific profile in the near future.

Times are changing and for Jakarta EE to be perceived as a lean technology we will need some kind of composable profile (think of WildFly Swarm or Liberty) or "legacy-free" profile (I think Payara had some plans for that).

El sáb., 28 abr. 2018 10:07, Ralph Soika <ralph.soika@xxxxxxxxx> escribió:

Hi,

to my background: I have been developing enterprise applications for more than 10 years, mostly as EARs. So I am mainly a User of EE and was never part of a EE working group. My opinion about EARs after years is: It's an awful disaster if you're trying to develop an ear platform independently. So why should it be called 'standard'?

Today I wonder what can be achieved with an EAR, which could not be achieved easier and clearer with a clean microservice architecture?

So I'm suggesting removing EAR support from Jakarta EE. This makes the platform easier to learn and more lightweight.

If you like, you can read the following discussion. It's about the question of how to package shared EJB libraries in one ear. And it shows how awkward it is to talk about EAR deployment questions. 
https://github.com/payara/Payara/issues/2508#issuecomment-385129757

What is your opinion about the future support of the concept of EAR?

===
Ralph


_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jakarta.ee-community

_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jakarta.ee-community


_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jakarta.ee-community

Back to the top