| Re: [jakarta.ee-community] A Composable Platform Over Profiles |
Another issue is that specs often used to define a cross-concern functionality (e.g. CDI, validation, security) when there wasn't a spec that already covered it. This is for reasons how JCP worked.
Within Eclipse and Jakarta EE I hope there will be much smaller barrier to create new specs and also to split big specs like Servlets, CDI, EJB into smaller ones.
In short, we should: modularize existing specs, improve how they integrate when used together and deprecate duplicate functionality. Only after that we should make them work with plain Java SE and integrate with Spring and other frameworks.
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------------------------------ ------------------------------ ----------------------------
Registered in England and Wales: 09998946 | www.payara.fish | info@xxxxxxxxxxx | @Payara_Fish
From: jakarta.ee-community-bounces@eclipse.org <jakarta.ee-community-bounces@eclipse.org > on behalf of Reza Rahman <reza_rahman@xxxxxxxxx>
Sent: 03 May 2018 22:30:16
To: jakarta.ee-community@eclipse.org
Subject: Re: [jakarta.ee-community] A Composable Platform Over ProfilesI honestly don't want to drag this on too much and prefer other people chime in with what they think.
Imagine for a moment that someone wants to use Java EE MVC with Spring or Guice for DI, etc. That would be a lot easier if you can just do the bootstrap through a Servlet Filter or Listener - that's what Spring, Guice, etc mostly rely on to do Java EE bootstrap/integration. Now you'll need to do that some other way - probably CDI/JAX-RS. You can basically make the same argument for any Java EE API that mostly runs in a web environment. That's why it's best to just treat Java SE and Servlet as the baseline the best you can and try to stick to AtInject the best you can.
Of course none of this is black and white. It is though a matter of accepting a practical reality that in order for Jakarta EE to go anywhere now we have to acknowledge that we are basically second-class citizens "in our own ecosystem". In a parallel reality where we do not have the tragic history that Java EE does, maybe we would have the luxury to behave otherwise. Will it really do us favors if we live in that parallel reality? Or is it better if we hedge our bets, make sure we retain some mind share in an ecosystem we no longer control and still serve a narrower but slowly growing population that does have real loyalty to the platform as opposed to merely utilizing parts they think they can't do without?
It's not easy, but that's the challenge if we are to really make it. It has been for a dozen+ years now. Our altruism is no accident I believe. There is a good chance we would have ceased to exist otherwise.
On 5/3/2018 3:48 PM, Werner Keil wrote:
Not sure if Spring MVC relies on Servlet, it probably does, but the "Jakarta EE" MVC standard does not, so a pure RESTful Microservice or Self-Contained System (which also may include a Web UI) can do with CDI, JAX-RS, JSON(P/B) and where the UI is required something like "Ozark" (or whatever it shall be called under Eclipse) MVC.
I can't see a mandatory Servlet requirement in the MVC RI, so why force it onto a profile if that may not use it?
On Thu, May 3, 2018 at 5:20 PM, Reza Rahman <reza_rahman@xxxxxxxxx> wrote:
To be honest with you, I opposed not including Servlet in MicroProfile too. The reason for this is twofold and nothing much to do with just the bare technical merits of Servlet alone: it would have kept the focal point of the platform centralized unequivocally on Servlet and also because the vast majority of things that attempt to build upon anything Java EE most often use Servlet as a bootstrap point and certainly not CDI (the most prominent example being Spring).
I think we've created a situation in MicroProfile now that the Spring guys might have a hard time adopting that API even if they wanted to. A more judicious path in my view would have been to adopt CDI only when it makes total sense, adopt Java SE wholeheartedly, and stick to AtInject as much as possible as a baseline. I was hoping we could correct these things with Jakarta EE or at least the Servlet part. I really think one of our big mistakes throughout the years has been fighting market realities too much instead of judiciously adapting to them in the name of technical merit alone. I don't think it has worked and I think we need to think differently at this juncture in terms of marketing too.
On 5/3/2018 10:55 AM, Richard Monson-Haefel wrote:
--Good points. Keep in mind that I have not stated what the Core is, only that CDI be part of the core. In other discussions on this topic I have argued that Servlets also be part of the core. I would also include interceptors, but beyond that I’m not sure. I think there needs to be more in the core than CDI, Servlets, and Interceptors but I’m not sure what that would be. Servlets are, I agree, critical to the identity of Jakarta EE and can be the foundation, in addition to CDI, to many profiles. But things in the Core need not be leveraged by every profile. If MicroProfile makes more sense without Servlets, than so be it it. The purpose of the core is to provide a foundation that profiles can build on - not a foundation that every profile is required to use exhaustively.
On Thu, May 3, 2018 at 9:34 AM Reza Rahman <reza_rahman@xxxxxxxxx> wrote:
To be honest, I am totally supportive of CDI being a key Jakarta EE
technology and simultaneously totally opposed to CDI being part of the
core Jakarta EE profile. Whatever the technical merit, the reality is
that this will instantly juxtapose Jakarta EE as a platform with Spring
- which by far will be more popular than CDI in the foreseeable future.
While defining core as Servlet does not completely guarantee this, a
core based on Servlet is what will make Jakarta EE beyond question the
most pervasive and relevant Java server-side technology in the
foreseeable future and the most amenable to broad collaboration. There
is tremendous marketing value in that for Jakarta EE.
On 5/3/2018 10:03 AM, Adam Bien wrote:
>
>> On 3. May 2018, at 15:49, Richard Monson-Haefel <rmonson@xxxxxxxxxxxxx> wrote:
>>
>> I agree with Steve that Jakarta EE should centralize around CDI, but I think some technolgoies (e.g. JDBC and JMS) can have Java SE implementations. That should be up to each working group for each technology. That said, when doing Jakarta EE the Core of the platform should require use of CDI when components for application logic are needed.
> +1 CDI should be the core.
>
> We should also transfer the EJB "added value" (discussed several times) to CDI, then we could deprecate EJB and make the core or main profile leaner.
>
>
>> On Wed, May 2, 2018 at 12:21 PM Steve Millidge (Payara) <steve.millidge@xxxxxxxxxxx> wrote:
>> I personally don’t think it’s possible for each specification to support bare metal Java SE or always ship standalone. What this will lead to is a further proliferation of security models, bean models etc. as each specification reinvents the wheel independently of others. There is already not enough consistency across specifications. Spring provides a level of consistency as everything is built on a centralised DI framework and in general individual Spring projects don’t attempt to be usable outside of the Spring framework. We need to bring this consistency of approach across Jakarta EE and this will require dependencies between specifications and perhaps a centralisation around CDI as the baseline specification.
>>
>>
>>
>> I don’t think we should strive for JPA to be standalone and independent of say CDI and JTA. Also I don’t think JAX-RS should reinvent a bean model when it could be based on CDI. It is currently crazy that JAX-RS annotations are not bean defining for example. It is these inconsistencies that make Jakarta EE harder to learn and develop against over other frameworks.
>>
>>
>>
>> On the point of not developing for a server, where is the thread handling, transaction handling, http handling, socket handling etc? SpringBoot just packages a server up inside the application when creating an uber jar . This is semantically no different to deploying an application on a Jakarta EE server or using a technology like Payara Micro to build an uber jar. Server runtimes are always there even when they are denied via marketing. Jakarta EE is different to Spring in that it will have multiple competing implementations of the specifications and the implementations will likely manifest themselves as “servers” that is what makes it unique.
>>
>>
>>
>> Steve
>>
>>
>>
>>
>>
>> From: jakarta.ee-community-bounces@eclipse.org <jakarta.ee-community-bounces@eclipse.org > On Behalf Of reza_rahman
>> Sent: 02 May 2018 13:14
>> To: Michael Remijan <mjremijan@xxxxxxxxx>; Jakarta EE community discussions <jakarta.ee-community@eclipse.org >
>>
>>
>> Subject: Re: [jakarta.ee-community] A Composable Platform Over Profiles
>>
>>
>>
>> I think you are basically saying all Jakarta EE specifications should support bare metal Java SE (or make minimal assumptions about a profile), ship standalone and have a standalone TCK.
>>
>>
>>
>> I do think this is essential going forward.
>>
>>
>>
>> Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone
>>
>>
>>
>> -------- Original message --------
>>
>> From: Michael Remijan <mjremijan@xxxxxxxxx>
>>
>> Date: 5/1/18 3:02 PM (GMT-05:00)
>>
>> To: Jakarta EE community discussions <jakarta.ee-community@eclipse.org >
>>
>> Subject: Re: [jakarta.ee-community] A Composable Platform Over Profiles
>>
>>
>>
>>> I argue that a better approach would be to define the platform as a palette of composable standards[1]
>>
>>
>>
>> I completely support this but I don't think it takes it far enough. For an "enterprise" standard to survive in the coming years, I think it must become more "Spring like" meaning the standard must become a framework of libraries which development teams can import into their application in any combination they see fit. I truly believe if JakartaEE continues to develop specifications for a *server*, then it won't survive the coming years. Organizations just don't move their servers fast enough. They are slow to upgrade existing servers and forget about moving to a different EE server. Organizations typically are OK with updating libraries and frameworks - they don't care what's running inside the server - just as long as they don't need to update the server itself.
>>
>> It's not uncommon for me to see the latest and greatest frameworks and libraries shoehorned into 10+ year old EE servers because organizations can't move on their server technology. Granted, this is not all organizations. But, it is a huge appeal of Spring being able to bring in new features without server updates.
>>
>>
>>
>>
>>
>>
>>
>> On Tuesday, May 1, 2018 01:11:23 PM CDT, Jason Greene <jason.greene@xxxxxxxxxx> wrote:
>>
>>
>>
>>
>>
>> Over the years there has been vigorous debate about what makes the perfect profile. “Should spec X be included or not?” “Should we create a “plus” variant of the web profile?" “How many profiles is too many?" “How many is too few?" Recent threads you can see the topic rising again with Stable and Legacy profile proposals, and debate about whether or not JAX-WS should be part of the platform.
>>
>>
>>
>> A related issue is that EE compliance is overly strict. An implementor must ship exactly what a profile defines, with limited exceptions on variation. As an example, a certified web or full implementation can’t ship a newer version of the Servlet API, even though it’s fully backwards compatible. The default run mode / config of the implementation is also not allowed to enable a subset of the profile, even though the implementor’s primary audience may not need all of the specified technologies.
>>
>>
>>
>> The idea behind a rigid platform certainly had merit, and it arguably led to the very strong level of portability across containers we enjoy today. However, this one-size-fits-all approach just no longer fits the current state of software, with developers expecting a high degree of application specific tailoring.
>>
>>
>>
>> I argue that a better approach would be to define the platform as a palette of composable standards[1], where profiles define only what must be available for a developer to choose from, and only limit the version of a given standard to the minimum that must be provided[2]. Under this model there is less of a need to define a perfect profile, since it can be freely adjusted by the developer to fit his or her needs. Instead, all that matters is that we have a sensible array of choice.
>>
>>
>>
>> [1] It’s worth noting that this would require the TCK to be split up, as discussed previously, to facilitate the flexibility required in testing a near arbitrary combination of standards.
>>
>>
>>
>> [2] For clarity, the full and web profiles would still be versioned (8.0 etc) as today, this is just a rule softening to support variation.
>>
>>
>>
>> --
>>
>> Jason T. Greene
>>
>> Chief Architect, JBoss EAP
>>
>> Red Hat
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>>
>> 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-communit y
>>
>> _______________________________________________
>> 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-communit y
>> --
>> Richard Monson-Haefel
>> http://twitter.com/rmonson
>> http://www.tomitribe.com
>> http://www.tomitribe.io
>>
>> _______________________________________________
>> 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-communit y
> _______________________________________________
> 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-communit y
_______________________________________________
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-communit y
_______________________________________________ jakarta.ee-community mailing list jakarta.ee-community@eclipse.o rg To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/jakarta.ee-communit y
_______________________________________________
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-communit y
_______________________________________________ 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