|
|
|
|
|
by threeseed
4065 days ago
|
|
There is no doubt this combination would be extremely high performant e.g. Wildfly was always in the top handful on Techempower benchmarks. But using JSF and EJB is a pretty extraordinary combination to be using these days. You would honestly be laughed out of every Java development team for even considering it. Would definitely like to see why something like Dropwizard, Vert.x or even Play 1 wasn't considered. |
|
The fact is that both invoke memories of old times where they were very heavyweight and problematic technologies.
EJB was a total disaster, where you needed to implement 3 interfaces and inherit from a framework provided base class, compile your code with a special "enhancing" tool and run yet another tool to generate something called stubs and skeletons, just to do hello world.
Modern EJB on the other hand is a POJO with a single annotation:
That's all. There are no required framework or business interfaces, no obligation to put ejb beans in a separate EJB module and there are no specific compiler tools needed. It's a total day and night difference.In modern Java EE there's no reason whatsoever to avoid EJB.
There's a similar story with JSF. The first versions (1.x) were mostly POST focused, had heavy session space requirements, and components were hard to create.
In modern JSF 2.x, there's first class support for using GET, and the PRG pattern is at the heart of interactions that are logically POST. Session requiremebts are largely minimized by use of a partial state saving (only changes to state are saved) and a stateless mode (nothing is saved). You can use plain html to author pages with a single extra namespaced attribute to mark it as a component to JSF.
Again a night and day difference and no need to avoid it anymore.
Then JSF has a number of very cool extensions available such as PrimeFaces (beautiful visual components) and OmniFaces (Swiss army knife like Guave is for plain Java)