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