An extensionless URL is a URL without a final suffix like .xhtml , .html , .jsp , etc. Such a suffix is seen as technical "clutter" that's hard to remember for humans. Servers often need it though to route a request to the right controller. JSF, a Java EE MVC framework, has supported extensionless URLs for some time via PrettyFaces (now merged to the general Rewrite framework) and OmniFaces . Both of these solutions used various workarounds to trick JSF into working with extensionless URLs. Though JSF 2.3 does, unfortunately, still not support extensionless URLs fully out of the box via e.g. a single parameter, it can provide support for it by basically combining the new support for exact mapping and the API for obtaining a list of all view resources . Additionally combining this with the Servlet 3.1 feature for dynamically adding Servlet mappings and some JDK8 streaming and lambdas, makes it possible to enable extensionless support with just 2 statements (albeit so
In Java EE's CDI, beans can be augmented via 2 artefacts; Decorators and Interceptors . Decorators are typically owned by the application code and can decorate a bean that's shipped by the container ( build-in beans ) or a library. Interceptors are typically shipped by a library and can be applied (bound) to a bean that's owned by the application. So how do you bind a library shipped interceptor to a library shipped/build-in bean? In CDI 1.2 and before this wasn't really possible, but in CDI 2.0 we can take advantage of the new InterceptionFactory to do just this. It's not entirely trivial yet, but it's doable. In this article we'll demonstrate how to apply the @RememberMe interceptor binding from the new Java EE 8 Security spec to a build-in bean of type HttpAuthenticationMechanism , which is from the Security spec as well. First we configure our authentication mechanism by means of the following annotation: @BasicAuthenticationMechanismDefin
At OmniFaces we poll the community from time to time about Java EE and related technologies. With all the changes that are about to happen with the move of Java EE to Eclipse and the subsequent renaming to Jakarta EE , we expanded the survey a little for this year. In the 2018 edition, there are 4 categories of questions: Current usage of Java EE Servlet containers APIs related to Java EE The future of Java EE / Jakarta EE Jakarta EE provides the opportunity to revitalise and modernise Java EE, but in order to do that it's more important than ever that we know what matters to all of its users out there. So therefor we'd like to invite all Java EE users to participate in The Java EE Survey 2018 Update: Survey now closed
Comments
Post a Comment