Re: [jakarta.ee-community] A Composable Platform Over Profiles

[arjan tijms <arjan.tijms@xxxxxxxxx>]

Hi,

On Thu, May 3, 2018 at 8:34 PM, Jason Greene <jason.greene@xxxxxxxxxx> wrote:

I think it would be a mistake to hobble the platform, and leave out fundamental elements of the EE programming model, which is what would happen if you built everything on JSR-330, since it is intentionally a partial standard. Even if we wanted to, the other specs would ultimately end up reimplementing their own DI to fill that gap (as we saw in the past), which would hurt the overall consistency of the platform. Thats not to say that the specs can’t be improved and/or better facilitate proprietary extension.  I’m all for increasing the adoption of the standard, but it shouldn’t give up being an actual standard to do so. 

I agree, I think the biggest mistake of Java EE has been to always put itself on the second or even third place and enabling "other uses" before everything else. That seems noble, but it means Java EE didn't became the strong framework it could have become. Instead it became at some places too complex and too much of a hotchpotch of different technologies.

JAX-RS is not based on Servlets, since perhaps someone out there wants to use it with a Python based HTTP engine?

JAX-RS again wasn't CDI based since someone out there might want to run JAX-RS standalone and doesn't want to add a CDI jar? (I know the development of JAX-RS and CDI were done largely in parallel, so one couldn't take advantage of the other initially, but that could have been corrected soon after)

And Servlets don't even provide build-in beans for usage with CDI because GW thinks he has to implement CDI fully then, and has to integrate with all other CDI implementations separately? (see https://issues.jboss.org/browse/CDI-492) Let alone Servlets being CDI beans.

So now we have interceptors, but they don't work on Servlets. We have @RolesAllowed but it doesn't work on CDI beans. We have JAX-RS resources, but they can't be injected via @Inject by default. We had two RequestScopes, of which only one worked on CDI beans, etc etc.

The idea that Java EE users have to be given the choice to choose "their own DI" kinda weakens the platform from within. I'd much rather see a Java EE (Jakarta EE) first approach, meaning CDI, _expression_ Language, Bean Validation, etc are all first class citizens with no shame to use them. If someone wants to use another technology, the existing extension points of CDI can be used (CDI is quite flexible there), and/or a CDI bridge can be used. All other specs (JSF, Servlet, Batch, JAX-RS, EE Security, ...) should be free to take full advantage of CDI and other specs directly.

Kind regards,

Arjan

 

-Jason

_______________________________________________
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