| Re: [jakarta.ee-community] Why not dropping EARs in Jakarta EE? |
We need to clean up the API for sure, to separate preferred and frequently used APIs from other APIs. Some less used APIs make sense to be pruned (made optional) to make life easier for implementers. Other less used APIs should stay but be made less visible for newcomers.
Especially for newcomers, it's very hard to get started and avoid using older and less preferred technologies. There are many obsolete tutorials and docs that are still widely used. We should definitely update the documentation to cover the most important APIs first and put those less important parts to advanced tutorials. Otherwise, newcomers are confused.
The current Java EE 8 tutorial is a perfect example of how not to present things to newcomers. It's a complete reference, with XML and SOAP mentioned prominently in the overview section, all Java EE APIs listed together in the same list without any context, packaging section talks about EJBs, EJB JARs, etc. Newcomers expect to learn the most important subset first and then add on top of it.
Cheers,
Ondrej Mihályi
Senior Payara Service Engineer
Payara Server – Robust. Reliable. Supported.
E: ondrej.mihalyi@xxxxxxxxxxx | T: +1 415 523 0175 | M: +421 902 079 891
----------------------------------------------------------------------------------------------------------------------
Payara Services Limited, Registered office: Unit 11, Malvern Hills Science Park, Geraldine Road, Malvern, WR14 3SZ
From: jakarta.ee-community-bounces@xxxxxxxxxxx <jakarta.ee-community-bounces@xxxxxxxxxxx> on behalf of Jorge Vargas Garcia - Edivargas <edivargas@xxxxxxxxx>
Sent: 01 May 2018 15:12:02
To: Jakarta EE community discussions
Subject: Re: [jakarta.ee-community] Why not dropping EARs in Jakarta EE?
Aditionally to technical issues about deprecating technologies. Remember most of programmers are there trying to understand and use JakartaEE frameworks and API, they don't have a hapoy path to do it.
We cant' change names and deprecated them every n months. We need (like someone says) stabilized JakartaEE platformn.
BR
El mar., 1 de may. de 2018 7:35 AM, reza_rahman <reza_rahman@xxxxxxxxx> escribió:
We've discussed the EJB issue before so don't really want to beat a dead horse too much again (you'll forgive the pun). I think the consensus was that we need to get it done and it was mostly a question of who was going to do the work.
It has long been my opinion that we should have replaced EJB in Java EE 7 and deprecated it in Java EE 8. It's water under the bridge now, but not doing this has hurt due Java EE adoption in a way I have repeatedly seen first hand. I do hope we can focus on putting this problem finally behind us quickly in Jakarta EE. The problem with EJB is both technical and marketing oriented.
Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone
-------- Original message --------
From: Guillermo González de Agüero <z06.guillermo@xxxxxxxxx>
Date: 5/1/18 7:36 AM (GMT-05:00)
To: Jakarta EE community discussions <jakarta.ee-community@xxxxxxxxxxx>
Subject: Re: [jakarta.ee-community] Why not dropping EARs in Jakarta EE?
Hi,
EJB was just an example, as could be JSP. EJB has indeed a lot of unique features like you said (as has SOAP over REST). I don't think there is much interest in developing the EJB spec further, which makes the API a candidate for the "stable spec". Most people I've talked to would like to see its good features available as CDI extensions. Apparently Oracle didn't have much interest on that lately, but the Concurrency Utilities project is now led by Steve Millidge (Payara) [1] and EJB and JMS will be led by David Blevins (TomiTribe) [2].
That makes me hope we'll be able to move the required features soon. As shown by Arjan, most is already achievable right now with the existing APIs.
Even then, we might not want to *deprecate* EJBs, but new users should be encouraged to use CDI, where the effort will be centered.
We can replace the "deprecated" or "stable" term with "not-so-cool-right-now". My emphasis is that we need a way to move users forward without forgetting existing investings.
Deprecating a spec might not be the right way to achieve it. In fact, to my knowledge, the JCP didn't deprecate specs, but it was Java EE which decided that *in its context*, a spec was deprecated or proposed optional. Here I see each committee will have a different role:
- The technical/steering committee decides that some specific technology is not worth putting much effort into, as it is already well stablished and needs no further development.
- Based on that, the technical/steering committee decides that, in the context of Jakarta EE, that spec isn't on the "bleeding edge" right now, tags it at "stable", and removes them from the proposed "Bleeding Edge Profile", that would be there just for people who want the latest thing.
- The spec committee won't usually update the spec, not because the project is dead, but because the project is already stable and little updates would be needed. The technology is not deprecated, so one can expect some update eventually if there's enough interest. The spec itself wouldn't be deprecated nor tagged stable. That just exists in the context of Jakarta EE distributions.
SOAP is still *widely* used. We don't see articles on how cool it is, but most of us still have to deal with it in one way or another. People in need for it could just add the implementation dependency, configure the server to provide the module (if the runtime supports that kind of modularity), or just use the Full Profile as we've been all doing until now.
Nobody complains the Web Profile doesn't contain JAX-WS or remote EJBs, because that profile it's specifically dedicated to web developments. My opinion is that we need a way to separate what most modern developments need, without implying that a specific technology is dead and should not be used anymore. Until now we only had the deprecation process, but that doesn't fit all cases.
Hope my opinion is clearer now.
El mar., 1 may. 2018 a las 12:28, Instantiation Exception (<instantiationexception@xxxxxxxxx>) escribió:
@Guillermo, how can you qualify EJB 3 as deprecated if we don't have any standard alternatives for scheduling, concurrency, pooling, security...
@all, I work in industry where all our integration partners use SOAP :-/ and I think I am not alone.
On Tue, May 1, 2018 at 10:38 AM, Mrinal Kanti <mrinal.kanti@xxxxxxxxx> wrote:
What is the criteria for marking a feature/technology for deprecation in Jakarta EE specs? Just because a certain segment of the consumers do not use it, does it qualify that feature to be marked as deprecated?
IMO, the deprecation process should be judiciously used in scenarios when a particular feature conflicts with newer versions. For example, when EJB 3 had to be supported along with EJB 2.x. Similarly, it can be used to say that SOAP(or JAX-WS) version X is deprecated in favor its more recent version Y. Deprecation should NOT be used to suggest that SOAP(or JAX-WS) is being superseded by REST(or JAX-RS) or any other technology for that matter.
-Mrinal
On Tue, May 1, 2018 at 1:48 PM, Guillermo González de Agüero <z06.guillermo@xxxxxxxxx> wrote:
So, just to understand your view, do you think we should get rid of the deprecation process from Java EE?
El mar., 1 may. 2018 10:16, Mrinal Kanti <mrinal.kanti@xxxxxxxxx> escribió:
I don't think it would be a wise idea for a standardizing body to comment/tag on its own specifications based on user opinions or technology direction. IMO, this kind of reflects poorly on its own standardizing processes. It should be left to implementors/vendors on how much value-add they choose to provide on top of these technologies (while supporting others for backward compatibility). Also I think commenting on stability or direction is something that should be left to solution providers or consulting firms. A good example of this might be the ThoughtWorks Technology Radar.
-Mrinal
On Tue, May 1, 2018 at 1:14 PM, Guillermo González de Agüero <z06.guillermo@xxxxxxxxx> wrote:
In the end those are only semantic issues to me, but you are right, "deprecated" sends the message that something is "coming to and end". Expanding your idea, I imagine we could accommodate the current deprecation process to add a new "stabilized" phase.
So we could have:
- "Live" specs: the same as today. Specs where development takes place.
- Stabilized specs: we acknowledge there are valid uses, but they are no longer the *recommended* solution, unless you need a specific feature from them. JAX-WS and EJB could make into it. There's nothing wrong with using them, but the development effort is now somewhere else and there are "improved" ways to achieve most of their funcionality from the new specs. We should clearly document alternatives and the reasons why we have decided that these specs are not the better suit for new developments. In the same vein, we must state the unique features that are not covered by any other newer technology. Users should feel free to use these specs if they need something specific from them. SOAP is a great example of this.
- Deprecated specs: basically the same as today. In my understanding, deprecation was introduced in Java EE as a way to facilitate eventual removal. For me deprecation shouldn't imply planned removal.
- Proposed optional (removed) specs: same as today.
With this enhanced lifecycle, we may create a new "Jakarta EE Bleeding Edge Profile", containing every spec in the "Live" status. Stabilized, deprecated or proposed optional specs would be out.
Traditional customers would just use the classic Full Profile and don't bother some specs they use are now "stabilized" (they sure already know it now). New users just use the Bleeding Edge Profile, which will remove specs in future versions as they get stabilized or deprecated. In that way, the Bleeding Edge Profile *wouldn't be* backwards compatible.
What if the "Bleeding Edge Profile 9" removes some spec (as it has been "stabilized") from 8 that you needed? You have two options:
- Upgrade to Full Profile.
- Modularity to the rescue! Both WildFly and Liberty already provide easy ways to add/remove most features. GlassFish once had an OSGi console to manage installed bundles. I expect more modularity improvements on Jakarta EE due to JPMS and the need for customized runtimes.
Keeping this scenario in mind, the Bleeding Edge Profile would be the recommended one for new users, while having the Full profile for existing users that know they need something more (similar to WebSphere Traditional vs Liberty).
What do you think?
Regards,
Guillermo González de Agüero
El lun., 30 abr. 2018 a las 22:43, Andy McCright (<j.andrew.mccright@xxxxxxxxx>) escribió:
Regarding "deprecating" or "removing" these technologies (whether it is EARs, JAX-WS, WS-*, etc.), I'd recommend that we also consider "stabilizing". Stabilizing should communicate that we are not planning to remove the technology, but we also are not planning to add new function to it.
Thanks, Andy
On Mon, Apr 30, 2018 at 3:00 PM, Mrinal Kanti <mrinal.kanti@xxxxxxxxx> wrote:
On Mon, Apr 30, 2018 at 9:22 PM, Jason Greene <jason.greene@xxxxxxxxxx> wrote:
...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.
+1 Exactly. I think the word "enterprise" needs an strong emphasis here and of course the role that SOAP plays (even if that involves preaching to the choir ... and since we are already scratching that itch...).
SOAP by itself: If one is looking at SOAP as ONLY a messaging format then its definitely not the most efficient solution for real-time messaging. But the real value of SOAP becomes evident in the set of technologies and standards that are built around it, such as many of the WS-* specifications. Notable among these are WS-Security, WS-Notification, WS-Addressing, WS-Policy etc. depending upon which of these specifications one has been exposed to. SOAP along with its WS-* specs ensure that concerns like security, publish-subscribe, reliable messaging are inter-operable even if implemented across multiple technology platforms.
Tool Support: Speaking of tool support, I am not talking about the usual code completion or schema driven content assist, but integration tools that help in mapping input message formats to output message formats and applying relevant transformations in between. Enterprises rely heavily on such mapping tools for integrating services across multiple Lines of Business (LOBs), third-parties or business partners. Again SOAP as a messaging format is indispensable here and supported by almost all enterprise-grade integration platforms.
SOA Landscape: Most large enterprises, by now, have already been through some kind of SOA adoption/transformation plan. They have different Lines of Business (LOBs) which are at different levels of SOA maturity. SOAP still is widely used as a common messaging format for web services across LOBs within the enterprise due to its wide support across multiple platforms. From business perspective, it also facilitates implementing SOA governance using tools like service registry most of which have built-in support for SOAP based web services.
Industry adoption: There are some who believe that SOAP and related WS-* technologies should be deprecated just because of apparent stagnation in their development. There are a lot of standard bodies (such as BIAN) who are actively using SOAP for defining their service landscape. Unfortunately, most of their activities are restricted to participating members only and may not be accessible to the general public. I am aware of large enterprise clients who are heavily invested in actively driving such banking industry standards. To me this is not a sign of stagnation but an attestation to its stability and maturity.
-Mrinal
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 --------
From: Ben Evans <benjamin.john.evans@xxxxxxxxx>
Date: 4/30/18 11:07 AM (GMT-05:00)
To: Jakarta EE community discussions <jakarta.ee-community@xxxxxxxxxxx>
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@xxxxxxxxxxx>
> > 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@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.
> > >> >
> > >> > 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
> > >>
> > >> _______________________________________________
> > >> jakarta.ee-community mailing list
> > >> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> > >> _______________________________________________
> > >> jakarta.ee-community mailing list
> > >> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> > >
> > >
> > > _______________________________________________
> > > jakarta.ee-community mailing list
> > > To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> > >
> > >
> > > _______________________________________________
> > > jakarta.ee-community mailing list
> > > To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> > > _______________________________________________
> > > jakarta.ee-community mailing list
> > > To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> >
> > _______________________________________________
> > jakarta.ee-community mailing list
> > To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> > _______________________________________________
> > jakarta.ee-community mailing list
> > To change your delivery options, retrieve your password, or unsubscribe from this list, visit
>
> _______________________________________________
> jakarta.ee-community mailing list
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> _______________________________________________
> jakarta.ee-community mailing list
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
_______________________________________________
jakarta.ee-community mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
_______________________________________________
jakarta.ee-community mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
_______________________________________________
jakarta.ee-community mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
_______________________________________________
jakarta.ee-community mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
_______________________________________________
jakarta.ee-community mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
_______________________________________________
jakarta.ee-community mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
_______________________________________________
jakarta.ee-community mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
--
Regards,
Guillermo González de Agüero
_______________________________________________
jakarta.ee-community mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
_______________________________________________
jakarta.ee-community mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
_______________________________________________
jakarta.ee-community mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
--
Regards,
Guillermo González de Agüero
_______________________________________________
jakarta.ee-community mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
_______________________________________________ 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