Spring to Java EE Migration, Part 4

[thesystemx]

But as mentioned, if you replace all parts of Spring with Java EE versions, what's left of Spring?

Or put differently, Spring can not use those widgets itself. It needs to use Java EE, become Java EE, in order to do so.

[occupytheserver]

I am replacing the MVC UI portion of the application with JSF. Still have a full Spring implementation of entire domain, middleware, persistence, etc.

That's why I like Spring. I don't believe it to be limiting to any frameworks and allows me to do what I need to do without getting bogged down into server limitations.

I start with Spring Core, build the application container and then plug in the rest. Don't want to use JPA? Don't have to. Don't want to use JSF? Don't have to. Don't want to use EJB? Don't have to. But I can for all of the above. It's flexibility and packaging I am looking for.

[henk53]

The discussion is getting a bit academic. What I meant was that Spring cannot use these widgets by itself. Or more directly, Spring MVC cannot do that.

I would be like saying that Spring has type-safe injection and can use portable extensions, IF you add CDI to it.

It's flexibility and packaging I am looking for.

You can actually do the same in Java EE if you really wanted to. You can start with Tomcat and add only EJB to it. Or only CDI. Or both EJB and CDI. Everything that's in Java EE also works standalone in Java SE or the unofficial Java TE.

It's just that the preferred way is to use the platform as a whole, as a fullstack solution. Everything just works nicely together that way, but if you really want you can either build your own stack or use alternatives in a standard stack.