Featured FREE Whitepapers

What's New Here?


Devoxx 2012: Java 8 Lambda and Parallelism, Part 1

Overview Devoxx, the biggest vendor-independent Java conference in the world, took place in Atwerp, Belgium on 12 – 16 November. This year it was bigger yet, reaching 3400 attendees from 40 different countries. As last year, I and a small group of colleagues from SAP were there and enjoyed it a lot. After the impressive dance of Nao robots and the opening keynotes, more than 200 conference sessions explored a variety of different technology areas, ranging from Java SE to methodology and robotics. One of the most interesting topics for me was the evolution of the Java language and platform in JDK 8.   My interest was driven partly by the fact that I was already starting work on Wordcounter, and finishing work on another concurrent Java library named Evictor, about which I will be blogging in a future post.In this blog series, I would like to share somewhat more detailed summaries of the sessions on this topic which I attended. These three sessions all took place in the same day, in the same room, one after the other, and together provided three different perspectives on lambdas, parallel collections, and parallelism in general in Java 8.On the road to JDK 8: Lambda, parallel libraries, and more by Joe Darcy Closures and Collections – the World After Eight by Maurice Naftalin Fork / Join, lambda & parallel() : parallel computing made (too ?) easy by Jose PaumardIn this post, I will cover the first session, with the other two coming soon. On the road to JDK 8: Lambda, parallel libraries, and more In the first session, Joe Darcy, a lead engineer of several projects at Oracle, introduced the key changes to the language coming in JDK 8, such as lambda expressions and default methods, summarized the implementation approach, and examined the parallel libraries and their new programming model. The slides from this session are available here. Evolving the Java platform Joe started by talking a bit about the context and concerns related to evolving the language. The general evolution policy for OpenJDK is:Don’t break binary compatibility Avoid introducing source incompatibilities. Manage behavioral compatibility changesThe above list also extends to the language evolution. These rules mean that old classfiles will be always recognized, the cases when currently legal code stops compiling are limited, and changes in the generated code that introduce behavioral changes are also avoided. The goals of this policy are to keep existing binaries linking and running, and to keep existing sources compiling. This has also influenced the sets of features chosen to be implemented in the language itself, as well as how they were implemented. Such concerns were also in effect when adding closures to Java. Interfaces, for example, are a double-edged sword. With the language features that we have today, they cannot evolve compatibly over time. However, in reality APIs age, as people’s expectations how to use them evolve. Adding closures to the language results in a really different programming model, which implies it would be really helpful if interfaces could be evolved compatibly. This resulted in a change affecting both the language and the VM, known as default methods. Project Lambda Project Lambda introduces a coordinated language, library, and VM change. In the language, there are lambda expressions and default methods. In the libraries, there are bulk operations on collections and additional support for parallelism. In the VM, besides the default methods, there are also enhancements to the invokedynamic functionality. This is the biggest change to the language ever done, bigger than other significant changes such as generics. What is a lambda expression? A lambda expression is an anonymous method having an argument list, a return type, and a body, and able to refer to values from the enclosing scope: (Object o) -> o.toString() (Person p) -> p.getName().equals(name) Besides lambda expressions, there is also the method reference syntax: Object::toString() The main benefit of lambdas is that it allows the programmer to treat code as data, store it in variables and pass it to methods. Some history When Java was first introduced in 1995 not many languages had closures, but they are present in pretty much every major language today, even C++. For Java, it has been a long and winding road to get support for closures, until Project Lambda finally started in Dec 2009. The current status is that JSR 335 is in early draft review, there are binary builds available, and it’s expected to become very soon part of the mainline JDK 8 builds. Internal and external iteration There are two ways to do iteration – internal and external. In external iteration you bring the data to the code, whereas in internal iteration you bring the code to the data. External iteration is what we have today, for example: for (Shape s : shapes) { if (s.getColor() == RED) s.setColor(BLUE); }There are several limitations with this approach. One of them is that the above loop is inherently sequential, even though there is no fundamental reason it couldn’t be executed by multiple threads. Re-written to use internal iteration with lambda, the above code would be: shapes.forEach(s -> { if (s.getColor() == RED) s.setColor(BLUE); }) This is not just a syntactic change, since now the library is in control of how the iteration happens. Written in this way, the code expresses much more what and less how, the how being left to the library. The library authors are free to use parallelism, out-of-order execution, laziness, and all kinds of other techniques. This allows the library to abstract over behavior, which is a fundamentally more powerful way of doing things. Functional Interfaces Project Lambda avoided adding new types, instead reusing existing coding practices. Java programmers are familiar with and have long used interfaces with one method, such as Runnable, Comparator, or ActionListener. Such interfaces are now called functional interfaces. There will be also new functional interfaces, such as Predicate and Block. A lambda expression evaluates to an instance of a functional interface, for example: PredicateisEmpty = s -> s.isEmpty(); Predicate isEmpty = String::isEmpty; Runnable r = () -> { System.out.println(“Boo!”) };So existing libraries are forward-compatible with lambdas, which results in an “automatic upgrade”, maintaining the significant investment in those libraries. Default Methods The above example used a new method on Collection, forEach. However, adding a method to an existing interface is a no-go in Java, as it would result in a runtime exception when a client calls the new method on an old class in which it is not implemented. A default method is an interface method that has an implementation, which is woven-in by the VM at link time. In a sense, this is multiple inheritance, but there’s no reason to panic, since this is multiple inheritance of behavior, not state. The syntax looks like this: interface Collection<T> { ... default void forEach(Block<T> action) { for (T t : this) action.apply(t); } }There are certain inheritance rules to resolve conflicts between multiple supertypes:Rule 1 – prefer superclass methods to interface methods (“Class wins”) Rule 2 – prefer more specific interfaces to less (“Subtype wins”) Rule 3 – otherwise, act as if the method is abstract. In the case of conflicting defaults, the concrete class must provide an implementation.In summary, conflicts are resolved by looking for a unique, most specific default-providing interface. With these rules, “diamonds” are not a problem. In the worst case, when there isn’t a unique most specific implementation of the method, the subclass must provide one, or there will be a compiler error. If this implementation needs to call to one of the inherited implementations, the new syntax for this is A.super.m(). The primary goal of default methods is API evolution, but they are useful as an inheritance mechanism on their own as well. One other way to benefit from them is optional methods. For example, most implementations of Iterator don’t provide a useful remove(), so it can be declared “optional” as follows: interface Iterator<T> { ... default void remove() { throw new UnsupportedOperationException(); } }Bulk operations on collections Bulk operations on collections also enable a map / reduce style of programming. For example, the above code could be further decomposed by getting a stream from the shapes collection, filtering the red elements, and then iterating only over the filtered elements: shapes.stream().filter(s -> s.getColor() == RED).forEach(s -> { s.setColor(BLUE); }); The above code corresponds even more closely to the problem statement of what you actually want to get done. There also other useful bulk operations such as map, into, or sum. The main advantages of this programming model are:More composability Clarity – each stage does one thing The library can use parallelism, out-of-order, laziness for performance, etc.The stream is the basic new abstraction being added to the platform. It encapsulates laziness as a better alternative to “lazy” collections such as LazyList. It is a facility that allows getting a sequence of elements out of it, its source being a collection, array, or a function. The basic programming model with streams is that of a pipeline, such as collection-filter-map-sum or array-map-sorted-forEach. Since streams are lazy, they only compute as elements are needed, which pays off big in cases like filter-map-findFirst. Another advantage of streams is that they allow to take advantage of fork/join parallelism, by having libraries use fork/join behind the scenes to ease programming and avoid boilerplate. Implementation technique In the last part of his talk, Joe described the advantages and disadvantages of the possible implementation techniques for lambda expressions. Different options such as inner classes and method handles were considered, but not accepted due to their shortcomings. The best solution would involve adding a level of indirection, by letting the compiler emit a declarative recipe, rather than imperative code, for creating a lambda, and then letting the runtime execute that recipe however it deems fit (and make sure it’s fast). This sounded like a job for invokedynamic, a new invocation mode introduced with Java SE 7 for an entirely different reason – support for dynamic languages on the JVM. It turned out this feature is not just for dynamic languages any more, as it provides a suitable implementation mechanism for lambdas, and is also much better in terms of performance. Conclusion Project Lambda is a large, coordinated update across the Java language and platform. It enables much more powerful programming model for collections and takes advantage of new features in the VM. You can evaluate these new features by downloading the JDK8 build with lambda support. IDE support is also already available in NetBeans builds with Lambda support and IntelliJ IDEA 12 EAP builds with Lambda support. I already made my own experiences with lambdas in Java in Wordcounter. As I already wrote, I am convinced that this style of programming will quickly become pervasive in Java, so if you don’t yet have experience with it, I do encourage you to try it out.   Reference: Devoxx 2012: Java 8 Lambda and Parallelism, Part 1 from our JCG partner Stoyan Rachev at the Stoyan Rachev’s Blog blog. ...

Composing Java annotations

The allowed attribute types of a Java annotations are deliberately very restrictive, however some clean composite annotation types are possible with the allowed types.                     Consider a sample annotation from the tutorial site: package annotation; @interface ClassPreamble { String author(); String[] reviewers(); } Here the author and reviewers are of String and array types which is in keeping with the allowed types of annotation attributes. The following is a comprehensive list of allowed types(as of Java 7):String Class any parameterized invocation of Class an enum type an annotation type, do note that cycles are not allowed, the annotated type cannot refer to itself an array type whose element type is one of the preceding types.Now, to make a richer ClassPreable consider two more annotation types defined this way: package annotation;public @interface Author { String first() default ''; String last() default ''; }package annotation;public @interface Reviewer { String first() default ''; String last() default ''; } With these, the ClassPreamble can be composed from the richer Author and Reviewer annotation types, this way: package annotation; @interface ClassPreamble { Author author(); Reviewer[] reviewers(); } Now an annotation applied on a class looks like this: package annotation;@ClassPreamble(author = @Author(first = 'John', last = 'Doe') , reviewers = {@Reviewer(first = 'first1', last = 'last1'), @Reviewer(last = 'last2') } ) public class MyClass { .... } This is a contrived example just to demonstrate composition of annotations, however this approach is used extensively for real world annotations, for eg, to define a many to many relationship between two JPA entities: @ManyToMany @JoinTable(name='Employee_Project', joinColumns=@JoinColumn(name='Employee_ID'), inverseJoinColumns=@JoinColumn(name='Project_ID')) private Collection<Project> projects;   Reference: Composing Java annotations from our JCG partner Biju Kunjummen at the all and sundry blog. ...

Death by Redirect

It is said that the greatest harm can come from the best intentions. We recently had a case where, because of the best intentions, two @#@&*@!!^@ parties killed our servers with a single request, causing a deadlock involving all of our Tomcat instances, including all HTTP threads. Naturally, not a pleasant situation to find yourself in.   Some explanation about our setup is necessary here. We have a number of Tomcat instances that serve HTML pages for our website, located behind a stateless Load Balancer. The time then came when we added a second application, deployed on Jetty.     Since we needed the new app to be served as part of the same website (e.g. http://www.wix.com/jetty-app), we proxied the second (Jetty) application from Tomcat (Don’t dig into why we proxied Jetty from Tomcat, we thought at the time we had good reasons for it).So in fact we had the following architecture:At the Tomcat end, we were using the Apache HttpClient library to connect to the Jetty application. HttpClient by default is configured to follow redirects. Best Intentions #1: Why should we require the developer to think about redirects? Let’s handle them automatically for her… At the Jetty end, we had a generic error handler that on an error, instead of showing an error page, redirected the user to the homepage of the app on Jetty. Best Intentions #2: Why show the user an error page? Let’s redirect him to our homepage… But what happens when the homepage of the Jetty application generates an error? Well, apparently it returns a redirect directive to itself! Now, if a browser would have gotten that redirect, it would have entered a redirect loop and break it after about 20 redirects. We would have seen 20 requests all resulting in a redirect, probably seen a traffic spike, but nothing else. However, because we had redirects turned on at the HttpClient library, what happened is the following:A Request arrives to our Tomcat server, which resolves it to be proxied to the Jetty application Tomcat Thread #1 proxies a request to Jetty Jetty has an exception and returns a redirect to http://www.wix.com/jetty -app Tomcat Thread #1 connects to the www.wix.com host, which goes via the load balancer and ends at another Tomcat thread – Tomcat Thread #2 Tomcat Thread #2 proxies a request to Jetty Jetty has an exception and returns a redirect to http://www.wix.com/jetty Tomcat Thread #1 connects to the www.wix.com host, which goes via the load balancer and ends at another Tomcat thread – Tomcat Thread #3 And so on, until all threads on all Tomcats are all stuck on the same one requestSo, what can we learn from this incident? We can learn that the defaults of Apache HttpClient are not necessarily the ones you’d expect. We can learn that if you issue a redirect, make sure you are not redirecting to yourself (like our Jetty application homepage). We can learn that the HTTP protocol, which is considered a commodity can be complicated at times and hard to tune, and that not every developer knows to perform an HTTP request. We can also learn that when you take on a 3rd party library, you should invest time in learning to use it, to understand the failure points and how to overcome them. However, there is a deeper message here. When we develop software, we trade development velocity and risk. The faster we want to develop software, the more we need to trust the individual developers. The more trust we give developers, the more risk we gain by developer black spots – things a developer fails to think about, e.g. handling redirect. As a software engineer, I am not sure there is a simple solution to this issue – I guess it is up to you.   Reference: Death by Redirect from our JCG partner Yoav Abrahami at the Wix IO blog. ...

Tomcat Clustering Series Part 4 : Session Replication using Backup Manager

Hi, this is my fourth part of the Tomcat Clustering Series. In this post we are going to discuss how to setup session replication using Backup Manager in tomcat clustering environment. Session replication makes High availability and full fail-over capability to our clustering environment.   [Check the video below for better understanding] This post is a continuation of my last post (Session replication using Delta Manager). In delta manager each tomcat instance needs to replicate the session information to all other tomcat instances. It takes more time and replication if our cluster size is increased, so, an alternative manager is there, the Backup Manager.   Backup Manager replicates the copy of session data to exactly one other tomcat instance in the cluster. This is the main difference between Delta and Backup managers. Here one tomcat instance maintains what is the primary copy of the session whereas another tomcat instance holds the replicated session data acting as the backup one. If any one of the tomcat instances fails the other one serves the session. That way fail over capability is achieved. The setup process of backup manager is same as Delta manager. Except we need to mention the Manager as BacupManager (org.apache.catalina.ha.session.DeltaManager) inside <Cluster> element. Suppose we have 3 tomcat instances like previous post, and i configured into backup manager. Now user try access the page. User request comes to load balancer, and load balancer redirect the request to suppose tomcat1. Now tomcat one create the session, now tomcat1 is responsible to replicate exactly one copy to any one of the tomcat. So tomcat1 picks any tomcat which is part of the cluster (multicast). Here tomcat1 picks tomcat3 as a backup. So tomcat3 hold the backup copy of the session. We are running the load balancer in sticky session mode so all further request from that particular user is redirect to tomcat1 only. All modification in tomcat1 is replicated to tomcat3. Now tomcat1 is crashed/shutdown for some reasonNow same user try to access the page. This time load balancer tries to redirect to tomcat1 but tomcat1 is down, so load-balancer picks one tomcat from the remaining tomcats. Here interestingly 2 cases are there. Case 1: Suppose Load balancer picks the tomcat3, then tomcat3 receives the request and tomcat3 itself holds the backup copy of the session. So tomcat3 makes that session as primary copy and tomcat3 picks any one tomcat as backup copy. So here remaining only one tomcat is there. So tomcat3 replicates the session to tomcat2. Now tomcat3 holds primary copy and tomcat2 holds the backup copy. Now tomcat3 gives the response to user. All further request is handled by tomcat3 (sticky session). case 2: Suppose Load balancer picks the tomcat2 then tomcat2 receives the request and tomcat2 don’t have the session. So tomcat2 session manager (Backup Manager) asks all other tomcat managers: ‘hi anybody hold the session for this user (based on session id [cookie])’. Actually tomcat3 has the backup session. So tomcat3 informs to tomcat2 and replicate the session to tomcat2. Now tomcat2 makes that session as primary copy and tomcat3 whose already have copy of session as remains as a backup copy of that session, so now tomcat2 hold primary copy and tomcat3 hold the backup copy. Now tomcat2 give the response to user. All further request is handled by tomcat2 (sticky session). So in either case our session is replicated and maintained by backup manager. This is good for large cluster. Check the video below Check my configuration in my github repo or get as ZIP file Screen Cast:  Reference: Tomcat Clustering Series Part 4 : Session Replication using Backup Manager from our JCG partner Rama Krishnan at the Ramki Java Blog blog. ...

Rule of 30 – When is a method, class or subsystem too big?

A question that constantly comes up from people that care about writing good code, is: what’s the right size for a method or function, or a class, or a package or any other chunk of code?   At some point any piece of code can be too big to understand properly – but how big is too big? It starts at the method or function level.             In Code Complete, Steve McConnell says that the theoretical best maximum limit for a method or function is the number of lines that can fit on one screen (i.e., that a developer can see at one time). He then goes on to reference studies from the 1980s and 1990s which found that the sweet spot for functions is somewhere between 65 lines and 200 lines: routines this size are cheaper to develop and have fewer errors per line of code. However, at some point beyond 200 lines you cross into a danger zone where code quality and understandability will fall apart: code that can’t be tested and can’t be changed safely. Eventually you end up with what Michael Feathers calls “runaway methods”: routines that are several hundreds or thousands of lines long and that are constantly being changed and that continuously get bigger and scarier. Patrick Duboy looks deeper into this analysis on method length, and points to a more modern study from 2002 that shows that code with shorter routines has fewer defects overall, which matches with most people’s intuition and experience. Smaller must be better Bob Martin takes the idea that “if small is good, then smaller must be better” to an extreme in Clean Code: “The first rule of functions is that they should be small. The second rule of functions is that they should be smaller than that. Functions should not be 100 lines long. Functions should hardly ever be 20 lines long.” Martin admits that “This is not an assertion that I can justify. I can’t produce any references to research that shows that very small functions are better.” So like many other rules or best practices in the software development community, this is a qualitative judgement made by someone based on their personal experience writing code – more of an aesthetic argument – or even an ethical one – than an empirical one. Style over substance. The same “small is better” guidance applies to classes, packages and subsystems – all of the building blocks of a system. In Code Complete, a study from 1996 found that classes with more routines had more defects. Like functions, according to Clean Code, classes should also be “smaller than small”. Some people recommend that 200 lines is a good limit for a class – not a method, or as few as 50-60 lines (in Ben Nadel’s Object Calisthenics exercise)and that a class should consist of “less than 10” or “not more than 20” methods. The famous C3 project – where Extreme Programming was born – had 12 methods per class on average. And there should be no more than 10 classes per package. PMD, a static analysis tool that helps to highlight problems in code structure and style, defines some default values for code size limits: 100 lines per method, 1000 lines per class, and 10 methods in a class. Checkstyle, a similar tool, suggests different limits: 50 lines in a method, 1500 lines in a class. Rule of 30 Looking for guidelines like this led me to the “Rule of 30” in Refactoring in Large Software Projects by Martin Lippert and Stephen Roock:   “If an element consists of more than 30 subelements, it is highly probable that there is a serious problem”:Methods should not have more than an average of 30 code lines (not counting line spaces and comments). A class should contain an average of less than 30 methods, resulting in up to 900 lines of code. A package shouldn’t contain more than 30 classes, thus comprising up to 27,000 code lines. Subsystems with more than 30 packages should be avoided. Such a subsystem would count up to 900 classes with up to 810,000 lines of code. A system with 30 subsystems would thus possess 27,000 classes and 24.3 million code lines.What does this look like? Take a biggish system of 1 million NCLOC. This should break down into:30,000+ methods 1,000+ classes 30+ packages Hopefully more than 1 subsystemHow many systems in the real world look like this, or close to this – especially big systems that have been around for a few years? Are these rules useful? How should you use them? Using code size as the basis for rules like this is simple: easy to see and understand. Too simple, many people would argue: a better indicator of when code is too big is cyclomatic complexity or some other measure of code quality. But some recent studies show that code size actually is a strong predictor of complexity and quality – that“complexity metrics are highly correlated with lines of code, and therefore the more complex metrics provide no further information that could not be measured simplify with lines of code”. In ‘Beyond Lines of Code: Do we Need more Complexity Metrics’ in Making Software, the authors go so far as to say that lines of code should be considered always as the ‘first and only metric’ for defect prediction, development and maintenance models. Recognizing that simple sizing rules are arbitrary, should you use them, and if so how? I like the idea of rough and easy-to-understand rules of thumb that you can keep in the back of your mind when writing code or looking at code and deciding whether it should be refactored. The real value of a guideline like the Rule of 30 is when you’re reviewing code and identifying risks and costs. But enforcing these rules in a heavy handed way on every piece of code as it is being written is foolish. You don’t want to stop when you’re about to write the 31st line in a method – it would slow down work to a crawl. And forcing everyone to break code up to fit arbitrary size limits will make the code worse, not better – the structure will be dominated by short-term decisions. As Jeff Langer points out in his chapter discussing Ken Beck’s four rules of Simple Design in Clean Code:“Our goal is to keep our overall system small while we are also keeping our functions and classes small. Remember however that this rule is the lowest priority of the four rules of Simple Design. So, although it’s important to keep class and function count low, it’s more important to have tests, eliminate duplication, and express yourself.”   Sometimes it will take more than 30 lines (or 20 or 5 or whatever the cut-off is) to get a coherent piece of work done. It’s more important to be careful in coming up with the right abstractions and algorithms and to write clean clear code – if a cut-off guideline on size helps to do that, use it. If it doesn’t, then don’t bother.   Reference: Rule of 30 – When is a method, class or subsystem too big? from our JCG partner Jim Bird at the Building Real Software blog. ...

Securing your Tomcat app with SSL and Spring Security

If you’ve seen my last blog, you’ll know that I listed ten things that you can do with Spring Security. However, before you start using Spring Security in earnest one of the first things you really must do is to ensure that your web app uses the right transport protocol, which in this case is HTTPS – after all there’s no point in having a secure web site if you’re going to broadcast your user’s passwords all over the internet in plain text. To setup SSL there are three basic steps…           Creating a Key Store The first thing you need is a private keystore containing a valid certificate and the simplest way to generate one of these is to use Java’s keytool utility located in the $JAVA_HOME/bin directory. keytool -genkey -alias MyKeyAlias -keyalg RSA -keystore /Users/Roger/tmp/roger.keystore In the above example,-alias is the unique identifier for your key. -keyalg is the algorithm used to generate the key. Most examples you find on the web usually cite ‘RSA’, but you could also use ‘DSA’ or ‘DES’ -keystore is an optional argument specifying the location of your key store file. If this argument is missing then the default location is your $HOME directory.RSA stands for Ron Rivest (also the creator of the RC4 algorithm), Adi Shamir and Leonard Adleman DSA stands for Digital Signature Algorithm DES stands for Data Encryption Standard For more information on keytool and its arguments take a look at this Informit article by Jon Svede When you run this program you’ll be asked a few questions: Roger$ keytool -genkey -alias MyKeyAlias -keyalg RSA -keystore /Users/Roger/tmp/roger.keystore Enter keystore password: Re-enter new password: What is your first and last name? [Unknown]: localhost What is the name of your organizational unit? [Unknown]: MyDepartmentName What is the name of your organization? [Unknown]: MyCompanyName What is the name of your City or Locality? [Unknown]: Stafford What is the name of your State or Province? [Unknown]: NA What is the two-letter country code for this unit? [Unknown]: UK Is CN=localhost, OU=MyDepartmentName, O=MyCompanyName, L=Stafford, ST=UK, C=UK correct? [no]: YEnter key password for(RETURN if same as keystore password): Most of the fields are self explanatory; however for the first and second name values, I generally use the machine name – in this case localhost. Updating the Tomcat Configuration The second step in securing your app is to ensure that your tomcat has an SSL connector. To do this you need to find tomcat’s server.xml configuration file, which is usually located in the 'conf' directory. Once you’ve got hold of this and if you’re using tomcat, then it’s a matter of uncommenting: <Connector port='8443' protocol='HTTP/1.1' SSLEnabled='true' maxThreads='150' scheme='https' secure='true' clientAuth='false' sslProtocol='TLS' /> …and making it look something like this: <Connector SSLEnabled='true' keystoreFile='/Users/Roger/tmp/roger.keystore' keystorePass='password' port='8443' scheme='https' secure='true' sslProtocol='TLS'/> Note that the password ‘password’ is in plain text, which isn’t very secure. There are ways around this, but that’s beyond the scope of this blog. If you’re using Spring’s tcServer, then you’ll find that it already has a SSL connector that’s configured something like this: <Connector SSLEnabled='true' acceptCount='100' connectionTimeout='20000' executor='tomcatThreadPool' keyAlias='tcserver' keystoreFile='${catalina.base}/conf/tcserver.keystore' keystorePass='changeme' maxKeepAliveRequests='15' port='${bio-ssl.https.port}' protocol='org.apache.coyote.http11.Http11Protocol' redirectPort='${bio-ssl.https.port}' scheme='https' secure='true'/> …in which case it’s just a matter of editing the various fields including keyAlias, keystoreFile and keystorePass. Configuring your App If you now start tomcat and run your web application, you’ll now find that it’s accessible using HTTPS. For example typing https://localhost:8443/my-app will work, but so will http://localhost:8080/my-app This means that you also need to do some jiggery-pokery on your app to ensure that it only responds to HTTPS and there are two approaches you can take. If you’re not using Spring Security, then you can simply add the following to yourweb.xml before the last web-app tag: <security-constraint> <web-resource-collection> <web-resource-name>my-secure-app</web-resource-name> <url-pattern>/*</url-pattern> </web-resource-collection> <user-data-constraint> <transport-guarantee>CONFIDENTIAL</transport-guarantee> </user-data-constraint> </security-constraint> If you are using Spring Security, then there are a few more steps to getting things going. Part of the general Spring Security setup is to add the following to your web.xml file. Firstly you need to add a Spring Security application context file to the contextConfigLocation context-param: <context-param> <param-name>contextConfigLocation</param-name> <param-value>/WEB-INF/spring/root-context.xml /WEB-INF/spring/appServlet/application-security.xml </param-value> </context-param> Secondly, you need to add the Spring Security filter and filter-mapping: <filter> <filter-name>springSecurityFilterChain</filter-name> <filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class> </filter> <filter-mapping> <filter-name>springSecurityFilterChain</filter-name> <url-pattern>/*</url-pattern> </filter-mapping> Lastly, you need to create, or edit, your application-security.xml as shown in the very minimalistic example below: <?xml version='1.0' encoding='UTF-8'?> <beans:beans xmlns='http://www.springframework.org/schema/security' xmlns:beans='http://www.springframework.org/schema/beans' xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance' xsi:schemaLocation='http://www.springframework.org/schema/beanshttp://www.springframework.org/schema/beans/spring-beans-3.0.xsdhttp://www.springframework.org/schema/securityhttp://www.springframework.org/schema/security/spring-security-3.1.xsd'><http auto-config='true' > <intercept-url pattern='/**' requires-channel='https' /> </http><authentication-manager> </authentication-manager></beans:beans> In the example above intercept-url element has been set up intercept all URLs and force them to use the https channel. The configuration details above may give the impression that it’s quicker to use the simple web.xml config change, but if you’re already using Spring Security, then it’s only a matter of adding a requires-channel attribute to your existing configuration. A sample app called tomcat-ssl demonstrating the above is available on git hub at: https://github.com/roghughe/captaindebug   Reference: Securing your Tomcat app with SSL and Spring Security from our JCG partner Roger Hughes at the Captain Debug’s Blog blog. ...

Introducing Spring Scala project

The Spring Scala project was first revealed to the world last October at SpringOne2GX. SpringSource now has revealed more information about it as well as how it can be used in Scala projects. Spring Scala project is here in order to bring the power of Spring framework in Scala. It combines the best of two worlds, Spring framework and Scala. Using a pure Java framework like Spring in Scala would feel awkward, so Spring Scala was introduced as a first-class citizen. ...

A Guide To Authenticating Users With Mozilla Persona

Having only twitter and facebook authentication so far, I decided to add Mozilla Persona to the list for my latest project (computoser, computer-generated music). Why?                I like trying new things Storing passwords is a tough process, and even though I know how to do it, and even have most of the code written in another project, I don’t think that I should contribute to the landscape of every site requiring password authentication Mozilla is an open foundation that has so far generated a lot of great products. Persona implements a BrowserID protocol that may be supported natively in browsers other than Firefox in the future (for now, you need to include a .js file) 3rd party authentication has been attempted many times, and is a great thing, but isn’t mainstream for a couple of reasons. Being a bit different, Persona might succeed in becoming more popular. This explanation by Mozilla makes senseSo, I started with the “Quick setup” guide. It is looks really easy. Way easier than OpenID or OAuth authentication – you don’t have to register anything anywhere, you don’t need 3rd party libraries for handling the verification on the server, and you don’t need to learn a complex authentication flow, because the flow is simple:user clicks on the signin button a pop-up appears if not authenticated with Persona, the user is prompted for registration if authenticated with Persona, the user is prompted for approval of the authentication to your site the popup closes and the page redirects/refreshes – the user is now signed inOf course, it is not that simple, but there are just a few things to mind that are not mentioned in the tutorial. So let’s follow the official tutorial step by step, and I’ll extend on each point (the server-side language used is Java, but it’s simple and you can do it in any language) 1. Including the .js file – simple. It is advisable to get the js file from the Mozilla server, rather than store it locally, because it is likely to change (in order to fix bugs, for example). It might be trickier if you merge your js files into one (for the sake of faster page loading), but probably your mechanism allows for loading remote js files. 2. The signin and signout buttons. This looks easy as well. Probably it’s a good idea to add the logout handler conditionally – only if the user has logged in with Persona (as opposed to other authentication methods that your site supports) 3. Listening to authentication events. Listening to events is suggested to be put on all pages (e.g. included in a header template). But there’s a problem here. If your user is already authenticated in Persona, but his session has expired on your site, the script will automatically login the user. And this would require a page reload in a couple of seconds after the page loads. And that’s not necessarily what you or the users want – in my case, for example, this may mean that the track they have just played is interrupted because of page refresh. It can be done with AJAX of course, but it is certainly confusing when something in the UI changes for no apparent reason. Below I’ll show a fix for that. Also, the logout listener might not be needed everywhere – as far as I understand it will automatically logout the user in case you have logged out of Persona. This might not be what you want – for example users might want to keep open tabs with some documents that are not accessible when logged out. 4. Verifying the assertion on the server. Here you might need a 3rd party library in order to invoke the verification endpoint and the parse the json result, but these are pretty standard libraries that you probably already have included. Now, how to solve the problem with automatic authentication? Declare a new variable – userRequestedAuthentication – that holds whether the authentication has been initiated explicitly by the user, or it has been automatic. In the signin button click handler set that variable to true. Here’s how the js code looks like (btw, I think it’s ok to put the code in document.ready(), rather than directly within the script tag. Assuming you later need some DOM resources in the handler methods, it would be good to have the page fully loaded. On the other hand, this may slow down the process a bit). Note that you can include an empty onlogin handler on all pages, and have the complete one only on the authentication page. But given that the login buttons are either on the homepage, or shown with a javascript modal window, it’s probably ok having it everywhere/on multiple pages. <script type='text/javascript'> var loggedInUser = ${context.user != null ? ''' + context.user.email + ''' : 'null'}; var userRequestedAuthentication = false; navigator.id.watch({ loggedInUser : loggedInUser, onlogin : function(assertion) { $.ajax({ type : 'POST', url : '${root}/persona/auth', data : {assertion : assertion, userRequestedAuthentication : userRequestedAuthentication}, success : function(data) { if (data != '') { window.location.href = '${root}' + data; } }, error : function(xhr, status, err) { alert('Authentication failure: ' + err); } }); }, onlogout : function() { window.locaiton.open('${root}/logout'); } }); </script> As you can see, the parameter is passed to the server-side code. What happens there? @RequestMapping('/persona/auth') @ResponseBody public String authenticateWithPersona(@RequestParam String assertion, @RequestParam boolean userRequestedAuthentication, HttpServletRequest request, Model model) throws IOException { if (context.getUser() != null) { return ''; } MultiValueMap<String, String> params = new LinkedMultiValueMap<>(); params.add('assertion', assertion); params.add('audience', request.getScheme() + '://' + request.getServerName() + ':' + (request.getServerPort() == 80 ? '' : request.getServerPort())); PersonaVerificationResponse response = restTemplate.postForObject('https://verifier.login.persona.org/verify', params, PersonaVerificationResponse.class); if (response.getStatus().equals('okay')) { User user = userService.getUserByEmail(response.getEmail()); if (user == null && userRequestedAuthentication) { return '/signup?email=' + response.getEmail(); } else if (user != null){ if (userRequestedAuthentication || user.isLoginAutomatically()) { context.setUser(user); return '/'; } else { return ''; } } else { return ''; //in case this is not a user-requested operation, do nothing } } else { logger.warn('Persona authentication failed due to reason: ' + response.getReason()); throw new IllegalStateException('Authentication failed'); } } The logic looks more convoluted than you’d like it to be, but let me explain:As you can see in the javascript code, an empty string means “do nothing”. If anything else is returned, the javascript opens that page. If not using spring-mvc, instead of returning a @ResponseBody String from the method, you would write that to the response output stream (or in php terms – echo it) First you check if there’s an already authenticated user in the system. If there is, do nothing. I’m not sure if there’s a scenario when Persona invokes “onlogin” on an already authenticated user, but if you are using other authentication options, Persona won’t know that your user has logged in with, say, twitter. Then you invoke the verification url and parse the result to JSON. I’ve used RestTemplate, but anything can be used – HttpClient, URLConnection. For the JSON parsing spring uses Jackson behind the scene. You just need to write a value-object that holds all the properties that Persona might return. So far I’ve only included: status, email and reason (jackson detail: ignoreUnknown=true, spring-mvc detail: you need FormHttpMessageConverter set to the RestTemplate). It is important that the “audience” parameter is exactly the domain the user is currently on. It makes a difference if it’s with www or not, so reconstruct that rather than hardcoding it or loading it from properties. Even if you redirect from www to no-www (or vice-versa), you should still dynamically obtain the url for the sake of testing – your test environments don’t have the same url as the production one. If Persona authentication is “okay”, then you try to locate a user with that email in your database. If there is no such user, and the authentication action has been triggered manually, then send the user to a signup page and supply the email as parameter (you can also set it in the http session, so that the user can’t modify it). The registration page then asks for other details – name, username, date of birth, or whatever you see fit (but keep that to minimum – ideally just the full name). If you only need the email address and nothing else, you can skip the registration page and force-register the user. After the registration is done, you login the user. Note that in case you have stored the email in session (i.e. the user cannot modify it from the registration page), you can skip the confirmation email – the email is already confirmed by Persona If there is a user with that email in your database, check if the action has been requested by the user or whether he has indicated (via a checkbox in the registration page) that he wants to be automatically logged in. This is a thing to consider – should the user be asked about that, or it should always be set to either true or false? I’ve added the checkbox. If login should occur, then set the user in the session and redirect to home (or the previous page, or whatever page is your ‘user home’)(“context” is a session-scoped bean. You can replace it with session.setAttribute('user', user)). If the authentication attempt was automatic, but the user doesn’t want that, do nothing. And the final “else” is for the case when the user doesn’t have an account on your site and an automatic authentication has been triggered – do nothing in that case, otherwise you’ll end up with endless redirects to the registration page in case of failed authentication be sure to log the reason – then you can check if everything works properly by looking at the logsA cool side-effect of using the email as unique identifier (make the database column unique) is that if you add Persona later to your site, users can login with it even though they have registered in a different way – e.g. facebook or regular registration. So they can set their password to something long and impossible to remember and continue logging in only with Persona. The details I omitted from the implementation are trivial: the signup page simply gathers fields and submits them to a /completeRegistration handler that stores the new user in the database. The /logout url simply clears the session (and clears cookies if you have stored any). By the way, if automatic signin is enabled, and Persona is your only authentication method, you may not need to store cookies for the sake of keeping the user logged in after the session expires. Overall, the implementation is still simple, even with the points I made. Persona looks great and I’d like to see it on more sites soon.   Reference: A Guide To Authenticating Users With Mozilla Persona from our JCG partner Bozhidar Bozhanov at the Bozho’s tech blog blog. ...

Comprehending the Mobile Development Landscape

There’s no shortage of mobile growth statistics, but here’s a few specific ones paint an overall picture of mobility:Roughly 87% of the worlds population has a mobile device Earlier this year, Facebook claimed an astounding 488 million mobile monthly active users Android’s user base is growing by 700,000 subscribers a day        These three facts clearly point out that mobility is a growing, global phenomenon, and that it’s drastically changing how people use the Internet. What’s more, from a technology standpoint, mobile is where the growth is! But the mobile landscape is as varied as it is big. Unlike a few short years ago, when doing mobile work implied J2ME on a Blackberry, mobile development now encompasses Android, iOS, HTML5, and even Windows Phone. That’s 4 distinct platforms with different development platforms and languages – and I haven’t even mentioned the myriad hybrid options available! The key to understanding the mobile landscape is an appreciation for the various developmental platforms – their strengths & weaknesses, speed of development, distribution, and, if you are looking at the consumer market, their payout. Android Android device distribution, as I pointed out earlier, is growing faster than other platforms, and the Android ecosystem has more than one app store: Google Play and Amazon’s store, just to name the two most popular ones. And by most accounts, Google Play has as many or more apps than Apple’s App Store (careful with this statistic though, see details below regarding payouts). The massive adoption of Android, however, has lead to fragmentation, which does present some significant challenges with respect to testing. In fact, the reality for most developers is that it is almost impossible to test an app on all combinations of device-OS version profiles in a cost effective manner (this is a growing service industry, by the way). On a positive note, Java, the native language of Android apps, is a fairly ubiquitous language – some estimates peg as many as 10 million active developers so there’s no shortage of able-bodied Java developers and their associated tools out there. Thus, with Android, you have a wide audience (both people with Android devices and developers to build apps) and multiple distribution channels. Yet, this large distribution of disparate devices does present some testing challenges; what’s more, it can be more difficult to make money on the Android platform compared to iOS, as you’ll see next. iOS iOS, the OS for iPhones and iPads, has a tight ecosystem and an avid user base, willing to spend money, ultimately translating into more money for developers. That is, even though there are far more Android devices globally than iOS ones, the iTunes App Store generates more money than Google Play, which means more money for developers of popular apps. In many respects, users of iOS devices are also more willing to pay a fee for an app as opposed to Android ones. The development ecosystem for iOS has a higher barrier to entry when compared to something like Java or JavaScript. OSX is a requirement and the cost alone here can be a barrier for a lot of developers; moreover, Objective-C can present some challenges for the faint of heart (manual memory management!). Yet, the tooling provided by Apple is almost universally lauded by the community at large (much like Microsoft’s VisualStudio) – XCode is a slick development tool. While there isn’t a lot of device fragmentation on iOS, developers do have to deal with OS fragmentation. That is, there are only a handful of Apple devices but quite a lot of different versions living in the field at any given time due to a lagging factor of user upgrades. The iOS platform certainly offers a direct path to revenue, provided you can build a stellar app; however, compared to Android, this is a closed community, which has the tendency to rub some portion of developmental community wrong. Given you can quickly embrace Objective-C and afford the requisite software, iOS is almost always the first platform app developers target. HTML5 HTML5 is truly universal and its apps are available on all platforms without any need to port them – JavaScript is as ubiquitous as Java; what’s more, HTML itself has almost no barrier to entry, making HTML5 and JavaScript a force to content with when it comes to finding talented developers and mass distribution. Cost isn’t even really part of the HTML5 equation too – tools and frameworks are free. Yet, HTML5 apps suffer from a distribution challenge – the major app stores do not carry these apps! Thus, in large part, as an HTML5 app developer, you are relying on a user to type in your URL into a browser. I for one, almost never type in a URL on my iPhone (while I will on my iPad). Lastly, HTML5 is no where near parity with respect to UX compared to native apps (and may never be). This, however, is only a disadvantage if you are building an app that requires a strong UX. There are plenty of great HTML5 apps out there! HTML5 offers an extremely low developmental barrier to entry and the widest support available – all smart devices have browsers (note, they aren’t all created equal!); however, because there isn’t a viable distribution channel, these apps have limited opportunity to make money. Windows Phone Windows is still unproven but could be an opportunity to get in early – first movers in Apple’s App Store without a doubt made far more money than if they had submitted the same apps today. In this case, you if want a truly native experience you’ll build apps on the .NET platform (presumably C#). Windows machines are far cheaper than OSX ones, so there is little financial barrier other than license fees for VisualStudio and a developer fee for the Windows Phone Marketplace. Indeed, it appears that Microsoft is modeling their app store and corresponding policies off of Apple’s – thus there is a tightly managed distribution channel, presenting an opportunity to reach a wide audience and earn their money. But, at this point, the wide audience has yet to develop. That’s 4, but there’s still more! As I alluded to in the beginning of this post, there are 4 primary platforms and myriad hybrid options, such as PhoneGap and Appcelerator, for example. These hybrid options have various advantages and disadvantages; however, the primary concerns one needs to think through are still speed of development, distribution, and payout. Before you embark on a mobile development effort, it pays to have the end in mind – that is, before you code, have tangible answers for app distribution, development effort, and potential payout as these points will help guide you through the mobile landscape.   Reference: Comprehending the Mobile Development Landscape from our JCG partner Andrew Glover at the The Disco Blog blog. ...

The new log4j 2.0

Before a while a new major version of the well known log4j logging framework was released. Since the first alpha version appeared 4 more releases happened!   You see, there is much more activity than with the predecessor log4j 1. And seriously, despite log4j 2s young age it is ways better.   This blog will give an overview on a few of the great features of Apache log4j 2.0.         Modern API In old days, people wrote things like this: if(logger.isDebugEnabled()) { logger.debug('Hi, ' + u.getA() + “ “ + u.getB()); } Many have complained about it: it is very unreadable. And if one would forget the surrounding if-clause a lot of unnecessary Strings would be the result. These days String creation is most likely optimized by modern the JVM, but should we rely on JVM optimizations? The log4j 2.0 team thought about things like that and improved the API. Now you can write the same like that: logger.debug('Hi, {} {}', u.getA(), u.getB()); The new and improved API supports placeholders with variable arguments, as other modern logging frameworks do. There is more API sweetness, like Markers and flow tracing: private Logger logger = LogManager.getLogger(MyApp.class.getName()); private static final Marker QUERY_MARKER = MarkerManager.getMarker('SQL'); ...public String doQuery(String table) { logger.entry(param); logger.debug(QUERY_MARKER, 'SELECT * FROM {}', table); return logger.exit(); } Markers let you identify specific log entries quickly. Flow Traces are methods which you can call at the start and the end of a method. In your log file you’ll would see a lot of new logging entries in trace level: your program flow is logged. Example on flow traces: 19:08:07.056 TRACE com.test.TestService 19 retrieveMessage - entry 19:08:07.060 TRACE com.test.TestService 46 getKey - entry Plugin Architecture log4j 2.0 supports a plugin architecture. Extending log4j 2 to your own needs has become dead-easy. You can build your extensions the namespace of your choice and just need to tell the framework where to look. <configuration … packages='de.grobmeier.examples.log4j2.plugins'> With the above configuration log4j 2 would look for plugins in the de.grobmeier.examples.log4j2.plugins package. If you have several namespaces, no problem. It is a comma separated list. An simple plugin looks like that: @Plugin(name = 'Sandbox', type = 'Core', elementType = 'appender') public class SandboxAppender extends AppenderBase {private SandboxAppender(String name, Filter filter) { super(name, filter, null); }public void append(LogEvent event) { System.out.println(event.getMessage().getFormattedMessage()); }@PluginFactory public static SandboxAppender createAppender( @PluginAttr('name') String name, @PluginElement('filters') Filter filter) { return new SandboxAppender(name, filter); } } The method with the annotation @PluginFactory seves as, well, factory. The two arguments of the factory are directly read from the configuration file. I achieved that behavior with using @PluginAttr and @PluginElement on my arguments. The rest is pretty trivial too. As I wrote an appender, I have chosen to extend AppenderBase. It forces me to implement the append() method which does the actual job. Besides Appenders, you can even write your own Logger or Filter. Just take a look at the docs. Powerful Configuration The new log4j 2 configuration has become easier. Don’t worry, if you could understand the old way to configure log4j, it will take you only a short time to learn the differences to the new way. It looks like that: <?xml version='1.0' encoding='UTF-8'?> <configuration status='OFF'> <appenders> <Console name='Console' target='SYSTEM_OUT'> <PatternLayout pattern='%d{HH:mm:ss.SSS} [%t] %-5level %logger{36} - %msg%n'/> </Console> </appenders> <loggers> <logger name='com.foo.Bar' level='trace' additivity='false'> <appender-ref ref='Console'/> </logger> <root level='error'> <appender-ref ref='Console'/> </root> </loggers> </configuration> Please look at the appenders section. You are able to use speaking tags, f.e. matching the name of the appender. No more class names. Well, this XML document cannot be validated of course. In case you urgently need XML validation that, you can still use a more strict xml format, which reminds on the old format: <appenders> <appender type='type' name='name'> <filter type='type' ... /> </appender> ... </appenders> But that’s not all. You could even reload your configuration automatically: <?xml version='1.0' encoding='UTF-8'?> <configuration monitorInterval='30'> ... </configuration> The monitoring interval is a value in seconds, minimum value is 5. It means, log4j 2 would reconfigure logging in case something has changed in your configuration. If set to zero or left out, no change detection will happen. The best: log4j 2.0 does not lose logging events at the time of reconfiguration, unlike many other frameworks. But there is even more exciting stuff. If you prefer JSON to XML, you are free to go with a JSON configuration: { 'configuration': { 'appenders': { 'Console': { 'name': 'STDOUT', 'PatternLayout': { 'pattern': '%m%n' } } }, 'loggers': { 'logger': { 'name': 'EventLogger', 'level': 'info', 'additivity': 'false', 'appender-ref': { 'ref': 'Routing' } }, 'root': { 'level': 'error', 'appender-ref': { 'ref': 'STDOUT' } } } } } The new configuration is really powerful and supports things like property substitution. Check them more in detail on the manual pages. log4j 2.0 is a team player: slf4j and friends Apache log4j 2.0 has many integrations. It works well if your application still runs with Commons Logging. Not only that, you can use it with slf4j. You can bridge your log4j 1.x app to use log4j 2 in the background. And another opportunity: log4j 2 supports Apache Flume. Flume is a distributed, reliable, and available service for efficiently collecting, aggregating, and moving large amounts of log data. Java 5 Concurrency From the docs: “log4j 2 takes advantage of Java 5 concurrency support and performs locking at the lowest level possible.”. Apache log4j 2.0 does address many deadlock issues which are still in log4j 1.x. If you suffer from log4j 1.x memory leaks, you should definitely look at log4j 2.0. Built at the Apache Software Foundation As log4j 1.x, log4j 2.x is an Apache Software Foundation project. It means it is licensed with the “Apache License 2.0? and thus will stay free. You can build your own product upon it, you are free to modify it to your own needs and you can redistribute it, even commercially. You don’t need to care on intellectual property. The Apache Software Foundation does care about that. If you would like to know more on licensing and how you can use log4j 2.0 for your own project, I refer you to the Licensing FAQ.   Reference: The new log4j 2.0 from our JCG partner Christian Grobmeier at the PHP und Java Entwickler blog. ...
Java Code Geeks and all content copyright © 2010-2014, Exelixis Media Ltd | Terms of Use | Privacy Policy | Contact
All trademarks and registered trademarks appearing on Java Code Geeks are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries.
Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.
Do you want to know how to develop your skillset and become a ...
Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you two of our best selling eBooks for FREE!

Get ready to Rock!
You can download the complementary eBooks using the links below: