On Apr 30, 2018, at 7:53 AM, Mrinal Kanti <mrinal.kanti@xxxxxxxxx>
wrote:
Why are we still discussing this?
Java EE had profiles (web and full) support since v6. It is for good
reasons that the web profile has been implemented as a subset of the
full profile and not as a stand-alone profile, Applications that
work with web profile should not break when working with full
profile thereby assuring upgrade-ability and portability. If CDI or
any other platform technologies has any problems inter-operating
with the full profile then it is the responsibility of the
respective platform technology stakeholders to address that in their
own specs/implementations unless there are valid issues/limitations
with any of the full profile specs/implementations. In addition to
the EAR support mandated by the JEE full specs, several app servers
have provided their own proprietary classloader mechanisms to make
packaging and deployment more flexible albeit, at the cost of vendor
lock-in/portability.
Modifying EAR support will have severe impact on several existing
enterprise packaging and deployment scenarios especially involving
shared libraries and entities (such as JAXB, JPA). Also the concept
of having a inter-application-wide parent classloader facilitates
several implementation approaches such as scoped objects and
simplified transaction boundary realization - stuff that are not
easy to implement over microservices (and are often ignorantly
dismissed as anti-patterns).
JPMS support is fairly new and its spec has been validated largely
against the JDK libraries. Even then, I see it as augmenting the EAR
classloader specs rather than replacing it.
Marking EAR support as optional/deprecated will only cause more
problems as more and more specs(and TCKs) would start ignoring it.
Personally, I do not see any strong argument against the EAR support
so long as enterprises are still using monolithic deployments.
Though micro-services are increasingly becoming popular, the
monolithic deployment approaches are still relevant in several use
cases.
Besides, the issue raised by the OP has already been addressed in
the original GH issue.
-Mrinal
On Mon, Apr 30, 2018 at 4:27 PM, Dmitry Kornilov
<dmitry.kornilov@xxxxxxxxxx> wrote:
I think that Jakarta EE should have profiles. Full profile should be
as much backwards compatible as possible with previous version (read
Java EE). It should support EARs. Other profiles (Web, Micro?) may
not support EARs, or it should be up to implementations to support
it.
— Dmitry
On 30 Apr 2018, at 11:55, Alexander Salvanos <salvanos@xxxxxx>
wrote:
Hi all,
while I agree, that dropping EAR's feels like a good idea, for large
scaled Java EE projects in huge companies, this could result into
costs we could avoid, by keeping backward compatibilty.
Just like RMI-IIOP we should begin at the most with the term
PROPOSED OPTIONAL and later OPTIONAL for a long period, before it
can be dropped.
Best,
Alex
GESENDET: Montag, 30. April 2018 um 11:27 Uhr
VON: "Adam Bien" <abien@xxxxxxxxxxxxx>
AN: "Jakarta EE community discussions"
<jakarta.ee-community@xxxxxxxxxxx>
BETREFF: Re: [jakarta.ee-community] Why not dropping EARs in Jakarta
EE?
HI Ralph,
EARs are helpful to deploy multiple WARs at once. E.g. a main
microservice with a corresponding sidecar.
However: I didn't created any EARs since Java EE 6,
cheers,
adam
On 28. Apr 2018, at 10:06, Ralph Soika <ralph.soika@xxxxxxxxx>
wrote:
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
[1]
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 [2]
_______________________________________________
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 [2]
_______________________________________________
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 [2]
_______________________________________________
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 [2]
