Posts

Testing JASPIC implementations using Arquillian and full wars

Image
In a previous article about JASPIC we saw that not all servers behaved the same. In fact there were rather large differences between implementations with respect to JASPIC. From time to time new servers come out, e.g. since the last article JBoss has released JBoss EAP 6.1, Oracle has released GlassFish 4 and WebLogic 12.1.2 and even Geronimo has released a new version of its server; Geronimo 3.0.1. I previously tested via a series of handcrafted web applications that I would deploy manually, do some tests with it and then observe its behavior. This initially worked fine, but it's a bit laborious and perhaps even brittle to retest again some time later. It also makes it harder for others to verify the tests. So automation was the key, but how to automatically deploy several wars to a variety of application servers? There are a couple of options for starting & stopping a Java EE application server, plus deploying and undeploying an archive (web, ear, ...) to it: JSR-88 ...

Java EE 8 wish list

Java EE 7 has been recently released and is a truly great release. While for most vendors the job to implement Java EE 7 has just started or may even still has to start ideas for the next version, Java EE 8, may already be shaping. If history is anything to go by; last time Java EE 6 was released Dec 10, 2009 and we saw the first real Java EE 7 events about a year later , so we may have some time till Java EE 8 is really kicking off. Around the Java EE 7 kickoff time, Antonio Goncalves, presented a very interesting wish list of things that should be in Java EE 7. Interestingly 2 of his 4 items (flows and batch) indeed made it in Java EE 7, while a 3rd item (caching) would have been included but was dropped at the very last moment. It's a bit early days, but in this article I'd like to present my wish list for Java EE 8: CDI everywhere More thorough Pruning & Deprecating A standardized caching API In-app alternatives for all "administrative objects...

Trying Liberty 8.5.5

Historically Java EE servers were known for being monolithic and heavyweight. Over the years this has improved tremendously with many free, open source and lightweight solutions available, such as GlassFish, TomEE, Resin and JBoss. Even the grandfather of the modern Application Server, Bea's WebLogic (now Oracle's) has severely slimmed down . One "heavyweight beast" remained though; IBM's WebSphere. It's perhaps an understatement to say WebSphere is not universally liked by developers . A 2GB download size that happens via a proprietary installer (which is 100MB), which doesn't cleanly work on all possible Linux flavors and doesn't work at all on OS X, which needs another 200MB orso just to create a "profile" after the 2GB download which came after the 100MB installer, takes ages to start and can't be started in any of the popular IDEs (like Eclipse, NetBeans or IntelliJ) are all things that don't really fly with the average dev...

OmniFaces 1.5 Release Candidate now available for testing

We're pleased to announce that the release candidate of OmniFaces 1.5 is now available for testing. The following items are new for this release: Decode UIComponent children in <o:param> when no value attribute is specified (so that you can specify JSF/HTML code as outputFormat parameter) Allow endusers to specify custom passthrough attributes for Html5RenderKit Added new includeRequestParams attribute to <o:form> <o:messages> which extends <h:messages> with support for multiple client IDs in for attribute, ability to disable HTML escaping and ability to perform markupless rendering like <ui:repeat> Faces#includeCompositeComponent() to programmatically include a composite component in given parent component Add list based alternatives for the converters that automatically convert based on select items Message interpolator for Bean Validation that allows a component's label to be inserted in the middle of ...

What's new in Java EE 7's authentication support?

Java EE 7 comes with a lot of improvements in many areas. Things like JSF 2.2 , CDI 1.1, JMS 2.0 and JAX-RS 2.0 have all been massively improved. However, not all specs have seen a significant revision. A number of them like JSP 2.1 and EJB 3.1 only had a minor revision, called a maintenance release. In this post we'll take a look at the changes that were done for the standardized authentication support in Java EE: JASPIC 1.1 (JSR 196). The second maintenance release of JASPIC, called Maintenance Release B officially has seen its version bumped from 1.0 to 1.1. It's sometimes confusing, but a small maintenance release can have the same version increment as a significant revision. E.g. JSF 2.1 was a small maintenance release of its prior version 2.0, but EJB 3.1 was a significant revision of its prior version 3.0. On to the changes in JASPIC 1.1: Standardized application context identifier (AppContextID) for Servlet Profile One of the big hurdles when trying to ...

Easy extensionless URLs in JSF with OmniFaces 1.4

Image
For some time now there's a trend going on to simplify URLs used on the web. Increasingly the trend is to remove technical clutter from URLs and make them cleaner and friendlier for humans to remember. E.g. from something like http://www4.campaign.myorgananization.com/dlt/cmp/~foobar/camp-2013/E3483A78H.jspx we went to: myorgananization.com/sale2013 The protocol, "http://", is mostly skipped when printing URLs for humans to type over nowadays since browsers simply default to it. The elaborate subdomains, specifically the "www1", "www2", "wwwN" nonsense, is mostly handled internally by load balancers these days, etc. E.g. I photographed the following from an ad that was displayed on Rembrandtplein, Amsterdam: The extension One specific technical part of the URL that can also be shaved off is the extension (".jspx" in the example above), and this will be the topic of this article. Technically, an extension can have ...

A basic implementation of basic access authentication using JASPIC

Basic access authentication is a crude mechanism to authenticate that's part of the HTTP standard. It allows both an agent to send username/password credentials and a server to request the agent to authenticate itself. This happens in a simple but standardized way. The mechanism can be easily implemented using Java EE's JASPIC and a sprinkle of utility code from the experimental OmniSecurity project (which is currently being discussed as one of the possible options to simplify security in Java EE 8). A basic implementation looks as follows: public class BasicAuthModule extends HttpServerAuthModule { @Override public AuthStatus validateHttpRequest(HttpServletRequest request, HttpServletResponse response, HttpMsgContext httpMsgContext) throws AuthException { String[] credentials = getCredentials(request); if (!isEmpty(credentials)) { UsernamePasswordIdentityStore identityStore = getReferenceOrNull(UsernamePa...