Posts

Showing posts from May 4, 2016

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's mysterious message policy

Users of Java EE authentication (JASPIC) may have noticed that the initialize method of a SAM takes two parameters of type MessagePolicy . But what are these parameters used for? In this article we'll take a somewhat deeper look. In practice, the overwhelming majority of SAMs only seem to use this MessagePolicy in one way; completely ignore it. As such, there aren't many if any examples available that demonstrate how these passed in policies should actually be enforced. The JASPIC spec isn't quite clear about this either. It does seem to say in a somewhat cryptic way that the isMandatory method is an alias for the "javax.security.auth.message.MessagePolicy.isMandatory" entry in the MessageInfo map, and that the ProtectionPolicy of the TargetPolicy of the MessagePolicy must be ProtectionPolicy.AUTHENTICATE_SENDER and/or ProtectionPolicy.AUTHENTICATE_CONTENT . Pretty much the only example we have in code that at least references the MessagePolicy ty