Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakarta.ee-community] A Composable Platform Over Profiles
As you probably know, that's basically what the Glassfish update manager does/did. The specification definitely needs to have enough details to enable addition and subtraction of modules/technologies from a given profile. I had always hoped that's a GlassFish feature other vendors would adopt too - especially in terms of CLI and admin console functionality in addition to descriptors/build-time facilities.

That's the kind of polished standout feature in the specification/product that convinces skeptics that Java EE is something they should take seriously as opposed to a legacy technology forever trying to catch up. I remember client reactions back in the day in the Java EE 6 era that GlassFish could do those things. I think that kind of thing looks even more impressive on the cloud and with Docker.

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

-------- Original message --------
From: arjan tijms <arjan.tijms@xxxxxxxxx>
Date: 5/5/18 9:02 AM (GMT-05:00)
To: Jakarta EE community discussions <jakarta.ee-community@xxxxxxxxxxx>
Subject: Re: [jakarta.ee-community] A Composable Platform Over Profiles

Hi,

Since everyone wants a different profile, why not just have the full profile and at most a legacy free profile, and then require a “prune” tool, so that people can prune the AS to only contain what their application actually uses.

E.g. if a have a JSF + JPA web app, the tool finds out all transitive dependencies and the produces a new server instance that only contains these components (eg JSF, Servlet, _expression_ Language, CDI, JPA, JTA, ...), but eg EJB, JMS and JBatch would physically not be there.

Kind regards,
Arjan

On Friday, May 4, 2018, Josh Juneau <juneau001@xxxxxxxxx> wrote:
I've now had an opportunity to read through all of the messages in this thread, and I wanted to send a follow-up to my original response.  I apologize for the follow-up...

 There is some really great discussion in this thread, and it is difficult to predict exactly what everyone wants or needs, with respect to the different APIs.  I stick to my original +1 on having a small set of profiles to choose from, but providing the ability for one to create their own profile or choose APIs to use in an ad-hoc manner.  I'm not sure if this is all technically possible to do, but if it is, then I think it would make Jakarta EE a very flexible platform, providing freedom of choice if one wishes to use it.

Ease of use (e.g. very few profiles from which to choose) is nice to have.  Making Servlet API a base for all profiles (even ad-hoc) may make sense...However, flexibility is also an important key in building a platform that will work for everyone, in my opinion.


On May 4, 2018, at 8:12 AM, Josh Juneau <juneau001@xxxxxxxxx> wrote:

I am glad that this topic is being discussed early-on.  I apologize if I am simply re-iterating what someone else already mentioned earlier in this thread, as I simply did not have time to read through all of the messages.  

I vote +1 for having a small set of profiles from which to choose, if one wishes to use a profile.  One of them (the full profile) should be the default.  We also need to ensure that Jakarta EE is modular (as discussed in the early messages in this thread), such that it is easy for one to pull in other APIs, if needed.  If one wishes to create a completely new profile for their organization, then they should be able to do it...simply including only the profiles that they wish to include.  In my opinion, being "Jakarta EE Compliant" would mean that the server has the capabilities to deploy applications according to the full profile...including all APIs.  However, the server should also have the capability to deploy applications that include a subset of the modular APIs, allowing organizations flexibility.


On May 4, 2018, at 1:03 AM, Guillermo González de Agüero <z06.guillermo@xxxxxxxxx> wrote:

Hi,

I see the value on your proposition, but if I were using Spring, which has it own REST component why would I look at JAX-RS? Nowhere in the Spring documentation it will be mentioned that the integration is possible as they would only promote their particular solution. On the other hand, if I'm not using Spring and I'd like to use JAX-RS, what stops me from using CDI?

You are right we must accept the reality. One reality is that Spring is the clear king at the moment. But there's another reaility, that Java EE most specs are inconsistent in that they redefine the same things on their own again and again. And that hurts us, the real Java EE users.

In my opinion our efforts should be focused on better integrating our specs so that our own users enjoy a solid and pleasant development experience. CDI is own tool for doing that right now. If a particular spec find at some point of time that a non-CDI version would be useful, it can be developed as needed.


Regards,

Guillermo González de Agüero

El jue., 3 may. 2018 a las 22:30, Reza Rahman (<reza_rahman@xxxxxxxxx>) escribió:
I 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-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
>> --
>> 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-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,

Guillermo González de Agüero
_______________________________________________
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

Back to the top