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?
Yes I agree and this is why I said we need to understand the "real world implication" of such and act.

Once we have an understanding of the impact that would drive what we would need to do and when.
Could be as simple as a survey or as complicated as hosting a technical forum on the topic.

I guess I am pointing out, in a round about way, the need for planning, process and communication structure
pertaining to making technical changes to Jakarta EE. 

As we move forward this type of discussion will come up repeatedly.

On Mon, Apr 30, 2018 at 11:52 AM, Jason Greene <jason.greene@xxxxxxxxxx> wrote:
I am not trying to split hairs, but I think it’s important that we differentiate between JAX-WS and SOAP. A Jakarta EE developer may have no control over whether the protocol is used since there is a peer involved that they might not govern. 

On Apr 30, 2018, at 10:28 AM, reza_rahman <reza_rahman@xxxxxxxxx> wrote:

Just to be clear, I am not in favor of deprecating or removing JAX-WS precisely for these reasons.

Whether it needs to be part of any other profile by default other than the "complete" or "full" Jakarta EE profile is another question. I think the answer is that it does not.

Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone

-------- Original message --------
Date: 4/30/18 11:07 AM (GMT-05:00)
To: Jakarta EE community discussions <jakarta.ee-community@eclipse.org>
Subject: Re: [jakarta.ee-community] Why not dropping EARs in Jakarta EE?

Just my own data point, but I train several hundred graduates as new intake at a couple of reasonably savvy banks. SOAP is still very much part of the curriculum.

SOAP may not be the new hotness any more, but there’s a lot of it out there & it’s still a major integration tech for 3rd party / vendor products.

Thanks,

Ben

On Mon, 30 Apr 2018 at 15:56, Adam Bien <abien@xxxxxxxxxxxxx> wrote:
Just deprecating - not removal. SOAP was not updated for years. I see only a little difference to IIOP. Some of my clients are still happy with RMI-IIOP....

> On 30. Apr 2018, at 16:53, Abdessamad Amzerin <abdessamad.amzerin@xxxxxxxxx> wrote:
>
> I agree with Reza Rahman, Soap is still widely used, and I guess that removing JAX-WS from right now wouldn't be a good idea, especially that Jakarta ee is in it's early stages
>
> On Mon, Apr 30, 2018, 15:16 Adam Bien <abien@xxxxxxxxxxxxx> wrote:
> We could deprecate SOAP now, and remove it in a few years.
>
> > On 30. Apr 2018, at 16:15, reza_rahman <reza_rahman@xxxxxxxxx> wrote:
> >
> > I definitely see many customers still using SOAP. It may make sense to drop JAX-WS altogether some time in the future, but I think it's best to wait a few more years right now.
> >
> > The right solution to many of these issues in my view is Jakarata EE fully embracing modularity, perhaps ideally based on JPMS.
> >
> > We should continue to have various profiles such as:
> >
> > * Core (Servlet only)
> > * Web
> > * Microservice
> > * Complete
> >
> > However, more importantly unlike today with Java EE, the platform should be clear that implementations will allow the user to add or remove Jakarta EE technologies with compatible versions at will. GlassFish was well on its way to achieving this under Sun ownership until everything with GlassFish went south with the Oracle acquisition.
> >
> > Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone
> >
> > -------- Original message --------
> > From: Peter Richardson <astropcr@xxxxxxxxx>
> > Date: 4/30/18 9:54 AM (GMT-05:00)
> > To: Jakarta EE community discussions <jakarta.ee-community@eclipse.org>
> > Subject: Re: [jakarta.ee-community] Why not dropping EARs in Jakarta EE?
> >
> > Why would you want to get rid of SOAP support? It is still heavily used in security critical deployments for its strict XML schema message enforcement and ability to easily embed certain security AA constructs such as SAML tokens.
> >
> > JakartaEE has to be more than microservices and REST.
> >
> > -Peter Richardson-
> >
> > On Mon, Apr 30, 2018, 9:21 AM Adam Bien <abien@xxxxxxxxxxxxx> wrote:
> > I could find some use cases for EARs -- SOAP / JAX-WS might be a better candidate for deprecation / pruning,..
> >
> > > On 30. Apr 2018, at 15:19, Peter Richardson <astropcr@xxxxxxxxx> wrote:
> > >
> > > I agree completely with Mrinal.
> > >
> > > While microservices are hot today we need to keep in mind Java EE is used for a lot more than that and there are many, large, and expensive to refactor, legacy EE projects that are still smarting from the decision to drop EJB. If these projects are to keep pace with Jakarta EE's more rapid release pace and the resulting testing and acredidation requirements levied by customers then backwards compatibility will be key.
> > >
> > > I would rather this group work towards making EAR a real cross-platform specification so that an EAR could be deployed on Wildfly, GlassFish, TomcatEE etc. without reconfiguration. Right now I agree that this is an issue as well we recently moved our EAR deployment from GlassFish to JBossEAP with some headaches.
> > >
> > > -Peter Richardson-
> > >
> > > On Mon, Apr 30, 2018, 8: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@eclipse.org>
> > >> 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
> > >> >
> > >> > What is your opinion about the future support of the concept of EAR?
> > >> >
> > >> > ===
> > >> > Ralph
> > >> >
> > >> > _______________________________________________
> > >> > jakarta.ee-community mailing list
> > >> > jakarta.ee-community@eclipse.org
> > >> > 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@eclipse.org
> > >> 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@eclipse.org
> > >> 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@eclipse.org
> > > 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@eclipse.org
> > > 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@eclipse.org
> > > 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@eclipse.org
> > 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@eclipse.org
> > 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@eclipse.org
> 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@eclipse.org
> 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@eclipse.org
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@eclipse.org
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@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jakarta.ee-community




--
Regards,

Christopher D. McCoy
240-501-7414

Back to the top