| Re: [jakarta.ee-community] A Composable Platform Over Profiles |
Steve,The reason why JAX-RS has its own DI mechanism (I’m assuming that’s what you mean by bean model) is because it pre-dates CDI by a number of years. Had CDI been around at the time JAX-RS started, it would have been a different story.When CDI arrived, JAX-RS was extended to support it (without depending on it) but clearly having multiple DI systems leads to lots of ugly edge cases. Dropping its existing DI system in favor of CDI would have meant breaking backward compatibility, which was a non-starter. Consistency and backward compatibility often don’t play along.There have been some discussions in the JAX-RS dev alias about a future (3.0?) version of JAX-RS which would embrace CDI (as a dependency), dropping its own mechanism as well as backward compatibility. I think this is worth discussing, especially in a platform that places CDI at its core.— Santiago_______________________________________________On May 2, 2018, at 1: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.SteveFrom: jakarta.ee-community-bounces@xxxxxxxxxxx <jakarta.ee-community-bounces@xxxxxxxxxxx> On Behalf Of reza_rahman
Sent: 02 May 2018 13:14
To: Michael Remijan <mjremijan@xxxxxxxxx>; Jakarta EE community discussions <jakarta.ee-community@xxxxxxxxxxx>
Subject: Re: [jakarta.ee-community] A Composable Platform Over ProfilesI 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 --------Date: 5/1/18 3:02 PM (GMT-05:00)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. GreeneChief Architect, JBoss EAPRed Hat_______________________________________________jakarta.ee-community mailing listTo 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
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