Showing posts from March 19, 2015

Jakarta EE Survey 2020

At OmniFaces we poll the community from time to time about Java EE (now Jakarta EE) and related technologies. With the transfer of Java EE to Jakarta EE now almost completed, people are now starting to think about Jakarta EE 10 , the first Jakarta EE release after Java EE 8 having new featues. As such it's a good time to poll the community again. In the 2020 edition, there are 4 categories of questions again: Current usage of Java EE / Jakarta EE Servlet containers APIs related to Java EE / Jakarta EE The future of Jakarta EE Compared to 2018, we simplified some of the questions somewhat, omitting some of the less popular options to make it more manageable. We added questions about the future of Jakarta EE and MP together, the preferred Jakarta EE cadence, and generally updated the choices (such as adding Quarkus , which wasn't quite on the radar in 2018 and our own Piranha Cloud ). Jakarta EE provides the opportunity to revitalise and modernise Java EE, but i

Java EE authorization - JACC revisited part III

This is the third and final part of a series where we revisit JACC after taking an initial look at it last year. In the first part we mainly looked at various role mapping strategies, while the main topic of the second part was obtaining the container specific role mapper and the container specific way of how a JACC provider is deployed. In this third and final part we'll be bringing it all together and present a fully working JACC provider for a single application module (e.g. a single war). Architecture As explained before , implementing a JACC provider requires implementing three classes: PolicyConfigurationFactory PolicyConfiguration Policy Zooming into these, the following is what is more accurately required to be implemented: A factory that provides an object that collects permissions A state machine that controls the life-cyle of this permission collector Linking permissions of multiple modules and utilities Collecting and managing permissio